Date   : Sun, 05 Jan 1986 23:19:59-MST
From   : Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Z-System Problems

                   IMMEDIATE Z-SYSTEM PROBLEMS
                         by Richard Conn

                IF PROBLEM UNDER ZCPR 3.0/3.1/3.2
     As  many of you are aware,  there are various versions of my 
original  FCP floating around (version 1.4 is the latest I  heard 
of).   Somewhere along the way,  Jay Sage decided to reverse  the 
state of the program error flag.  This is a fundamental change to 
the definition in the ZCPR3 Environment descriptor,  and, as many 
of  you  who understand Z-System fundamentals are aware,  such  a 
change can have a ripple-effect over the entire Z-System.  If you 
are going to reverse the program error flag (like Jay did),  then 
you have to CHANGE EVERY PROGRAM WHICH USES THIS FLAG.
     As  you can guess,  I'm rather busy at this time  (like  all 
times,  it  seems),  and I really don't have the time now to scan 
every  program (over 70 programs with ZCPR3,  plus  DISCAT,  plus 
TERM III,  plus ...).   Hence,  Jay's action stands as-is for the 
time  being.   You will find some programs responding to  the  IF 
ERROR flag one way, others another, until I release ZCPR 3.3.  At 
that  time,  because Jay's approach DOES provide more flexibility 
to the system,  the IF ERROR flag will indicate no error if 0 and 
an  error  if  not 0;  if not 0,  the  specific  value  may  have 
significance in further identification of the error.


                        ZCPR3 CPR PROBLEM
     Jay  has  also taken it upon himself to play with the  ZCPR3 
CPR  and  modify  the  Environment  Descriptor  in  other   ways, 
particularly  by  making use of areas I had originally set  aside 
for user (rather than system) definition.   This impacts any user 
programs  which were freely using the user-defined  SYSENV  areas 
(which,  in particular,  impacts some of my plans with TERM III).  
Hence,  be  warned that if you are using Jay's ZCPR3 CPR,  it  is 
possible  that you may find things crashing down if some  program 
comes  in  and  modifies something in the  user-defined  area  of 
SYSENV.

                          GENERAL NOTE
     Both  of these problems reflect the consequences  of  making 
changes to the base of the Z-System itself.   Unlike conventional 
CP/M,  the  Z-System  is integrated with its programs to a  great 
extent.  Any change to a definition in the Environment Descriptor 
has the potential of impacting EVERY PROGRAM, forcing a change to 
be  required to EVERY PROGRAM.   If I had not already begun  work 
and plans on ZCPR 3.3,  I would really have been disturbed by the 
disruption  of the Z-System caused by Jay's actions.   As it  is, 
the creation of ZCPR 3.3 will naturally impact SYSENV,  and I had 
already  planned on making the required changes to EVERY  PROGRAM 
and DOCUMENTING the nature of the change (so that others  writing 
Z-System programs know what to look for).   Now that I am working 
full-time on the Z-System, I plan to keep an eye out particularly 
for  such disruptions in the future and stop them before they  go 
too far (if necessary).