Jose: your idea is good but very difficult to implement at present. Perhaps
when we have the file server functions it will be easy to automatically add the
stats files to 'listname FILELIST' with a GET=(listname) and PUT=Owner, which
would allow the list owner to delete them easily and users to retrieve them.
But at present, only the postmaster would be able to delete them or retrieve
them :-( Any idea?
As you may know I've been reshaping a few lists this weekend. I ran into a
lot of troubles and decided to take steps to avoid them in the future.
1) I killed the EARNTECH list at CEARN by sending a STORE request to the wrong
server -- the list intended for FINHUTC was stored at CEARN and here died
the CEARN list. Hopefully I had kept a copy of it in my reader and could res
tore it. I was lucky, I could have been unlucky. Version 1.5c will save the
old version of the list as "listname OLDLIST" and there will be a (OLD
option to the GET command to retrieve it if needs arise. I could have done a
GET EARNTECH (OLD to get back a copy of the old list.
2) Issuing a GET, HOLD and FREE to the seven LSTSRV-L peers is a pain. I'll im-
plement a (GLOBAL option to these commands. Ditto for DELETE.
3) It's a pain to have lists come in with a filetype of list. As you may know I
had fought off a suggestion that the filetype be set to 'nodeid' because I
intended to have all servers know about ALL the recipients of the list, ie a
"listname LIST" and "listname RMTLIST". That would have solved the REView
problem and also the send=private issue. I was discouraged by the number of
people who logon to the LISTSERV userid to modify their lists (I'm the first
to do it by the way :-) ), thereby thwarting any attempt at informing other
servers of the change :-(
Anyway, I've now opted for a filetype = nodeid on the REV/GET commands,
except:
- If there is no peers= keyword, the filetype will be LIST, quite logical-
ly. Only one central list --> no need for nodeid.
- If the command is GET and the GLOBAL option was not specified, the file-
type will be LIST so that GET listname --> listname LIST and GET listna
me (GLOBAL --> bunches of listname nodeid files.
Also, LSVPUT has been improved: there is a new (LIST option which can be
used in conjunction with the "listname nodeid" files: you just do a
FLIST LSTSRV-L * (for example), then LSVPUT / (LIST, =,=,=,=,=, and the
files get stored automatically at servernode = filetype. This already works
and is compatible with 1.5b provided that you rename the lists manually.
LSVPUT filename still stores filename LIST, of course.
4) Some servers run an obsolete version of the $DEFAULT MAILFORM. Version 1.5c
will automatically RENAME MAILFORM --> OLDMFORM and NEWMFORM --> MAILFORM
if $DEFAULT NEWMFORM is found on the disk. That should solve the problem.
5) Some servers still have a SAMPLE LIST (with myself as the owner usually).
I'd recommend you did a TELL LISTSERV CMS ERASE SAMPLE LIST. Not that this
list causes problems or anything. I'm just getting questions from user that
"Why is such a widely-spread distribution list not accessible to subscrip-
tion, and why does it reports it as not operational?" :-)
To answer a question from many of you: file LISTSERV NAMES is not needed at all
unless you want to define your own nicknames in the LISTSERV userid, of course.
I'm not responsible for the stupidity of NAMEFIND which complains when you do a
mere NAMEFIND (SIZE * to set up the default size of the file buffer.
About the security memo: I've got a lot of requests from US people. I realized
that the mailing fee was much more important than I thought yesterday... I
don't mind paying 15*$1 for European users, but 10*$5 is something different
(especially since I wouldn't be surprised to get more requests during the
week)... I'll be delaying the US mailings until I find a solution: either mail
them low priority or get permission from FRECP11 to send them through the
school mailing service or suchlike. I'm not a millionaire!!
Eric
|
