I am looking for beta-test sites (preferrably running CMS4 or CMS7) for the new LISTSERV PASCAL REXX library. This is basically a programming environment allowing me to write REXX functions in PASCAL and to package them into a single MODULE, with a single copy of the PASCAL run time library. This includes a number of string manipulation and I/O functions which avoid turning a 10-lines REXX program into a horrendous 100-lines array of unwarranted if/then/begin/end/else/begin/end. Before someone asks, this environment is not supported for any purpose other than the LISTSERV code I write; if you decide to use it for local applications, you do so at your own risk. The purpose of this PASCAL REXX library is to allow a smooth conversion to a compiled language that can address the performance requirements of LISTSERV. IBM has made it clear that they do not intend to provide the REXX compiler and pre-requisite libraries as a standard part of VM, or at least as an affordable supplement. In any case, early experience with the REXX compiler in the LISTSERV environment shows only a marginal improvement in CPU usage (about a factor of 2), while the amount of storage required to hold the "compiled" code is 4 times higher. Due to an unfortunate intersection of brain-damaged features of CMS, the migration to this PASCAL REXX library is, regrettably, not going to be a painless one. The first problem is that, with the possible exception of the REXX compiler, IBM has always refused to make compilers for VM. The PASCAL compiler, like all other compilers, is an MVS compiler that relies on the fact that VM emulates a subset of OS system calls. Storage for the run time environment and other things beyond programmer control is allocated using OS calls (GETMAIN), and may be unexpected destroyed without warning should another OS application issue an STRINIT call. The COPYFILE command was originally written by MVS people who only knew about OS calls, and happily issued a STRINIT before requesting storage (this is why COPYFILE have you an abend rather than a nonzero return code if it ran out of storage). This was fixed with CMS5, but code had to be added to the PREXX library to detect STRINIT calls under CMS4 and take corrective action; this code has to be tested. Another problem is that the PASCAL compiler, like all IBM compilers, uses its own private procedures for allocating storage (which, ultimately, call OS simulation routines). A library routine (for instance a string manipulation routine) should return storage allocated using these procedures, so that it behaves like regular PASCAL storage. There is, obviously, no documented interface for calling these procedures. Since they are presently implemented using the standard PASCAL linkage sequence, the risk that they might change in the future seems low, but it will always be there and there is no other solution. Due to the brain-damaged interface the REXX interpreter uses to access external REXX functions, a significant number of LISTSERV modules will have to be renamed. The reason is that only the first 6 characters of the REXX function name are meaningful, in the case of external functions. That is, the standard STORAGE() function, which is implemented as an external assembler function, can be invoked via STORAGECLEAR(), STORAGRAFF(), or whatever strikes your fancy. The consequence is that, if you were to convert LSVBESTP to PASCAL, any call to LSVBESTE (a totally different program) would silently call the new LSVBESTP. The bottom line is that almost every single piece of REXX code will have to be edited to replace all occurences of LSVxxx with LSVyyy. Once this has been done, it will be extremely difficult to issue fixes, so a new release will have to be sent - as soon as possible. This is why I am looking for beta-test sites now. Presently, LSV822TO and LSVNADDR have been converted to PASCAL (the former is called 15,000 times a day on backbone hub sites, the latter about half as much); in addition, the part of LSVDBNB that builds list archive indexes has also been converted, as there was a notable performance problem in that area (the new code can read the file and build the index in about half the CPU time you need to read the file using EXECIO with the SKIP option). Due to the editing process described above, the resulting update deck is 6389 lines in CARD format, so I will have to restrict distribution to sites with good connectivity, as this has to be installed manually and I don't want to split it into smaller files for that reason. Since most EXEC's are affected by just these two name changes (the new names are LSV82T and LSVADR), you have to backup the whole 191 minidisk before doing the CARD LOAD. Afterwards, all you have to do is restart - there is no configuration change. The new source code is another 2616 lines in CARD format. Eric