I have been asked to state my position regarding the support of LISTSERV in XA-mode virtual machines. There seems to be a lot of religious arguments about XA-mode support, and I would like to avoid a useless "flame war". The present status is that LISTSERV does not work with SET MACHINE XA (period). There is, pragmatically, little or nothing to be gained from running LISTSERV in an XA-mode machine (try doing "x = copies('',15e6)" in an XA-mode machine with 100M and you will immediately understand why), and therefore the priority of making LISTSERV even XA-tolerant is very low. That is, LISTSERV will run with SET MACHINE XA if, by chance, all the little things that prevent it from working in an XA machine happen to disappear. If there is a complete rewrite of LISTSERV some day, I will make sure that it runs in an XA machine, though. The LDBASE user interface does not run in an XA machine either, because it is based on LSVIUCV, which is one of the main sources of reasons why LISTSERV itself doesn't go very far when started on an XA machine. Here however I agree that it is a pain for the end-user to have to switch back to 370 before running LDBASE, so I will try, with a low priority, to make LSVIUCV run in an XA machine. However, there is very little addressability left, and dual-pathing code because of the lack of watchdog timer in XA machines (and the lack of clock comparator in vanilla SP or HPO virtual machines), not to mention all the SSM's (and corresponding lack of STxSM without ECMODE OFF), is likely to take a lot of space; this is not a "trivial" job - give it a try, and you'll be convinced :-) Eric