CP/M

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

/ CP/M / CPM_CDROM.iso / jsage / znode3 / tcj / tcj37.wsa < prev next >

Wrap

Text File | 1994-09-02 | 36.6 KB | 652 lines

The main topic for this column will be the second installment of theì discussion of ZFILER, the Z-System filer shell (Yes, I'm going to fool youì all by actually doing as I promised last time!). As usual, there areì several other items I would like to discuss briefly first. The originalì list included the following: (1) a Z-Node update; (2) a hint on patchingì those hardware-specific utilities provided by computer manufacturers thatì don't work right under NZ-COM so that they will work; (3) my views on theì appropriate way for Z-System programs to be coded for compatibility withì various stages of evolution of ZCPR3; (4) an update on making PRL filesì without a PRL-capable linker; and (5) a suggestion to programmers for how toì deal with bad-directory-specification errors under Z-System. As usual,ì including all this material put TCJ's ink supply at risk, and I had roomì only for the first two items. Now that I have finished the article and amì coming back to hone this section, I also have to add that I did not haveì room to complete the ZFILER discussion; the topics of customization andì configuration will have to wait until another time. Z-Node Update As I mentioned in a previous issue, I have been hard at work trying toì survey the Z-Node remote access systems (RASs) and to revitalize theì network. It was Echelon's creation of that network that first got meì started as a Z-System activist, and I continue to feel that it is the singleì most important source of mutual support for users and developers of the Z¡ System. My list of currently active nodes is reproduced in Listing 1. I haveì added three new columns to Echelon's original format. The one on the farì right shows the last date on which operation of the system was verified. ì The column to its left indicates for nodes accessible by PC-Pursuit the codeì for the outdial city and the highest bit rate supported for that city. At this point I have at least attempted (usually several times) to callì every North American Z-Node on Echelon's old list. Where contact was made,ì I requested that the sysops register with Z Systems Associates, and the onesì who have done so are designated by an "R" in the leftmost column. For thisì listing I have retained a number of systems that seemed still to beì interested in the Z-System but have not yet registered. However, if I doì not hear from them, they will be dropped from the next list. So, if you useì one of those nodes (or one of the nodes I have already dropped), please letì the sysop know that you want him to continue as a Z-Node, and suggest thatì he delay no longer in registering. Once we have all the sysops' names andì addresses, we can start to think about things like a software distributionì chain to make it easier for the nodes to stay current with Z-System softwareì developments. Many of the boards I called had only very old versions ofì programs. I would like to extend a special welcome to several new Z-Nodes, and Iì look forward to doing this in each column as more new nodes come on line. ì Bob Dean has for some time run the excellent Drexel Hill NorthStar system inì Drexel Hill, Pennsylvania, just outside Philadelphia. When I saw what anì enthusiastic Z-System supporter he was, I asked Bob if he would like toì become a Z-Node. He was delighted and has joined the network as node numberì 6. Ted Harmon in Minneapolis has been working for some time at getting hisì node (#80) up, and I hope that he will be in regular operation by the timeì you read this. So far I have not succeeded in connecting with his node. Bob Cooper in Ventura, California, is the newest node (#81), and fromì many voice conversations with him during the past couple of months I knowì how enthusiastic Bob is. His node is no in full scale operation. Sinceì newly commissioned systems generally have fewer callers than establishedì systems, their sysops would, I am sure, especially appreciate your calls. Patching Programs for NZ-COM As I described in an earlier column, NZ-COM creates a Z-Systemì automatically from the host CP/M-2.2 system by setting up a virtual systemì underneath the original one and forwarding calls presented to the virtualì BIOS (basic input/output system, the hardware-specific portion of theì operating system code) to the "real" BIOS except for warm boots, which areì intercepted to prevent a reloading of the host CP/M system. This produces aì software environment that is indistinguishable from a manually installed Z¡ System, and all programs that adhere to CP/M or Z-System standards shouldì run perfectly. There is, however, a class of programs that generally do not follow thoseì rules. These are most often utilities supplied by the manufacturer of theì computer to perform special operations, such as configuration of theì hardware. They usually make assumptions about the internals of theì operating system code -- in most cases, the BIOS -- under which they areì running. (Regrettably, they usually take no steps to verify that theì environment is what they expect -- see Bridger Mitchell's column in TCJì #36.) Programs of this type generally do not run correctly under NZ-COM, justì as they would not run correctly if the user rewrote his or her BIOS withoutì taking into account the assumptions the manufacturer made as to the locationì of certain data structures in the BIOS. (This same problem is less likelyì to occur, I believe, in a Z3PLUS Z-System running under CP/M-Plus, becauseì Z3PLUS operates as an RSX, which was a fully defined system facility underì CP/M-Plus. Manufacturers' configuration utilities are more likely toì understand RSXs and operate correctly under them.) There are two approaches to dealing with this challenge. In many casesì the configuration utilities are used only when the system is initially setì up (and the newly configured system is then stored on the system tracks ofì the boot disk). In other cases the configuration utilities are used onlyì when the system is cold booted (i.e., powered up). These situations pose noì problem, since the hardware utilities can be run under standard CP/M beforeì the NZCOM command is issued to invoke the Z-System. In some cases, however, the configuration utilities are needed on a moreì regular basis. Utilities for setting baud rates, screen attributes, orì printer characteristics may fall into this class. These situations canì present a considerable nuisance to the computer user, who easily becomes soì accustomed to the facilities of Z-System that he or she nearly loses theì ability to operate under vanilla CP/M. I can suggest two possible solutionsì here. One approach is to put the configuration utility in a directory that isì not on the path (or to give it a new name) and invoke it indirectly by wayì of an alias. The alias would initiate a SUBMIT batch operation, asì described in the NZ-COM manual, that would first remove the NZ-COM systemì using the NZCPM command, then run the configuration utility under vanillaì CP/M, and finally reload the standard NZ-COM system. (If you are veryì clever, you can probably make an ARUNZ alias figure out which of severalì standard versions of NZ-COM is running and automatically reload it.) Thisì approach will give the appearance of successful operation under NZ-COM of aì utility that actually cannot run under it. The main penalty is the extraì time it takes to exit from and return to the NZ-COM system. There is also aì problem if you have loaded a module (RCP, FCP, NDR, etc.) that is not theì one in your standard configuration. It will be lost. The second approach is to make the utility work properly under NZ-COM. ì In many cases I have been able to accomplish this without the source codeì for the utility by using the technique described below. But be forewarned;ì the technique will not always work. Most of these BIOS-specific utilities determine the address of the dataì structures to be modified by adding an offset to the BIOS warm boot entryì point whose address is obtained from the warm boot vector (jump instruction)ì stored at address 0000H in a CP/M system. Usually the instruction LDì HL,(0001) is used to load the address into the HL register. The problem isì that under NZ-COM this vector points to the NZ-COM virtual BIOS, and offsetsì from it generally fall right in the middle of one of the Z-System modules. ì Not only does the utility fail to make the desired change to the machine'sì real BIOS; it even corrupts some other code, resulting in behavior thatì ranges from unpredictably bizarre to instantly catastrophic. The simplest corrective patch consists of replacing the LD HL,(0001)ì indirect load instruction with a LD HL,WBOOT direct load instruction, whereì WBOOT is the actual warm boot entry point address of the real BIOS. Thisì kind of patch is performed by using some utility to scan the utility's codeì for occurrences of the three-byte sequence 2A (load HL indirect immediate),ì 01, 00 (the immediate address 0001H). ZPATCH is a natural candidate forì performing the search, but it unfortunately uses 00 as its string terminatorì and thus cannot search for a zero byte. Perhaps Steve Cohen will eliminateì this minor shortcoming in a future version of ZPATCH (hint, hint -- I knowì you're reading this column, Steve). The next step is to replace the 2A byte with 21, the direct load opcode. ì The other two bytes, 01 and 00, are replaced by the BIOS address that youì have determined previously (perhaps by looking at the contents of memoryì location 0001H while running normal CP/M). The low byte is entered first inì place of the 01 (it will always be 03). The second byte will be a someì relatively large number, almost always with a first hex character of D, E,ì or F. Blindly replacing sequences as described above does have its risks. ì Without careful inspection you cannot be sure that the sequences are beingì used to perform the assumed function. If you are an experienced coder, youì can use a disassembler (such as the one built into debuggers like DDT andì DDTZ) to examine the code. The LD HL,(0001) should be followed fairly soonì by an ADD HL,DE or ADD HL,BC to add the offset to the BIOS structure to beì modified. There is also always the possibility that the utility gets theì address it needs in some other way (for example, LD A,(0002) will get theì page address of the BIOS). The procedure I just described "hardwires" the utility to a BIOS at aì specific address. This is fine until you someday set up a new CP/M hostì system with a different BIOS starting address or until you give thisì modified version to a friend with a different BIOS. By then you will haveì forgotten all about these patches and will be pulling your hair out tryingì to figure out why the utility that worked perfectly before is nowì misbehaving. By then you will also have forgotten exactly what was patchedì and will not know how to fix the utility. A more sophisticated patch will allow the program to work with a BIOS atì any address. This approach follows Bridger Mitchell's philosophy of "knowì your environment." The patch checks to see if it is running under NZ-COMì and makes the changes only when it is. Source code for this patch, which can be applied using the MLOAD utility,ì is given in Listing 2. There are several pieces of information that youì will have to determine in advance and enter into the patch code. I have putì all that information at the front of the patch using macros whereì appropriate. If you do not have a macro assembler, you can always put theì material directly into the code where the macros are called instead. First, as before, you have to determine all the addresses at whichì indirect loads from address 0001 have to be changed to direct loads. Theseì values have to be placed in the patch address table in the patch code. ì Since the patch will be added to the end of the existing utility code, youì will also have to determine that address. You can calculate this from theì file size of the COM file in records as displayed either by STAT or by SDì with the "C" option. Alternatively, you can read the COM file into aì debugger and note the next free address it reports. This address must beì entered as the value of the symbol PATCHADDR. Most of the utility programs I have patched this way start at 100H with aì jump to the actual working code. The destination address of that jump mustì be determined and entered as the value of the symbol STARTADDR. If theì utility does not begin with a jump, then you will have to examine the codeì at 100H and determine the instructions that occupy the first three or moreì bytes. These instructions should be entered into the REPLACED macro in theì patch. The address of the next instruction after the ones replaced shouldì be entered as the value for STARTADDR. Once you have put all the necessary data into the UTILPAT.Z80 sourceì code, it should be assembled to a HEX file. Then the patch can be added toì UTIL.COM to make NEWUTIL.COM by using the following command: MLOAD NEWUTIL=UTIL.COM,UTILPAT Be sure to save the original program, and test the new version carefully. ì One additional word of caution. Some utilities cannot be expected to workì under NZ-COM no matter what you do. For example, a utility that takes theì running CP/M system and writes it to the system tracks will fail becauseì under NZ-COM the only part of the CP/M system that is still present is theì BIOS. For the same reason, programs that try to patch the BDOS will fail. ZFILER, Installment 2 ===================== Last time we covered most of the built-in functions and had left theì macro commands for this time. One built-in function was also deferred, theì option command "O", and we will take up that subject first. The Option Command When the option command letter "O" is pressed, a special options screenì is displayed. Eleven operating characteristics can be changed from a menuì with the following appearance (approximately): A. single replace query Y B. group replace query Y C. archive replace query N D. verify query Y E. verify default Y F. suppress SYS files Y G. sort by file name N H. set copied file attributes Y I. use dest file attributes Y J. archive destination Y K. search path for CMD file N We will explain the meaning of each of these options in a moment. First aì few words about the mechanics. While the options menu is displayed,ì pressing the index letter at the left will cause the setting of theì corresponding option to be toggled, and the new state will be shown in theì column at the right. The listing above shows the initial state of theì options in my personal version of ZFILER. When you are finished togglingì options, just press carriage return to return to the main ZFILER menu. ì These option settings are stored in the ZFILER shell stack entry and willì thus continue in effect through all ZFILER operations until the command "X"ì is used to terminate the shell. The first three options concern how ZFILER responds when copying (orì moving) files and a file of the same name already exists in the destinationì directory. Item A applies when individual files are copied (commands "C"ì and "M"); item B applies when a group copy is performed (commands "GC" andì "GM"); and item C applies when performing an archiving operation (commandì "GA"). If the option is "YES", then ZFILER will prompt one before existingì files are erased and give one the chance to cancel the operation for thatì file, leaving the existing file intact. If the option is toggled to "NO",ì then existing files will be overwritten without even a message. The next two options affect the verification of the copied file in theì destination directory. Item D determines whether or not the user will beì asked about verification. If this option is set to "N", then the state ofì option E will determine whether or not verification is performed on fileì copies. If this option is set to "Y", then before each copy, move, groupì copy, or group move, ZFILER will put up the prompt "Verify (Y/N)?". The next two options affect the way files are displayed on the screen. ì If item F is set to "Y", then files with the "system" or SYS attribute willì be suppressed, that is, not included among the selected files on whichì ZFILER acts. This is a reasonable choice for this option, since the mostì common use of the SYS attribute is to make the files disappear fromì consideration during file maintenance and display operations. Item G on theì options menu determines whether files are sorted first by name and then byì type or vice versa. Changing this option is presently equivalent to the "A"ì command from the main ZFILER command menu. The next three options concern how file attributes are treated when filesì are copied. One possibility is to create new files with a clean slate ofì attributes (that is, all attributes reset: not read-only, not SYS, notì archived). This is what will happen when option H is set to "N" (but noteì option J, which may override this). When the attributes of the destinationì file are to be set, they can be set in two possible ways. If a file of theì same name existed in the destination directory, then its file attributesì could be used for the copy that replaces it. This is what will be done ifì option I is set to "Y". If option I is set to "N" or if there was noì matching file in the destination directory, then the attributes will be setì to match those of the source file. Option J can set a special override for the archive or ARC attribute. Ifì the option is set to "N", then the ARC attribute is treated just like theì other attributes according to options H and I. If option J is set to YES,ì then the destination file always has its ARC attribute set. There was at one time a great deal of controversy over the way the ARCì attribute is handled under ZFILER. At one time it was always reset, so thatì the destination file would be marked as not backed up. Another school ofì thought asserted that, on the contrary, the file was backed up, since thereì was a copy of it on the source disk from which the file was copied. Thatì latter argument made considerable sense in the case of copying files from aì master disk to a RAM disk before a work session. Here it was certainlyì important to start with all files marked with the ARC attribute so that oneì could easily tell at the end of the session which files had been modified soì that they could be copied back to the permanent storage medium. All in all, I never understood this controversy. Both approaches clearlyì have merit, and since ZFILER supports both, I saw no reason for all theì argument. In a future version of ZFILER, I think I would like to add a flagì word that would indicate which drives should automatically set the ARC flagì when the J option is set to YES. That way, the option could be made toì apply to RAM drives only. The final item on the option menu, option K, determines how the macroì command file ZFILER.CMD (see discussion below) will be located. There areì two choices. If option K is set to YES, then ZFILER will look for it firstì in the currently displayed directory and then along the entire ZCPR3 searchì path. This option is useful if one wants to have different macro commandì files that apply to specific directory areas. Alternatively, if option K isì set to NO, then ZFILER locates the CMD file without using the path. ì Depending on how ZFILER is configured (this will be discussed another time),ì the file will be sought either in the root directory of the path (the lastì directory specified on the search path) or in a specific drive/user areaì coded into ZF.COM. This alternative results in faster operation, especially if the specified directory resides on a RAM disk. The options controlled by the option menu can also be permanently changedì in the ZFILER program file using a patching utility like ZPATCH. In theì first page of the file, you will see the ascii string "OPT:". The elevenì bytes following this string contain the startup values for the elevenì options. Patch a byte to 00 for NO or FF for YES. ZFILER Macros Although ZFILER can accomplish many tasks using its built-in functions,ì its real power comes from the macro facility, which allows it to be extendedì to include any functions that can be performed using combinations of otherì programs. This is where ZFILER really makes use of its power as a shell. ì First I will describe how the macro facility is used, and then I willì describe how the user defines the macro functions. As with the built-inì functions, macro functions can operate either on single files or on groupsì of files. The single-file macro facility is well developed and was alreadyì present in nearly the same form in VFILER; the group macro facility is newì with ZFILER and has not been fully developed yet. Invoking Macros One way to initiate a macro operation on the pointed-to file is to pressì the macro invocation key, which is normally the escape key. A prompt ofì "Macro:" will appear after the normal ZFILER command prompt. At this pointì you have several choices. If you know the key corresponding to the macroì you want to run, then you can simply press that key. ZFILER will thenì construct a command line and pass it on to the command processor forì execution. If ZFILER is configured for instant macro operation (itì generally is), then macros associated with the number keys "0" through "9"ì can be initiated without the macro invocation key; the number key enteredì alone at the main ZFILER command prompt will generate the macro function. If you press the macro invocation key a second time, a user-created helpì screen will be displayed. This screen generally lists the available macroì functions. You can now press the key for the desired function, or you canì press carriage return to cancel the macro operation and return to the mainì ZFILER menu. The help menu screen will also be displayed if you press theì "#" key. This is a holdover from VFILER and arises in part because of theì structure of the file in which the macros are defined (more on thisì shortly). Group macros are invoked in a similar way from the group function commandì line. After you have tagged a group of files, press the "G" key to enterì group mode. The prompt will list only the built-in group functions, but ifì you press the macro invocation key, you can proceed as described above forì single-file macro operations, except that the macro function will beì performed on each of the tagged files. The group macro facility works a little differently than the single-fileì macro facility. Since the command line would generally not be long enoughì to contain the commands for all the tagged files, the group macro facilityì works by writing out a batch file for processing by ZEX or SUBMIT. In thisì way there is virtually no limit to the number of files on which group macrosì can operate. There are many configurable options (described below) that are associatedì with the group macro operation. These include the name of the ZEX or SUBì batch file, the directory to which it is written, and the command line thatì ZFILER generates to initiate the batch operation. The NZ-COM version ofì ZFILER uses a file called ZFILER.ZEX and the command line "ZEX ZFILER". Theì Z3PLUS version, under which ZEX will not run, uses a file called ZFILER.SUBì and a command line of "SUBMIT ZFILER". Since macros (and the main menu "Z" function) work by passing commands toì the command processor, file tags will be lost in the process, and whenì ZFILER resumes operation, it starts afresh. In a future version of ZFILER,ì I hope to preserve the tag information by having it optionally written to aì temporary file (the shell stack entry is far too small) and read back inì when ZFILER resumes. Defining Macros -- The CMD File Now let's learn how to define the macro functions we want. As Iì indicated earlier, the macros are defined in a file called ZFILER.CMD (theì ZFILER ComManD file). In the version of ZFILER distributed with NZ-COM andì Z3PLUS, the CMD file is searched for in the root directory of the ZCPR3ì command search path. As described earlier, the option menu allows theì entire path to be used. There are also some additional configurable optionsì that will be discussed another time. You must be sure to put yourì ZFILER.CMD file in the appropriate directory. If the file cannot beì located, you will still get the macro prompt, but, after you have specifiedì a macro key, the error message "ZFILER.CMD NOT Found" will be displayed. The ZFILER.CMD file is an ordinary text file that you can create with anyì editor or wordprocessor that can make plain ascii files (WordStar inì nondocument mode, for example). The CMD file has two parts. The first partì contains the macro command definitions; the second contains the help screenì (described earlier). In the first part of the CMD file, each line defines a macro. Theì character in the first column is the key associated with that definitionì (case does not matter). Macros can be associated with the 10 number keys,ì 26 letter keys, and all printable special characters except for "#"ì (explained below). The space character and all control characters are notì allowed. Owing to an oversight, the rubout character can be associated withì a macro! After the character that names the macro there can be any number ofì blanks (including zero). If the first non-blank character is "!", then theì "strike any key" (shell-wait) prompt will appear before ZFILER puts up theì file display after a macro command is run. This should be used whenever theì macro will leave information on the screen that you will want to read. ì After the "!" there can again be any number of spaces. Any remaining textì on the line is taken as the script for the macro command. The second part of the CMD file starts when a "#" character is found inì the first column (hence the exclusion of that character as a macro name). ì Once that character appears, all remaining text, including text on the line,ì will be used as the help screen. Since ZFILER will add some information toì the display (the name of the pointed-to file and a prompt), you willì generally want to keep the help screen to no more than 20 lines, includingì an extra blank line at the end for spacing. With some experimentation youì will get the hang of designing this screen. Macro Scripts ZFILER macro scripts are similar to those in ARUNZ and in the other menuì shells (MENU, VMENU, FMANAGER) in that parameter expressions can appear. ì The critical parameters -- the ones that implement functions that cannot beì achieved any other way -- are those that convey information about theì directory currently displayed by ZFILER and about the pointed-to file. ì Parameters consist of a "$" character followed by one of the charactersì listed below. User prompt parameters ' User input prompt " User input prompt Parameters for directories - currently displayed directory C DIR form D Drive letter U User number - home directory (from which ZFILER was invoked) H DU form R Home DIR Parameters for pointed-to file P Full information (DU:FN.FT) F File name (FN.FT) N File name only T File type only Special parameters ! GO substitution indicator $ The dollar character The parameters are listed in a special order above, and we will explainì that later. First we will just present the meaning for each parameter. The parameter expressions $" and $' are used to display a prompt messageì to the user and to read in a response string. Single and double quotes areì equivalent. Once the prompt parameter has been detected, all subsequentì characters up to one of the quote characters are displayed as the userì prompt. Thus, if I am not mistaken, there is presently no way to put eitherì quote character into the prompt. The end of the line or the end of the fileì will also terminate the prompt. No special character interpretation is performed while expanding theì prompt. If you want to make fancy screens, you can include escape sequencesì and some control characters (obviously carriage return won't work). In theì future, ZFILER should be enhanced to provide a means to generate all controlì characters, to allow special characters to invoke screen functions based onì the current terminal definition, and to expand directory and file parametersì in the prompt. Now for the directory parameters. Parameters C, D, and U returnì information about the currently displayed directory, while H and R returnì information about the home directory, the one from which ZFILER wasì originally invoked. PLEASE NOTE: macros always operate from the homeì directory. The reason for this is that ZFILER can display directories withì user numbers higher than 15 even when it is not possible to log into theseì areas. If you want to operate in the displayed directory, then your scriptì must include an explicit directory-change command of the form "$D$U:" at theì beginning (or "$C:" if your system requires the use of named directories)ì and a command of the form "$H:" (or "$R:") at the end. One special note about the parameters that return directory names. Ifì the directory has no name, then the string "NONAME" is returned. This willì presumably not match any actual name and will lead, one hopes, to a benignì error condition. These parameters are included only for systems that do notì allow directories to be indicated using the DU form (I hope that few if anyì systems are set up this way). Now we come to the four file name parameters. They allow us to generateì easily the complete file specification or any part of it. Note that "$F" isì not quite the same as "$N.$T". The latter always contains a dot; the formerì does not if the file has no file type. Finally, we have two special parameters. "$$" is included to allow aì dollar sign character to be entered into the script. "$!" is a controlì parameter that is used only when a group macro is executed. If it is placedì immediately before a token (string of contiguous characters), then thatì token will be replaced by the string "GO" on all but the first expansion ofì the script. This allows group macro scripts to operate faster by avoidingì repetitive loading of a COM file. It must be used with great care andì consideration, however, for reasons that I will not go into here. Rules for Script Expansion ZFILER follows a specific sequence of steps when expanding a script, oneì that gives it a special feature that, I would guess, few users are aware of. ì The first step in the expansion is to process only the user-input promptì parameters, substituting for the prompt whatever the user entered inì response. This results in a modified script that is then processed by theì second step in the expansion. Because the expansion is handled this way,ì the user input ^Scan include ZFILER script parameters! Thus the script canì be used to write a script. You will see an example of this later. The second step in the expansion is to substitute values for theì directory parameters, which are a kind of constant. They do not change as aì function of the pointed-to file. Finally, in a third step, the remainingì parameters are expanded. For group macros, this final step in the expansionì is repeated for each of the tagged files. The file parameters are expandedì differently for each file, and, starting with the second tagged file, theì "$!" parameter causes "GO" substitution. Macro Examples Listing 3 shows an example of a ZFILER.CMD file, one designed toì illustrate some techniques of macro writing. While writing this article, Iì discovered that one can include blank lines as shown to make the CMD fileì easier to read. The help screen part of the listing is taken from myì personal script file (which, I have to confess, I have not really workedì very hard at). The macro definition part of the listing includes only a fewì of the definitions. The macro "Q" is included to illustrate a very simple, but useful, typeì of macro. It invokes the very powerful file typing program QL (quick look)ì on the pointed-to file. This is handy when you want more powerful viewingì capability than that offered by the built-in "V" command. QL can handleì crunched files and libraries, and it can display text or hex forward orì backward. Macro "U" uncompresses a file. It illustrates a more complex script thatì involves flow control and parameters that extract individual components ofì the pointed-to file name. It tests the file type to see if the middleì letter is "Q" or "Z". In the former case, it unsqueezes the file; in theì latter, it uncrunches it. The uncompressed file it put into the sourceì file's directory. Macros S, K, and B illustrate the use of input prompting. The first oneì allows the user to specify the file attributes to be set. Note that theì prompt includes a helpful reminder of the syntax required by SFA. Macro K crunches files to a user-specified destination. It alsoì illustrates how one logs into the currently displayed directory. I do thisì here so that a null answer to the prompt (i.e., just a carriage return) willì result in the crunched files being placed in the currently displayedì directory rather than in the home directory, as would otherwise be the caseì (since that is where the macro runs from, remember). As a result, however,ì this macro will not operate properly in user areas above 15 under BGii orì versions of the command processor that do not allow logging into high userì areas. Macro B performs a slightly more complex function. It not onlyì compresses the pointed-to file to a specified destination directory, but itì then marks the source file as having been backed up. A combination of theì group archive built-in command (to tag files that need backing up) and aì group macro B (to perform the backup) gives the ZFILER user a way to back upì files in crunched form on the backup disk. Macro M is included to show that a ZFILER macro, when it needs to doì something more complex than it is capable of doing all by itself, can passì the task to an ARUNZ alias. The MOVE alias first determines whether theì source and destination are on the same drive. In that case, MOVE.COM isì used to perform the move. Otherwise, the source file is copied to theì destination and then deleted. What we have, therefore, is a MOVE commandì that frees the user of the responsibility of worrying about which drives areì involved -- another example of how Z-System can free you from considerationsì that need not concern you, that do not require human intelligence to decide. The final three macro examples are execution macros. Macro X causes theì pointed-to file to be executed. A more sophisticated version might check toì make sure that the file type is COM. I opted for the flexibility ofì pointing, for example, to PROGRAM.Z80 and having PROGRAM.COM run. If thereì is no COM file with a matching name, the error handler will take care ofì things. You will note the leading colon before the "$n" parameter. Itì makes sure that the current directory is searched even if it is not on theì path. Prompted input is used to allow a command tail to be included. The Z macro performs a user-specified function on the pointed-to file. ì Two separate user prompts allow both the command and a command tail to beì given. For example, if you wanted to squeeze the file to A0:, you wouldì enter "SQ" in response to the first prompt and "A0:" in response to theì second. The 0 macro illustrates how the response to a prompt can be used as aì ZFILER script. This macro takes care of all those functions we forgot toì include in ZFILER.CMD. The whole macro is just prompted input, and whateverì we answer will be run as a script. I use this function so often that I putì it on a number key so that it can be invoked with a single key rather thanì the usual pair. Also, as you may have noticed, I include in the macro helpì screen a list of the parameters that can be used. The only real limitation of this macro-to-write-a-macro approach is thatì prompted input cannot be included in the response. As I write this,ì however, it occurs to me that this limitation could be overcome byì recursively parsing the prompt parameters until none remain, and only thenì going on to the subsequent macro expansion steps. Well, I was going to discuss patching and configuring ZFILER, but thisì article is already too long, so that will just have to wait for anotherì time. I hope that this article will help you get more out of ZFILER. Seeì you in the next issue!