CP/M/CPM_CDROM.iso/jsage/znode3/tcj/tcj38.ws

Text File | 1994-09-02 | 25.1 KB | 461 lines

The Z-System Corner
TCJ Issue 38
Jay Sage


   True, February is a short month, but somehow I don't think that explainsì
why the beginning of February (the due date for this column) came quickerì
than usual.  It is probably a good thing that I have convinced severalì
others to start contributing regular columns to TCJ.  That way, Art Carlsonì
may be busy enough not to notice that the deadline passed without my column. ì
Because it is late and because we now have quite a few prolific writersì
joining the TCJ ranks, I'm going to keep my column shorter than usual thisì
time (I know I have said that before, but this time I think it really willì
be true).

   For this issue I will be catching up on some correspondence, informingì
you of the imminent release of the first high level language for Z-Systemì
programming, bringing you up to date on Z-Node developments (there is a newì
Z-Node Central), and beginning a discussion of issues related to bringing upì
a remote access system (so that more of you might decide to set up a Z¡
Node).


                                  Letters

   Despite our requests for letters with your comments and suggestions, weì
don't get very many.  Recently, however, Art forwarded to me two lengthy andì
thoughtful letters from James Ott.  I would like to begin by addressing someì
of his comments and questions.


The ZCPR33 Programmer's Reference Manual

   First, Mr. Ott asked about the "Programmer's Reference Manual" to which Iì
made reference in my ZCPR33 User's Guide.  Well, the truth is that afterì
writing the user's guide, I really didn't have energy left for another majorì
manual.  Instead, I started to release programming notes one at a time asì
files on the Z-Nodes.  Even at that, I only got to three of them.  The filesì
have names of the form Z33PNOTE.###, where "###" is a sequence number.  Noteì
001 deals with the command status flag in the message buffer and theì
extensions in its use introduced with ZCPR33.  Note 002 discusses properì
coding techniques for shells under ZCPR33 and later.  The third note coversì
the parsing of files by the Z33 and Z34 command processors.  I am tempted toì
reproduce some of that material here, but then I would surely fail in myì
resolve to keep this column to a reasonable length.  So you will just haveì
to look for them at the Z-Node in your neighborhood.  If it is not there,ì
see if the sysop will get a copy from Z-Node #3.


Shells and ZEX

   Mr. Ott continued: "The User's Guide mentions an addition to shell codingì
necessary to ensure the shell pushes its name onto the shell stack when itì
is called by ZEX."  I think there is some misunderstanding here.  It wasì
under previous versions of ZCPR3 that special code was required in shells toì
deal with ZEX (and it never had to do with pushing anything onto the shellì
stack).  Under Z33 and later, this code can (and, to make the programsì
smaller, should) be removed.  It has now been quite some time since theì
release of ZCPR33, and I think that most shells are now coded in the moreì
efficient way.

   As we have discussed in previous columns, a shell command comes into playì
when the command line buffer becomes empty.  In that case, if there is aì
command on the shell stack, the command processor invokes that commandì
instead of asking the user for the next command line.  In this way, theì
shell takes over the function of the command processor.

   ZEX's function is similar to that of SUBMIT and XSUB together.  Whileì
SUBMIT stores its script data in a disk file, ZEX keeps it in memory.  Thisì
enables ZEX to run much faster, but it reduces the memory available toì
programs.  A simple SUBMIT script feeds a series of commands to the commandì
processor, thus doing under CP/M what the multiple command line of ZCPRì
does.  SUBMIT can be useful even under ZCPR, however, because it can supplyì
a longer string of commands than could fit into the command line buffer.

   XSUB running under SUBMIT allows characters in the script to be fed notì
only to the command processor but also to programs as they run.  This isì
what is called input/output (I/O) redirection.  In this case it is inputì
redirection; the operating system is made to take its characters not fromì
its normal source -- the keyboard -- but from a disk file (SUBMIT) or aì
memory buffer (ZEX).  This is both extraordinarily useful andì
extraordinarily tricky.  Long ago I promised to discuss this subject atì
length in this column, but I have never gotten around to it.  Bridgerì
Mitchell, Joe Wright, and I are now engaged in a joint project to perform aì
major upgrading of ZEX, and I am sure it will be the subject of TCJ columnsì
by one or more of us.

     The ZCPR33 command processor observes the following hierarchy forì
