SAGE@LL.ARPA (06/12/87)
I am always sorry to see certain myths perpetrated about ZCPR3,
especially the ones that say ZCPR3 is good only on hard-disk systems and
that it uses up too much TPA. Different people have different personal
styles in computing, and some will like the way ZCPR works and what it
offers while others will not. But the choice should be made on sound facts
and sound reasoning.
It is only in the last year that I have had any personal 8-bit computer
system with a hard disk (I still do most of my work on a BigBoard I and
SB180 with only floppy drives), and I have always used ZCPR (1, 2, and 3) to
what I felt was great advantage. It is certainly true that ZCPR3 runs much
better on the hard-disk and RAM-disk systems, but what doesn't? ZCPR3,
because of its various forms of extended processing (path searching,
extended command processing, and error handling) does tend to be more disk
intensive. In one of my columns in The Computer Journal I described
techniques that can be used to significantly speed up these features with
floppy systems to the point that they approach hard-disk performance levels.
As for the reduction of TPA, it is quite true that a full-blown ZCPR3
implementation uses up a lot of TPA -- between 4K and 6K. In the kind of
work I do (wordprocessing, assembly language programming, and operation of a
remote access computer system), TPA is not a problem, and I have even opted
to use larger than standard RCP, FCP, and NDR modules for the conveniences
they offer. I understand that people who use C compilers often have
problems getting enough TPA space (sounds as though someone should write a
good virtual-memory C compiler like the SLR Systems virtual assemblers).
Although a full-blown ZCPR3 system uses lots of memory, it is not a
fair comparison to contrast CP/M -- with virtually none of the features --
only with ZCPR3 in its largest configuration. One can make a ZCPR3 system
that costs only 0.75K bytes of TPA that offers:
automatic command search path (dynamically changeable)
multiple commands on a line (200+ characters)
aliases (infinitely nestable and recursive with extensive
parameter expansion capability)
extended command processing (highly efficient and powerful
ARUNZ alias generation)
nested shells (including command line history with recall,
searching, and editing)
error handling (with command line editing)
terminal-independent operation (UNIX-like TCAP)
Thus, as with so many things in this world, more than 80% of the features
come with less than 20% of the cost.
The components in ZCPR3 that cost big memory are the ones that can most
easily be omitted: the named directory register (NDR, 0.25K per 14 names),
the flow command package (FCP, typically 0.5K), the resident command package
(RCP, typically 2K), and the input/output package (IOP, typically 1.5K). I
have had little use for an IOP and do not have it in use on any of my
systems (though many people like the I/O redirection and keyboard macro IOPs
that are available from Echelon). With my larger-than-usual NDR (35 names),
FCP (0.625K), and RCP (2.25K), I sacrifice a total of 4.25K of TPA. When I
use my database manager, the only program I use that does make heavy demands
on TPA, I will just boot up the small ZCPR system. I can afford the cost of
0.75K. In ZCPR version 3.3, by the way, the NDR, FCP, and RCP modules can
be configured dynamically, making it even easier to change the system
configuration.
I hope that some people will look more carefully before they dismiss
ZCPR3 as too big or too slow or too hard to use. It might not be the thing
for you, but then again it might.