Port ruby to z/OS UNIX

Ruby
1

hello,

I am trying to port ruby to z/OS UNIX. I resolved obvious EBCDIC to
ASCII problems and I encountered a problem:
(1) I get a message like below:
bash-2.03$ gmake
./lib/fileutils.rb:1277: [BUG] unexpected local variable
(2)I know the message is from eval.c and I add some break points at
eval.c and try to catch the problem. but I get another message:
fu_output_message is not a class/module

I am not sure if it is possible that the stack or the generation of node
tree has problems.

Thanks &Regards

HaiJun

2

HaiJun wrote:

I am not sure if it is possible that the stack or the generation of node
tree has problems.

Thanks &Regards

HaiJun

What is “z/OS UNIX”? Is it like Linux? Is it like AIX? My recollection
is the latter, so if someone has experience building Ruby on AIX, they
might have some clues for you.

3

z/OS is a 64-bit OS that runs on IBM mainframes. z/OS “UNIX” runs on
top of
this as an alternative to the traditional MVS.

4

shadow cipher wrote:

ASCII problems and I encountered a problem:

It’s been many decades since I had anything to do with IBM mainframes.
But way back then, there was VM and MVS. VM was Virtual Machine, and you
could run MVS as a guest under VM. There was also something called CMS
that ran as a guest and was popular with scientists. And back then, I
think there was a port of BSD 4.3 that ran as a guest as well. Some time
later, IBM came up with a “UNIX” that looked a lot like AIX that also
ran under VM.

In any event, if it is “Unix” in any form, you should be able to build
and run Ruby on it, although you might also need to build some of the
Gnu tools and GCC to make everything play together.

5

Greetings,
I have built Ruby 1.8.6 on z/OS as an ASCII application. I have
installed rubygems and Rails. I can run irb and ruby scripts, and I can
generate a Rails application.

The problem I run into is that the pseudo threads implementation in
eval.c depends on a technique of stack swapping from heap that the z/OS
C runtime setjmp/longjmp and getcontext/setcontext functions do not
support. The C runtime insists on stack integrity. When stack_extend
needs to be called, a valid chainback no longer exists. Ruby abnormally
ends (abends) with a stack check exception.

So long as Ruby threading is not used, e.g. in a typical script, all is
well. However, running a server application, where threading is
essential to support multiple clients, does not work.

If the pseudo threads implementation could be replaced with pthreads,
even if the pthreads were all synchronized (due to the lack of thread
safety for global variable access), then I believe a z/OS implementation
of the Ruby interpreter would work. I have attempted this myself, but I
need some more pthread API expertise.

I have built JRuby on z/OS, and it works reasonably well, if slowly. I
can build and run a Rails application, and I have run it using
mongrel-jruby. I have fiddled with ActiveRecord-JDBC to get this to work
with DB2 on z/OS. ActiveRecord-JDBC had some problems with Rails using
quoted numerics, but copying the jdbc-derby code to use with DB2 helped
there. However, BLOB/CLOB support is a bit unconventional on z/OS DB2,
and ActiveRecord-JDBC did not work with that (so Camping session, which
uses a text type that maps to a CLOB, does not work). (Note that if you
are using ibm_db from a workstation Ruby session to z/OS DB2, that
Camping runs fine. BLOB/CLOB support in ibm_db is robust).

I would be interested in working with folks to facilitate their efforts
at Ruby on z/OS, and who could help me with the bowels of eval.c. Ruby’s
utility as a scripting language suggests it could offer a lot to
sysprogs, dba’s, and testers. It would also be helpful to write servers
to provide health check info and access into the system. Rails might
also be an interesting exercise there.