
                    **********************************
                    *                                *
                    *     NZ-COM FOR THE BEGINNER    *
                    *                                *
                    * Copyright 1989 by Rick Swenton *
                    *        106 Melinda Lane        *
                    *     Bristol, CT 06010-7176     *
                    *                                *
                    **********************************

     What happened? I, along with many other long-time ZCPR3 enthusiasts, 
persuaded many CP/M users to migrate over to NZ-COM. Now is the time! No 
longer does installation of ZCPR3 require knowledge of system integration 
and assembly language. No longer is ZCPR3 reserved for the elect few. Now 
it is available to the masses. Plain old CP/M was simply too awkward and 
restrictive. Nobody should be left using CP/M 2.2 or even CP/M+ (CP/M 3.0) 
with NZ-COM and Z3PLUS available today. Many users took our advice.
     Now comes the phone calls and letters. At first, I thought that people 
were asking for help bringing up NZ-COM. It was not long that I realized 
that they were very successful getting NZ-COM running. Their main 
question was "What do I do with it, now that it is running?". I think the 
problem is that many users did not really try to exercise CP/M or push it 
to its limits. They never experienced the feeling of CP/M fighting back at 
you. They never really understood the limitations of CP/M so they don't now 
understand how NZ-COM is much better. Many used their CP/M systems to 
only run applications such as word processors and spreadsheets. Many 
never ran hard disks and many never, ever used a user area other than 
zero! (Most still don't know what a user area is today.)
     In this article, I will approach NZ-COM from the new user standpoint 
and answer many of the common questions asked by the new users. I will 
compare some of the NZ-COM features to plain CP/M to help you understand 
the similarities as well as the differences.
     I have heard it said many times that the way to learn ZCPR3 or the 
many associated environments (Z-SYSTEM, NZ-COM etc) was to first read the 
documentation. Then read the documentation again. Finally, read the 
documentation a third time! Z-System is so comprehensive that it is almost 
impossible to learn everything about it. Some of the material I will present 
here is a rehash of the same things I presented before. However, I am 
slanting this article more toward the beginner as well as spending more 
time contrasting NZ-COM features with that of plain CP/M.

                          *NZ-COM - What You Get*

     With NZ-COM, you have the following basic features not available in 
plain CP/M:

1 - Multiple Commands are allowed on a single command line, separated by a 
semi-colon

2 - Enhancement of the Directory (drive/user areas and named directories)

3 - Enhanced Command Processing (search paths and error handling)

4 - Memory-Resident Commands

5 - Flow Commands

6 - Shells

7 - Environment Descriptor

8 - Aliases

9 - ZCPR3 Enhanced Utilities

     This is not by any means an all-inclusive list but it is a good start. 
Let's talk about these one at a time.

                            *Multiple Commands*

     Multiple commands are permitted on a single line. Each command is 
separated by a semi-colon. Here's an example:

     WS MYFILE.DOC;ERA *.BAK;DIR

     This command line will invoke WordStar to edit MYFILE.DOC. When you 
finish with WordStar, the rest of the command line will be automatically 
invoked. First, all files *.BAK will be erased and then the directory will be 
displayed.

                      *Enhancement of the Directory*

     In CP/M, you are used to seeing the A> prompt where "A" is the 
currently logged drive.
     In ZCPR3, you will at least see the A0> prompt. "A" is the currently 
logged disk and "0" is the currently logged user area.
     Under CP/M there are 16 user areas on each disk. Under NZ-COM, 
there can be 32. User areas are sub-divisions of the disk. While you are 
logged into one user area, you only see files which are in that area. This 
is a great way of keeping related files in a separate area. For example, 
your WordStar disk could have WordStar and supporting files in User Area 
0, your personal documents in User Area 1, your business documents in 
User Area 2, and so on. Of course, you are still limited to the total maximum 
storage capacity of the disk.
     Under CP/M, you changed user areas with the USER command. However, the 
A> prompt remained unchanged. Even worse, while you were logged into 
another area, all those files in user area 0 were not available to you. If 
you log into a user area other than 0, DIR shows none of the files you know 
are there in user 0.
     Under NZ-COM, you change user areas by simply typing the number 
and a colon. For example, 2: will change to user area 2. B4: will change to 
Drive B, User 4. The system prompt will change to B4>. NZ-COM also allows 
a name to be assigned to a drive/user area. You could create the names and 
load them in the Named Directory Buffer. Now, you could change areas not 
only with the drive/user command, but also with the name of the directory. 
YOU create these directory names so you choose something meaningful to 
you for their names. Let's suppose that our WordStar disk is in drive B and 
we have files in user areas 0,1 and 2 as previously explained. We can see 
our WordStar files by typing B0: or WORDSTAR:. We can see our personal 
documents by typing B1: or PERSONAL: and we can see our business 
documents by typing B2: or BUSINESS:

                       *Enhanced Command Processing*

     Under CP/M, if you typed a command and it was not found on the 
currently logged disk in the current user area, the command was simply 
typed back at you with a question mark. Under NZ-COM, there are a number 
of routes that can be taken to resolve a command. The first is the Path.
     The Path is the route that ZCPR3 searches to find a COM file. If you 
like, you could specify that A0: is always searched for command files. This 
means that all the COM files which reside in A0: are always available to 
you, even if you are currently logged-into a different drive/user area. You 
don't have to keep separate copies of utilities in each drive/user area 
that you have files. The concept of a path may not be readily evident to 
you if you have never tried to take advantage of user areas under plain 
CP/M. User areas under plain CP/M was far from an advantage because CP/M 
made it VERY difficult to use them. Before I began using ZCPR3, the only 
time I used the user areas other than zero was on archive disks (the backup 
disks I store away for safe keeping). I used the popular NSWEEP to group 
related files in a common user area. NSWEEP made it very easy to bounce 
around in different user areas but that flexibility was only available 
while NSWEEP was running.
     Another method to resolve commands is called the Extended Command 
Processor. Some people build a library file (LBR) of infrequently-used 
commands and save it somewhere on disk, like in A15:. The reason for doing 
this is two-fold. First, all those files when clustered in a library file only 
take up one directory entry. Second, they take up less space on the disk. 
These are important considerations for floppy systems. There is a ZCPR3 
utility called LX.COM which can run COM files which are stored in libraries. 
By making LX.COM as the system's Extended Command Processor (ECP), you 
can automatically search this library file (typically called COMMAND.LBR) for 
COM files which were not found along the search path. It will take a bit 
more time to do this but all those COM files will appear to be "on-line" 
even though they are stuffed away in a single file. In my COMMAND.LBR I 
have ancient copies of PIP, STAT and DDT as well as infrequently used 
utilities like MENUCK and WHEEL.
     We can take this even further by making ARUNZ the system ECP. ARUNZ is 
a special program which takes a command from the user and searches a text 
file to see if there is a match. If it finds a match, it tries to execute 
the command associated with the match. Here is an example. You create the 
text file called ALIAS.CMD with your text editor. You create the following 
ALIAS definitions:

     WSTAR=WORD,STAR=EDIT ws $*

     Assuming that WS.COM exists on the disk, you can now invoke WordStar 
with any of the following commands:

     WS filename
     WSTAR filename
     WORD filename
     WORDSTAR filename
     EDIT filename

     The first command would run anyway, but the last four would be 
processed by ARUNZ. Since WSTAR.COM, WORD.COM, WORDSTAR.COM and 
EDIT.COM to not exist, no matching COM file would be found if they are 
run. ZCPR3 passes the request to the ECP. The ECP (ARUNZ) then scans its 
list of commands for a match. If there is a match, the requested command 
(WSTAR and others) is translated to a different command (WS) and executed.
     Finally, you could place LX.COM as the last definition in an ALIAS.CMD 
file so that ARUNZ and LX could be run together. If the command was not 
found in the ALIAS.CMD file, then COMMAND.LBR could be scanned for the 
request automatically. To do this, the last command should look like this:

     : lx / $0 $*

(Don't ask! The answer to why it looks like this is beyond the scope of 
this article!)
     Now suppose we exhaust all features and still did not find the 
command. If we installed an Error Handler, ZCPR3 will invoke it and we will 
likely be shown the whole command line which failed and we will be able to 
edit the line using WordStar (or other) control keys.

                        *Memory-Resident Commands*

     Memory-Resident Commands are stored in the RCP (Resident Command 
Package). The RCP typically occupies 2K of memory and contains familiar 
commands such as ERA, REN, TYPE, PRINT, REG, P, POKE, PORT, ECHO, CLS, 
DIR and H. It may not have them all. Use "H" to see what is available in 
your RCP. Since ZCPR3 was crammed with extra powerful features, there was 
no room left for many of the standard built-in commands. Placing them in 
the RCP makes them available again without having to resort to equivalent 
COM files, like ERA.COM, REN.COM, etc. Because they are memory resident, 
they execute almost instantly. Under plain CP/M, the commands DIR, ERA, 
REN, TYPE and SAVE were built into the Console Command Processor (CCP) 
and were very basic in nature. The RCP equivalent commands under NZ-COM 
are more versatile and flexible. For example, under CP/M, when you typed a 
file on the screen (TYPE FILE.DOC), the file was displayed line by line until 
you either stopped it with control-S or until the whole file scrolled off the 
screen right past you. Under NZ-COM, when you type a file, the system will 
automatically stop after 24 lines are displayed and wait for you to press 
any key before showing you another screen full.
     Plain CP/M had no memory resident commands other than the standard 
commands (DIR, REN, ERA etc) in the CCP. The advantage of ZCPR3 Resident 
Commands is that there can be an infinite number of Resident Command 
Packages (RCP) which can be loaded into memory to enable the features 
desired at the particular moment. Under NZ-COM, the size of the RCP can 
dynamically be as large or as small at you desire.

                              *Flow Commands*

     Flow Commands give you the ability to test for certain conditions and 
alter the sequence of commands based on these conditions. Among the 
primary flow commands are IF, AND, OR, ELSE, and FI (endif). Among the 
conditions you can test with these flow commands are EMPTY, EXIST, INPUT, 
REG and even BG, DS and many more. Here is an example. Suppose you have the 
following command line:

     if input SHOW FILES?;dir;else;if exist time.com;time;else;ztime;fi;fi

     When this line is entered, the following things will happen. First, you 
will be asked "SHOW FILES?" and the system will be waiting for you to type 
"Y" or "N". If you type "Y", then "dir" will be run. If you type "N", then 
the system will see if "time.com" exists. If it does, it will be run. 
Otherwise, "ztime" will be run instead. You may not see any use for this if 
it was typed in as a command line. The most valuable application of this 
feature is when this kind of command is part of a batch file (running under 
SUB or ZEX), part of an alias (created by SALIAS or part of the ALIAS.CMD 
file) or contained within a menu (MENU, VMENU or ZMANG) as well as being 
a ZFILER macro (in the ZFILER.CMD file).
     There is nothing remotely similar to Flow Control under plain CP/M.

                                 *Shells*

     Several Shells are provided with NZ-COM and new ones are written on 
a regular basis. Describing a Shell to a CP/M user is rather difficult 
because no similar program exists for CP/M. To put it simply, a Shell is a 
program which acts as a "front-end" to the system. It accepts input from 
the user, performs predetermined operations based on this user input, and 
then gets automatically re-invoked. It is an endless loop (sometimes). Menus 
are generally shells. You select a menu option. After the selection is made 
and the pre-programmed things happen, you return to the menu instead of 
the A0> prompt. If the person who wrote the menu did not provide for an 
exit from the menu, then the user would be "stuck" in the menu 
environment and would be restricted to only those options found in the 
menu. Although restrictive, this may be what you want, especially if the 
particular menu is to be used by someone who knows nothing about 
computers and you want to prevent them from ever seeing the A0> prompt 
where they could potentially do some damage.
     In Z-System, you have the ability to make ANY program into a shell. Of 
course you have to be careful because certain programs when made into 
shells would simply cause infinite loops. The program would continually re- 
invoke itself and would require a cold boot to get out of the loop.
     This quick overview of shells doesn't do the subject justice. Rick 
Charnes recently wrote a two part series on ZCPR3 shells in "The Computer 
Journal" in issues 36 and 37. This series is rather comprehensive and 
possibly intimidating to the novice user. The beginner would more likely 
use the shells SH, MENU, VMENU, ZMANG, ZFILER, EASE and most recently 
LSH.
     Under plain CP/M, the only thing which comes close to a shell is 
CP/M's ability to run a command on Warm Boot. If you CONFIGUR CP/M to 
run a command on Warm Boot, then every time a program ends, you will run 
that command. With this scheme, you should never be able to drop down to 
the A> prompt. Suppose you had a command like "MBASIC" entered as the 
command to run on Warm Boot. Every time the system was turned on, you 
would go directly to MBASIC. Every time you typed "SYSTEM" to exit to 
CP/M, you would immediately return to MBASIC! The only way to change 
this would be to SYSGEN the disk or to boot the system from another disk, 
copy the BIOS.SYS to that disk, run CONFIGUR on that BIOS and then copy 
it back to the original disk.
     Under ZCPR3, you can have as many shell programs as you want. They can 
be changed and exited (generally) at will.

         *The Environment Descriptor And Selecting Your Terminal*

     What is a terminal? Is a terminal the same as a computer? Why do we 
need to select the correct definition? These are common questions I have 
been receiving because my name is on the list of volunteer helpers which 
comes on the NZ-COM disk. Many times, those of us who have had long-time 
exposure to the ZCPR series of enhancements take for granted some things 
that the newer users are finding difficult to understand. One such cloudy 
area is your terminal and the TCSELECT utility. Let's talk now about how to 
make your terminal selection and what effects a correct and an incorrect 
terminal selection will have on your system.
     A terminal is generally a stand-alone video display with a keyboard. 
The internal terminal electronics may consist of simple digital logic along 
with standard video display circuits or it may consist of a microprocessor 
controlled intelligent system with fancy screen displays and options. In any 
event, it is not a computer. It is only a computer I/O (Input/Output) device 
which can display computer data on its screen or receive computer data 
from a user through its keyboard. Some computers require that you connect 
a terminal in order to use them.
     The Ampro Little Board, the Micromint SB-180, the Heath H8 and Morrow 
systems are among the computers which require a terminal. The older S- 
100, CompuPro, Cromemco and BigBoard systems (am I showing my age?) 
also required terminals.
     Many of the newer CP/M systems had built-in terminals. The Kaypro, 
Osborne, Heath H89 and Xerox 820 systems had built-in terminals. Here is 
where things get a bit confusing.
     The Heath H89 is actually a CP/M computer built right into the H19 
terminal cabinet. This means that there are two independent microprocessor 
chips in the box. One is the controller for the terminal. The other is the 
computer's Central Processing Unit (CPU). They operate independently and 
are only connected with a serial I/O cable. You could remove the CP/M 
computer from the box and have a stand-alone terminal.
     The other systems (Kaypro, Osborne, etc) have only one CPU chip. This 
CPU is programmed not only to be a CP/M computer but also to control the 
video display and keyboard at the same time. This is usually done with a 
very sophisticated interrupt driven software routine which writes 
characters to the screen and reads characters from the keyboard by 
suspending the current CPU activity, doing the screen write or keyboard 
read, and then restoring the current CPU activity.
     Since we have determined that there are many different kinds of CRT 
terminals, one can guess that it is likely that they all operate 
differently. Of course, this is true.
     Most of the time, terminals simply receive a character from the host 
(the CP/M computer) and display that character on the screen. However, the 
more sophisticated terminals have fancy bells and whistles which can be 
accessed to provide complex displays. Some of those features are cursor 
positioning, screen attributes (reverse video, underlining, blinking, bold or 
dim), graphics and editing (delete/insert character, delete/insert line). The 
commands which perform these functions are called "Escape Codes" because 
they generally begin with the Escape character as the first character of 
the command. The terminal's command set of Escape Codes is defined by the 
manufacturer in the terminal's firmware (ROM software).
     Applications programs which take advantage of the bells and whistles 
of the CRT terminal must be capable of running on a wide variety of 
terminals if the author expects to sell many copies. This is why programs 
like WordStar and dBASE-II have installation programs (WINSTALL.COM or 
INSTALL.COM) which allow the user to tell the program what kind of CRT 
terminal is being used.
     With the introduction of ZCPR3, a place was reserved within the 
operating system to store the details about the system's CRT terminal. This 
provided a very efficient way for ZCPR3 utilities to access the special 
features of the CRT without having the special sequences "hard coded" into 
each utility. For this reason, the same copy of a ZCPR3 utility will perform 
properly on many different systems with many different terminals. It gets 
the terminal information from the ZCPR3 TCAP (Terminal Capabilities) which 
resides in memory. Without the TCAP, each ZCPR3 utility which uses 
terminal features would have to be installed by the user for the particular 
terminal desired.
     Furthermore, if you are lucky enough to have more than one terminal 
and you want to operate it on the system, all you have to do is run 
TCSELECT and select the new terminal from the menu. Then, all the same on- 
line ZCPR3 utilities will work properly on the new terminal.
     Several people have asked me for help with TCSELECT. "My computer 
isn't on the menu! What do I do now?" One person had a Televideo TPC-1 
portable computer. There was no TPC-1 on the menu and he was 
understandably confused. After referring him to his owner's manual to find 
out what kind of terminal the TPC-1 emulated, we determined the correct 
selection was the Televideo 803. Non-hacker types have difficulty 
understanding the difference between a computer and a terminal. As this 
person discovered, the Z-Helper's List which comes on the NZ-COM disk 
contains names of volunteer consultants to help you with this kind of 
problem.
     If you don't select the correct terminal for your system, don't be 
surprised if the screen jumbles up when you try to run ZFILER, ZMANG or 
VLU and many other programs. In severe cases, the system may even lock- 
up (or seem to). A typical example would be if you selected a terminal 
which used ESCAPE } to clear its screen instead of your trusty Heath H19 
terminal. Your system would appear to lock-up because the ESCAPE } 
sequence which clears the other terminal's screen is the H19's Disable 
Keyboard Command!

                                 *Aliases*

     A ZCPR3 Alias is a program (or command) which invokes another 
