  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 