Hello everybody. First off many thanks to Rick McGuire for guiding me
here. I got about half way through porting the ooRexx 3.2 code to z/OS
when I hit
a major dead-end due to the pthread_t cast to long issue. I've taken
Ricks advice and signed out the svn trunk version and things are
looking promising. I'm going to have a good crack at porting ooRexx to z/OS.
I've got 20 years industry experience systems programming, apps
programming and software engineering. I've been using REXX since 1992,
mainly in the TSO/Batch/Netview environments. I have sound knowledge of
z/OS, C/C++, USS, HLASM assembler, Java.
I have previous experience porting *nix software to z/OS, most notably
the boost C++ libraries
(although that's still a work in progress, some of the template
meta-programming choked the compiler).
I've sketched out a plan off how I want proceed. I've broken the project
up into stages which I will then work on iteratively.
Stage 1
Get the thing built in the z/OS unix environment (USS). ooRexx is
*nix ready so this should be the simplest task.
I've run many a configure script in my time but have yet to actually
construct one. I'm noautoconf/automake expert so advice will be
well received.
The z/OS C/C++ compiler is a decent compiler, and USS is a fully
compliant POSIX unix environment. While I expect many compatibility
issues there should be no show stoppers. What is an absolute no-no
is building archives. Archives cannot be linked into standard z/OS
PDS(E)
load libraries. It's an absolute must that ooRexx should also be
able to run in Batch, TSO, not just USS.
IBM has a website of ported tools to z/OS unix
http://www-03.ibm.com/servers/eserver/zseries/zos/unix/bpxa1toy.html.
While it started off promising IBM
seems to have abandoned it and it's starting to look a bit
geriatric. autoconf/automake can be found there, but very dated
versions. If during this port I can update any
of the GNU toolchain for z it would be very well received by the
z/OS unix community.
I've started to implement EBCDIC support using #ifdef's with an
EBCDIC flag. So far I've only changed the scanner. If anybody knows
of any ASCII
specific code please let me know. This will help other potential
ports to EBCDIC systems like OS/400, z/VM, TPF...
Stage 2
Either enable the existing code or create extensions to handle z/OS
file systems. ooRexx handles stdio very well, but it's stream based.
z/OS stdio supports
the whole range, streams, QSAM, BSAM, PDS, VSAM, HiperSpaces. To
process a record oriented file such as QSAM one would specify keyword
parameters in the file mode. For example, fopen( "DATA.SET.NAME",
"rb, type=record, noseek").
The guys at dovetail have done a fine job writing stdio JNI wrappers
around to enable Java to process z/OS file systems
http://www.ibm.com/developerworks/eserver/library/es-java-batchz.html
Stage 3
Now the tricky stuff, enabling TSO/ISPF support.
TSO is not so hard. I originally thought that if ooRexx was running
in a TSO environment just passing the command string to the
system(..) function would work,
as it already does on z/OS. However, to enable TSO system command
and use all the POSIX pthread/USS stuff I would have to use the
_POSIX_SYSTEM=NO
environment variable, which has to be set when the enclave
initializes. This would preclude switching command environments. My
plan now is to fall back on IKJEFTSR to issue commands.
One of the most useful features of TSO REXX is issuing and trapping
the output from a TSO command. TSO REXX supplies an outtrap() function
for this. I can implement something similar using the STACK\GETLINE
services.
ISPF is tricky. ooRexx makes extensive use of threads. One of the
big differences between TSO REXX and ooRexx is concurrency. I've
attempted to use pthreads and ISPF before and ISPF choked!
I would like to be able to solve this problem, writing ISPF dialogs
is probably the most common use of REXX on z/OS.
I'm also unsure about how to map a variable from the ISPF function
pool to an ooRexx string.
Stage 4
Write some useful extensions! Although I'm a competent assembler
programmer writing function packages/command processors for TSO REXX
is painful. Most of the packages I want to
create are wrappers to libraries written in C/C++. A case in point
are the apache Xereces/Xalan libraries in the XML toolkit. Using TSO
REXX I would have to play a lot of tricks with the
LE CEEPIPI service to create a persistent environment, using an
assembler stub to forward calls to C++. ooRexx comes into it's own
here. I'm very excited about having XML for REXX.
Mainfraimers will to love it! And I know there's plenty of demand
for it.
DB2 support using the ODBC interface.
Lots of other useful stuff. I can potentially reuse anything in the
C/C++ runtime library, which is a huge amount of functionality.
My current employers are happy for me to work on this in my spare time.
We're an IBM business partner specialising in database/systems
management tools for z/OS. We've got a z800
which is a decent enough machine to implement/test the port.
From looking at the code it's evident that this will be a very exciting
hobby project for me, working with some exceptionally talented
individuals and a great code base. Although my main priority is to
complete the port
I am determined to learn as much as I can about the core
design/implementation of ooRexx. I've never worked on a programming
language, let alone an industrial strength one. As I said to Rick,
mainframers love REXX,
and if we get this right I think they're going to love ooRexx. Almost
everybody I work with, developers, testers, ID know REXX. I see ooRexx
as the perfect language for mainframers to learn OO, many of whom
find Java difficult and C++ impossible. The mainframe needs ooRexx!
I'm going to be asking a lot of questions guys, please be patient.
David
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