program (or command). First, an Alias can be a COM file created by an 
Alias utility. This COM file simply passes a command line to ZCPR3. For 
example, let's create the Alias TEST.COM. The alias will contain the following 
command line:

     B4:;MBASIC WHUMPUS;A0:;DIR

     When we type "TEST", the above command line will be sent to ZCPR3. The 
system will log into drive B user 4 and run MBASIC. MBASIC will load 
WHUMPUS.BAS and execute it. When we're done playing WHUMPUS, the system 
will log us into drive A user 0 and display the directory. That long 
command line exists in the file TEST.COM. The other contents of TEST.COM is 
code which will place that long command line into the ZCPR3 Multiple 
Command Line Buffer (MCLB). As soon as ZCPR3 detects that the MCLB is 
suddenly no longer empty, it begins processing its contents. Notice that 
while WHUMPUS was running, the remainder of the command line - A0:;DIR 
was still lurking in the MCLB waiting to be processed after you were done 
with WHUMPUS.
     An Alias can also be a command expression. There is a ZCPR3 utility 
called ARUNZ (Alias RUN ZCPR3) which can process Aliases contained in a 
text file. In our example above we created an alias which was a COM file. 
You can also create a list of aliases with your word processor or editor 
just like you would create a document. Call this file ALIAS.CMD, your Alias 
Command File. Let's say you have a few Basic games and you want to be 
able to run them by just typing their name. Create the following ALIAS.CMD 
file:

     WHUMPUS b4:;mbasic whumpus;a0:
     WARS b4:;mbasic wars;a0:
     DND b4:;mbasic dnd;a0:

     WHUMPUS, WARS and DND are the names of the Basic game programs. Now if 
