The Computer Journal, Issue 40

Z-System Corner

© Jay Sage

Reproduced with permission of author and publisher.

For some time I have been planning to discuss issues connected with setting up a remote access system (RAS), such as a Z-Node. There is still a great need for new nodes, and I think there are quite a few people toying with the idea of setting one up; they just aren't sure they know how to do it.

In fact, I am going to take up only a very small part of this question here - and not even the part that would really help someone implement a system. After thinking about it, I realized that I am not the best person to talk about the procedures. I may not even be a good person. In fact, I'm not even sure that I know any longer how to do it!

To solve this problem, I am going to try to take the approach I have been taking more and more recently - recruit someone else to write a TCJ article. Specifically, I hope to get the sysop(s) of one or more of the newer nodes to document the procedures they went through. After all, they are the real experts on the subject. My discussion here will instead cover only theoretical issues. I hope that even those who have no interest in setting up their own RAS will find such a discussion interesting.

As usual, before I get to the main technical topic, I have a number of other matters to cover first. Here is my list for this issue: Z-Node update, Z-Helpers, GEnie, and BDS C.

Z-Node Update

It has been three issues since the last update on the Z-Node roster, and there have been quite a few changes. The complete list is reproduced in Listing 1. Many inactive nodes have been dropped, and four new nodes have been added.

Chris McEwen's Socrates board in New Jersey is now Z-Node #32. The system is running under NZCOM on a Xerox 16/8 computer. Besides offering general support to the 8-bit community, Chris is a special resource for owners of Xerox computers. Unfortunately, the recent changes in the Newark outdial of PC-Pursuit have cut ZN32 off from a lot of its regular callers. As a result, Chris has switched to an alternative low-cost data transfer service called StarLink.

Briefly, StarLink provides much wider geographical access and full support for 2400 bps connections without the packet-switching delays encountered on PCP. It is more expensive than PCP at higher monthly usage rates but cheaper at lower usage levels. In the future we want to include in the Z-Node roster the StarLink addresses as well as PCP outdials. I'd appreciate it if anyone with such information would could get it to me using any of the methods indicated in the sidebar to my column.

The NYOUG (New York Osborne User Group) Fog #15 node (sysop Livingston Hinckley) has become a Z-Node as well, with the same number 15. The system is running on an Osborne Executive (CP/M-Plus) with the Z3PLUS version of Z-System. It is, thus, the first Z-Node - though, I believe, not the first RAS - to run under Z3PLUS. The board supports data rates up to 9600 bps using a USR Courier HST modem.

Dave Trainor in Cincinnati, Ohio, has signed up as Z-Node #7. His NZCOM-based system has many of the Z-System tools, such as VLU and VFILER, available for use on-line.

Greg Miner established a new frontier for Z-System as he became Z-Node #11 in Port Williams, Nova Scotia. Greg is fairly new to the Z-System but has already made a significant contribution as a programmer. He realized that on properly aliased Z-Systems, a "DIR *.COM" command does not really indicate to the user the commands that are available. So, he wrote ADIR (Alias DIRectory). It examines the ALIAS.CMD file, figures out the names of all the ARUNZ aliases (allowing for the multiply named scripts), and displays a sorted listing of them. A very fine program!

Finally, Ludo VanHemelryck, with assistance from Michael Broschat, will be setting up a new Z-Node in Seattle to replace Norm Gregory's system, which has gone over to MS-DOS. Recently, while on a business trip to Portland, Oregon, I had the pleasure of meeting Ludo and Michael (frankly, I was rather flattered that they were willing to drive all the way down from Seattle), and I think they will do a lot to boost Z-System interest in the Seattle area.

