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
|