acquiring new commands, where step 1 has the highest priority and step 5 theì
lowest.  The way this hierarchy functions is described in more detail in theì
ZCPR33 User's Guide.

    1.    Commands pending in the multiple command line buffer
    2.    Commands from a ZEX script
    3.    Commands from a SUBMIT script
    4.    A shell command
    5.    User input

   Under ZCPR30, ZEX did not appear explicitly in this hierarchy; it cameì
into play only by virtue of its ability to redirect input at step 5.  Thisì
posed a serious problem when a ZEX command was issued under a shell.    ì
Although the user intended the script to be performed as commands, the shellì
would take it as input to the shell instead.  To avoid this, rather lengthyì
code had to be included in every shell to see if ZEX was running and, if so,ì
to feed its input directly to the multiple command line buffer.  Thisì
resulted in completely useless loads of the shell code for each line of theì
ZEX script.  Execution was so slow and annoying that for all practicalì
purposes ZEX scripts could not be run under shells.

   The ZCPR33 command processor was redesigned to deal with ZEX explicitlyì
just as ZCPR30 always did with SUBMIT.  ZEX was placed above SUBMIT in theì
hierarchy so that ZEX scripts would function like arbitrarily long commandì
lines and could be invoked from SUBMIT scripts.


The New Libraries

   Mr. Ott had several questions about the assembly-language libraries thatì
support the Z-System.  I will not comment extensively here, but I would likeì
to announce that new versions of the libraries, which have been in use by aì
number of us for many months already, will soon be made available to theì
public.  I had expected them to be a commercial product, but, for severalì
reasons, it now appears that the code will be made available at no charge. ì
Only the manual, which will be quite a large book, will be sold.  This isì
good news.

   One of Mr. Ott's suggestions was that the Z3LIB routine called PRGLOAD,ì
which is used for chaining from one program to another, be updated to allowì
for type-3 programs.  This probably could be done without a great deal ofì
difficulty, but I am not sure that it is worth the trouble.  What aboutì
type-4 programs?  Loading them is much more complex because of the need toì
compute the relocation to a run-time address.  It seems to me that a betterì
way for programs to chain to other programs is via the multiple command lineì
buffer.  If anyone can suggest any advantages of a direct load, I would beì
interested in hearing them.


The Command Line Tail

   One of the mistakes in ZCPR30 was its failure to check for command lineì
tails that would not fit in the buffer from 80H to FFH.  CP/M had no problemì
with this because the whole command line was not long enough to allow thisì
to occur.  With a 200-or-more-character command line buffer, there isì
nothing to stop a user from entering a command with a tail longer than 128ì
bytes.  Under Z30 this caused a catastrophe, because the tail was copiedì
into the buffer after the program was loaded, and then the tail couldì
overwrite the beginning of the code.  Z33 and later monitor the length ofì
the tail and stop copying before this can happen.

   With type-3 programs that load at addresses higher than 100H, longerì
tails could be copied without damaging the code, and Mr. Ott requested thatì
this be implemented in future versions of the command processor.  I thinkì
this would be a very bad idea.  One of the reasons for using type-3 programsì
is so that any code residing at 100H can be run again later using the GOì
command.  If the type-3 program's tail overwrote the TPA, then trouble wouldì
occur when the GO command was executed.

   Moreover, there is absolutely no need for such a feature.  If a programì
wants to support a tail longer than 126 bytes (it doesn't even have to be aì
type-3 program), it can simply read its arguments not from the buffer at 80Hì
but directly from the multiple command line buffer.  As an aside, I haveì
thought of making the command processor not convert the command line bufferì
to upper case.  Then programs could process lower case input directly (as inì
MS-DOS) without the special symbols to indicate case shifts as in the ECHOì
and IF INPUT commands.  The command tail buffer at 80H must be converted toì
upper case for compatibility with CP/M programs, which assume that that willì
be done.  Besides the fact that there might be a significant code penaltyì
(the command tail buffer and the command file control block would both haveì
to be individually case shifted), I worry that there may be a number of Z¡
System programs that either rely on the command line being in upper case or,ì
worse, convert it to upper case.  I'd be interested in hearing any opinionsì
on this topic.


Still More on Z3 vs. Z2 Shells

   Mr. Ott sent me a lengthy letter with some interesting examples of theì
use of the shell stack.  I think his is the first response I have receivedì
that pointed out an aspect of the shell stack that I had not previouslyì
appreciated.

   I don't think about shell command lines with more than one command, soì
