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