you type ARUNZ WHUMPUS or ARUNZ WARS or ARUNZ DND, the requested game will 
run and you will return to drive A user 0 when you're done. The invocation 
of the aliases contained in the ALIAS.CMD file can become automatic. Just 
rename ARUNZ.COM to CMDRUN.COM. CMDRUN is the default name of ZCPR3's 
Extended Command Processor. CMDRUN is invoked after ZCPR3 exhausts all 
possibilities while searching for a requested COM file. Assuming that no 
COM files exist with the same names as our basic games, all you have to do 
is type the name of the game - WHUMPUS. First, ZCPR3 will search all the 
drives and user areas defined in the PATH. (I am trying to keep this simple 
- really!) Not having found WHUMPUS.COM anywhere, it invokes CMDRUN and 
passes WHUMPUS to it. Since CMDRUN is really ARUNZ in disguise, it begins 
to scan the ALIAS.CMD text file for the word WHUMPUS. Having found it as 
the first entry, it passes the command line B4:;MBASIC WHUMPUS;A0: back to 
ZCPR3 (in the MCLB) for ZCPR3 to execute. Using ARUNZ, you do not have to 
create a COM file for each alias you desire. All you have to do is type a 
few bytes into the ALIAS.CMD text file. This technique saves disk space and 
directory entries.
     Some novice users have asked me what the difference was between an 
