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