home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.barnyard.co.uk
/
2015.02.ftp.barnyard.co.uk.tar
/
ftp.barnyard.co.uk
/
cpm
/
walnut-creek-CDROM
/
CPM
/
CCP
/
EZCPR.LBR
/
EZINST.HQP
/
ezinst.hlp
Wrap
Text File
|
2000-06-30
|
37KB
|
766 lines
EZCPR Installation Guide
PROGRAMS NEEDED FOR EZCPR OPERATION
MSW Utilities Used with EZCPR
Replacements for Built-In CP/M Commands
Use of ZCPR2 Utilities with EZCPR
BASIC EZCPR INSTALLATION
Configuration Check
EZCPR Initiation
GUARD Protection
WIZ Control of Privileged Operations
STANDARD OPERATING PRACTICES
Using the CMDRUN Feature
EZCPR Configuration Options
Error Recovery
SUBMIT Procedures
:EZINST 1.00 EZCPR INSTALLATION GUIDE dh: 84-06-28
========================
This guide provides technical information for installers of EZCPR, a
replacement for the standard CP/M* Console Command Processor (CCP).
EZINST.HLP explains the first-time installation of EZCPR and also provides
reference material of use during trouble-shooting, re-installation, and
election of custom configuration options.
EZINST.HLP 1.00 is based on specific details of EZCPR #1.09. Although
the general concepts will apply for other versions, variations in detail
should be expected.
Copyright 1984, Dennis E. Hamilton
This guide may be freely reproduced for private use so long as all
notices of authorship and copyright are preserved. All other rights are
reserved. Send enquiries to The MSW Company, P.O. Box 229, Penfield NY
14526-0229.
* CP/M is a trademark of Digital Research, Inc.
: PROGRAMS NEEDED FOR BASIC EZCPR OPERATION
=========================================
EZCPR will usually operate by itself, "right out of the box." This
can be used for trial demonstration and limited exploration, but is
insufficient for permanent installation and heavy usage. To make a
complete basic installation of EZCPR, the following programs should be
obtained and used:
* MSW utilities EZCPR.COM (the "installer" of EZCPR), SYSTEM.COM,
GUARD.COM, and WIZ.COM.
* Favorite utilities to be operated in place of the no-longer built-in
operations DIR, TYPE, REN, and ERA. (SAVE is the only built-in CP/M
operation retained in EZCPR. USER is accomplished another way.)
* ZCPR2-specific utilities configured for non-ZCPR2 operation in order
to also be used under EZCPR.
* Versions of utilities and applications that can operate in the pres-
ence of User-Interface Guardian protection. (Some programs which add
appendages to the CP/M BDOS are hostile to presence of other ones.)
: MSW UTILITIES USED WITH EZCPR
-----------------------------
For complete, basic operation of EZCPR, the following programs are
required:
SYSTEM.COM #2.14 or later: EZCPR #1.09 is implemented to the same
level of automatic configuration as SYSTEM #2.15.
GUARD.COM #1.04 or later: Earlier versions of GUARD.COM will not
operate in the presence of EZCPR.
WIZ.COM #1.03 or later: Earlier versions of WIZ.COM have the same
problems as early GUARD.COM versions.
EZCPR.COM #1.09 or later: This is the program used to "turn on" EZCPR
as the system User-Interface Command Processor.
Generally, MSW utility versions dated since 84-06-21 are always preferable
under EZCPR. To verify the version of any MSW-convention program, use the
command form
a>program -# OR a>program -?
: REPLACEMENTS FOR BUILT-IN CP/M COMMANDS
---------------------------------------
The standard CP/M CCP implements a small number of services directly
in the command processor. EZCPR preserves only SAVE, the one operation
that cannot be easily obtained with a CP/M transient ".COMmand" program.
The following operations have no built-in counterpart with EZCPR:
* DIR for showing the presence of files in a particular directory
* TYPE for presenting the content of text files on the CP/M CON:
* ERA for removing files from a disk directory
* REN for changing the name of a disk file
If you require any of these operations while your CP/M system is under
EZCPR control, you will need programs that provide such functions in the
form that you prefer. Depending on requirements for operational security,
you can also omit or protect selected operations, such as ERA and REN,
which can be dangerous when used incorrectly. (EZCPR's SAVE operation is
disabled using WIZ.) [next: How to install new "built-ins".]
Installing Built-In Operation Replacements
------------------------------------------
The easiest way to install counterparts to built-in operations is to
copy substitute .COM programs onto disk A under user 0 (disk A0: in
EZCPR/ZCPR2 parlance). Disk A0: is "home base" for EZCPR operations -- the
basic version will always look in A0: for programs that can't be found
elsewhere. This means that you only need one mounted copy of each opera-
tion program, since it can be found on A0: when not present on the disk
which is currently "logged-in," whether D0: or P15:.
In the past, introduction of custom counterparts to built-in opera-
tions required use of different names (such as XDIR, TYPEL, RENAME, and
ERZ). You now have the option to use the original built-in names for the
substitutions, making your system easier to use by operators accustomed to
the basic CP/M facilities. Of course, you can still substitute versions
that show off your computer's capabilities, too.
As you become more accustomed to the configuration capabilities of
EZCPR, you can experiment with making different built-ins available to
different operators, or as part of different applications, with or without
added security checks. [next: Typical Built-In Selections]
Typical Built-In Operation Substitutions
----------------------------------------
On the first system to use EZCPR, Orcan Conclave RCP/M #0, the
following substitutions are installed on A0: for local operation:
* DIR.COM is SD #2.4 as configured by John Stetson for use of the
Heathkit H19 terminal's VT52-compatible display features.
* TYPE.COM is TYPEL #2.3, a program developed by Sigi Kluger and
designed to directly display text files, SQueezed files, and either
kind of file from within a .LBR file collection.
* ERA and REN are omitted. Instead, two utilities are used in their
place: Richard Conn's VFILER and Durant Software's SimpliFile, both
configured for H19. (Simplifile is used to maintain a descriptive
catalog on the disk.) Other popular substitutions include SWEEP,
DISK7, and the ZCPR2 "extended" commands for ERASE and RENAME.
There is ample variety in both public-domain and proprietary form.
Many substitutes use advanced equipment features to great advantage, also.
And built-in operations of packages like WordStar and MDM7 still operate.
: USE OF ZCPR2 UTILITIES WITH EZCPR
---------------------------------
Being based on the highly-popular ZCPR2 System of Richard Conn, EZCPR
supports similar concepts and facilities. But EZCPR does not require any
modifications to the underlying CP/M system: You don't have to install
EZCPR, you can simply turn it on.
In addition, EZCPR operates on most CP/M 2.2 systems, whether equipped
with 8080A, Z80, 8085, or Z800 processors. EZCPR is also designed to
provide consistent operation under CP/M 1.4, CP/M 3.0 (CP/M+), and some
configurations of MP/M and CP/M-86 as well.
To achieve this flexibility, ZCPR2 installation practices are aban-
doned. ZCPR2 features are supported, BUT NOT THE SAME WAY. In particular,
* The multiple-command buffer (of 128+ bytes) is internal to EZCPR.
* EZCPR keeps an internal WIZ flag in preference to external WHEEL byte.
* An 8-entry disk-search path is carried internal to EZCPR itself.
* A 16-entry directory-name table is also kept resident in EZCPR.
* Input-Output redirection is a special case of MSW RSX Portal usage.
[next: Impact on ZCPR2 Utilities]
Impact on ZCPR2 Utilities
-------------------------
Certain features of the ZCPR2 System are supported by setup of dedi-
cated data areas at locations where their content is preserved from one
application to the next, from one CP/M restart (warm boot) to the next. It
is allocation and initialization of these areas that requires special CP/M
modifications for full ZCPR2 operation on most systems.
If you have ZCPR2 fully installed on your system, your ZCPR2 utilities
will already be configured to locate the custom data areas. BUT EZCPR WILL
NEITHER NOTICE NOR USE THEM. And, although EZCPR has equivalent system
data areas within its own storage locations, ZCPR2 UTILITIES CANNOT LOCATE
OR USE THEM.
[WARNING: Do NOT attempt to locate the equivalent areas within a
loaded copy of EZCPR and install the addresses of those locations in your
ZCPR2 utilities. There are format incompatibilities, and the locations
tend to move around within EZCPR. In addition, EZCPR does not have to load
in the same place every time it is initiated.]
[next: Making ZCPR2 Utilities Work]
Making ZCPR2 Utilities Work
---------------------------
The smoothest way to operate ZCPR2 utilities in an EZCPR regime,
WHETHER OR NOT ZCPR2 IS ALSO INSTALLED, is by eliminating those
configuration options which depend on the use of ZCPR2-external data.
Using the ZCPR2 GENINS program, review the features of the desired
utility and make sure that the following features are not used or are
disabled in the utility:
* EXTERNAL SEARCH PATH: Set not available (set internal path instead)
* EXTERNAL COMMAND BUFFER: Set not available (address of 0000H)
* DEFAULT CHARACTER: "$" should always be used in path lists
* RESIDENT DIRECTORY-NAME TABLE: Set address to 0000H and try to keep
ZCPR2 use under 16 entries for future EZCPR compatibility.
* Any other feature (such as WHEEL byte address) which requires a fixed
address in the system. Also check whether a Z80 is required.
As a compromise, you can implement some of these dedicated locations
for sharing between ZCPR2 utilities, but without EZCPR participation.
[next: Bridging the Gap from EZCPR to ZCPR2]
Bridging the Gap from EZCPR to ZCPR2
------------------------------------
As can be seen, not all ZCPR2 options are supported the same way by
EZCPR, so those who have already installed ZCPR2 may prefer to use EZCPR
just for special occasions.
New users are encouraged to install EZCPR first as a way of quickly
gaining experience with the basic procedures, switching to ZCPR2 (or ZCPR3)
only after deciding on those configuration details which make the labors of
permanent installation worthwhile. EZCPR can still be used after ZCPR2 is
installed, providing additional operating flexibility when needed.
In addition, the autoconfiguration capabilities of SYSTEM, GUARD, WIZ,
and other MSW-convention utilities can be adopted in upgrades to ZCPR2
utilities. Such all-purpose utilities first check for the presence of
EZCPR and use those facilities in that case. If it is confirmed that ZCPR2
is operating instead, then ZCPR2 parameters are honored. With care, it is
possible to develop utilities which operate indifferently under both ZCPR2
and EZCPR, automatically adjusting without any operational discontinuity
whatsoever. [See the EZCPR technical guide for more information on inter-
faces and techniques available to utilities.]
: BASIC EZCPR INSTALLATION
========================
If you simply place EZCPR.COM on a disk and perform the operation
a>EZCPR UP
EZCPR will attempt to load itself and operate in place of the CCP, if any,
that is already active. An EZCPR initiated in this way, if able to load,
will persist in the system until the next CP/M Restart (Warm Boot). At
that time, standard CCP (or ZCPR1 or ZCPR2) operation is restored as part
of the reloading/cleanup of CP/M.
But the full capability of EZCPR and allied MSW-convention utilities
is not tapped until EZCPR is "locked in" the system by use of GUARD.
Following GUARD protection of EZCPR (and any other dynamic CP/M extensions
that are used), special privileges can be turned off and on using WIZ.
Although independent of EZCPR, the MSW SYSTEM utility is indispensable
for reviewing your current CP/M configuration. EZCPR and other utilities
will see your configuration exactly the same way that SYSTEM does. Use
SYSTEM for a report of how your configuration is arranged at the moment.
: SYSTEM CONFIGURATION CHECK
--------------------------
To operate SYSTEM #2.15 (also distributed under the name SYS215),
place it on your system disk, rename it as necessary and try the simple
operation
a>SYSTEM -?
The utility should identify itself and provide a short summary of its
usage options.
If, instead, you encounter a CCBROKE error message, it is possible
that the program is damaged. Obtain a replacement for the program and try
again. If you encounter a CCMEMRY failure, CCBROKE persists when the
program works fine on other computers, or SYSTEM obviously misbehaves in
other ways, DO NOT ATTEMPT TO OPERATE EZCPR.
SYSTEM is the advance scout for MSW-convention utilities. It does not
interfere in any way with normal system operation. In addition, SYSTEM is
designed to balk rather than proceed in uncertain or dangerous settings.
[next: A Good SYSTEM Report]
A Good SYSTEM Report
--------------------
If SYSTEM -? operates without difficulty, it is safe to try normal
operation of the program. Operate SYSTEM without any command options:
A>system
SYSTEM> Heath/Zenith H89/Z90 Computer Configuration
Z80 Processor
CP/M 2.2.03 Operating System S/N 196-3-0-34029
E600 BIOS .03 base location
D800 BDOS 2.2 base location
D000 CCP base location
Single-Segment Memory Model
D000 current TPA ceiling
CFF8 Stack Point
1DFC Heap Point
0100 TPA base location
52992-byte TPA capacity
45564-byte free zone
[next: What to Look for from SYSTEM]
What to Look for from SYSTEM
----------------------------
The amount of detail that SYSTEM reports varies for each CP/M instal-
lation. It is unimportant whether SYSTEM can describe every detail of your
configuration. IT IS IMPORTANT THAT SYSTEM REPORT THE TRUTH, whether or
not all of the truth. That is, nothing in the SYSTEM report should
contradict sure knowledge that you have about your computer system.
For purposes of EZCPR operation, the most important information is
about the available Console Command Processor:
. . .
D800 BDOS 2.2 base location
===> D000 CCP base location
Single-Segment Memory Model
. . .
If SYSTEM reports a base location for CCP (ZCPR1, ZCPR2, or EZCPR),
EZCPR.COM will use that same location for loading of a fresh copy of EZCPR.
(If CCP is non-resident instead, as with CP/M 3.0, EZCPR loads just below
the TPA ceiling.) [next: When EZCPR Can't Load]
When EZCPR Can't Load
---------------------
Whenever SYSTEM reports "CCP Not Located", the presumption is that
there is probably a CCP present in the system, but it can't be found by the
techniques incorporated in SYSTEM.COM. There are usually two
possibilities:
* The SYSTEM program was itself not called from the command level, so it
is unable to satisfactorily locate the CCP in charge of operation.
This can happen, for example, if you were to <R>un SYSTEM from
WordStar or any other package that retains control of the system while
operating external programs and overlays. (Reaching SYSTEM by
chaining or from a SUBMIT file is all right, since the CCP is respon-
sible for actual loading and operation of the program in those cases.)
* Because of a non-standard appendage to CP/M, whether BYE, DDT, or
other special-purpose attachment, SYSTEM is unable to locate the true
BDOS base location. This has interfered with SYSTEM's attempt to
confirm the presence of a CCP in front of BDOS or any BDOS RSX.
In the absence of positively-confirmed CCP status, EZCPR won't load.
: EZCPR INITIATION
----------------
When a CCP is positively confirmed to be either present or non-
resident, according to SYSTEM, EZCPR.COM can load a new EZCPR copy. Use
an EZCPR UP command:
A>ezcpr up
EZCPR> #1.09 84-06-26 User Command Interface
CP-MIG edition by Dennis E. Hamilton
D000 = active CCP to be replaced by the new one.
2048 bytes needed, with 2048 allowed.
D000-D7FF RELOCATED CODE BLOCK
D65E-D7FD data segment
D11E-D65B instruction segment
D002-D11B data segment
EZCPR #1.09 84-06-26
A0> [next: The EZCPR Signature]
The EZCPR Signature
-------------------
You can always tell that EZCPR or ZCPR is present by appearance of
user numbers in the CP/M command-input prompt. ("A0>" is EZCPR's home-base
prompt for operator input. Form "A0<" is used when showing command lines
taken from an active SUBMIT file.)
In addition, every EZCPR version identifies itself when asked for
version information via built-in command "#":
A0>#
EZCPR #1.09 84-06-26
A0>B3: __ You don't have to stay on A0, of course.
B3>15: __move up to user 15; # __ Who'd you say you were?
EZCPR #1.09 84-06-26
B15>
[more ...]
And it is always a good idea to confirm presence of EZCPR with SYSTEM:
B15>system
SYSTEM> Heath/Zenith H89/Z90 Computer Configuration
Z80 Processor
CP/M 2.2.03 Operating System S/N 196-3-0-34029
E600 BIOS .03 base location
D800 BDOS 2.2 base location
====> D000 EZCPR base location
Single-Segment Memory Model
D000 Current TPA ceiling
CFF8 Stack Point
1DFC Heap Point
0100 TPA base location
52992-byte TPA capacity
45564-byte free zone
B15>
[NOTE: With CP/M 1.4 you are confined to operation under user number
0, but all other features of EZCPR are fully available.]
: GUARD PROTECTION OF EZCPR
-------------------------
When any CCP, including EZCPR, is riding at the Current TPA ceiling,
it is vulnerable to over-writing by applications and to reloading from disk
on the next CP/M restart (either warm or cold boot). For example, under
unmodified CP/M 2.2:
B15>^C
B>
and CP/M's attention is still at user level 15, although it is not
so indicated.
B>user 0
B>a:
A>ezcpr up
will restore a fresh copy of EZCPR in this case.
The MSW-convention program GUARD is designed specifically to provide a
barrier above which the CCP is protected from erasure and reloading. [more]
A0>guard up
GUARD> #1.04 84-06-23 USER-ENVIRONMENT PROTECTION
CP-MIG edition by Dennis E. Hamilton
User Interface is via EZCPR at D000.
There is no protection.
PREPARING ENVIRONMENT PROTECTOR:
D000 = active CCP to be kept above the RSX.
CFF4 = SP preserved to insure a way out.
226 bytes are needed for the RSX itself.
CF12-CFF3 RELOCATED CODE BLOCK
CFDD-CFF1 data segment
CF3B-CFDA instruction segment
CF20-CF38 data segment
CF14-CF1D instruction segment
D806 = the new second RSX.
CF18 = the new first RSX.
[more ...]
The accomplishment of GUARD is easily confirmed with SYSTEM. The
significant results involve configuration of memory and the resulting size
of TPA:
A0>system
SYSTEM> . . .
D800 BDOS 2.2 base location
D000 EZCPR base location
===> CF18 Guardian RSX entry
===> Environment protected via CF18
Single-Segment Memory Model
CF18 current TPA ceiling
. . .
===> 52760-byte TPA capacity
45332-byte free zone
The presence of environment protectors is so significant for operation
that SYSTEM singles out the location of the particular protector. The most
significant result is that CP/M restart no longer involves reloading of the
CCP. Continuity of EZCPR operation is secured.
[more ...]
With a Guardian overseeing the retention of EZCPR,
A0>^C
A0>
will reset the system, but CP/M is not reloaded. (Side benefit: When GUARD
is UP, the disk in drive A must have a valid directory, but it does not
need a copy of the CP/M system. You can limit the contents of drive A to
just those programs needed for your application.)
Guardian RSX provide other information as part of their operation:
A0>guard check
GUARD> #1.04 84-06-23 USER-ENVIRONMENT PROTECTION
CP-MIG edition by Dennis E. Hamilton
User Interface is via EZCPR at D000.
Protection is via Guardian RSX at CF18.
1 restart has occured since guard raised.
504 BDOS service requests.
A0: is the interface's base directory.
: WIZ CONTROL OF PRIVILEGED OPERATIONS
------------------------------------
Even though EZCPR is up, and under GUARD protection, it is possible to
replace the current copy by performing another EZCPR UP operation. In
addition, GUARD protection is dropped simply by using the GUARD DROP
option. (This is what you do, short of rebooting, in order to restart CP/M
completely.)
In order to insure the system against accidental removal of protec-
tion, the WIZ utility can be used to remove authorization of all operations
that can change your operating-software configuration:
A0>wiz out
WIZ> Modified #1.03 84-06-23 WIZARD STATUS
CP-MIG edition by Dennis E. Hamilton
** The WIZ is OUT **
A0> __ WIZ shows as a "Modified" version because a password
A0> __ has been added by GENINS for WIZ IN authentification.
[more ...]
Once WIZ is OUT, all programs that require WIZ privileges in order to
perform major configuration adjustments will refuse to comply:
A0>guard drop
GUARD> #1.04 84-06-23 USER-ENVIRONMENT PROTECTION
CP-MIG edition by Dennis E. Hamilton
+++ WIZCHEK: WIZ authority needed to try that.
+++ CCABEND: Attempting System Restart.
A0>
Similarly, EZCPR will not replace an operating EZCPR when WIZ is OUT:
A0>ezcpr up
EZCPR> #1.09 84-06-26 User Command Interface
CP-MIG edition by Dennis E. Hamilton
+++ WIZCHEK: You can't do that here.
+++ CCABEND: Attempting System Restart.
A0> b1: [more ...]
There is an intimate connection between EZCPR and the privilege
authorization capabilities of the WIZ utility. (In fact, there is a rudi-
mentary, build-in WIZ operation that EZCPR uses to notice when WIZ is being
requested. If the program is not found, EZCPR sets WIZ OUT on its own.)
EZCPR monitors WIZ status so the one remaining built-in operation,
SAVE, can be controlled. When WIZ is OUT, EZCPR will FORGET that SAVE is
built-in, treating SAVE commands just like any other program request:
B1>save 0 c3: __ trying to create an empty blank-name file on C3:
+++ SAVE !?
A0>
illustrating the response of EZCPR to an unrecognizable command (no program
found). With WIZ IN, the SAVE request would be handled the same as for
CP/M 2.2, except that a destination user can be specified along with a
destination drive. (And if the SAVE were successful, EZCPR attention would
remain in B1: instead of dropping back to A0: in response to the error
condition.)
: STANDARD OPERATING PRACTICES
============================
When operated without modification, EZCPR automatically sets up with
the following arrangement:
* Maximum Drive Specifiable: "D" under CP/M 1.4, "P" in all other cases
* Maximum User Specifiable: 0 under CP/M 1.4, 31 in all other cases
(User numbers above 15 may not be used for the default base however.)
* WIZ authority is required for EZCPR UP, but no password is needed.
* Initial disk search path: $$ -> A0 (any specified or default base is
searched first, then A0: is checked if the program is still not
found.)
* Initial (latent) command line: "#"
* Initial directory-name table: no entries
* Initial WIZ status: IN
: USING THE CMDRUN FEATURE
------------------------
When searching for the program to be executed, each location on the
active search path is examined for a program of the specified name. For
example, with search path $$ -> A0 and command
B7>D:HELP A31:EZCPR
EZCPR first attempts to use D7:HELP.COM. If examination of D7: is
unsuccessful, the next check will be for A0:HELP.COM. When that fails, the
request is aborted and EZCPR bails-out to A0:
B7>D:HELP A31:EZCPR
+++ D:HELP !?
A0>
That description is literally true when there is no program CMDRUN.COM
anywhere on the search path. When there is a CMDRUN.COM program anywhere
along the path, THAT PROGRAM PREVENTS CONTINUATION OF SEARCH PAST THAT
POINT. The CMDRUN.COM program will be executed instead. [more ...]
The actual rule for CMDRUN usage is to the effect that EZCPR makes two
command-program searches at the same time, one for
B7>D:HELP A31:EZCPR
and also B7>D:CMDRUN D:HELP A31:EZCPR
The request that is satisfied first will be used, and command search
fails only if neither program is found. (Ties are always won by the non-
CMDRUN original form.)
This rule is quite different than the ones available under ZCPR2.
However, you can get equivalent operation by only placing CMDRUN programs
at the ends of your search paths, not at any mid- or starting-point disks.
This EZCPR CMDRUN rule supports placement of barriers to program
"visibility" along the search path. Having ONLY a CMDRUN at A0 can also be
used to force expanded error recovery following a bail-out.
Typically, programs such as MBASIC, SUBMIT, HELP, and .LBR LRUNZ are
installed as CMDRUN processors. (EZCPR also makes it possible for such a
program to determine what it was named and the disk it was found on.)
: EZCPR CONFIGURATION OPTIONS
---------------------------
The program EZCPR.COM can have its basic configuration options changed
by using the ZCPR2 GENINS program. Of those options which are available
for selection in accordance with the GENINS structure, only the following
have any effect:
* Internal Path Data, if provided, will be used to set the initial path
in EZCPR
* Max Disk and Max User values can be used to restrict the explicit
specification of disk locations in command-line file references
* The Privileged User Password can be used to require a password, IN
ADDITION TO WIZ authority, before EZCPR UP will operate.
* Any non-null WHEEL Byte Location will be consulted to determine if WIZ
is IN when EZCPR is not already operating. This lets WHEEL be used to
prevent unauthorized replacement of ZCPR2 by EZCPR.
[next: Internal Path Processing]
Internal Path Processing
------------------------
If no Internal Path is specified in the GENINS parameters, the default
path of $$ -> A0 will be used.
If an Internal Path is present, it will be incorporated in the EZCPR
Disk Search Path whenever EZCPR is loaded from this copy of the program.
Even though there are other restrictions placed on the drive letters
and user numbers which can be used, those restrictions DO NOT APPLY TO THE
INTERNAL SEARCH PATH. That is, the search path can lead to directories
that operators are not allowed to specify directly.
The above special capability, along with the CMDRUN rule, can be used
to obtain quite flexible location of programs on behalf of particular
applications. In addition, the EZCPR search procedure works the same
whether or not a disk directory is explicitly named in the command or not.
The base directory (used as $$) is either the one specified or, if none is
given, is the directory currently logged as the CP/M default. Resolution
of disk search-path locations proceeds from that point.
[next: Limiting the Available Disks]
Limiting Available Disks
------------------------
Every time that EZCPR is initiated, it sets its internal limitations
on Max Disk and Max User based on the version of CP/M that is running.
(Recall that CP/M 1.4 systems are restricted to disks A-D and user 0.)
You can further restrict the explicit specification of disks by
providing even smaller values in the GENINS Max Disk and Max User values.
The only reason to lower the Max User value is to provide secure
directories that can only be reached by search path and special programs.
It can also be valuable to lower the Max Disk value to include only
those logical drives actually present on your system. This will help
prevent BDOS Select Error reports and can be especially helpful when
operating an RCP/M system.
Note that the limitation on Max Disk and Max User does not apply to
search paths and it is possible for a program to log EZCPR onto a directory
that can't be specifically named in a command line! The Max values apply
to the conversion of ALL file references parsed by EZCPR, though.
: ERROR RECOVERY
--------------
EZCPR is designed to support automatic and unattended operation of
CP/M systems. It is important, in such settings, to have failures always
take the system into a predictable state so that recovery measures can
operate in a reliable way.
For EZCPR, any failure which requires conclusion that assumptions
about the state of the system no longer hold will also cause SYSTEM BAIL
OUT. Bail out consists of the following steps:
* The disk system is reset.
* If there is an A0:$$$.SUB file, it is erased.
* Any commands stacked in the multiple-command buffer are discarded.
* The base default disk is set to A0, and operation continues from A0>.
[next: Errors Which Force Bail Out]
Errors Which Force Bail Out
---------------------------
EZCPR keeps track of when it is running and when it is idle. EZCPR is
idle only when
* EZCPR has just been loaded and not done anything yet
* EZCPR is waiting for input from the operator CON: interface
* A transient program has been successfully loaded and control
transferred to it. EZCPR remains idle until the transient requests
bail out or EZCPR regains control through CP/M reset or application-
program return.
In all other cases, EZCPR is considered to be running. When EZCPR is
running, bail out is provoked by
* Any disk error in the attempted processing of an active SUBMIT file.
* Any error in the form of file-reference expressions actually used by
EZCPR. (References passed to applications are not taken so seriously.)
* Any CP/M restart of an already-running EZCPR (e.g., disk error)
* Failure to find and successfully load the requested program
* Failure to successfully record a file during authorized SAVE operation
* Any input at CON: noticed before starting the current command
: SUBMIT PROCEDURES
-----------------
EZCPR has special rules that apply to the design and operation of
SUBMIT procedures:
* Any time that EZCPR performs a disk reset and an A0:$$$.SUB file is
present, that file immediately becomes the source of further command
lines. (It must be in standard SUBMIT output format.)
* Until A0:$$$.SUB is consumed, or there is an intervening bailout,
additional command lines are always taken from the .SUB file,
REGARDLESS OF WHERE THE DEFAULT LOGGED DISK MIGHT BE. That is, A0 is
used for active submit commands even when the base disk is not A0:
* When no A0:$$$.SUB is active, EZCPR will not notice the creation of a
new one until the next disk reset. (This is usually taken care of by
the SUBMIT processor's exit via CP/M reset request.)
* Remember that command lines in SUBMIT procedures may not exceed 125
characters, and there may not be more than 128 lines in a $$$.SUB.
:
:
: EZINST.HLP 1.00 created by Dennis E. Hamilton on 1984 June 28.
important, in such