Alias and SUB or ZEX. The main difference is that an Alias sends a command 
line directly to the ZCPR3 command line buffer, the length of the command 
line is limited to 203 characters, and each alias definition can't exceed this 
line length. Under SUB or ZEX, the length of the command line still has 
this character count limitation but the number of LINES is almost unlimited. 
Furthermore, SUB or ZEX batch jobs must be handled by the overhead of 
their respective utility (SUB.COM or ZEX.COM) where either speed or memory 
usage are affected. A SUB or ZEX job can't exist as a COM file, ready to be 
run. You have to type SUB JOBNAME or ZEX JOBNAME. For those short jobs 
under 204 characters long, use an Alias. For longer ones, use SUB or ZEX.

                        *ZCPR3 Enhanced Utilities*

     The many ZCPR3 utilities were written to take advantage of the 
increased versatility of ZCPR3. As stated before, many utilize screen 
displays which access the CRT terminal's special features, and all conform 
to ZCPR3's syntax. For example, you could reference a drive/user area with 
an expression like A3: or a Named Directory like WORDSTAR:. Nearly all 
ZCPR3 utilities will display a brief help message if invoked with a double 
slash - ARUNZ // or ZEX // etc. Most ZCPR3 utilities take advantage of 
information for your system, contained in the Environment Descriptor. If 
you have correctly defined your environment, these utilities know how many 
floppy or hard disks you have (and if there are gaps, i.e. Hard Disks A: B: 
and Floppy Disks E: and G:). They will also know your CPU clock speed; when 
time delays are involved, they'll be correct on everyone's system. They 
will know about your printer - how many characters per line, how many lines 
per page, can it accept form feed, etc. And as I stated above, they know 
about the CRT terminal and send the correct codes to it to perform enhanced 
full-screen operation.
     Even WordStar-4 is capable of accepting ZCPR3-style syntax. WordStar- 
