Platform.IS_OPENVMS is unknown in jorg.jruby.ext.posix.util.Platform

jnr-posix should build using maven (in which case, it'll suck in jnr-constants automagically).

To make jnr-posix work properly, you would want to regenerate the constants in jnr-constants for openvms, at the very least, the Errno constants. That might be a bit tricky, since I'm pretty sure the generator is hardcoded to use gcc ... or at least a decent posix environment. It also depends on a working JRuby FFI.

That can all be worked around though with a bit of hacking of the generator scripts.

Hi,

After jruby-jnr-posix/src/org/jruby/ext/posix/Platform.java has been
modified to include Platform.IS_OPENVMS support, the file
jruby-jnr-posix/target/jnr-posix-1.1.8.jar has been generated using "$
mvn clean install" on my Linux Fedora 15. This file has then been SFTP
transfered to the VMS system as jnr-posix.jar to
PHV:[PHV.jruby_vms.jruby-1^.6^.3.build_lib] directory as a new file version of
the JRuby supplied one.

Then on OpenVMS:
$ set def PHV:[PHV.jruby_vms.jruby-1^.6^.3]
$ ant "clean"
$ set def [-]
$ @jruby_vms-1^.6^.3.com

[.Jruby-1^.6^.3.src.org.jruby.util] directory contains my DeccTranslateName.java where I suppressed the main entry point.

Now first success opening a file with a VMS file syntax.
$ pwd
PHV:[PHV]
$ jirb
irb(main):001:0> fp=open("[.jruby_vms]DECC_test.rb","r")
=> #<File:/PHV/PHV/jruby_vms/DECC_test.rb>
irb(main):002:0> puts fp.readline()
require 'ffi'
=> nil
irb(main):003:0>
puts fp.readline()
require 'ffi/platform'
=> nil
irb(main):004:0>
puts fp.readline()
=> nil
irb(main):005:0>
puts fp.readline()
module Portablelibc
=> nil
irb(main):006:0> fp.close()
=> nil
irb(main):003:0> quit
$ jruby "--version"
jruby 1.6.3 (ruby-1.8.7-p330) (2011-07-27 $

)
(Java HotSpot(TM) 64-Bit Server VM 6.0) [OpenVMS-ia64-java]
$

You may close this problem. How may I contribute to JRuby submitting my OpenVMS changes ? Do you prefer a Linux diff file ?

Regards,
Philippe Vouters

If the JRuby team is interested with, it may download all my current source changes to jnr-posix and JRuby 1.6.3 from http://vouters.dyndns.org/zip/jruby-1.6.3_jruby-jnr-posix.diff.tar.gz

This file is a tarball of two Linux diff -Naur outputs. This is to include OpenVMS support to JRuby 1.6.3.

Philippe Vouters

Philippe: Thank you for your help with this!

I have applied the jnr-posix patch, which just adds the OpenVMS platform. I have not incorporated the new jnr-posix into JRuby for 1.6.4 because of a few concerns with the other patch. If you can address these, we'd happily roll them into 1.6.5 and JRuby master.

• The patch includes your .com files from bin. While we're not opposed to those changes, they should be raised and discussed in a separate bug.
• The build changes are fine, and could be included...but I think things work differently on master. Ideally if you can provide a patch that works on both jruby-1_6 branch and master, we can quickly pull it in.
• In the many places where you check for OpenVMS, it might be better if we pulled out the common logic into a separate class, rather than bulking up the ones that are there. For example, you replace get_path calls with get_path + OpenVMS logic, which could all be abstracted behind get_path.

I think my recommendation to you would be to fork JRuby on github and apply your changes there. That will allow us to selectively merge them, refactor them in place (to reduce duplication) and improve OpenVMS support in JRuby without being quite as intrusive. Ok?

Dear Charles,

My understanding is that the JRuby team is welcoming adding OpenVMS support to JRuby. This is an excellent news as JRuby is currently the only possible way to bring the Ruby language onto OpenVMS platforms. I am very good willing to definitely add this JRuby support onto any further version of JRuby.

However you have to train me upon your work methodology so that I interfere the less with your current developments. My so far work method has been to download a stable JRuby version and work upon it, as much as possible thoroughly testing my additions along with Thierry Uso close collaboration so that they give enough satisfaction to VMS end users across the world.

Along with Thierry who wrote all VMS .com files in bin/, we propose either a ready to use VMS virtual disk (Thierry's part) or a VMS way to rebuild JRuby from sources (my part). I have been responsible for any code change within the JRuby code stream.

Should we adjust our strategy ???? Could you explain me by mail sent to Philippe.Vouters@laposte.net how I can quickly get into your git environment and what I should do and should not do to less as possible interfere with your current developments, meanwhile doing productive work ?

I just need some little training with your work methodology. This is necessary if we want to more closely collaborate together.

With my best regards to you.
Philippe

I just want to register our continued interest in resolving this. I was in the process of noting in our internal issues system some problems we've had (missing mappings for errno codes) which we've managed to work our way around so far in other ways. That brought me back to this bug. I have not yet been able to work on this for the next JRuby release, since so far as our team is concerned, we've "solved that" (with our workarounds). Personally, I'm not overly happy with our team having to make that call, as it may end up costing us down the road, but ... that's not your problem. I will at least summarize this bug's status into our issues system now. Maybe once there's a stronger case for my time being spent on this project, I'll be able to lend a hand.

Ok, here's what we'll do.

• I'm going to resolve this as fixed, since the original reported issue should be solved (having Platform.IS_OPENVMS available).

• Ben: If you like, open a bug for any specific work we need to do. The bottom line is that we're happy to improve OpenVMS support given bite-sized patches that don't impact other platforms. Philippe did some great work, but I don't know where we left it off. Parts of it could probably be merged in, and other parts need more work and analysis.

This bug has lingered for a long time, so I think closing it is best. We have been trying to avoid having open-ended "fix all the things" bugs. Better would be for us to open more bugs (here or on Github issues or as pull requests) for specific problems/patches.