Morrow Owner's Review, Volume 4, #5, page 7 (Oct/Nov '87)

Forever Z

by Rick Charnes

FIRST things first. WordStar 4.0, which will be released by the time you read this, has a number of excellent features specifically tailored for us ZCPR3 users. This reflects the superb hand of Dave McCord, Echelon's chief technician and creator of the Morrow bootable disk. Dave has been working with MicroPro on this and the resulting product is now the most ZCPR3- enhanced major CP/M-compatible application program that we have. Files can now be referenced either from the command line with their named directory reference; i.e., "AO:COMMAND>WS LETTER:SYLVIA.LTR". Both the "D" (edit a document) and L)og a new directory commands will accept a named directory. The currently logged named directory is also displayed at the opening menu along with the DU: designation, adding a very nice touch.

WordStar's R)un a program command has had its power greatly increased under ZCPR3. It fixes a major problem that previously existed for us, viz. it could not previously run a non-COM-file alias. This of course means ARUNZ/ALIAS.CMD entries, which is the main way we are making aliases. Since such a large part of our work from the command line consists of referencing ALIAS.CMD aliases, WordStar can now be used very much like a one-time ZCPR3 shell. Additionally, we can now run any resident commands such as REN, SAVE, ERA, etc. from the R) command. Note that this only works for ZCPR3 users; CP/M users (poor souls) cannot run resident commands and are still limited to executing COM files.

Finally, if you never got the hang of ZRDOS' public directory feature (shame on you!), WordStar will now search along ZCPR3 path for its overlay files, a very nice touch that rounds off the superb work MicroPro has done towards "Z-ifying" this cxcellent product.

I'd like now to describe two of the most innovative of the new programs hot off the ZCPR3 presses and available from Z-Node BBSs everywhere.

The brilliantly unorthodox nature of the programming work done by Mr. Dreas Nielsen of Corvallis, Oregon has always impressed me profoundly. He works in a realm more or less neglected by other programmers, dealing with what might be called non-menu shells and shell variables. Some of you may have experimented with his exotic and brilliant QUEUE.LBR which he wrote in the very earliest days of ZCPR3 when even ZCPR3: The Manual was unavailable. It was an extraordinarily sophisticated technique that would place filenames in a "queue" to be executed one by one by a user-specified command or series of commands. The utilities he used when he wrote this 2 1/2 years ago SH, SHSET, SHVAR, SHDEFINE remain even today unappreciated and unused by the vast majority of ZCPR3 computerists.

Following these chronologically in Mr. Nielsen's pantheon was the release of his superb GETVAR/RESOLVE duo, with which one is able to store (GETVAR) and then reference (RESOLVE) a named variable based on user input given in response to program query. I hope to be able to go into these important programs in a future column.

More recently he has done superb work in enhancing SH.COM and SHVAR.COM, two of the early ZCPR3 non-menu shells. And finally, as his crowning glory, Mr. Nielsen has now graced us with his elegant FOR/NEXT/PERFORM series, contained within the library FORNXT2.LBR. These progams give the 8-bit world something which we have never previously had, "FOR/ NEXT" looping from the command line. Those programmers among you will understand the significance of this particular form of syntax. It is actually a refinement and culmination of the basic concept Dreas started in 1985 with QUEUE.LBR. As the ZCPR3 world has progressed and more sophisticated tools have become available, programmers such as Mr. Nielsen have been able to use these tools as building blocks from which they may go on and create even more elegant concepts, and FORNXT2.LBR is his gift to us.

The purpose of these programs is to generate a list of "arguments" upon which any number of possibly unrelated commands are then executed (PERFORMed). In one of its simplest applications, the arguments would be a list of filenames. Suppose, for example, you're writing a book and today is the day to put the finishing touches on your last four chapters, each of which exists as a separate file on your disk. For each (using FOR.COM, get it?) of these files, you want to edit it with NewWord and then run it through both CORRECT-IT and GMK.COM ("Grammatik" checks for grammar, style, punctuation, etc.). Since your editor is one of those unlucky persons with one of those obsolete IBM PC's, you have to run them through FILTW.COM to strip out all nonASCII codes. Then finally before you turn your computer off for the night you want to archive each file to your backup floppy. This is all a fairly ordinary flow of procedures for many writers.

But it sounds like a great deal of repetitive keyboard work, a lot of the same commands to remember for each file, right? OK, let's put our ZCPR3 thinking caps on. We're smart and we know we could write an alias including all of the above commands. But that would still entail running the alias four times, once for each file. We are really enraptured by the Muse today and don't want to be bothered by all that computerizing. Well, if all the files have a similar name, such as CHAPTER.016, CHAPTER.017, etc. we'd know what program would take care of this: Steve Cohen's W.COM. Standing for W)ildcard, W.COM gives programs accepting only unambiguous parameters the ability to accept them wildcarded. We'd simply write our alias, called say, WRITE, enter "W WRITE CHAPTER.*", and off we'd go.

But suppose the chapters of our autobiography are named, for instance, after the various cities in which we've lived, and the filenames are therefore unrelated? Try this on for size, and get a sample of FOR/PERFORM:

FOR CHERHIIL BOSTON
GLOCSTER FRISCO PERFORM ECHO
PROCESSING $X...$|NW
$X$|CORRECT $X$|GMK $X$| >>
FILTW $X$|AC $X BACKUP: /A

Quite a mouthful, but this command line could easily take us through the entire day's computing. We're all running HSH, of course, the command line editor, so any mistakes in entering are easy to correct. Let's go through it slowly.

The initial "FOR" line creates the list of "arguments", in this case filenames (could be entire command lines!), and places them into a file called FORFILES.SYS that is automatically created by FOR.COM. This is a "system" file (has its $SYS attribute turned on) so a directory display will not ordinarily show it, but that's fine with us. We could if we wished look into FORFILES.SYS with an editor and we would see a text file consisting simply of the four files we entered as parameters.

Now for PERFORM. PERFORM.COM reads the list contained within FORFILES.SYS and in our case substitutes each file, one by one, into the parameter symbol "$X" in its own command line. It's very similar to the usual parameter symbols "$1", "$2", etc. used elsewhere. If you look closely, however, you'll see an odd-looking symbol, "$|". The symbol is a "substitute multiple-command separator". It is PERFORM.COM's substitute for the normal ZCPR3 semicolon (';') used for separating commands in the ZCPR3 multiple command line buffer. Remember: we're not at the system level; we're still working inside an application and applications have their own rules and symbols. It may look like we are stringing together a series of separate commands for the regular ZCPR3 command line buffer, but appearances are deceiving. Everything on that command line is really simply parameters for PERFORM.COM.

We therefore need some way of telling PERFORM that it should consider all our seemingly separate commands as input for it to process. We do this with the '$|' symbol. In the above line when you see a '$|' flush right against a '$x', keep in mind that they are really not together; the former symbol is simply acting to separate what precedes it from what follows it. When PERFORM does its marvelous work of substituting each of the files in FORFILES.SYS one at a time wherever it sees the '$X' symbol, it also will translate each '$|' into a semicolon. Each time it loops through our entire sequence of commands, it does the two substitutions a filename for '$X' and a ';' for '$|'. It THEN sends this "resolved" command line over to the command processor proper and runs it.

(To be continued next issue ...)

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.