- LISTSERV is now able to recover from REXX errors encountered while a command
was being processed. The command is merely ended with an error message and a
nastygram sent to the postmaster. That way if I find yet a new way to break
DIST2 in 1.5m, all the servers in the world won't stop when I start testing
the thing again :-) The actual REXX error message is still printed on the
console log by REXX, and is not passed on to LSVCMD (which gets only
"incorrect call to routine").
- LSVLTELL has been improved to stop formatting messages with 50-chars lines
just because it doesn't know for sure that the stuff is going out as mail.
Now it goes into some more trouble to find out, on a user basis, whether
they can handle 80 chars or would rather stay at 50.
- LSVTELL has been improved to stop sending the same messages messages 3 times
to yours truly just because he happens to be (a) the command issuer, (b) the
local postmaster and (c) listed in the LCOORD variable. This was
particularly awful with LSVLTELL messages, because you would then get 3
copies of the first line, 3 copies of the second line, etc. If you specify
multiple occurences of a given userid in a LSVTELL call, the second and
subsequent ones are now discarded.
- LSVTELL can now accept more than one output line in a single call (separate
them with X'15's). LSVLTELL (and several command processors) take advantage
of the resulting performance improvement. Try a HELP command from a local
console before and after installing 1.5m. Note that the lines will still be
sent "as is", without folding or spilling.
- Support for LSV$PROF EXEC in SYSVARS FILE has been removed, as I announced
previously.
- Support for the NETSERV CONTACTS file has been removed too. I got tired of
trying to determine who is the contact for this or that particular NETSERV,
especially as some NETSERVs just DON'T have a contact (see UKACRL). Mail for
NETSERV userids now gets bounced to the postmaster and nobody else.
- The AFD/FUI commands now have a REP operand which is a synonym with ADD.
This is for compatibility with the new NETSERV syntax, which I don't like.
File cache servers now have to send REP commands to NETSERV (instead of
ADD), so I allowed REP to function with LISTSERV but I do NOT plan to change
ADD into a "no-replace" addition. At best I would provide a NOREP option for
ADD, and only if someone could prove clearly that it would really be useful.
- The AFD/FUI command has been expanded to allow postmasters and NADs to issue
LIST/ADD/DELETE requests on behalf of other users. The syntax is "AFD FOR
userid@node whatever". This is not compatible with the NETSERV syntax of
"AFD password whatever FOR userid@node", which I don't like (again). I think
that users should be allowed to put a 'FOR' in the next-to-last word of
their prolog texts if they want. I had thought about enhancing the LISTSERV
PUT command so that you can specify a 'FOR userid@node' keyword to indicate
the userid of the person who's to get the reply messages, since there is
little point in sending a reply back to a NETSERV or other server. So I
would have AFDed to NETSERV with a prologtext of "PUT fn ft filelist FOR
ERIC@FRECP11"
>>> Note: AFD FOR xxx and FOR xxx AFD don't do the same thing <<<
0. The following discussion holds for FUI as well.
1. With FOR xxx AFD, the target gets a copy of every message that gets sent to
you. The password you must specify is the target's password, since "he" is
issuing the command. With AFD FOR xxx, he won't get a copy of your messages
and the password to specify is your personal password, since "you" are
issuing the command.
2. With AFD FOR, the target will get notified of ADD/DELs you might perform
against his subscription lists. With QUIET AFD FOR, nothing is sent out.
With FOR xxx AFD, he'll get notified via interactive messages only (like
you).
3. With AFD FOR, file access verification is done with YOUR userid, so that
you can subscribe the target to files he is not authorized to get. Note
that this might not work if a File Access Validation Exit has been
installed for the file. What happens at actual AFD time is strictly under
its control, and it might decide to refuse the AFD. There is no problem
with FUI of course.
4. 'AFD FOR xxx GET yyy' does the same as 'AFD GET yyy'. This is a consequence
of point 3.
5. You should therefore not use FOR xxx AFD unless you have a good reason to.
- You can now PUT lists with your personal password. THIS DOES NOT MEAN YOU
SHOULD LEAVE THE LIST PASSWORD BLANK! Anyway you'll get a warning message
whenever you store a list with a blank password.
- I plan to completely reshape the File Access Validation Exit calls for
AFD-time processing. The current protocol is very messy and not precisely
satisfactory, and may cost a lot of CPU time. It also conflicts with the
nature of the AFD-via-DISTRIBUTE feature of 1.5l :-) I must improve it so as
to save CPU for "vanilla" files (in cases where the FAVE only adds a few
tests to the userids allowed to GET or AFD to the file), and to allow
"customized" files to be sent via AFD (and without DISTRIBUTE) if the FAVE
so desires. The present setup makes it technically impossible to AFD to
something like the NOTEBOOK FILELIST, where the contents depend on the
person who issues the GET command.
- I plan to write LISTFOWN afterwards. The main reason is that I need to check
that everything is consistent, and the only way out is to document it :-) I
have no idea when it will be done, I have a lot of mandatory courses this
year. By the way, now that I am in a CS-only course, I have been given
access to the best computer students have access to. In other words, I have
upgraded from a PDP 11/23 with teletypes (yup, no screen, just a printer and
a keyboard) to a PDP 11/73 with VT100s. The VT100s have a very nice
"feature" (in IBM rep terms): the characters on the first line of the screen
are about twice as big as those on the last line. This way you can move the
portion of text you're working on on line 1, and see it magnified. Very
clever. I'm learning to love these VT100s. You can move 1 line down in the
file you are editing in less than 5 seconds by just pressing cursor down.
Really fantastic. On the teletype, it took much longer because it had to
print the next line (scratatatatatatatatata...hrhrhrhrhrhr). We have just
discovered a new game: try to edit on a VT100 at the same speed you'd do it
on a local 327x. After about 2-3 seconds, you are actually typing some 10-15
seconds of wall clock time ahead, and you start losing track of where the
cursor is (I mean, will be). We take bets as to the number of characters
we'll botch up and have to retype when the PDP is done processing our input.
When we have become proficient enough, we'll be able to type in a complete
program and then leave the VT100 to digest our input while we take a break
for coffee. And I thought I wouldn't learn anything useful in Supelec... :-)
Eric
|