the following distinction never occurred to me.  One can think of the shellì
stack as containing not just, say, four commands but rather four groups ofì
commands.  The shell stack not only holds these commands; it also providesì
the mechanism for grouping them, for providing parentheses, if you will. ì
The Z2 approach to shelling would have a very hard time doing this.  Forì
example, if the first element on the shell stack contains the command lineì
"CMD1A;CMD1B" and the next lower element the line "CMD2A;CMD2B;CMD2C", theì
equivalent Z2 situation would have the command line

    CMD1A;CMD1B;CMD2A;CMD2B;CMD2C

The SHCTRL POP command removes an entire Z3 shell entry, containingì
possible multiple commands.  How could we implement this function with aì
Z2-style shell?  Even if each command were marked with a "/s" token, oneì
could still not tell which ones were grouped with which.  There might be aì
solution to this problem, but the Z3 shell approach certainly handles itì
nicely.

   Mr. Ott's letter included a very interesting application example.  I'veì
made a few changes that, I hope, do not harm its essence.  When the computerì
is booted, the STARTUP alias loads the command sequence "FIRSTSH;MENU",ì
where FIRSTSH is a special utility that places the following commandì
sequence onto the shell stack:

    PARK;VID RST.MSG;STOP

When this sequence runs, it will park the heads on the disk drive, display aì
message to shut off the computer, and run a program called STOP that locksì
the machine.  Of course, this multiple-command shell could easily beì
replaced by an alias SHUTDOWN.

   This termination shell does not run immediately because of the commandì
MENU following it in the command sequence.  This loads a second shell ontoì
the shell stack.  The user then lives inside the MENU shell for some time. ì
At some point, the user may make a selection that generates the command "CDì
WORK:".  This would log into the WORK: directory and issue an automatic STì
command there.  The ST alias might have the script

    LDR WORK.NDR;SHCTRL POP;ZFILER

This would install a new set of named directories, pop MENU off the shellì
stack, and replace it with the ZFILER shell.  The user could then do someì
work using ZFILER.  From ZFILER, a macro command might make another shellì
change by popping the shell stack and installing another shell.

   The above process would continue until the user made an exit selection. ì
This would pop the shell stack without installing a new shell.  As a result,ì
that first line we put on the shell stack would become active, forcing theì
computer to be shut down in an orderly, preplanned way.  Of course, thisì
approach is not totally foolproof if the user has access to the power switchì
or power cord.  But it certainly helps.

   Mr. Ott worried that this example could not be achieved using a Z2 shellì
system.  I think it could, though not with quite the same ease and elegance. ì
The STARTUP alias would contain the line

    MENU;SHUTDOWN

When MENU ran, it would substitute for itself in the command line theì
desired command line plus its own reinvocation command with the flag "/S" toì
mark it as a shell.  Thus the command line would become

    USERCMD;MENU /S;SHUTDOWN

For the user command CD WORK:, the command buffer would evolve as follows:

    CD WORK:;MENU /S;SHUTDOWN
    ST;MENU /S;SHUTDOWN
    LDR WORK.NDR;SHCTRL POP;ZFILER;MENU /S;SHUTDOWN

When the SHCTRL command ran, it would scan the command line for the nextì
shell command as marked by the "/S" flag and remove it from the commandì
line.  This would leave one with

    ZFILER;SHUTDOWN

When ZFILER generates a macro command, the command buffer would have

    MACROCMD;ZFILER /S;SHUTDOWN

This would continue until one cancelled the shell.  Then the SHUTDOWN aliasì
would run.

   Mr. Ott was concerned that the command line would grow longer and longerì
as old shell commands piled up.  Indeed, this would happen if there were noì
'popping' mechanism.  The "/S" marker I proposed in my previous columns isì
critical here, since without it there would be no way to tell which commandì
to pop.  This approach, I think, would fail with aliases as shell commands. ì
The Z3-type shell really helps us in this case.


                  High-Level-Language Support for Z-System

   I have some especially exciting news about the first high level languageì
specially designed for Z-System.  In late January, I got a phone call fromì
Leor Zolman, author of BDS C.  He was interested in bringing out a newì
version of his C compiler for the modern 8-bit market.  After someì
consultation with me on what was needed to support Z-System, Leor went toì
work on the run-time code, and in less than two weeks he had a version readyì
for beta testing

   He came over to my house to demonstrate the result, and I was amazed toì
