On 30/10/2013 3:01 PM, Timothy Sipples wrote:
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.
Any z/OS tool that doesn't support EBCDIC is a dud from the start.
Simple as that.
There is no problem building Lua, but you may have issues executing it.
"make posix" will build the basic interpreter and runtime, that's all.
Then optimize the code and run a coroutine - ABEND. z/OS C has a
different stack layout to other *nix systems. There was
a similar problem porting Ruby to z/OS.
https://www.ruby-forum.com/topic/114046. Then you have to tackle the
regex like string handling routines. And then of course to do anything
useful
you need packages, and that's where the hard work starts. It's certainly
not as simple as running make. Porting packages for web programming,
like HTTP protocols, will require EBCDIC work at the socket level to
handle those pesky newlines.
And then there's a lot of patching the C code for runtime
inconsistencies (almost all packages were coded for Linux). It took me
a good few days just to port the socket package. There is a considerable
amount
of work getting it to run smoothly on z/OS. It's taken me a year to
build up the runtime and I've got almost 20 years of C/C++ programming
experience and have ported a lot of software to z/OS.
I've had a lot of interest in Lua, including vendors and several IBM
labs. I should be ready to release it soon.
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?
I don't see what the big issue is. Just maintain a separate patch file.
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.
Wishful thinking! And I don't know any z/OS Unix programmer who has
anything good to say about the z/OS Unicode Systems Services API.
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.
I prefer the Apache method of EBCDIC/ASCII translation depending on
the content-type mime header!
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: sipp...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
