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