CP/M

home *** CD-ROM | disk | FTP | other *** search

/ CP/M / CPM_CDROM.iso / cpm / zcpr33 / tcj / tcj27.mag < prev next >

Wrap

Text File | 1994-07-13 | 30.8 KB | 549 lines

The ZSIG Column #3, January 10, 1987 This file was prepared with the PMATE text editor. All of these header lines should be stripped away for use with other word processors. I have used control-n in several places in the text to toggle underlining on and off. ZL14_10I R76;I8 The ZSIG Column Jay Sage 1435 Centre Street Newton Centre, MA 02159 When I first offered to write a regular column for The Computerì Journal, I wondered if I would have enough material for a column every twoì months. Instead, the problem has become one of finding the time to set downì all the thoughts I have. For this issue I had planned to cover four topics,ì there is only room for three of them. They are: 1) corrections of someì errors in the last column (and an excuse for more discussion of flow controlì in Z System); 2) a brief rundown on the files in the first officiallyì released ZSIG diskette; and 3) a discussion of command-line-buildingì programs in ZCPR3, including aliases and shells. Corrections ----------- There were two errors that I noticed in the last column. One was aì minor one that was Art Carlson's fault; the other was more serious and wasì my doing. First for the easy one. Art was kind enough to add informationì at the end of the column on how to contact me, but the Z-Node he listedì there was not mine. It was the Lillipute Z-Node in Chicago, which is theì official ZSIG remote access system (its phone number is 312-649-1730). ì Messages left for me there will get to me, but I will get them sooner ifì they are left for me on my own node in Boston at 617-965-7259. I can alsoì be reached on my voice phone at 617-965-3552 (please don't mix the twoì numbers up, especially if you are calling in the middle of the night!). ì Finding me at home is not always easy, and your chances will be best if youì call between 10pm and just after 11pm (Boston time, of course). Now for the error I made. In the discussion of the flow controlì package (FCP) and the transient IF.COM, I said that one can force use of theì transient program by including a DU: or DIR: prefix or even just a colon inì front of the 'IF'. This is not true. I thought I had verified theì statement experimentally, but my experiment was flawed, and the conclusionì incorrect. A colon does force the command processor to skip commands in theì resident command package (RCP) and in the CPR itself and to proceed with aì search for a COM file, but all the FCP resident commands are intercepted noì matter whether there is a colon or not. There is a very good reason forì this. The FCP commands must be executed even when the current IF state isì false. This is especially clear for commands like ELSE, which reverses theì current IF state, and FI, which terminates the current IF state. Transientsì ELSE.COM and FI.COM could not do this. After a bit of thought you canì probably see that this is true for all the flow control commands. I have long been searching for ways to give the user control overì whether IF processing is performed by resident or transient code. Oneì solution that I introduced some time ago was adding alternative names forì condition options in IF.COM so that one could force the more powerfulì transient processing to be performed even when the function was supported byì the resident FCP. The trick was to use condition names in IF.COM that wereì different from the names of the same functions in the FCP module. ì Specifically, I changed the first letters to 'X' (for example XXIST forì EXIST and XNPUT for INPUT). Frank Gaude' in the Echelon Z-News has reportedì examples in which the transient program is given a name other than IF.COMì (such as IF13.COM). Then the command "IF INPUT" gives resident processingì and "IF13 INPUT" transient processing. This will work correctly for firstì level IF processing but will not work in general. Neither of these solutions was really satisfactory. A proper solution,ì I felt, would operate both correctly and automatically. I have now writtenì a new FCP package (FCP10) that is presently under test by ZSIG programì committee members and should be ready for release with the next ZSIGì diskette. It handles both resident and transient code. It can examine theì command line to see if there was a colon before the IF. In that case, theì FCP ignores its internal condition options and invokes the transient IF.COMì immediately. If no colon was present, the FCP first looks to see if theì condition option is included in the resident code. If not, it automaticallyì invokes the transient IF processor. The user need not be concerned withì which options are resident in the FCP. The script "IF NULL $1" in an aliasì will take advantage of fast resident processing if the NULL option isì supported in the resident code or will automatically invoke transientì processing if not. When one wants to be sure to get transient processing,ì one simply uses the colon as in ":IF EXIST FILE1,FILE2". To go along with FCP10 there is a new transient IF processor, COMIF10. ì It supports dozens of additional condition tests. One is AMBIG, which testsì a file specification for ambiguity (question marks or asterisks). Registerì (numeric) and string (alphabetic) comparisons are now extended to the fullì range of tests: equal, not equal, greater, less, greater than or equal, andì less than or equal. I plan to add file attribute testing (SYS, DIR, RO, RW,ì ARC, WP) and testing for the presence of Plu*Perfect Software's excitingì Backgrounder task-swapping program. The new FCP/COMIF combination also adds an important new twist inì transient processing. They have the option of loading the transient codeì not at 100H, as has been done until now, but high in memory, where it willì not overwrite a user program that is loaded at 100H. In this way the GOì command can be used to rerun the last user program after flow controlì processing no matter whether resident or transient flow processing was used. ì Thus the user need not concern himself with how the flow processing wasì performed. While I was at it, I also added two new commands to the FCP module. ì One, IFQ (if query), is designed to help users -- advanced as well as noviceì -- learn how flow control works (or, perhaps, is not working as oneì intends). It displays on the screen the complete flow state of the systemì -- the true/false status of all IF levels. The second is ZIF (zero ifs). ì It is like XIF (end all ifs) except for one thing. XIF clears all IF statesì only if the current IF state is true; if the current IF state is false, XIFì is flushed (ignored) just like any other command. ZIF, on the other hand,ì clears all IF states no matter what. I'm sure that everyone who hasì experimented with flow control has at one time or another gotten himself soì messed up that nothing seemed to work. The only way out, short ofì rebooting, was to type a string of FI's until things started working again. ì ZIF is a quick way to reinitialize the flow control system (and it takesì very little code in the FCP). ZSIG Diskette #1 ---------------- Now that I have atoned, I hope, for my sin in the last issue, I willì turn to the first new subject, the inaugural ZSIG diskette. Let me remindì you that this diskette and a number of others put out by NAOG/ZSIG (NAOG =ì North American One-Eighty Group, the group formed to support the SB180ì computer and other computers using the Hitachi HD64180 microprocessor) canì be ordered from NAOG/ZSIG (P.O. Box 2781, Warminster, PA 18974). Iì encourage all of you to join ZSIG ($15). You'll get a nice newletter with Zì System tips and details on all the NAOG/ZSIG diskettes. Here is a listing of the files in ZSIG diskette #1. Z-RIP.LBR VERROR17.LBR VCED18.LBR ZCRCK.LBR ZFINDU.LBR ZLDIR.LBR ZTXTTOWS.LBR ZWC.LBR PPIP14.LBR UF.LBR LDSK20.LBR W20.LBR The first three programs are by Paul Pomerleau. Paul is a speed freak and,ì like many of us, found the process of installing Z programs with Z3INS (theì standard installation utility) tedious and slow. So Paul wrote Z-RIP, givenì that name because it rips through an entire disk of files at incredibleì speed, automatically identifying the ZCPR programs and installing them. Theì new autoinstall versions of ZCPR3 may make Z-RIP (not to mention Z3INS)ì obsolete, but it is great for those running standard ZCPR. VERROR is Paul'sì video error handler. It provides a screen display of the entire commandì line in which an error was detected and allows the user to edit it freely,ì moving about using WordStar-like commands. VCED is Paul's Video Commandì EDitor, a video history shell. With VCED running as a shell, the userì always has full command-line editing. In addition, past commands can beì recalled, searched for, edited, and run. As if that were not enough, itì doubles as a video error handler as well! Paul astutely noted theì functional similarity between correcting old commands with errors andì entering new commands -- so he combined the two functions in a singleì program. The next group of five programs comprises Z versions of common CP/Mì utilities. Most of these were created by the prolific program fixer andì NAOG/ZSIG chief, Bruce Morgen. The main feature that makes these programsì ZCPR3-compatible is their ability to accept named directory (DIR:)ì references as well as drive/user (DU:) references. For programmers andì aspiring programmers reading this, you should know that the code to do thisì in ZCPR3 is actually much simpler than the CP/M code needed just toì recognize the DU: form. This is because the ZCPR3 command processor alreadyì does all the work for the first two arguments on the command line (includingì translating named directory references into drive/user values). Unlikeì CP/M, ZCPR3 saves not only the drive but also the user number in the defaultì file control blocks at 5CH and 6CH. A ZCPR3 program need only fetch theì values from the appropriate locations. The hardest part of making theseì ZCPR3 versions of the CP/M programs was stripping out the complex andì lengthy parsers required to accept DU: syntax in CP/M. (So much for theì myth of ZCPR3 complexity! Programming in ZCPR3 is often, as in thisì example, simpler than programming in standard CP/M.) The third group of programs includes two more ZCPR3 versions of CP/Mì programs. They are listed separately only because they do not have namesì with Z's in front! Here is a quick listing of the functions of all seven ofì these converted programs: ZCRCK computes cyclic redundancy check codes for files using both common CRC polynomials ZFINDU searches for text strings in files, including files that are squeezed ZLDIR displays a directory of the files in a library ZTXTTOWS converts standard text files to WordStar files ZWC counts the number of words in a text file PPIP14 copies files (as does PIP) but with nicer interface and fast -- I renamed it to COPY and use it all the time UF Steven Greenberg's ultrafast file unsqueezer The last two programs are original creations for the Z System. LDSK,ì by Wilson Bent with modifications by Earl Boone, solves a longstandingì problem that owners of floppy-disk-based computers had with namedì directories. With hard disks, there is an unchanging association betweenì directory names and drive/user values, but with floppies the associationì changes every time the diskette is changed. Wilson devised this niftyì scheme for automatically loading the named directory register (NDR) with theì names associated with user areas on a floppy diskette. To give a user areaì a name, one simply puts a (usually zero-length) file in that user area withì a name of the form "-NAME". When LDSK is run (specifying the drive to beì loaded), it scans the disk for files of this type, strips the leadingì hyphen, and creates an entry in the NDR associating the name with that userì number on the drive. As I wrote in the last column, I still have a lot ofì floppy-only systems, and I love LDSK. Haven't you at times wished that you could take some program that onlyì works on a single file and magically make it work with an ambiguous fileì reference. Well, Steve Cohen did, so out of his programmer's hat he pulledì the wildcard shell 'W' to do it. It just shows again that the only realì limitation with the Z System is one's imagination! Here are some examplesì of how 'W' can be used. Bob Freed wrote a quick little program called PCPCKì that checks a file for proper transmission over Telenet's PC-Pursuit packetì network (certain character sequences cause problems). The trouble is, PCPCKì only works on a single file, and it is no fun to run it manually on everyì file one is about to send somewhere. But along comes 'W' and all I have toì do is enter "W PCPCK *.*" and away we go. Or suppose you are just lazy andì hate typing exact names of files. Just put a 'W' in front of the commandì and enter a wildcard file name that specifies the file you want. That's allì there is to it. I have 'W' implemented in an alias on my Z-Node system soì that users can type a file without having to enter the exact name. If aì user can't remember (or doesn't really care) whether the file isì AUTOINST.FIX or AUTOINST.FQZ or AUTOINST.FZX, all he has to enter is "TYPEì AUTO*.*" and the file (whatever it is called) will appear on the screen. Command Line Generators ----------------------- Many people call me about problems they are having getting an alias orì VFILER script to work correctly. Often the problem turns out to be aì misunderstanding of what command line generators are really doing. I willì try to shed a little more light on that subject here. First a little philosophy. There are many features in the Z Systemì about which one might well at first just shrug one's shoulders and say, "Soì what!" The flow control system discussed earlier is one such feature, andì multiple commands on a line might be another. After all, how many of usì actually think far enough ahead to enter more than one command at a timeì anyway? Well, the answer lies in the interplay of all the features in Zì System and in the ways they allow things to be accomplished automatically. Aliases The multiple command capability of Z System, for example, is importantì not so much because it allows the user to enter a whole sequence of commandsì manually but rather because it allows other programs to do so automatically. ì The simple, standalone 'alias' created with the original ALIAS.COM or one ofì the more sophisticated alias programs like TALIAS, BALIAS, or VALIAS is aì good example. Let's see how such an alias might be used. Suppose we areì working on a new program with a source file called MYPROG.Z80. Our standardì sequence of operations is to edit the source with a command like "EDITì MYPROG.Z80" and then to assemble it with a command like "ASM MYPROG.AAZ" andì then to load it with a command like "MLOAD MYPROG". We can speed things upì and reduce the amount of typing (and the number of typos!) by creating anì alias which we might give the name DO.COM. We would create it, with VALIASì for example, with the following script (command line form): EDIT MYPROG.Z80;ASM MYPROG.AAZ;MLOAD MYPROG Now when we want to start a new cycle, we just enter the easily spelledì command "DO". The rest is automatic. But how does this alias actually work? When you enter the commandì "DO", the operating system loads DO.COM into memory and starts running it. ì DO contains within its file the script line put there by VALIAS.COM (forì example) when the alias was created. DO.COM has code to determine where theì Z System multiple command line is located in memory (this information comesì from what is called the environment descriptor, whose address is installedì in a standard location near the beginning of all true Z System programs). ì Next DO.COM takes its command script, appends any other commands in theì multiple command line that come after the "DO" command, and then writes theì result back to the command line buffer. When it then returns to Z System,ì the ZCPR3 command processor, as usual, looks at the command line buffer toì see if there are more jobs listed there for it to do. Since DO.COM hasì filled the command line buffer with the script, ZCPR3 responds just as if weì had typed the long command line script instead of the simple "DO". Now let's see how flow control can be used with alias scripts. Oneì problem with the command sequence in our example arises when the assemblerì reports an error. In that case there is no sense going through the MLOADì operation. Assemblers like ZAS from Echelon and Z80ASM from SLR Systems setì a flag in the Z System to show whether or not they encountered any fatalì errors during the assembly, and the flow control command "IF ERROR" can testì the state of that flag. We can improve our script as follows: EDIT MYPROG.Z80;ZAS MYPROG;IF ~ERROR;MLOAD MYPROG;FI In this script the MLOAD command will only be executed if the program errorì flag has not been set by ZAS (the tilde '~' has the meaning 'not'). Typingì all those flow control commands manually would be more trouble than enteringì single commands at a time, but with an alias we are still typing only twoì letters: "DO". So far so good. But what happens when we want to start work on anotherì program, say NEWPROG? Do we have to create a new alias, such as DONEW? Theì answer is that the alias program actually does much more than just copy aì command script as is into the multiple command line buffer. It is capableì of making parameter expansions, the simpler examples of which are like theì parameter expansions that occur with the CP/M SUBMIT program. We can storeì the alias script as EDIT $1.Z80;ZAS $1;IF ~ERROR;MLOAD $1;FI The '$1' is a symbol representing the first token after the command on theì command line that invoked the alias program. Thus when we enter the commandì "DO MYPROG" we get the first script we discussed, but when we enter "DOì NEWPROG" we get a command line for working on NEWPROG instead. A singleì alias thus becomes very flexible. There are quite a number of parameterì forms that can be processed by aliases, and I refer you to Rick Conn'sì "ZCPR3, The Manual" and various HELP files for more detailed information. Now let's try something a little trickier. Sometimes we have alreadyì edited a file and just want to assemble and load it (if there is no error inì assembling, of course). So we create an alias called AL (for assemble/link) ZAS $1;IF ~ERROR;MLOAD $1;FI [I am using ZAS in these examples rather than the SLR Z80ASM, which Iì prefer, because the SLR assemblers can produce a COM file directly in oneì pass and do not need MLOAD or the flow control error checking. Thus they doì not serve the purposes of my example here.] Now what do you think willì happen if we define our DO alias as follows: EDIT $1.Z80;AL $1 Do you think that will work? One alias inside another? Well, it willì indeed! Aliases can be nested. How deeply? Without any limit! Before weì explain why this is, let's look at an even more fascinating example. When Iì sit down to work on a program, I typically go through one edit/assembleì cycle after another (just don't seem to be able to get it right the firstì time). So I make my DO alias have the following script: EDIT $1.Z80;AL $1;DO $1 This alias actually invokes itself!! When one cycle is finished, it justì goes back for more. Now let's look at what goes on in the system after weì enter the command "DO MYPROG". The DO alias expands its script and writesì the following command line into the multiple command line buffer: EDIT MYPROG.Z80;AL MYPROG;DO MYPROG. After the editing is finished, AL runs, expands its script, and fills theì command line buffer with the following command line: ZAS MYPROG;IF ~ERROR;MLOAD MYPROG;FI;DO MYPROG Note that the alias always appends to its own script any other commands inì the command line after itself (hence the DO MYPROG on the end). Now ZASì runs, and, depending on whether there were errors or not, MLOAD may run. ì Finally ZCPR3 gets to the DO command, and we are right back where weì started. The whole process is repeated (and repeated again). In fact, theì only trouble with this alias is that there is no way out! You can't stop! Well, we all hope we will get the program right eventually, so weì really would like to be able to get out of the alias. Flow control can helpì us again. Consider the script EDIT $1.Z80;AL $1;ECHO EDIT AGAIN?;IF INPUT;DO $1;FI Now, before reinvoking DO, the alias asks us if we want to edit the fileì again. If we give a negative answer (anything other than carriage return,ì space bar, 'Y' for yes, or 'T' for true), the loop is broken. If we answerì affirmatively with a quick tap of the return key, we start again. Veryì quick and easy. There is one subtle problem, however. If you go through the exerciseì of expanding the alias scripts, you will see that with each cycle an extraì 'FI' builds up at the end of the command line. Even more careful analysisì will show that with each cycle we go one IF level deeper as well. One ofì two problems will eventually spoil our plan. Either the command line willì get so long that it won't fit in the command line buffer, or we will run outì of IF levels (eight is the maximum). What can we do about these problems? The FCP has the XIF command precisely for this reason. If we put anì XIF command at the beginning of the script, we will reset the IF system toì level 0 every time we reenter the loop. Then the limit will be overflow ofì the command line. When this happened to me, I invented a special type ofì alias -- the recursive alias -- and incorporated it into my VALIAS programì (as far as I know only VALIAS and ARUNZ support this alias type). It worksì the same as a regular alias except for one thing -- it does not append toì the script expansion any commands that were pending in the command lineì buffer; it just throws them away. Thus in the above example all the FIsì would be discarded when DO was invoked again, and the pileup would beì avoided. When an alias is created with VALIAS, one can select either aì normal alias or a recursive alias. But note that no other command can everì follow a recursive alias on a multiple command line. Recursive aliasesì should be used only in special cases like the one described here. Shells Aliases are not the only command line generators. Most shells alsoì generate command lines for the user. In some cases (VCED, described above,ì and MENU) this is their main purpose; in other cases it is secondaryì (VFILER). Before we examine the way they generate command lines, let's lookì at the way shells operate in the Z System. The essential purpose of shells is to create just the kind of recursiveì command situation we were just developing with our alias example. But theyì achieve that function in a very different way. A shell has a kind ofì schizophrenic personality as a result of being invoked in two significantlyì different circumstances. One circumstance is when it is invoked directly orì indirectly (e.g., from an alias) as the result of a user command. In thisì case, the shell has one basic purpose -- to perpetuate its own existence asì a command. It does this by entering its name as a command into a specialì buffer (area in memory) in the Z System called the shell stack. Having doneì that, it can then return control to the operating system. (The smarterì shells generally do something a little more sophisticated at this point, butì the principle is correct as I have described it.) Now we come to the unique role of shells in the Z System. The CP/Mì command processor gets commands from only two possible sources: 1) from aì submit file, if one exists, or 2) from the user. The Z System gets commandsì from at least four sources and in the following order of priority (ignoringì the tricky role of ZEX): 1) from the multiple command line buffer; 2) from aì submit file; 3) from the shell stack; and 4) if all else fails, from theì user. Observe that so long as the shell stack has a command in it, theì command processor will never turn to the user for input! That is why oneì can regard the shell as taking over the command processor function. Whileì the shell is running, it becomes the source of commands for the system. How does the shell do this? By expressing its second and more dramaticì personality. Another special buffer in the Z System, the message buffer,ì contains a flag byte that is set by the ZCPR3 command processor to indicateì whether a program has been invoked as a user command or as a shell (or as anì error handler). We have already discussed the simple goal of the shell inì the former case. In the latter case the shell actually carries out its realì function in life. Let's consider the MENU shell as an example. When the MENU.COM is loaded as a shell, it displays a screen of commandì choices to the user. Each single-character choice is associated with aì command line script, much like the alias script. When the user strikes aì key, MENU looks up the script associated with that character, expands theì script (substituting parameters), and puts the resulting command into theì multiple command line buffer. It then returns control to the ZCPR3 commandì processor. ZCPR3 executes the commands in the command buffer one afterì another until they have all been performed. Then, when the command bufferì is empty again, ZCPR3 looks in the shell stack, finds the MENU commandì there, and runs MENU again. This process continues until a special user keyì is entered (control-c in the case of MENU) that signals the shell that itì should remove itself from the shell stack. Then things return to the stateì they were in before the shell was invoked initially by the user. ì Shells, by the way, can be nested (the usual shell stack is four entriesì deep), so when one shell removes itself from the shell stack, control mayì still not return to the user. Another shell, whose role was superceded byì the most recent shell, may now come back into control. With the MENU.COM the displayed menu of choices and the scriptsì associated with the choices are both included in a text file that is read inì by the program. This makes it very easy for the user to create and modifyì the display and the scripts. Considering again our program developmentì example, we might create a menu screen with the following display: S. Select name of program E. Edit program source code A. Assemble program to HEX file L. Load program to COM file R. Run program F. Full cycle (edit, assemble, load) These choices might be associated with the following command scripts: S setfile 1 "Enter name (only) of program to work on: " E edit $n1.Z80 A zas $n1 L mload $n1 R $n1 F edit $n1.z80;zas $n1;if ~er;mload $n1;fi There are two interesting new parameters illustrated in these scripts. ì One is the $N1 parameter. As part of the Z System environment buffer, fourì system file names are defined. MENU can read these four file names and putì into scripts the complete filename ($Fn), the name only ($Nn), or the typeì only ($Tn), where 'n' is 1, 2, 3, or 4. The 'S' selection sets the firstì system file name using the program SETFILE, and the others then use it. The 'S' selection illustrates the other new script parameter --ì prompted user input. When the script for choice 'S' is being expanded, theì text between quotes will be displayed as a prompt to the user, and one lineì of user input will be substituted into the command line in place of theì prompt. It is with prompted input that many users get confused and makeì mistakes. Suppose you want to be clever and helpful by displaying aì directory of existing programs to jog the user's memory before asking forì his choice. You might think of using the script S dir *.z80;setfile 1 "Enter program name: " This will not have the effect intended! One must not forget that the userì is prompted for input by the shell at the time the script is expanded, notì at the time when the command line is executed. In this example the userì will be prompted for his choice before the directory is displayed. Thus,ì the directory display is useless. To achieve the result intended above you must combine scripts. You canì create an ARUNZ alias called SETNAME with the following script (ARUNZì supports prompted input): SETNAME setfile 1 "Enter name of file: " The MENU script would then be S dir *.z80;arunz setname When the MENU script is expanded, the command becomes "DIR *.Z80;ARUNZì SETNAME", and this command is then run. It is not until ARUNZ SETNAME isì executed that ARUNZ prompts the user for the name of the file. At thisì point the directory of files with type Z80 has already been displayed on theì screen. There is obviously much more that could be said about the command lineì generators in ZCPR3. The discussion here has been only an overview, but Iì hope that it will inspire you to take a fresh look at and to experiment withì aliases and shells of all kinds: the standalone aliases generated by ALIAS,ì VALIAS, TALIAS, or BALIAS; the text-file-based alias generator ARUNZ withì its ALIAS.CMD file; the menu- or macro-type shells MENU, VMENU, FMANAGER,ì VFILER, and ZFILER; and the command-line history shells HSH and VCED. Plans for Next Time ------------------- As I said at the beginning of the article, I had planned to cover,ì along with all the subjects above, techniques for customizing the Z-COMì self-installing version of Z System. But there just isn't the time orì space. So I will have to leave that for the next issue. Let me just sayì one thing here. If you do not already have Z System running on yourì computer and have held back on buying Z-COM from Echelon because you thoughtì it would not offer you the flexibility of a custom installation, hold off noì longer. Buy Z-COM! Start the exhilarating process of discovering Z Systemì now. By the time my discussion of Z-COM hacking is complete, you will knowì how to get just as much flexibility with Z-COM as with a manually installedì version. It is much more fun to start with something that is working and toì improve it than it is to spend many frustrating weeks trying to get anì initial manual version working. I want to close with my usual invitation and encouragement -- pleaseì write and call with your comments and suggestions of all kinds.