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
|
