To: Jay Sage, Bridger Mitchell, et al--

(Uploaded to addressees' respective Z-Nodes November 9-10 1988)

Miscellaneous minor hangups, fixes, questions, etc., encountered in 
installing an elaborate Z3PLUS system on a Morrow MD-5:

Note:  this installation uses LARGE version of Z3PLUS as its default system.
Most of the following matters are probably problems with supporting  utilit-
ies, not with Z3PLUS itself... Will pass comments to more appropriate people
if you can identify who ought to get what.  I'll check back to the two nodes
later in the month.

This is probably overwritten,  but I seem to be incapable of suppressing all
my opinions.   I'll beg for your forbearance and send this off as is;   I've 
taken too long to pull these comments together and don't want more delays.

Besides, Sage at least is guilty of the same sin;  indeed,  his  tendency to 
digress is one of the things that makes his stuff in TCJ interesting and fun 
to read.  Mitchell could be similar but I haven't read enough to be sure.

1.  EDITNDR: VERY fussy.  Has tendency to hang system. Achieved best results
    by saving after each added name. Once one learns not to give up but keep
    on trying, larger NDR can be defined without too much difficulty.

2.  SALIAS: similar problem to EDITNDR: fussy!  Hangs, especially with rapid
    use of editing commands. Like EDITNDR, not used very often (only for the
    STARTZ3P file and the ST.COM files in some directories) so not much of a
    problem.  Haven't tried the old MKALIAS routine on the MD-5, but I'd bet
    that it would not exhibit the same problems...

    Problems (1) and (2) are so alike in their effects that it makes me won-
    der if the source files for both programs might have called on the  same 
    (presumably flawed) subroutine from SYSLIB or a similar source...  Don't 
    have source code, so can't check this guess.

3.  System hangs up on exit of command to format floppy disk;  fixed with an
    alias, as follows:

    format     [echo <text message>;pause;]fmt b d;r

    The key to avoiding hangup is "r" reset command after FORMAT in multiple
    command line.  The text message isn't essential, mine just tells user to 
    place disk to be formatted in Drive B.  "Pause" is public domain "pause"
    (similar to SAK=Strike Any Key) command.  "FMT" is renamed Morrow FORMAT 
    command (HD version). Solution also helps add a little extra security to 
    FORMAT...  I don't have the foggiest idea why this works but it does...

4.  VLU 1.0 will sometimes not load;  system reports BDOS error finding file
    "????????.LBR."  Haven't figured out why.  Happens only once in a while;
    doesn't seem to happen at all under conventional menu-driven operations.
    Problem goes away after rebooting system. VLU also gives incorrect space 
    remaining on disk... Other VLU problems mentioned in the comments in the
    VLU101.LBR file also apply,  like extracting empty files when a disk has
    filled up.  Novosiekski's original LU also did that;  turned out to be a
    useful feature,  sort of,  for a kludge routine I used to use to catalog
    files in libraries  (I extracted them to a full disk to get a quick dir-
    ectory of names for the update routines).    This is not to say that the
    bug shouldn't be fixed!   The buggy VLU is still a nice program, and for
    the moment--unless I run into more problems--I plan to leave it in place
    as an adjunct to ZFILER and ZMANG, at least until Version 2 comes along.
    
5.  ZMANG21C has same problem with remaining space report as VLU.  Also:

    The list of built-in commands stored in the form of a HELP screen within 
    ZMANG itself incorrectly reverses the alternate commands to  go  to  the
    next/previous screens. The real commands are the logical ones: "+" to go 
    to the next screen, "-" to go to the last screen.  Both actual functions 
    are okay, it's the listing that's wrong.   I did a kludge fix on my copy 
    of ZMANG by changing the command explanations, but it would be better to 
    fix the actual command locations in the list, so  they follow a sensible 
    order.  Looking at the configuration notes provides some clues here, but
    I haven't taken the time to follow up on that yet.

    The command to Jump to any file has been lost.  Instead, the list of in-
    ternal commands gives ^B as the jump command, same as go to  the  bottom
    of the screen.  No other control character yields the jump prompt.   One
    could easily provide a substitute menu command to  jump to any file,  by
    resetting the appropriate system file,  I guess,  but  this still leaves 
    the program with an error in its innards.

    Also: the prompt to "rename R/O files anyway?" garbles the filename. All
    in all, this begins to sound like some of the comments in the VLU101.LBR
    and again I wonder: could these problems relate to some source macro li-
    brary used to assemble both programs?

6.  EASE appears to interfere with the Morrow KEY  function  key  assignment
    utility,  slowing it down so that stored key assignments come  out  only
    one character at a time. Fooling with KEY's "SWITCH _FST" functions does
    not help.  Cured, sort of, by using single-character aliases for any key
    assignments  needed,  then hitting function keys twice  (required second 
    character is the carriage return).  Trying SmartKey with SKEYPAT did not 
    cure this problem (must admit I did not try real hard, though; I've been
    using the Morrow program exclusively because it works fine with ZCPR3).

    EASE is such a good program that I happily accept these few drawbacks...
    I had become so used to the shareware CED command editor for DOS systems
    that I could not stomach using IBM-standard machines without it; carried 
    around a floppy disk with CED and other essential DOS add-ons, so when I
    was asked to fix somebody's problem I would not have to work with crappy 
    tools. The problem with EASE is that it now makes me impatient with CED.
    I bought PCED from Cove for my office system but never got around to ac-
    tually installing it--I was just paying my shareware dues--so now I sup-
    pose I'll have to finally look at it to see if it can search its history 
    file.  See how Z systems have a way of complicating your life?   Haven't 
    even tried VCED; the documentation gave me the impression that a command 
    has to be issued to use the editor, which seems silly.

7.  DU Version 8.9 works fine with the MD-5's hard disk, CP/M-3, and Z3PLUS.
    (My  copy of this program turned up inside a Version 8.7 library  file.)
    One exception:  "M" command for producing file allocation map results in 
    a hung system (NB: I have NOT implemented time/date stamping on the sys-
    tem; directories seem to be standard Morrow-style format). Still, better 
    to have some disk editor capability than none...  Christensen's stuff is 
    going to be around forever.  This helps make up for the loss of DU3...

8.  Is there a way to use an alias,  SUBMIT file,  CP/M-3 GET file, or other
    facility to carry out this sequence without other user actions:  exit to 
    CPM3/run a program/reload Z3PLUS...  Also: is there a way to tell Z3PLUS
    >>not<< to run the usual STARTZ3P sequence, so that it doesn't run a set
    of boot-time screens whenever one returns from a temporary exit to CPM3?
    I have memory hog programs, in particular an enhanced version of the oft
    maligned PEARL relational DBMS, and for these I would like access to the
    full 62K TPA that I can get with CP/M-3.0... 

9.  (Late addition) Occasional "ovfl" report on longer (typically 100+ chars
    but less than 150 chars) command lines.  Assume due to other stuff  (Z2-
    type shell commands, expanded aliases, whatever) in MCL buffer...  

    Effects of this can be hard to judge,  since the overflow condition does
    not show up until the part of the command to be expanded  is  processed.
    For self-evident reasons, the overflows tend to occur early in executing
    lengthy lines (while there's still lots of stuff waiting to be called in
    the buffer); my impression is that the tail of the line gets  truncated, 
    but since the problem is rare and I haven't deliberately tried to get it 
    to occur, I can't say for sure...  

    Is this a problem?   Well,  that depends on how we define "problem";  in 
    this case, I believe we have an example of how new ZCPR features lead to 
    new and possibly unexpected kinds of complications.

    First, users without a lot of previous exposure to Z systems--you should 
    be hearing from such folks,  since in effect you are introducing ZCPR to 
    the CP/M-3 community--may need to be warned that having a  250-character 
    MCL buffer doesn't automatically mean that the system will always accept 
    up to 250 characters from the console,  especially when the command line 
    includes things like aliases that can significantly expand the  contents
    of the buffer.  Ain't no free lunches, not even with Z3PLUS.

    In my judgement this glitch is a more serious drawback  for  experienced 
    users than for neophytes.   New users can simply be warned to keep their 
    command lines down to an 80-character line or so,  until they've  gotten
    fully conversant with the system, just to play it safe--they're probably 
    gonna do that anyway,  since good understanding of the command  mode  is 
    needed to come up with long lines in the first place.   But for the more
    experienced users, the weakness becomes more serious because it leads to
    uncertainty about just how hard one can press the system's  limits,  and  
    therefore to a tendency to play it safe, and that's not a very satisfac-
    tory solution...   Of course if you've memorized the exact length of all
    your aliases and can instantly intuit what expansion will do,  including
    possibilities of aliases calling still other aliases, then this is not a
    problem.  Sure.  Uh, huh.

    Maybe one solution is a patch to flush the line when an overflow  condi-
    is detected.  At least that way you could use the system freely, knowing
    that at least you will not get into trouble because some subsequent com-
    mand in the line has been truncated, leading to unexpected results.  But
    that wouldn't save the user if the truncation affected the current  com-
    mand  (I suppose that ain't very likely, but read on).   There is a more
    generalized version of this dilemma in that it isn't easy to halt a line
    of commands once they've been initiated.  I wonder how many other Z sys-
    tem users have suddenly realized, as I have a couple of times, that they 
    were better off punching a reset button, rebooting the system, than they 
    would be to allow a possibly disasterous line of  multiple  commands  to 
    run on to completion.  To deal with that one, I suppose some sort of RSX 
    would be needed to monitor keyboard output,  watching for a "Hey, stop!"
    order.  I don't like this approach much, it seems out of place in ZCPR.

    Might be nice to have some sort of facility built into EASE that accepts
    command lines, expands aliases, and then invokes the error handler if an
    overflow condition is indicated...as it stands, the error handler is NOT
    invoked  (I suppose it would be if the truncation resulted in a nonsense
    command, but so far that doesn't seem to have happened; instead the line
    just stopped early). If such an "improved" version of EASE slowed things
    down a lot, though, I'm not sure that I'd use it...  There's going to be
    a tradeoff between secure operations and responsiveness.

    Seems to me that the more one begins to use elaborate aliases--which are
    certainly encouraged by Z3PLUS and ARUNZ--then the less workable  is the
    traditional rule of thumb that a 250-character MCL buffer is big  enough
    for almost all anticipated situations.   To the contrary,  I wouldn't be 
    surprised to see some users start to go to 512 bytes...  Probably a good
    sign that one is about to hit the limits is when you decide you need  an
    alias to facilitate editing the ALIAS.CMD file (yeah, I have one). I can
    imagine an ultimate case in which I add a single-character alias to  the
    .CMD file that leads to all kinds of expansions in a 1,024 byte MCL buf-
    fer, enter the single character and get an immediate "overflow" message.

    There is this urge to have the bullet proof system...  All the Z systems 
    I have done are set up to be workable as demo installations that can  be 
    explored by completely unschooled users, while also being attractive and 
    interesting to people with lots of computer smarts. The MD-5 is intended
    to be capable of providing an unattended computing demonstration  system
    for public use in settings like local libraries/schools/museums,  so the 
    desire for better bullet proofing ain't just a matter of aesthetics...

    This dilemma applies to any system using aliases and especially to those
    using ARUNZ, n'est-ce pas?

    By the way, I was a little irritated by the roundabout way  Z3PLUS  (and
    ARUNZ) documents the DEFAULT alias...  'Tain't fair to play  games  with 
    users to the extent of expecting all of them to learn about this by tak-
    ing a look at the notes on LX. Suppose somebody wants to default to some
    other command?  Nowhere, so far as I can tell, are folks told that their
    DEFAULT alias better be the last one in the file.  If they put it at the
    start, the problem is self-evident,  but why not just state  the  rules?
    The coy hint in the Z3PLUS documentation is enough to tell  people  that
    somewhere there will be info on chaining to another ECP,  but  I  wasn't
    happy taking up a couple of hours to check this out...  Also by the way,  
    you oughta run the public domain INDEX routine on the Z3PLUS docs.

10. Some plain vanilla RSX's seem to fail under Z3PLUS (I haven't tested all
    of these without Z3PLUS so this is not a firm conclusion but rather it's
    a matter of possible early warnings or needs for advice)...  For example
    HP+ (HP reverse polish calculator as an RSX), DP (RSX for deferred print
    management), etc.  I ain't no expert on CP/M-3; my current sense is that
    RSX's probably present some similar or at least analogous problems as do
    DOS TSR's...   Z3PLUS users may need more guidance/intelligence on these
    matters...  I get some funny behavior even from the standard CP/M-3 sys-
    tem utility PUT--it appears to insist on using full syntax:  if the sup-
    posedly optional words are left out in a request to redirect the console
    output to a file, the command quits working after the first line  and  a
    half  of  output...  Without other guidance I assume that if I  want  to 
    use any of these facilities what I should try next is to check out where
    they are trying to load... I get some location reports that seem just  a
    tad out of whack; makes me suspect system leaves Z3LDR RSX in place, be-
    low the start of the Z3PLUS CCP itself.  More technical documentation on
    Z3PLUS may be in order here, or maybe a piece by Mitchell in TCJ...  For
    all I know maybe these RSX's (including the original DRI PUT) are buggy.

11. Related to the above,  another minor hindrance is that EASE seems to in-
    tercept stuff I would rather have it pass along untouched, like  the HP+
    program's Control-^ command (to invoke it as a pop-up) and the Control-P 
    function to toggle printer output (or have I just missed some other EASE 
    function? I'm editing this on a DOS system at my office, can't check the 
    full list of EASE commands here. Arrrgh)...  Re comments in (10), above,
    I did try HP+ without EASE to see if that was my only problem,  but that
    didn't help... Judging by the comments in EASE14.LBR (I think that's the
    version), you can change EASE's input commands but not its outputs; may-
    be the program needs to include room  for  two  or  three user-definable  
    output commands.  I seem to vaguely recollect that the EASE14 documenta-
    tion mentioned a command to simply pass along a character but that I had
    not noticed such a command in the (actually installed) version of EASE I
    got with Z3PLUS.  Maybe I better look again...

    Don't-feel-like-wasting-your-time-but-on-the-other-hand-why-withhold-on-
    compliments section:

    Z3PLUS is super.  The problems are trivial.  I have been setting up ZCPR
    installations on Morrow computers for myself and some friends since 1983
    and this one is clearly the best yet...  I will probably want to pick up
    NZ and ZSDOS for the floppy systems when (if I ever) get done with  this
    conversion, which has turned into a monster project (2,500K of software,
    1,000K of games, 600K of HELP,  catalog of around 2,000 files in program 
    archives, etc., etc.)...

    I had done applications and installations for a couple of MD-11 systems, 
    but until the release of Z3PLUS,  I wasn't personally interested in  the
    hard disk Morrows because they couldn't use ZCPR (true, EZCPR will work,
    but that's a poor substitute for the real thing; Lopushinski's CCP+ ser-
    ies probably works fine for RCP/M uses, but it doesn't provide the other
    ZCPR features I value in personal work stations).  CP/M-3 is such a pain 
    in the butt,  with its brackets all over the place and verbose syntax...
    About all that could be done with it was to write dozens of little batch 
    files to give users some shortcuts  and a limited menu-driven interface.  
    Z3PLUS transforms the hard disk Morrows as much as the earlier Z systems 
    transformed the floppy machines; it makes them desirable.  Right now,  a 
    used MD-5 can be had dirt cheap  (mine cost just $300, complete with the 
    very fine MD-70 terminal and a large bundle of software).  This  kind of 
    change is the essence of what the Z systems have meant to many of us:  a 
    way to turn inexpensive CP/M systems into state-of-the-art computing in-
    stallations.   That  kind of combination of low cost and high power is a 
    definition of good value...

    My congratulations and respect to both of you and to Joe Wright.  I will
    do what I can to spread the word.   If other purchasers of Z3PLUS in the
    D.C. region need no-cost (and no promises) help,  I'll be willing to try 
    to provide it.
    
    October 25-November 9, 1988

    Dick Ellis  
    21 10th Ave
    Brunswick MD 21716
    
    Home phone: 301/834-7976
    
    Office: 202/546-2237 (Director, Engineering Manpower Commission, American 
      Association of Engineering Societies, Washington, D.C.)

