LISTSERV@CEARN is  looping and probably  eating hundreds of minutes  of CPU,
either because it has entered the LSVBITFD  loop or because it has received an
invalid  Netdata  file   from  DMZRZU71  like  mine.  I   have  contacted  the
CONSOLE@CERNVM  crew but  they  seem  unable to  either  permanently stop  the
server, hold all its  reader files, or re-autolog it (they  even asked me what
their LISTSERV's  logon password was... I  didn't know of course  so they said
they  couldn't restart  it, but  they ended  up doing  it anyway).  I'm afraid
nothing can prevent LISTSERV@CEARN from eating a few DAYS of CPU this weekend.
:-(
 
  Anyway, I had sent  a set of fixes for release  1.5i (FIX15I SHIPMENT) which
seems not  to have been  distributed. I  think it's still  in LISTSERV@CEARN's
reader  and has  not been  lost  so I  won't  be resending  it unless  Olivier
confirms that the shipment has been lost.
 
  I  am seriously  thinking  about  something: it  seems  that regardless  how
serious a computing  center is, you will unavoidably  find yourself confronted
to a novice  operator on the very  precise day that you need  a competent one.
The only thing that you can ask an  operator is to issue a CP FORCE command --
it's something he will  understand. He won't be able to  do an AUTOLOG because
he won't know the  password. He won't be able to hold  reader files because he
won't know the command.  There are basically two cases when  a server enters a
CPU loop:
 
1) It enters the loop at  initialization. This is very unlikely, especially as
   it would probably happen while you (the LISTSERV owner) are logged on too.
 
2) It enters a loop while processing some command/request from its reader.
 
 
  In the first case  nothing can be done by an operator. In  the second case I
think there is a solution: as soon as a reader file has been read in, LISTSERV
changes it to HOLD status (this file  is supposed to be PURGEd upon completion
of the command, or  TRANSFERred to the postmaster if there  was a problem). If
it subsequently  enters a loop,  you can  ask the operator  to CP FORCE  it --
that's something  they always manage to  do without problem. If  you then have
some kind  of server that  checks all servers from  time to time  and AUTOLOGs
them if they're logged off, or if your operators can AUTOLOG without password,
the server will eventually restart and will not process the lethal reader file
again. :-) I think it would work so I'm going to put it in the next release.
 
  Apart from  that, LSVXMAIL has  been fixed (Mail-Via  I mean). Valdis  has a
copy of the fixed exec, but it is NOT included in FIX15I SHIPMENT (ie I solved
the problem after sending FIX15I).
 
  Eric