Almost all of these "mysterious halt" problems are due to exceeding a virtual memory quota. There is no core file because the core file limit is usually also exceeded. A large LISTSERV installation will typically not function with the standard, rachitic 1980 quotas used on some unix systems. People who migrate from VM also tend to assume that if LISTSERV worked great on 32M under VM, it would do the same under eg Digital unix or AIX, but this is not the case. One reason is that RISC code just takes up more space, but above all if you compare a PC or unix workstation to a mainframe, you will find that the PC/workstation has cheap RAM and comparatively limited I/O. It makes a lot of sense to just burn a few more megabytes of cheap RAM to reduce I/O and improve throughput, and LISTSERV will do this by default. You can turn most of these functions off, but frankly you don't want to. We didn't add these functions to annoy people and force them to buy more hardware that we don't make a cent on, but because they really make a difference. I am curious what would happen on VM if these functions were activated, maybe one day IBM will decide to finally deliver this MP3000 (we have only been waiting since October, understandably they are still unable to provide a delivery date) and I will be able to try it out. Anyway, spending some time figuring out how to make your system actually allow LISTSERV to use more memory is a good investment. On some systems it is not sufficient to increase the quota in 'go', you may have to change kernel parameters and increase swap space whether the swap space is actually going to be needed or not. Eric