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).
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
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]