see how easily one could write a utility, complete with named-directoryì
support, even including password protection.  A little fine-tuning is stillì
needed, but I am already excited about the impact that the availability ofì
this quality high level language will have on Z-System development. ì
Marketing details have not been worked out at this point, but you can expectì
the new BDS C to be available at an attractive price through Z Systemsì
Associates (ZSA) channels (Plu*Perfect Systems, Sage Microsystems East, Z¡
Nodes, and Z-Plan user groups).


                           The New Z-Node Central

   Ron Bardarson, who had operated Z-Node Central after David McCord retiredì
as the sysop, decided to change the focus of his system and his nodeì
designation from Z-Node to X-Node.  This was to indicate its experimentalì
nature and its focus on software and systems development rather than on theì
distribution of Z-System software.  Its number remains 408-432-0821 (CASJOì
on PC-Pursuit).

   To maintain a center of support for Z-System users and for Z-Node sysops,ì
we have established a new Z-Node Central.  Richard Jacobson, whose Lilliputeì
Z-Node in Chicago has long been, in my opinion, the premier Z-Node in theì
country, has agreed to take on this new role.  He will continue to use theì
delightfully ironic Gulliverian name (at over 100 Mbytes, his is the leastì
Lilliputian of the Z-Nodes), but his node number now drops from 15 to 1.

   This new function is added to several special services that Lilliputeì
already provides.  It is the official bulletin board and remote accessì
system for both the North American One Eighty Group (NAOG) and TCJ.  Theì
full system, comprising two independent computers, is available on aì
subscription basis.  All users who provide registration information will getì
15 minutes per day of free access.  Unlimited access to both computersì
(within reason) is available at a rate of $25 for six months or $40 for aì
full year.  TCJ subscribers and NAOG members get free access to limitedì
areas and can upgrade to full subscriber privileges at $5 less than theì
standard rates.  Z-Node sysops will have free access to the full system. ì
The phone numbers are 312-649-1730 and 312-664-1730, accessible via theì
ILCHI outdial of PC-Pursuit.


                       System Security Under Z-System

   As part of my plan to build up the network of Z-Nodes, I would like toì
begin a series on issues related to setting up a remote access system (RAS)ì
using Z-System.  Many people do not realize it, but NZCOM and Z3PLUS (theì
automatic Z-Systems for CP/M-2 and CP/M-Plus, respectively) create systemsì
with the full security capability necessary for a RAS.  It just takes a fewì
simple operations to engage it.

   These issues have been brought to my attention recently because I haveì
been in the process of setting up a second remote access system at my house. ì
This one is for the BOSKUG group of the Boston Computer Society.  It will beì
a two-line system running on a very powerful 16 MHz Kaypro 286 computer withì
multitasking software.  For all this power, however, I was struck by theì
tremendous complexity of setting up a remote system on such a computer, allì
because of the lack of a secure operating system.

   With MS-DOS, a remote system absolutely cannot allow a caller to gainì
direct access to the operating system command prompt, because once he hasì
that access, there is no way to limit what he can do.  It made me realizeì
how fortunate we are with Z-System to have an operating system with enoughì
security to permit callers on a remote system to run the system more or lessì
as if they were sitting at the keyboard of their personal machine.  Theyì
don't have to have an elaborate apparatus standing between them and theì
system.

   There are two main aspects of that security.  One is the wheel byte. ì
This system flag is tested by many Z-System programs to determine whetherì
certain operations should be permitted or denied.  Commands for doing thingsì
like erasing, renaming, or copying files typically require that wheel statusì
be in force.  Other commands will allow some operations to non-wheel usersì
but deny other operations.  For example, some directory programs allowì
writing an image of the directory to disk or to the printer.  These optionsì
are (or should be) restricted to 'wheel' users.  The wheel byte itself isì
set and cleared by special commands, such as the WHL command of the RCP. ì
Obviously, a password must be entered correctly before WHL will set theì
wheel byte.

   The second and more complex security feature in Z-System concerns theì
facilities for limiting the disk areas which a user can access.  Many usersì
are unaware of these features, and even those who are aware of them often doì
not understand them fully and clearly.  I will cover the major points here.

   With version 3.3 of ZCPR, I introduced extensive and significant changesì
in the way directory references and security are handled.  These changesì
made understanding security more complex for the system implementor but muchì
easier and less intrusive for the user.

   ZCPR3 supports two basic forms of directory reference, the disk/user orì