Postscripts--

1.  To Jay Sage: your comments in latest TCJ on Z2/Z3 shells read with 
    interest. I agree with your position.  I can see some people wondering
    if they oughta convert back to Z2 VFILER... Actually I suspect the
    problem may not be terribly serious unless one has WS4 and uses it
    your way as a primary shell (that is, making a lot of use of the "R"
    command.  Will WS4 let you Run a Program while editing a file, without
    going back to a no-file menu?  If so that makes WS4 more tempting than
    I had realized)  ...I suspect my habits are more common for most users;
    they reverse your practice (as I understand it, anyway).   I use the 
    filer utilities or ZMANG as a primary shell and run editors like NewWord
    from them, and I like the way Z3PLUS lets users stack up these shells
    (EASE/MENU/ZMANG, for example) so that as each is popped the system goes
    back to its earlier state without a hitch.  Probably people are going to
    find that both Z2 and Z3 versions of some shells make sense, depending
    on the application or system state...  A cute solution would be to set
    up a single shell to be loaded either way, either with a command line
    parameter or with a get/poke/go sequence.

    I have been saying for some time that RCPM sysops were too hasty in
    dumping ZCPR2 in favor of ZCPR3.  There are some situations where the
    Version 2 system has a lot to be said for it, especially since it's
    possible to have it without relocating the system image at all (at
    least on a Morrow, a one-line (78 char) MCL buffer can be slipped into 
    the Zero Page of memory; sophisticated users have to watch out for the 
    fact that they can conflict with the space reserved for DDT and related 
    jumps to high memory, but that's the only gotcha with this approach).  
    Most of the original Version 3 features can be emulated with utility 
    programs on such a system.  NZ-COM probably finally lays this to rest as 
    far as full-scale systems are concerned, but your column seems to imply 
    that some ZCPR2 utilities might be resurrected, in effect (actually, I
    suppose newer programs would be reconfigured)... 

2.  To Bridger Mitchell: I assume that there have to be serious hardware-
    related reasons why access to Bank 0 on a 128K CP/M system is as limited
    as it seems to be... Surprisingly little intelligence seems to be around
    on this, all I find are some tips from Hattwell-Batten (spelling? --the
    sysop at the Tesseract RCPM in New South Wales, Australia) plus some
    utilities to inspect Bank 0 memory from folks like Kim Levitt and Jim
    Lopushinski...  Lopushinski's Meadowlark RCPM seems to have disappeared
    from listings, by the way, as has the CP/M 3.0 collection point at 
    Syracuse, N.Y.; I have a limited older collection of CP/M 3.0 utilities 
    and other support files from those sources, but am having trouble locating
    a current source for anything newer...  Can't help suspecting that I've 
    got lots of unused RAM in Bank 0...  Do you know of any sources (RCPMs or 
    others) on these kinds of issues?  Know of utilities to make added uses of
    Bank 0 (a ramdisk, for example)?  Gonna do BGPLUS?