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