Date   : Wed, 30 Sep 1987 13:35:23 EDT
From   : <SAGE@LL.ARPA>
Subject: Flow Control Without an FCP

     Bruce McIntosh sent the following message to me directly.  I am posting
my answer to the entire list since there may be others who are interested in
this subject.
 
Date:         Wed, 30 Sep 87 04:01 EDT
From:         Bruce H. McIntosh <Z8BHM%SCFVM.BITNET@WISCVM.WISC.EDU>
Subject:      Flow control without FCP ?
To:           Jay Sage <sage@ll.arpa>
 
Jay,
     Is it possible to have flow control processing without having an FCP
installed?  I'm considering eliminating FCPs and RCPs in favor of the jump
in TPA space it'll get me.  Inspiration for this move comes from your bit
on minimal-space Zsystems in TCJ.
                                            Bruce
 
       -------------------------------------------------------------
 
                        FLOW CONTROL WITHOUT AN FCP
 
     While one should always hesitate to say that something is impossible,
that is my reaction to your question about flow control without an FCP.
 
     Flow control is implemented in the command processor through the FCP
module (see the "ZCPR33 User Guide" discussion of how commands are resolved
in the CCP).  Those commands have to be detected and executed regardless of
current flow state and, therefore, have to be in a separate module.
 
     Frank Gaude' gave many examples in Z-News of invoking IF13.COM manually
from the command line (it had to be given a name different from IF so that
it would not be intercepted by the FCP).  This does not achieve proper flow
control and can cause problems.  It only works correctly when it appears
during a true flow state; during a false flow state it is flushed and fails
to kick the flow state up to the next higher level.  If there were no FCP in
the system, you could run IF.COM and could write an ELSE.COM, FI.COM, etc.
to do the right things to the current flow state.  But all programs would
run no matter whether the current flow state were true or false.  The system
would know the flow state but would not act on it.
 
     Flow control could be achieved in this situation by modifying
individual programs to respond to the flow state.  For example, a linker
could be made to check the flow bytes in the message buffer and perform the
linkage only if the current flow state flag is ture.  Under a false flow
state it would simply return without doing anything.
 
     To avoid having to modify every program, one could write a utility that
would test the current flow state.  If it is false, the rest of the command
line would be flushed and the flow state reinitialized.  This program
(called FLOWTEST in the example below) could then be run before a standard
linker in the following sort of command:
 
          ZAS PROG;IF ~ERROR;FLOWTEST;ZLINK etc.
 
ZAS would set the program error flag; IF would set the flow state based on
the error flag, setting it true if the error flag is clear.  FLOWTEST would
run in either case, since there is no FCP, but would flush the rest of the
command line (ZLINK etc.) if the flow state is false.  The normal operation
of complex command lines and ZEX scripts would be seriously affected by this
kind of scheme (there is no such thing as ELSE or FI), however, and I would
not at all recommend it.  But it may help you think of something better.
 
     What I would do instead of eliminating the FCP is to write the smallest
possible FCP, one that would recognize the commands intended for it and feed
them to a COM file for processing.  I have recently been thinking in
background mode of a scheme to get the command processor to perform the
loading of the file so that I don't have to include that code in the FCP, as
is done now.  I think there should be a way to write a fully functional FCP
that takes up only one record (128 bytes).  If the TPA can't stand that much
of a loss, then one might as well just drop back into CP/M.
 
     Here is the germ of a scheme I have in mind to achieve this.  Have the
resident FCP create a phony true flow state one level higher and insert
'FLOW ' in front of the command in the command line.  Then, for example, the
command 'ELSE' would turn into 'FLOW ELSE'.  Because of the phony true flow
state, the command processor would load and run FLOW.  FLOW would undo the
phony true state and perform the 'else' function, adjusting the flow message
bytes accordingly.  FLOW, being a transient, could be as complex and
sophisticated as one wishes.  Other flow commands (IF, FI, XIF, ZIF, OR,
AND, and others that might be invented) would be handled similarly.  The
question is how to fool the CCP into running the command.
 
     Since this whole discussion arose from your desire to maximize TPA, I
would like to add that my next column in The Computer Journal is going to
describe (among other things) a new ZCOM (NZCOM) that does automatically all
of the things (and more) that I described in the previous two columns.  It
can switch to a minimum Z-System for a single command or group of commands
and then switch back to a normal system.  Using SUBMIT it can even switch
back to CP/M, execute some commands, and then automatically return to Z-
System!  I think this will really solve the TPA dilemma with Z-System.  I
plan to get rid of all my manually installed Z-Systems, bring up maximum-TPA
CP/M systems with stripped-down BIOSs, and then use NZCOM to implement Z-
System.