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