>I've recently been writing web servers using Lua/Orbit. >From the reports I've read there doesn't seem to be any particular problem compiling Lua on z/OS (via "make posix"). As mentioned previously, if you want to operate on EBCDIC data there might be additional steps you have to take (might), but if that's true it would be true of Lua in general and not only when running on z/OS specifically. Though I did see a report that a commercial firm decided to use Lua on IBM i, and they may have done so with EBCDIC support.
If I could coach a little bit on the Perl "conversation" within the open source community, Perl's maintainers seem to be particularly hung up on EBCDIC support and not particularly interested in it (to be charitable). Well, OK -- but why impose that requirement when it doesn't exist in reality? If somebody wants to have an EBCDIC extension to Perl -- Perl allows various non-core extensions, which is partly what makes Perl popular in certain domains -- then OK, and that extension can be separately maintained (and would be useful both on and off z/OS since EBCDIC is not unique to z/OS nor useful only when running on z/OS). But why try to force EBCDIC into Perl "mainline" itself when z/OS doesn't require EBCDIC? In my view, those that are interested in encouraging and supporting more open source software on z/OS -- as I am -- need to be a bit more, er, diplomatic. Yes, I understand why many z/OS-centric and z/OS-specific features would be nice to have, including support for operating on EBCDIC data. However, various open source communities have different priorities and interests -- and that's not a z/OS-specific observation. Moreover, something like EBCDIC support should be quite easy to keep well segregated and generalized, via z/OS Unicode Services in particular. So "keep it simple" when porting and rely on z/OS's support for UNIX, POSIX, Unicode, and other common standards. Then, later, optionally, "plug into" a generalized z/OS Unicode Services layer (for example), which *might* involve negotiating over only one or a couple lines added to the mainline source code for the particular open source project. Thinking aloud (metaphorically speaking), maybe it would make a lot of sense to have a generalized z/OS-exploiting services layer, with common services that typical open source software users can optionally use but which aren't required to be incorporated into the open source mainline itself. It seems like that sort of approach ought to be very possible. What I'd suggest is agreeing on a ranked list of "technically optional but nice to have" z/OS-exploiting features, then figuring out how to have a common services runtime/library that "typical" open source software would either automatically tap into (via existing interfaces that open source software already use, such as file I/O) or that would involve at most adding at most a "line or two" to the mainline source. For example, if we're talking about EBCDIC support, then maybe one way to do that -- thinking aloud again -- is via bog standard open source-friendly file I/O. For example, if the path begins with: /ebcdic/... Then that would get *externally* trapped and handled at runtime without affecting the application's source code. (It'd be a bit more elegant than this, but you get the idea.) IBM did something vaguely similar to this with early Web serving on z/OS though in reverse. If the HTML file had a .ascii appended to the file name then the Web server would deliver it as ASCII (well, actually without any character set translation, i.e. "binary"), while otherwise it would pass through EBCDIC-to-ASCII/Unicode conversion. There are actually already some "MVS aware" file I/O services in z/OS UNIX which might already do the trick, or at least which are very close to what's required. -------------------------------------------------------------------------------------------------------- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
