I'm attempting to build ooRexx on z/OS. I didn't think it would be trivial and it's not.
I've tracked down some of the ASCII tables and replaced them with EBCDIC, but that's the
least of my problems.
ooRexx unix builds make extensive use of pthreads, which is great. Unfortunately there is
a lot of casting of pthread_t to long, which wont work on z/OS, where pthread_t is an opaque
type. I'm patching this as I go but I've now hit a dead end with the semaphores in rexxutil.cpp.
I've now come to the conclusion that this is a full blown port and I need a plan. Here are my issues:
Patch the configure scripts to correctly build on z. When I ran configure it didn't work smoothly, for
example it doesn't know how to detect how to build DLLs. I'm no autoconf/automake expert, any help will
be warmly received.
pthreads are Z are not compatible with other nix's. Casting pthread_t to a long is not an option.
ASCII issues - I've patched the parser, where else is there ASCII specific code/tables?
Once I get a clean build I will then start to implement z/OS function package, such as:
ZFile - function package to process z/OS files, QSAM, PDS, VSAM etc. This should be straightforward, just
wrap the stdio C runtime functions.
DB2 - function package to wrapper DB2 ODBC functions to provide access to DB2 data bases.
XML - function packages to provide XML/XSLT processing utilizing Xerces/Xalan and the new XML systems services
enabled DOM parser in the z/OS XML Toolkit.
If and when I succeed I will provide a patch file and the binaries for you guys to host here. I think the best way
to proceed is a seperate patch that I will maintain, otherwise the code may become obfuscated.
What I'm looking for is advice on how to proceed, especially with the pthread issue.
No worries about the arch docs. I've already built doxygen doco and reverse engineered the code into UML
so I've got everything I need for a fast start. Thanks for the advice, will post an intro soon...
First of all, a hearty welcome! People have been talking about a z/OS port for years, but it's nice to see somebody who's actually gotten beyond the "what compiler should I use question".
You might want to subscribe to the developer's mailing list and start using that for questions. More people follow that list, including at least one person who's also interested in a z/OS port. You might pick up some help that way.
I assume from your findings that you're working from the 3.2.0 code. You might want to consider working from the trunk version, even though that's less stable than the 3.2.0 version. The platform interface has been significantly reworked in trunk, with the pthread_t casting issue being one of many things that have been fixed. This code base is also (in theory at least) 64-bit clean. We've not gotten around to building/testing yet on a 64-bit platform, but we should be getting closer.
Providing patches is perhaps another good reason for switching to trunk. The code has been significantly reworked since 3.2.0. I'm not sure we really want to be applying any patches to that code base any more. Also, if you're working off of trunk, a "patch-early-and-often" strategy might be better. If the changes you need are directly incorporated in the base code, the rest of the team can be more sensitive to what issues exist...for example the EBCDIC issue. It's pretty simple thing to have those conditionally compile using #ifdef ASCII/EBCDIC tags. We can put that sort of change in any time you find it is needed.
Anyway, sounds like you're off to a pretty good start. I encourage you to ask lots of questions on the dev mailing list. The answers will help others, not just you.
Thanks Rick! I've signed out the trunk and from what I've already seen I'm more than confident that the port is feasible. I ported
boost last year, which was quite tricky. z/OS has a POSIX compliant unix system services stack, so if we all work together I think
we can get a good result. Mainframers love REXX and I'm sure they will love ooRexx.
I'm very happy with the code base, it's top quality stuff. If there's any architecture, standards docs I would love to see it.
The only concerns I have right now are autoconf/automake/configure and the EBCDIC issue. 64-bit not a problem. The big iron is 64-bit ready and so
is the z/OS C/C++ compiler (which is a high quality compiler).
I've subscribed to the developers mailing list so expect to see me asking a lot of questions in the next few weeks/months.
btw, you might want to make an intro post on the dev mailing list to attract the attention of any others interested in helping out.
No, there's no architecture docs for this...I generally have enough stuff on my plate that it's difficult to put other things (like writing code) aside to do an architecture doc. And, in my experience, they don't even remain up-to-date long enough for the ink to dry...I prefer documenting what's going on directly in the code, so there's a reasonable chance that things will remain current.
One of the reasons I encourage questions is I'm more than willing to take the time to explain how something works in the context of a question. And like I said earlier, these answers become part of the mail archives and can be seen by everybody, so ask away!
Thank you about the code comments...I had a very good teacher (Mike Cowlishaw).
Well, 64-bit might be an issue. The compiler and the hardware might be up to the task, but the 3.2.0 code most certainly is not. The pthread_t cast to a long was only the tip of the iceberg for that sort of behavior. Part of the goal of the next release was to get all of that stuff cleaned up so we can actually work in 64-bit mode. Things are looking pretty clean right now, but my experience with past 64-bit conversions is there are always hidden gotchas hiding in the shadows, so until the code has actually been tested in 64-bit mode, I'll not make definitive statements about its readiness.
Log in to post a comment.