rconn%brl@sri-unix.UUCP (11/23/83)
From: Rick Conn <rconn@brl>
To date, I have only received seven replies to the query
I sent out on the current state of ZCPR2 and the two questions on
retaining features. CCP GROUP has had tons of traffic on a lot
of issues as well, and the following summarizes the data to date:
Question 2: Should disk-based named directories be
retained? Yes - 1, No - 4; My Decision: NO
Comment 2: Loss of disk-based named directories has only
one disadvantage that I can see -- the tree and mesh structures
possible with them are no longer possible. With only memory-
based named dirs and the DU form, only a flat directory structure
is possible (with current mode of thinking). Loss of disk-based
named dirs has one major advantage -- all major ZCPR2 utilities,
including XDIR, XD, VFILER, ERASE, RENAME, PROTECT, MCOPY, etc,
will be smaller now and run faster.
Question 3: Should disk-based command files ($$$.SUB) be
retained? Yes - 2, No - 5; My Decision: MAYBE
Comment 3: Again, with ZEX around, SUB2/SUBMIT are not
necessary by and large. The only good reason to retain $$$.SUB
is to have the largest TPA possible. I am really reluctant to
remove this capability based on this one reason, but I fear the
space may be needed to implement the more-important new functions
of the command processor. As a result, I plan to proceed with
the design and reconsider this alternative only when it becomes
appearant that removal of the $$$.SUB processing is absolutely
necessary in order to get the newer features in.
Question 1: Bug Reports. I am very pleased with the
distinct lack of bug reports -- not bad considering that these
few bugs were found in over 1.5 million bytes of source code!
Here is a summary of the bugs reported. If you are planning to
submit a reply to the query, please look here first to see if
your bug has already been reported.
PROGRAM PROBLEM/NEW FEATURE
------- -------------------
ZEX (1) aborting via ^? does not return cleanly; this bug has been
duplicated and will be corrected
MCOPY (1) protection against accidentally copying into the same DU
as the source does not work in all cases; this bug will
be corrected; as a note, MCOPY will undergo a complete
redesign for greater speed, more flexibility, and better
human interface
(2) the ability to abort a multiple copy is requested; this
request will be granted
(3) accidental use of the A:FN1.TYP=A:FN2.TYP form will cause
the original file to be deleted and nothing left; this
bug will be corrected; MCOPY was not intended to be used
with this form, but the habit of using PIP that way
is not easily forgotten
DU2 (1) The ability to save the contents stored in the queue as a
disk file is requested; this request will be granted
GET (1) does not restore the DMA address if executed from a
$$$.SUB file; this has not been verified yet, but will
be looked into and corrected if verified
VFILER (1) "VFILER d" form may not log user into the same user area
that he was in originally; this will be investigated
and corrected
(2) new feature: lack of information passed from the pointer to
the CMD file being executed; add the ability to pass just
the "filename" or "typ" part of "filename.typ"
(3) new feature: include R/O attribute in file display and
add command to toggle it for file being pointed to
(4) new feature: add ability to duplicate the file pointed to
in the same directory under a different name
(5) more features in general requested; will be considered
EVAL10/ (1) may have a bug when some even numbers are input; will
SYSLIB investigate and correct
Thanks very much to all who responded. Your comments are
useful and of value, and your interest in this project is
appreciated. If any other ideas come to mind, feel free to
forward them to me.
There has been a lot of curiosity about two items: (1)
what will ZCPR3 be like and (2) when will it be released. I am
very reluctant to say anything either way at this time because
the design is still forming. Once the system has begun to take
operational shape, then something can be said. Two design
reviews are now planned -- one around the first two weeks in Jan
84 and the other around the first two weeks in Feb 84. Something
should be firm by the first review, and an announcement will be
made then. The big thing to remember is that ZCPR3 will be more
of the same thing as ZCPR2, and features such as paths, multiple
command lines, memory-based named dirs, redirectable I/O, and
screen-oriented tools (like VFILER) will also be found in ZCPR3.
There are some new features which are in line with the old ones
and significantly extend the capability of the system beyond
ZCPR2 -- first will come the implementation of these, and then
will come the news to you of them.
Will keep in touch.
RickCCVAX.ty%nosc@sri-unix.UUCP (11/23/83)
From: Ty Wernet <CCVAX.ty@nosc> Rick, A disadvantage to ZEX that makes me go back and use one of the disk-based submit type programs is that when using ZEX I am unable to run programs that need speed. For example, I am running a SUPER19 like rom in my terminal at 38,400 baud. I request the date from the terminal under the regular submit like programs and have no problem, when using ZEX, it is unable to handle the characters coming back from the terminal. That makes programs that use the date feature of my terminal useless. Even running at 9600 baud ZEX is unable to keep up. Other than the speed problem ZEX does everything else that I require. When I say ZEX is unable to handle the characters coming back from the terminal it is ZEX dropping/missing them. I have implemented ZCPR2 on our machines here at work and also all the ones we have at home. We currently do not use ZCPR2's named directories. We had developed a "CD" of our own running under ZCPR1. It is name based with unique directory recognition. The .dir file is only a text file containing disk,user#,name. A rather simple solution but works well. When ZCPR2 came around we just moved our "CD" over. ty@nosc ---