June, you have 2 problems with GLOBAL commands. First, they must be distributed to all the servers. That means a DIST2 job with a bunch of recipients, DIST2 is mostly REXX, and I don't want to move large fractions of it to assembler because that would require thousands of line of code and it would be difficult to manage. But that aspect is not what people complain about usually - there are a bunch of DIST2 jobs anyway. Then, each server needs to execute the command. There are scores of netwide SIGNOFFs a day (well it depends on the day of course). LISTSERV needs to look at all the lists to see if you're in there, and that's not a simple job given that SIGNOFF now ignores the case. On a server like CEARN where you have 50+ lists, some of which being over 200 subscribers, it is going to take time anyway, just for the I/O. But that's not where the complaints come from - these CPUs are dedicated to the network, as long as they're not saturated, fine. The complaints come from sites which have a good number of large local lists, sometimes with as much as 1000 subscribers on them, and who've got to justify every second of CPU time spent on network (ie non-local) services. I don't really know what to do there. They could be allowed to disable netwide functions, but then what happens if they do have a few non-local lists (that is usually the case, even if most lists are local)? What if a local user does a SIGNOFF with the NETWIDE option and doesn't get signed off these lists because the function is disabled? The best solution is to make the "find all the lists X@Y is on" function considerably faster, and I'm afraid that requires disk space and protection from manual XEDITing of the lists, in addition to the code itself. Would the postmasters on this forum accept a restriction on the use of XEDIT on the lists in order to gain better performance? I know that it's a hot topic - some people ONLY use XEDIT, never GET+PUT :-) Eric