There is a 'bug' in LISTSERV which causes it to pretend to have stored a file
after sending a message  saying there is an error in the file  and the file has
been rejected. Furthermore,  LISTSERV destroys the list  while still pretending
to have  stored it. The  only way to  recover the list is  to issue a  GET (OLD
command. I said 'bug',  because it's a bug in XEDIT in  fact. Under some condi-
tions which probably depend on a certain PTF having been applied to CMS or not,
the 'QUIT n' command does NOT return a  retcode of 'n' as it should. I have not
yet been able  to reproduce this problem  here, despite a lot  of attempts, and
since I'm  at SLU 412  (PUT 8606)  I definitely think  it is an  XEDIT problem.
Anyway what happens is LSVSTORE detects an error, yells, does a QUIT 999, XEDIT
exit with rc =  0 instead so LSVSORT thinks the file has  been stored and sends
you  the appropriate  message.  The list  had been  renamed  to OLDLIST  before
calling LSVSORT, and  since LSVSORT did not issue the  'FILE' command (since it
planned to reject the  store operation) to list is said not  to exist any more,
but you can restore it from the OLDLIST file on LISTSERV's A-disk.
 
  I have  fixed this  problem by  using a  GLOBALV to  pass the  return code...
*sigh* Another question: there are 3 important  fixes of that kind in 1.5f, but
I don't consider  the version as finished yet  and I did not write  any doc. Do
you think  I should ship  it out asap considering  the problems that  have been
fixed, or hold on a little more?
 
  Eric