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