DU form and the named directory or DIR form.  We will assume that the readerì
is already somewhat familiar with the basic concepts.  The DU form is nativeì
to CP/M, which knows about disk drives from 'A' to 'P' and user numbers fromì
0 to 31 (though there are restrictions on user numbers above 15).  The DUì
form of directory reference is basically physical in nature.  Drive lettersì
are associated with real physical devices, and the files in all user areasì
associated with a given drive letter are stored on the same physical device. ì
One can think of this directory structure as spanning a flat, two¡
dimensional space (in contrast to the hierarchical tree-structuredì
directories of Unix or MS-DOS).

   While the DU directories are basically physical, named directories areì
purely logical constructs.  The named directory register (NDR) module in aì
Z-System contains a mapping of directory names to drive/user values.  Theì
user can load different sets of directory associations at different times. ì
Thus, unlike the static (fixed in time) directory structure of Unix and MS¡
DOS, the directory structure of Z-System can be dynamic (changing in time).

   When the DIR form is used, the command processor or a Z-System programì
looks for the name in the NDR and substitutes the drive and user values. ì
Only drive/user values are used in the actual file references processed byì
the disk operating system (DOS).  Named directories provide two differentì
and important functions.  One is convenience.  It is much easier to rememberì
that one's assembly language tools are in ASM and one's wordprocessing filesì
in TEXT than it is to remember that the directories are A7 and B13.  Theì
second purpose of named directories is to provide security.

   Access to directory areas in a Z-System is controlled in both the DU andì
DIR domains.  Under Z30 these two control mechanisms were completelyì
independent; under Z33 and later, as we shall see, they are very closelyì
coupled.  The limits in the DU domain are set by values in the environmentì
descriptor (ENV) called max-drive and max-user.  They define a rectangularì
area of allowed directories in the flat directory space, with drive valuesì
ranging from 'A' to the drive specified by max-drive and user numbersì
ranging from 0 to the number specified by max-user.  The smallest spaceì
still includes the boot directory A0.

   Named directories offer a more flexible means of controlling access toì
areas on a system.  The user can access a named directory even if it refersì
to a DU area that is beyond the bounds defined above.  Each directory nameì
can have an optional password associated with it.  Whenever a reference isì
made to such a directory, the password is (should be) asked for and accessì
granted only if it is entered correctly.

   There are a number of important exceptions to the two security limitsì
described above.  One concerns the command search path specified in the Z¡
System PATH module.  No restrictions whatever are imposed on the DU areasì
specified there.  If the user was able to place a directory into the path,ì
then it will always be scanned as necessary by the command processor, evenì
if it would no longer be explicitly accessible.

   Another general exception occurs for the standard (but optional)ì
configuration of the command processor called WPASS.  With this option, whenì
the wheel byte is set, directory passwords are ignored.  The user can thenì
freely make reference to any directories either within the specified DUì
range or associated with a named directory (with or without a password).

   Versions of the command processor since Z33 also make the assumption thatì
if a user is in a given directory at the present time he must have had theì
authority to get there.  Therefore, the command processor will always acceptì
any reference to the currently logged directory, even if the DU is out ofì
range and it has no unprotected directory name.

   Another set of exceptions relates to the interplay of the DU and DIRì
limits.  Recent versions of the command process act on the principle that ifì
reference to a directory in one form (DU or DIR) would be allowed thenì
references using the alternative form should be equally allowed.  Forì
example, suppose that the max DU limit is set to B3 and that directory C4ì
has the name DIRNAME with no password.  Z30 would have refused to accept aì
reference to C4:, even though it would have no complaints about DIRNAME:. ì
Under Z34, either would work.  Conversely, if directory area A3 in theì
example had a directory name PRIVATE with password SECRET, Z30 would allow aì
reference to A3: but would insist on correct password entry if the referenceì
was made as PRIVATE:.  Again, Z34 always checks the alternate form ofì
reference, and if either meets the security restrictions, then both areì
accepted.

   The standard version of Z-System created by NZCOM or Z3PLUS has the maxì
DU limit set to P31.  Thus all directories are allowed using the DU format. ì
As a result, even when named directories with passwords are created, theyì
are accepted freely.  In order to create a secure system, the values of max¡
drive and max-user must be reduced.  Also, since password checking isì
bypassed when the wheel byte is set, the wheel byte must be cleared beforeì
the security limits imposed by directory passwords will take effect.  Onceì
those two changes have been made, your NZCOM/Z3PLUS system is ready to serveì
as a remote access system.