Revised Z-Node list as of May 30, 1989. An "R" in the left column indicates a node that has registered with Z Systems Associates. Report any changes or corrections to Z-Node Central (#1) or to Jay Sage at Z-Node #3 in Boston (or by mail to 1435 Centre St., Newton Centre, MA 02159-2469).

Z-Node List #53
Sorted by State/Area Code/Exchange

      NODE      SYSOP         CITY        STATE  ZIP    RAS Phone      PCP     Verified

    Z-Node Central
    --------------
    R   1 Richard Jacobson  Chicago         IL  60606  312/649-1730  ILCHI/24  05/20/89
    R   1 Richard Jacobson  Chicago         IL  60606  312/664-17330 ILCHI/24  05/20/89

    Satellite Z-Nodes:
    ------------------
    R   2 Al Hawley         Los Angeles     CA  90056  213/670-9465  CALAN/24  05/20/89
    R   9 Roger Warren      San Diego       CA  92109  619/270-3148  CASDI/24  02/01/89
    R  66 Dave Vanhorn      Costa Mesa      CA  92696  714/546-5407  CASAN/12  10/30/88
    R  81 Robert Cooper     Lancaster       CA  93535  805/949-6404            12/29/88
    R  36 Richard Mead      Pasadena        CA  91105  818/799-1632            11/01/88

    R  17 Bill Biersdorf Tampa              FL  33618  813-961-5747  FLTAM/24   (down)
          (node 17 expected to be up beginning of summer)

    R   3 Jay Sage          Newton Centre   MA  02159  617/965-7259  MABOS/24  05/20/89
    R  32 Chris McEwen      Plainfield      NJ  07080  201-754-9067  NJNEW/24  05/20/89
    R  15 Liv Hinckley      Manhattan       NY  10129  212-489-7370  NYNYO/24  05/20/89
    R   7 Dave Trainor      Cincinnati      OH  45236  513-791-0401            05/20/89
    R  33 Jim Sands         Enid            OK  73703  405/237-9282     11/01/88
    R  58 Kent R. Mason     Oklahoma City   OK  73107  405/943-8638
    R   4 Ken Jones         Salem           OR  97305  503/370-7655            09/15/88
       60 Bob Peddicord     Selma           OR  97538  503/597-2852            11/01/88
    R   8 Ben Grey          Portland        OR  97229  503/644-4621  ORPOR/12  05/20/89
    R   6 Robert Dean       Drexel Hill     PA  19026  215-623-4040  PAPHI/24  05/20/89
    R  38 Robert Paddock    Franklin        PA  16323  814/437-5647            11/01/88
    R  77 Pat Price         Austin          TX  78745  512/444-8691            10/31/88
    R  45 Robert K. Reid    Houston         TX  77088  713/937-8886  TXHOU/24  05/20/89
       10 Ludo VanHemelryck Seattle         WA  (new node being set up)
    R  78 Gar K. Nelson     Olympia         WA  98502  206/943-4842            09/10/88
    R  65 Barron McIntire   Cheyenne        WY  82007  307/638-1917            12/12/88
    R   5 Christian Poirier Montreal Quebec   H1G 5G5 CANADA  514/324-9031     12/10/88
    R  40 Terry Smythe      Winnipeg Manitoba R3N 0T2 CANADA  204/832-4593     11/01/88
    R  62 Lindsay Allen     Perth, Western AUSTRALIA 6153    61-9-450-0200     12/21/88
       50 Mark Little       Alice Springs, N.T. AUSTRALIA 5750  61-089-528-852

    Listing 1.
    Z-Node List

Z-Helpers

In the early days, getting ZCPR3 installed on a computer was a very arcane process, beyond the capability of most potential users. Echelon had the wisdom to compile a list of people all over the country (actually around the world) who were willing to help other users get through the process. These people were called Z-Helpers.

Today, thanks to NZCOM and Z3PLUS, getting the Z-System installed is very easy. It's even easy to get started using it, since it can be run just like CP/M. Taking full advantage of its capabilities, however, is another story. With a richness of function comparable to that of Unix, the Z-System can be daunting, but when one remains ignorant of its capabilities, one misses out on a lot of its utility and fun.

In looking over the Z-Helper list that is posted on the Z-Nodes and included with the NZCOM and Z3PLUS packages, I realized that this list has not been updated for many, many years, and most of its information is obsolete. It's high time that the list be rebuilt!

My plan is to discard the current list and start over, keeping only the few people I know to be active still. I would like to expand that list greatly. If you feel that you could be of some assistance to new Z-System users, please send me a post card or short note with the following information: name and address, voice phone number and hours, EMAIL addresses, if any (BBSs, GEnie, Compuserve, ARPAnet, BITNET, etc.), special areas of expertise, if any (specific computers, Z3PLUS). Remember, you do not have to be a Z-System know-it-all - none of us is. Willingness and eagerness to help are the most important qualifications of a Z-Helper, and by working with others, you will end up learning a lot yourself.

GEnie CP/M Roundtable

Some of you may have noticed the change in the sidebar to my article listing a GEnie mailbox for me (JAY.SAGE). GEnie has been making a determined effort to provide support to the CP/M community. The indefatigable Keith Petersen is the main force behind it, and he recruited me several months ago to join the staff as a sysop specializing in the ZCPR3 and Z-System areas.

A system like GEnie offers a significant advantage over individual Z-Nodes: universal connection. With the Z-Nodes, if you want to leave me a message, you have to call one of the Z-Nodes that I call into regularly, and then you have to call around again to see if and where I might have left a response. Systems like GEnie and Compuserve offer central communication points readily accessible from most places in the US and Canada (and with worldwide access developing rapidly - Japan is on-line already).

One of the activities on GEnie is called a real-time conference (RTC), in which users can communicate interactively. These conferences are held on many subjects. The CP/M RTC takes place every Wednesday evening at 10 pm eastern time, with the first Wednesday session of each month generally led by me and earmarked for Z-System discussion. So, if you have questions or suggestions that you would like to discuss with me and other Z-System users, please consider joining us on the GEnie RTC. If you don't already belong to GEnie, check BBS systems near you for information on a special GEnie signup offering that gives you $20 of free connect time as a new registrant.

BDS C Update

A couple of issues back I announced that a special Z-System version of BDS C would soon be available, and a number of people have been asking me about its status. The standard CP/M version 1.60 of BDS C has been available about a year already, and a working Z-System version is now being sold. We will probably eventually make a few more changes (such as adding support for type-3 program generation). In that case, everyone who ordered the earlier version will be offered an update at a price not to exceed the cost of media and shipping.

Some people have criticized the $90 price, comparing it to Turbo Pascal, which sells for only $60. What they don't realize is how much more one gets with BDS C for the extra $30. Listing 2 shows the contents of the four DSDD diskettes in the release, comprising well over 100 files and more than a megabyte of material!

First there are the core COM files you would expect: the compiler (CC.COM), the code generator (CC2.COM), the linker (CLINK.COM), and a librarian (CLIB.COM). CC, CC2, and CLINK come in both standard CP/M and Z-System versions, with separate run-time packages.

Then there is the stuff that almost no one gives you - the source code. True, you don't get the source for the core items, but you do get source code for everything else. Assembly-language source is included for the run-time package, and C source is provided for the collection of standard libraries. Some of the items are provided only in C source code; you have to compile them to produce COM files configured for your system and tastes. This includes two assemblers - one that uses Intel mnemonics (CASM) and one that uses Zilog mnemonics (ZCASM) - and a symbolic debugger (CDB). And while you don't get the source for CLINK, you do get the source for another linker, L2, that has even more capability (such as handling code that won't all fit in memory at one time).

RED, an editor with special hooks into the C error listing, is also provided, again in source form. You also get a number of sample programs, ranging from simple ones like CP (copy files) to an implementation of the MODEM7 file-transfer protocol (CMODEM.C). [P.S. If you absolutely and irresistibly crave the assembly-language source code to the BDS C core components (for personal use, not resale, of course), they can be purchased as an extra option for $200.]

Support is another important issue. Who supports Turbo Pascal? The same people who when asked about Turbo Modula 2 vigorously deny that they ever offered such a product at all! [Alpha Systems, unfortunately, acquired only the right to sell Turbo Pascal; Borland did not give them the source code and does not allow them to maintain it.] With BDS C, the situation is quite the opposite. On page 1 of the BDS C manual, at the top of the page, author Leor Zolman's personal phone number is listed, and he not only invites you to call him, day or evening, he actually is happy when you do!

In short, BDS C is a remarkable product from a remarkable programmer.

    XD III  Version 1.2   Standard BDS C, Version 1.60
    Filename.Typ Size K RS  Filename.Typ Size K RS  Filename.Typ Size K RS
    -------- --- ------ --  -------- --- ------ --  -------- --- ------ --
    CCC     .ASM     34     NOBOOT  .C        2     DEFF2B  .CSM     24
    BUILD   .C        6     RM      .C        2     DEFF2C  .CSM      8
    CASM    .C       24     STDLIB1 .C        8     WILDEXP .CZ       6
    CCONFIG .C       12     STDLIB2 .C        8     CDBUPDAT.DOC      6
    CCONFIG2.C        8     STDLIB3 .C        6     FILES   .DOC      4
    CDB     .C        6     TAIL    .C        2     CCONFIG .H        2
    CHARIO  .C        4     UCASE   .C        2     CDB     .H        4
    CLOAD   .C        4     C       .CCC      2     CDB1    .H        2
    CMODEM  .C       12     CC      .COM     16     CMODEM  .H        2
    CMODEM2 .C        8     CC2     .COM     18     DIO     .H        2
    CP      .C        6     CDB     .COM     16     HARDWARE.H        4
    DATE    .C        4     CLIB    .COM      6     STDIO   .H        2
    DI      .C        4     CLINK   .COM      6     BDS     .LIB      6
    DIO     .C       10     DEFF    .CRL     12     READ    .ME       4
    L2      .C       26     DEFF2   .CRL      6     C       .SUB      2
    LPR     .C        4     DEFF2A  .CSM     20     CASM    .SUB      2
         F  1:  --   48 Files Using   384K (   18K Left)

    XD III  Version 1.2   Standard BDS C, Version 1.60
    Filename.Typ Size K RS  Filename.Typ Size K RS  Filename.Typ Size K RS
    -------- --- ------ --  -------- --- ------ --  -------- --- ------ --
    ATBREAK .C        4     RED3    .C       26     BCD2    .CSM     24
    BMATH   .C       22     RED4    .C       20     DASM    .CSM      2
    BREAK   .C        4     RED5    .C        4     BUGS    .DOC      2
    CDB2    .C        2     RED6    .C        2     CRCK    .DOC      2
    CDBCONFG.C        6     RED7    .C        4     BDSCIO  .H        4
    COMMAND .C        6     RED8    .C       14     CDB2    .H        4
    DEMO1   .C        2     RED9    .C        2     MCONFIG .H        2
    LMATH   .C        2     TARGET  .C        4     RED     .H        6
    LONG    .C        4     TSTINV  .C        2     RED1    .H        2
    PARSE   .C       12     UTIL    .C        2     REDBUF  .H        4
    PRINT   .C       10     CRCK    .COM      2     RED-READ.ME       4
    RED10   .C       14     RCONFIG .COM     24     CDB2    .OVL     20
    RED11   .C       18     CRCKLIST.CRC      4     CRED    .SUB      2
    RED12   .C       16     BCD     .CRL     16     L2RED   .SUB      2
    RED13   .C        6     DASM    .CRL      2     LRED    .SUB      2
    RED14   .C        6     DEFF15  .CRL     10     NULL    .SYM      0
    RED2    .C       14     BCD1    .CSM      8
         F  2:  --   50 Files Using   376K (   18K Left)

    XD III  Version 1.2   Special Z-System Files
    Filename.Typ Size K RS  Filename.Typ Size K RS  Filename.Typ Size K RS
    -------- --- ------ --  -------- --- ------ --  -------- --- ------ --
    -BDSZ   .         0     CC2     .COM     18     DEFF2A  .CSM     20
    CCC     .ASM     50     CCONFIG .COM     20     DEFF2B  .CSM     24
    CP      .C        6     CLINK   .COM      6     ZUTIL   .CSM      2
    DI      .C        4     TAIL    .COM      6     STDIO   .H        2
    ECH     .C        2     DEFF    .CRL     12     BDS     .LIB      8
    TAIL    .C        2     DEFF2   .CRL      6     READ    .ME      18
    WILDEXP .C        8     DEFF3   .CRL      4     CASM    .SUB      2
    C       .CCC      4     TAIL    .CRL      2     NDEFF2  .SUB      2
    CC      .COM     16
         F  1:  --   25 Files Using   244K (  420K Left)

    XD III  Version 1.2   Zilog-Mnemonic Version of Assembler
    Filename.Typ Size K RS  Filename.Typ Size K RS  Filename.Typ Size K RS
    -------- --- ------ --  -------- --- ------ --  -------- --- ------ --
    -ZCASM  .         0     ZCASM   .DOC      8     READ    .ME       2
    ZCASM   .C       24     --READ--.ME       2     ZCASM   .SUB      2
    ZCASM   .COM     18
         F  2:  --    7 Files Using    56K (  420K Left)

    Listing 2.
    Files that comprise the four DSDD diskettes in the Z version of BDS C
    (directories captured using the BGii SCREEN command).

Remote Access Systems

I had hoped by now to have gone through the process of completely revamping the RAS software on my Z-Node. It has been many years since I designed that system, and I really do not remember all the details of what I went through. Being the sort I am, I made a great number of custom modifications to all the programs, and, as a result, I have been stuck using old versions of everything. I use a derivative of BYE503 when the latest version is BYE520; I run a modified KMD09 when KMD has not only advanced to a much higher version number but has really been superceded by Robert Kramer's excellent ZMD. Admittedly, I already incorporated a number of the improvements that these versions offer; nevertheless, my node is quite outmoded.

With the TCJ column as an excuse to look into all these new developments, I thought I would be able to modernize Z-Node #3 and be able to tell you how to go about creating a new Z-Node in the easiest possible way. Alas, as usual, I have been too busy with other things. As I said earlier, I hope to get one or more of the new Z-Node sysops to contribute articles to TCJ on this subject.

Since I can't give a prescription for creating a standard remote access system (RAS) using the current software, I will instead discuss some of the basic concepts behind a remote access system and the ways in which Z-System facilities can be used to advantage. The standard RAS software is designed to work under standard CP/M and is far less efficient than it could be.

I/O Redirection

Once you have a secure Z-System running, as we described last time, the next step is to make it possible for the system to be operated via the modem. The standard software that does this is called BYE, and it traces its roots all the way back to the work of Keith Petersen and others from the days of Ward Christensen's first remote CP/M (or RCPM) system in the late 1970s.

A great deal of development has occurred since that time, and BYE now provides a rich array of services. Its essential function, however, is to provide redirection of the console input/output functions. Program input is allowed to come not only from the local keyboard but also from the modem; program output is sent not only to the local screen but also to the modem. In this way, either the local operator or the person connected via the modem can operate the computer. With a secure Z-System, this alone would be enough for a rudimentary RAS.

BYE works by installing itself as an RSX, or resident system extension, generally just below the command processor. It patches the data in page 0 of memory (this is where programs find out how to request services from the operating system) and in the actual BIOS. These patches do two things. They protect BYE so that a warmboot will not result in its removal from memory, and they allow BYE to intercept software calls to the BIOS and DOS from any running programs. BYE can then substitute its own additional or special functions.

In a Z-System, the extended character I/O functions of BYE could properly be implemented using an IOP (Input/Output Package). The IOP is a generalization of the concept from early CP/M of the so-called IOBYTE, which was controlled by the STAT command and used to select from a fixed set of I/O devices (up to four possibilities in the case of the console). Richard Conn conceived of the IOP module as a way to handle just the kind of I/O operations needed for a RAS, and his book, "ZCPR3, The Manual," has some examples of this. Alternatively, the BIOS functions could be implemented directly in an NZCOM VBIOS (virtual BIOS), which could be loaded as needed.

Consider the case where the console is an external terminal connected to an RS232 serial port. The standard BIOS CONOUT (console output) function takes the character in register C and sends it to that serial port. For a remote system, the BIOS would send the character first to the terminal's serial port and then to the modem's serial port.

Similarly, the standard BIOS CONST (console status) function checks the terminal's serial port to see if a character has been received. If so, it returns with a nonzero value in register A; otherwise it returns a zero value. For a remote system, the CONST routine would check both serial ports and return a nonzero value if either one has a character ready. CONIN (console input) would poll the two serial ports alternately until it got a character from one or the other of them.

Conceptually, this is really all pretty straightforward. The biggest problem is that the code depends on the specific computer hardware, so no universal routines can be supplied. The BYE program has been cleverly designed, like an operating system, with the hardware-specific code separated from the hardware-independent code. As a result, customized versions of BYE can be assembled easily by putting source code inserts for one's specific hardware at designated places in the master file. There are two collections of inserts, one for many computer types and one for many types of real-time clocks (more about this later).

There are also some fine points about how the console redirection is handled. BYE, of course, knows the difference between the local console and the modem and can treat them differently where appropriate. For example, since modems commonly produce certain noise characters that rarely appear in intended input (such as the left curly brace), these can be filtered out (i.e., ignored). Also, some special functions can be assigned to local control codes. For example, pressing control-N at the local console will immediately end the callers session (used when the sysop doesn't like what a user is doing); on the other hand, control-U removes any connect time limit, and control-A allows special access by turning on the wheel byte (toggling it, actually).

The screen output can likewise be handled differently. Pressing control-W locally causes a local display of the current caller's name. Something I added to my version of BYE was a filter that prevents escape sequences from going to the local console. I allow (encourage) users to take advantage on-line of virtually all Z-System capabilities, including the full-screen utilities like ZFILER, ZMANAGER, and VLU. When I first started to do this, I found that the escape sequences going to the users' terminals sometimes did very bad things to my own terminal (the smartest terminals, like the Wyse and Televideo models, have the worst problems; they have sequences - that cannot be disabled - that lock out the keyboard!). I simply borrowed the code used in BYE for the incoming-character filter.

Modem Initialization and Call Detection

The first real complication we have to face is that the actions described above make sense only after the local modem is in communication with a remote modem. Consequently, BYE has traditionally been given the additional task of initializing the modem and monitoring it for an incoming call. A 'smart modem' (one that processes the Hayes "AT" commands and returns the Hayes result codes) is generally assumed, though BYE apparently will work with other modems to some extent.

The standard procedure today for answering calls (unless it has changed again since my BYE503) is not, as one might have expected, to set the modem to auto-answer mode. There are some subtle reasons why this is less desirable. Instead, BYE monitors the modem port for an output string from the modem indicating that it has detected a ring signal. This string will be "RING" if the modem is in verbose mode or "2" if it is in terse mode. BYE then sends the command "ATA" to the modem so that it will answer the call. Then BYE waits for another string that indicates the data rate of the connection; in terse mode these are "1" for 300 bps, "5" for 1200 bps, "10" for 2400 bps, and other values for higher speed or error-correcting modems. Finally, the serial port is synchronized to the modem's data rate.

If no connect indication is received within a prescribed time, BYE recycles the modem to make it ready for another call. Once a connection has been established, BYE generally displays a welcome message, and it may ask for a password. Then it loads an initial program, typically the bulletin board program.

The functions we just described do not really have to be handled in BYE at all, and TPA could be saved (remember, the BYE code remains resident in high memory at all times) if they were performed by a transient program. With a Z-System there is also no need for BYE itself to load a program file into memory. All it has to do is place a command line into the multiple command line buffer. This requires much less code and is faster and more flexible. Moreover, the full power of the command processor is available to locate and load the program code. Resident, type-3, and type-4 programs can be used. I modified my BYE to load the simple command line STARTRAS, which, as you probably guessed, is an alias (it can be an ARUNZ alias, in fact). This makes it very easy to make changes and experiment.

Carrier Monitoring

There is one further function of BYE that cannot easily be performed anywhere else. That is monitoring the carrier-detect line for a loss of connection. After all, a caller might hang up or become disconnected at any time. Some special clean-up functions must then be performed. The currently running program must be aborted, any system maintenance functions performed (such as updating the database of caller information), and the modem must be reset and readied for another call. Without going into any detail, I do want to point out that terminating a running program can be tricky, especially if file I/O is in progress.

Besides detecting when a user disconnects, either voluntarily or accidentally, BYE can also enforce a time limit on the caller. For many of its timing functions, BYE requires a real-time clock. As I mentioned earlier, there is a library of clock inserts that can be installed in the BYE source before it is assembled.

This completes the discussion for this issue. So far we have touched on the BIOS and modem-control functions of BYE; next time I plan to take up the DOS services that BYE provides.

[This article was originally published in issue 40 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]