- 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