Hi Dan! Dan Carter wrote: > David, my name is Dan Carter. Several years ago I decided to try to > port ooRexx to zOS, and I promptly ran into a jungle of I-don't-knows. > I have access to an IBM system (z10, I believe), and I make extensive > use of Rexx in my porting practice (CICS/COBOL to Un*x) but I have > little experience in the Un*x system-programming area. I am a competent > assembler programmer and I use C when I can, which is not often. > > Unfortunately mainframe migrations seem to be accelerating rapidly. It doesn't take a rocket scientist to work out why, costs, TCO etc.
We're going to need assembler down the line. REXX programmers would expect to be able to run ooRexx scripts that reside in SYSEXEC libraries. When I get to the TSO/Batch (non-USS) stage we will have to write some assembler that BLDLs on SYSEXEC to find scripts. As of z/OS 1.9 IBM has added an exciting new feature to the C/C++ compiler called Metal C. http://www-03.ibm.com/systems/z/os/zos/metalc/ This is basically the C equivalent of PL/X (which IBM never made GA), you can inline assembler in your C code, just like GCC. I know it sounds far-fetched but on the modern super-scalar processors I've often seen optimized C code run faster than hand coded assembler. The compiler understands the machine better and can schedule instructions to take advantage of parallelism. However, most z/OS systems services are assembler macros, so we're always going to need assembler when the C runtime library doesn't cut it. > I got stuck on understanding the ooRexx architecture in order to choose > a starting place. I have chosen to just start by trying to build the > product on Windows or Solaris or SUSE or wherever I can get it to build, > but I am experiencing significant time constraints. More people want to > move their CICS to Un*x than can be comfortably accommodated. You can > guess what suffers. > > I haven't really dug too deeply into the ooRexx architecture. My strategy is to get the thing built and then debug it. I'm looking for ASCII/EBCDIC issues and patching anything that doesn't compile. An example is pthreads, which IBM made of mess off on z/OS. They're now cleaning up with SUSV3 compliance. If you look at the folder structure you will see that the product consists of packages (or subsystems). Kernel, API, extensions etc. I would encourage you to do what I did and use doxygen with graphviz to create docs (which IMO are superior to Javadoc). This will give you a fast start. http://www.stack.nl/~dimitri/doxygen/download.html http://www.graphviz.org/Download..php > If I can be of any help I would enthusiastically volunteer, especially > if I can learn anything that will help me work with the SourceForge > environment, or building and installing on Solaris, et. al. > > I welcome your help! I've already started to submit patches, keep your eye out for patches submitted by dopc1. > I don't know that I can answer many questions, but I can help clarify > things, and I can certainly work on mainframe code. > > Mate, there's lots of mainframe coding ahead. I'm sure we can learn a lot of each other and pick up some skills along the way... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David > Crayford > Sent: Saturday, July 12, 2008 03:06 > To: oorexx-devel@lists.sourceforge.net > Subject: [Oorexx-devel] Porting ooRexx to z/OS > > 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 > > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
