Compiled REXX
Dave Salt
listserv groups.
The bank where I work doesn't have a REXX compiler, which probably explains
why I can't find a manual. However, we're susposedly getting a compiler in
the near future and I did manage to find a little bit of information in the
ISPF Dialog Developers Guide. Namely, it states that compiled REXX programs
can either be invoked using "SELECT CMD" or "SELECT CMD LANG(CREX)",
depending on which option (ie. "CEXEC" or "OBJECT") was used to compile the
REXX. If I use the "OBJECT" option, then I have to use the LANG(CREX)
parameter of the SELECT command. But if I use the CEXEC option, then I don't
have to use LANG(CREX).
As I've got lots of REXX/ISPF programs which call each other using "SELECT
CMD", it will save me a whole lot of source code changes if I compile my
programs using the CEXEC option. So, my questions are as follows:
1) Is there a downside to using CEXEC instead of OBJECT when compiling REXX
programs?
2) I got the impression from the limited information in the ISPF manual that
CEXEC REXX is still RECFM=FB (lrecl 80?), while OBJECT REXX is a load module
(presumably RECFM=U?). Is this assumption correct?
3) If the above assumption is correct, does this mean REXX execs compiled
using the CEXEC option can co-exist in the same PDS as non-compiled REXX?
4) Is there any difference in efficiency between the two types of compiled
REXX?
5) Is there any difference in security? Ie. is it easier to reverse engineer
one form of compiled REXX over the other in order to reveal the original
source code?
6) Any other tips/tricks/pitfalls/suggestions regarding the two types of
compiled REXX that anyone might like to share?
Please go ahead and respond even if you only know the answers to one or two
of the questions I've asked. Thanks in advance to all who respond!
Dave Salt
Systems Consultant
Toronto Dominion Bank
Canada
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Johnnie Hougaard Nielsen
> The bank where I work doesn't have a REXX compiler, which probably explains
> why I can't find a manual.
You can find almost all S/390 oriented manuals on the net at
http://www.s390.ibm.com/os390/bkserv/
The bookshelf for the REXX/370 compiler is at
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.exe/Shelves/EAGUB03
> If I use the "OBJECT" option, then I have to use the LANG(CREX)
> parameter of the SELECT command.
As far as I remember, LANG(CREX) is only needed on older OS/390 releases.
(I have'nt checked which release, or if there are caveats).
> 1) Is there a downside to using CEXEC instead of OBJECT when compiling REXX
> programs?
When using CEXEC, I noticed no downside, except for the search order impacts.
But that can also be an advantage, sometimes. Beware of search rules if you
choose to have both source (or CEXEC) and load module in the searched concats
at the same time.
> 2) I got the impression from the limited information in the ISPF manual that
> CEXEC REXX is still RECFM=FB (lrecl 80?), while OBJECT REXX is a load module
> (presumably RECFM=U?). Is this assumption correct?
Yes. "Classic Rexx" works as other compilers, producing an object module which
has to be linked into a load module. Or program bound into a program object
in a PDSE. In addition it can also execute compiled Rexx code from FB80
PDS(E) members.
<nitpick>
However "OBJECT REXX" does not exist on S/390, only on Windows/AIX/Linux.
</nitpick>
This object-oriented version on Rexx seems to be "stabilized".
> 3) If the above assumption is correct, does this mean REXX execs compiled
> using the CEXEC option can co-exist in the same PDS as non-compiled REXX?
Yes.
> 5) Is there any difference in security? Ie. is it easier to reverse engineer
> one form of compiled REXX over the other in order to reveal the original
> source code?
Probably not.
In my opinion, an important reason for developing the Rexx "Compiler" is the
ability to hide source code. The compiled program is not a "pure" machine
language program.
Regards, Johnnie
--
S/390 (zServer) Rexx links at the Open Directory Project:
http://dmoz.org/Computers/Programming/Languages/Rexx/S390/
Gozzard, Mark
the performance improvement wasn't significant. Most of the large (i.e.
slow) REXX programs were I/O intensive and the compiler makes practically no
difference.
Where there was a VERY significant difference was by moving the REXX
execs/modules from SYSEXEC to ISPLLIB as the search path is a lot shorter,
which works best for high usage REXX execs/modules (especially those called
repetitively from the same exec). This is the case where OBJECT is better
than CEXEC.
It's not necessary to compile all your REXX to get a performance
improvement, just the high usage ones and the CPU intensive ones.
Another possible benefit I've thought about is the possibility of putting a
compiled REXX into a APF authorised library. This should allow you grant
conditional access to a dataset only while the user is running the REXX i.e.
they could normally have NONE/READ access to the file and UPDATE access only
via the REXX load module.
Mark Gozzard
Mailto:mark.g...@eds.com
-----Original Message-----
From: Dave Salt [mailto:ds...@HOTMAIL.COM]
Sent: 12 December 2000 14:58
To: TSO-...@VM.MARIST.EDU
Subject: Compiled REXX
Hi all, this message is being cross-posted to both the REXX and ISPF
listserv groups.
The bank where I work doesn't have a REXX compiler, which probably explains
why I can't find a manual. However, we're susposedly getting a compiler in
the near future and I did manage to find a little bit of information in the
ISPF Dialog Developers Guide. Namely, it states that compiled REXX programs
can either be invoked using "SELECT CMD" or "SELECT CMD LANG(CREX)",
depending on which option (ie. "CEXEC" or "OBJECT") was used to compile the
REXX. If I use the "OBJECT" option, then I have to use the LANG(CREX)
parameter of the SELECT command. But if I use the CEXEC option, then I don't
have to use LANG(CREX).
As I've got lots of REXX/ISPF programs which call each other using "SELECT
CMD", it will save me a whole lot of source code changes if I compile my
programs using the CEXEC option. So, my questions are as follows:
1) Is there a downside to using CEXEC instead of OBJECT when compiling REXX
programs?
2) I got the impression from the limited information in the ISPF manual that
CEXEC REXX is still RECFM=FB (lrecl 80?), while OBJECT REXX is a load module
(presumably RECFM=U?). Is this assumption correct?
3) If the above assumption is correct, does this mean REXX execs compiled
using the CEXEC option can co-exist in the same PDS as non-compiled REXX?
4) Is there any difference in efficiency between the two types of compiled
REXX?
5) Is there any difference in security? Ie. is it easier to reverse engineer
one form of compiled REXX over the other in order to reveal the original
source code?
6) Any other tips/tricks/pitfalls/suggestions regarding the two types of
Thorsten Schaper
> The bank where I work doesn't have a REXX compiler, which probably explains
> why I can't find a manual.
You can download the latest version of the REXX/370 compilers user's
guide and
reference in PDF format from:
http://www.ibm.com/software/ad/rexx/download.html
> 1) Is there a downside to using CEXEC instead of OBJECT when compiling REXX
> programs?
No - the generated executable code is exactly the same.
> 2) I got the impression from the limited information in the ISPF manual that
> CEXEC REXX is still RECFM=FB (lrecl 80?), while OBJECT REXX is a load module
> (presumably RECFM=U?). Is this assumption correct?
The OBJECT compile option makes the compiler produce an OBJECT file like
any
other high level language compiler. These OBJECT files got to be linked
with
a STUB to generate a callable load module. These load modules can then
be
linked with other load modules, so that a compiled main program and
compiled
external functions may be packaged together into one load module. You
may even
link load modules that have been written in other languages (see the
C/C++ stub
at our download area for an example)
> 3) If the above assumption is correct, does this mean REXX execs compiled
> using the CEXEC option can co-exist in the same PDS as non-compiled REXX?
Yes - if you still like your REXX code with lrecl=80...
> 4) Is there any difference in efficiency between the two types of compiled
> REXX?
search paths are different - CEXEC is thought to replace interpreted
EXECs.
The compiled version behaves exactly the same as the interpreted
version.
Load modules may be linked together, which increases speed a lot, since
there
is no search needed at all for statically linked external functions.
> 5) Is there any difference in security? Ie. is it easier to reverse engineer
> one form of compiled REXX over the other in order to reveal the original
> source code?
The source code is only included in the compiled REXX if you specify the
SLINE compile option, which is required for the ALTERNATE option or if
you want
to use the SOURCELINE BIF in the REXX code. If you additionaly specify
the
CONDENSE compile option the compiled code gets condensed and the source
lines
included in the file are not human legible.
> 6) Any other tips/tricks/pitfalls/suggestions regarding the two types of
> compiled REXX that anyone might like to share?
Check out the makefile utility (->...download.html also) that makes it
easy to
package REXX applications (compile the EXECS to OBJECTS and link them
all
together)
greetings, Thorsten Schaper ... have fun with REXX !!!
IBM Entwicklung GmbH, SWSD REXX & TM Entwicklung
e-mail: Thorsten...@de.ibm.com
Adr. : Schoenaicherstr. 220, 71032 Boeblingen