I personally wouldn't bother with /UNREG. If you try a "REGISTER" command
with no argument (or with not enough arguments), you get told what the
proper syntax is and, if already registered, you get told how you can
unregister if that's what you want. If you do create a /UNREG, just do a
'CP M * FOR' origin 'REGISTER OFF' and that will be it.
Another matter I would like to discuss is that of global deletion. I have
been asked thousands of time how student accounts can be unregistered. My
problem is that presently french node admins have found out that I could
be reached by phone, and guess what happens when they have student
accounts to delete? :-)
With the present situation, the NAD can already issue a 'FOR userid
SIGNOFF *' command to any LISTSERV. Problem #1, it's not convenient nor
efficient if they have 200 accounts to trash. Well I'm personally more
concerned about efficiency. Problem #2, you have to send it to each
LISTSERV. This is the real problem. It should not be implemented in a
specific way for the signoff problem, ie you should be able to cause a
LIST command to be executed at all LISTSERV sites if you so desire.
Each LISTSERV has a list of other LISTSERVs, which is more or less up to
date. A non-backbone LISTSERV could tell you to refer to a backbone one,
and could even point you to what it thinks to be the nearest one, so this
is not a big problem and we can assume that the list is almost up to
date. Now there are two ways to forward the command:
1. Direct send. This eats very little CPU but generates NNN 2-3 recs
files. Not much network load, but all of a sudden you have 100-150
files in the RSCS reader. Well it can handle it, until some end-user
admin issues 200 such commands for the 200 accounts it is trashing.
Then you get 20000 spool files and you start crying for help.
2. DISTRIBUTE to all the LISTSERVs. This doesn't generate many files, but
you'd better be patient. Of course it isn't worse than a DISTRIBUTE
for your average 100-150 users list, but it isn't better either. If
your crazy admin sends 200 global commands, you get only 200 files but
you probably eat 200 minutes of CPU time.
Note that in any case, the admin should only send one file with the names
of the 200 userids. I was assuming an end-user admin who doesn't know,
sees how it works for 1 userid, and concludes that it would be just what
he wants with a 'do student=1 to 200;...;end' around it :-)
I could use a 'cache' file to speed up the DISTRIBUTE at the source node,
but what about the intermediate nodes? Anyway DIST2 already has a cache
file so this wouldn't be so much of an improvement.
Comments? Ideas? Note that I am certainly not going to go for anything
involving a fixed topology a la NETSERV. There have been enough NETSERV
loops and enough hundreds of files in my reader because of this
particular aspect of the NETSERV design.
Eric
|
