Morrow Owner's Review, Volume 4, #6, page 7 (Dec '87/Jan '88)

Forever Z

by Rick Charnes

(Continued From October/November)

All this activity is said to take place on the "shell stack" and '$X' is then called a "shell variable". PERFORM.COM places itself on this shell stack, just as do our more familiar "menu"-based shell utilities, VFILER, VMENU, and MENU. One easy way to see this visually is by simply adding the command 'SHOW' anywhere in the above line. When SHOW.COM loads choose the "S" option and you will be given a "realtime" view of what the shell stack looks like.

So now we're beginning to see what will happen. On the first loop through, our command line will have resolved to:


This command line in itself will keep us busy for quite a while, but of course when it finishes it will move us automatically on to BOSTON and the rest, repeating the entire series. We may spend two or three hours inside of NewWord working on each file. All the while the above command sequence is sitting patiently in the command line buffer, waiting for us to exit. When we do, it is immediately ready and available to go to work for us with the next command.

This is really a very simple use of these tools, nor does it even require NEXT.COM. FOR can create a list not just of files but of all user areas, named directories, command lines, or simply integers up to a user-specified limit, all capable of being acted upon by PERFORM. This combination provides a very powerful command structure with which we can greatly automate many of our operations, and I am very grateful to Mr. Nielsen for his bountiful work.

While we're exploring the command line buffer this is a good time to make a quick digression into explaining it as one of the fundamental differences between ZCPR3 and CP/M. When a warm boot occurs in either CP/M or ZCPR3 a fresh and virgin copy of the command processor is loaded from disk. The significance of this is as follows: in CP/M the command line resides directly in the command processor. When a warm boot takes place, such as when a program exits, this therefore flushes (wipes out) the command line. This is why CP/M 2.2 cannot support multiple commands. With ZCPR2 and ZCPR3 the command line was removed from its location in the command processor and placed in a specially protected area of memory known as a buffer. This way the command line can maintain, its integrity across warm boots and return as we like to do our bidding.

I'd also like here to pass on a tip that I have found very helpful in a number of circumstances in which I need to debug a command script I have written. It's ideal for aliases inside ALIAS.CMD, macro scripts in VFILER.CMD, MENU.VMN, etc. and as well with our PERFORM command line in case something had gone wrong. What we do is load the ZCPR3 program MU3 (Memory Utility) prior to anything else on the line. Once MU3 loads, we can then scan to the aforementioned special area in memory (the command line buffer) where our command line is kept, and simply view it. The beauty of this technique is that even though MU3 is the first command in the line, the command line will have already been built/generated by the time MU3 loads, and all the rest of commands have already been placed in the buffer and we are able to see the finished product. We see exactly what the command processor sees and therefore our job of debugging is made most easy.

In our customized Morrow Z-System configurations the MCLB (multiple command line buffer) is precisely at location FF04 in memory. So we precede our line with 'MU3 FF04' where 'FF04' is a parameter to MU3, and this takes us directly to where we wish to go. In aliases it should be placed as the very first item. In the above example and any example with shell variables, however, we want to see the buffer after PERFORM or whatever shell processor we are using has substituted its variables and transformed '$|' into ';', so we put it as the very first item in PERFORM's command line:


Note that positioned thusly PERFORM processes MU3 as one of its parameters, even though it's not a variable. The use of the command line separator '$|' ensures that it resolves all command line parameters in one pass, so MU3 is "resolved" along with the variables and we are allowed to peek into the fully expanded command line. The use of MU3 as a debugging tool has tremendous general applicability; in most circumstances we needn't concern ourselves with the above matters.

More new programs: Jay Sage, the author of ZCPR33, has developed ZFIILER v10f, a Z33-enhanced version of VFILER, our general daily interface with the command processor, that allows for "group macros". Until now we were limited to running our scripts on a single pointer file. With ZFILER10F we have the capacity to run a macro script on all tagged files. This is a tremendous enhancement and opens up all sorts of possibilities. ZFILER scripts are 95% compatible with your VFILER.CMD scripts with one major change: the '$' is used instead of '%' for the pointer file parameters.

Just to whet your appetite: suppose, for instance, you want to insert 6 different files on your disk into a single, already existing library. You write an easy macro in your VFILER.CMD; let's call it "I" for "Insert":

I nulu -0 $"Name of library file
([DlR:]LlBNAME): " >>
-a $f -x;era sf

For those who haven't yet discovered V/ZFILER's $" symbol, it requests user input before anything else runs in the script. It then inserts the user's response into the final, expanded command line precisely at the location between the $" and the terminating " (double-quote mark). When this script runs the very first thing that happens is that we are queried for the name of the LBR. We respond, hit <CR> and the pointer file, represented by '$f', is inserted into the LBR.

As an example let's say we are pointing to LETTER.TXT and we want to insert it inside CORRESPO.LBR. We hit our macro lead-in key (default is <ESC>) and then "I". The string

Name of library ([DIR:ILIBNAME):

appears on the screen. We answer "CORRESPO" and the following command line is generated:


NULU can accept all this on its command line, so it works beautifully. But, you ask, do you have to repeat the process six times for each of your files? With VFILER you do; with ZFILER you don't. Simply tag all your files, run the new "group macro" command, hit "I" again, and stand back and watch while one by one six command lines are generated and each file is inserted into CORRESPO.LBR.

There's more: Jay, in his usual brilliance, has thought of everything. The above technique is slowed considerably by time spent loading and re-loading NULU six times from disk. For those wanting to experiment with the resident GO command here is your opportunity. By preceding a command script with the symbol '$!' GO is substituted for the command verb (here 'NULU') on every run but the first. GO of course runs whatever is in TPA memory without having to pull it off the disk, so its speed is astonishing. The technique works flawlessly and is breathtaking to watch.

The latest on the Z280 front: I've had considerable contact with Zedux, Inc., the southern California manufacturer of the generic Z280 add-on board that I mentioned last time. They do in fact have a ready-to-run multi-tasking operating system called RP (Remote Partition) for their Accel 280, and I have arranged for them to come to San Francisco in mid-September to demonstrate their wares. They are urging attendees to bring whatever Z80 computers they use, and they promise to walk around the room and plug a board into the different machines so as many folks as possible can get the experience of a multi-tasking operating system running on their own computer. Promises to be quite a night.

Rick Charnes bought his MD-2 many years ago when he thought of himself primarily as a writer. Now a self-admitted fledgling technical type, his computer has turned from tool to toy. His immense love affair with ZCPR3 leaves some occasional time for mundane things like work. He is president of BAMDUA.