1. IBM's REXX compiler is completely useless for LISTSERV. In order to be
   able to  run the compiled code,  you need to have  the compiler (don't
   ask - you  also need the IBM  C compiler in order to  compile the REXX
   code). In order to have the  compiler, you need, of course, a license;
   and if you look at the license  costs, you will understand why this is
   a problem.
 
2. For  the reason  I just  mentioned,  we will  never buy  the IBM  REXX
   compiler here anyway.
 
3. IBM says this compiler provides  a performance improvement of a factor
   of "3  to 7".  Given the way  I program in  REXX (putting  the maximum
   amount of  work in the assembler  parts of the interpreter  which look
   for stems and perform the  PARSE function, avoiding nested DO's, etc),
   I'd be lucky if  I do get the factor of 3.  The REXX "compressor" mods
   improved performance  by 2 to 5%  on those parts of  the LISTSERV code
   which I benchmarked,  when other sites quoted  typical improvements in
   the 15-40% range.
 
Finally, some of the problems with LISTSERV are related to limitations of
the REXX  language. Example: when  I do a LSVFILER  of a large  file (say
2000 lines), or a LSVCARDR, the  data is read extremely quickly from disk
into storage. But then to give that  data over to REXX, I must either use
the program stack (4000 SVC 202,  2000 of which LSVFILER manages to cheat
into BALR calls), or use EXECCOMM (a bunch of SVC 202, although less than
in the stack case). In any case,  that's a huge bunch of DMSFREE calls. I
could of course keep  the data in storage and retrieve  it with a special
function of mine, but each function call  is an SVC 202 (and that doesn't
avoid the DMSFREEs). Tough.  Then there is all the nonsense  I have to do
in some cases  because there is no  pointer concept in REXX  (that one is
not a  criticism of  REXX, which  was not  designed to  do this,  just an
observation).  Then, worst  of  all, the  fact that  you  cannot write  a
"function library"  in REXX.  I mean,  I cannot write  a standard  set of
routines to perform  the menial tasks that need to  be done everywhere in
the code, because calling a function which is not in the same source file
as  yours is  a huge  re-initialization overhead,  even if  the thing  is
EXECLOADed. And  also because you  cannot pass a  stem to a  routine like
that, anyway. So guess  what I do? I use the XEDIT  GET command to insert
the code  I need, change the  variable names to remove  conflicts, delete
the code  I don't need, and  if there is a  problem I need to  change the
code in 25 places, and sure enough I'll forget about half of them.
 
If the  compiler had come with  extensions to the language  allowing BALR
calling of external  routines, passing stems to a routine  you call (even
if this  means the stem  has to be  R/W to the  routine - I  don't really
mind),  it would  definitely have  been  useful, regardless  of the  poor
performance savings,  and provided the  price was reasonable.  But that's
not the case, so let's forget about it.
 
  Eric