SAGE@LL.ARPA (09/30/87)
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.