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^S! 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!
[This article was originally published in issue 37 of The Computer Journal,
P.O. Box 12, South Plainfield, NJ 07080-0012 and is reproduced with the
permission of the author and the publisher. Further reproduction for non-
commercial purposes is authorized. This copyright notice must be retained.
(c) Copyright 1989, 1991 Socrates Press and respective authors]
