I have undertaken a REXXCOMP (REXX/370 Compiler) front-end to RexxC (in
ooRexx) to satisfy both my requirements and the requirements of others
looking for REXXCOMP source features (including my previous development
group within IBM). Coding is nearly complete and is functional;
documentation, at present, is in its usual state -- lagging at least a
couple of weeks behind. Current class name used by REXXCOMP for the
actual front-end is REXXFANC, in "honor" of the "FAN" module and message
prefix assigned to the REXX/370 compiler, unless there is a better
suggestion.
Basic logic, at present, has three phases: 1) Preprocess, 2) Tokenize
with RexxC, 3) Create final outputs, merge preprocessor and RexxC
messages, insert #!/usr/bin/rexx and mark tokenized output as executable
for open systems. Listing format is very similar to that of REXX/370
listings, although logic levels are neither determined or shown at
present. Total processing time for a 40K line program on a 1.7Ghz
single-core P4 is acceptable.
I have not wanted to "announce" the work to the primary ooRexx list,
until the work is a little further along, although I know there are some
folks who are looking for the capabilities. It is my intent to make the
work available to the project for inclusion.
For handling of the copyright directive, an address "string";address;
sequence is inserted to preface the contents of the first line (second
line if #! detected on first) of the RexxC input only, providing an
interim solution for RFE 2759666. After further research, this action
and placement is equivalent to current operation of the REXX/370
compiler, does not set any variables nor alter any perceived state of
the target program at execution time.
Supported Options (at present):
CEXEC
IEXEC
LINECOUNT
MARGINS (including automatic handling of sequence numbers in
73-80)
PRINT
SOURCE
SYSIN
DDNAME library specifications are supported, including search orders
compatible with the REXX/370 compiler on both MVS and VM (this makes for
some very ugly lookups). Shell variable substitutions, for example, %
Path% on Windows and bash $PATH, are supported. Since more than a simple
search is involved in locating a filename or ddname(member). To come
close to the locate function operation under z/OS and z/VM, a blended
functionality is used.
1) filename (z/VM) or member (z/OS)
Search array of paths described by the DDNAME[SYSLIB] array, and
then the source path, by appending the extensions described by
IncludeExtensions.
2) ddname(member)
Search array of paths described by the DDNAME[ddname] array by
appending the extensions described by IncludeExtensions.
In all cases, a caseless search will be performed for compatability.
Should multiple matches be found, only the first match will be
used.
Extensions:
- The filename may specify a file extension in the form
filename.ext.
- The filename or member name may not contain an asterisk (*), question
mark (?), slash (/), or backslash (\) [or in typesetting terms, virgule
(/) and reverse virgule (\)].
Delfault IncludeExtensions and lookup order:
COPY, REXXINCL, EXEC, MEMBER, SREX, SREXX, REXX
Directive status:
%COPYRIGHT - complete
%INCLUDE - complete, except for include level and record number in
listing (in process)
%PAGE% - started
%SYSDATE - started
%SYSTIME - started
%TESTHALT - not started, TBD
Questions:
1) What standards, if any, do I need to adhere/conform to, should the
routines be accepted for inclusion?
2) Any additional feedback or input?
Mark L. Gaubatz
------------------------------------------------------------------------------
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