4 will permit you to log into drives or user areas with the drive/user 
specification (DU: like B3:) as well as the named directory specification 
(DIR: like TEXT:)

                                 *Wrap-up*

     I realize I've covered much of this information in the past. Hopefully 
I've met many of the needs of the NZ-COM novice with the way I have 
presented the information here. Part of my objective was the "Read, read, 
then read again" philosophy.
     I strongly suggest that you seek out a CP/M users group which is 
known to support ZCPR3 and NZ-COM. Unfortunately, sometimes these users 
groups are a well-kept secret. Let's face it. People aren't flocking to CP/M 
club meetings. After all, CP/M is believed to be dead. Check into the Z- 
Nodes (the Bulletin Board Systems you can call with a modem). A list is 
provided on your NZ-COM disk. Jay Sage, author of ZCPR34, runs a Z-Node 
in the Boston area. His system is always flooded with the latest dialog as 
well as the latest releases of publicly distributed enhancements of ZCPR3 
software.
     Check with your local "Z-Helper" to find out where the closest "hot 
spots" of ZCPR3 activity are in your area. The list of Z-Helpers is also on 
the NZ-COM disk.
    Subscribe to "The Computer Journal". This is the authoritative source 
of the latest ZCPR3 and advanced CP/M information. Jay Sage, Bridger 
Mitchell (author of Backgrounder-ii and Datestamper) and many other noted 
personalities are regular contributors.

Sage Microsystems East 
1435 Centre Street 
Newton Centre, MA 02159-2469 
Voice: (617) 965-3552 
Z-Node: (617) 965-7259 
300/1200/2400 24 hours 
password = DDT 
MABOS on PC-Pursuit 

You can reach me on "The Computer Club" PBBS-RCP/M at (203) 673-8752 
300/1200/2400 24 hours

