- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Native java implementation of decc$translate_vms?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-16-2011 06:06 AM
05-16-2011 06:06 AM
Native java implementation of decc$translate_vms?
https://github.com/bg/jruby-vms
I will include more patches from Messrs. Uso and Vouters (e.g. FFI) in time, but before I do that, there are some issues with core components of JRuby that are important to address.
While Java on VMS does automatic filepath translation, we need some ability to translate between VMS and Unix-style filepaths that is under program control in Java, otherwise JRuby misparses them, e.g. by attempting to expand what it thinks is a relative path, ending up with a mishmash of Unix-style plus VMS-style filepaths:
"JAVA$FILENAME_CONTROLS" = "-1"
$ jruby disk:[dir]file.rb
Error opening script file: /DSA0/BG/disk:[dir]file.rb (no such file or directory (errno:2))
I cannot imagine upstream would accept a call into DECC to use decc$translate_vms from a core component such as src/org/jruby/util/JRubyFile.java. External modules like FFI, sure, but the core should be self-contained. Therefore, it seems to instrument JRubyFile.java with path translation, I need a native Java implementation of decc$translate_vms. Does one exist already that I have overlooked?
Ben
- Tags:
- JRuby
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2011 08:10 AM
07-21-2011 08:10 AM
Re: Native java implementation of decc$translate_vms?
Dear Ben,
As already email stated there is no need for the decc$translate_xxx C RTL source code access. This source code is very likely to make VMS specific calls you won't be able to turn to pure Java so that it can be accepted by the JRuby maintainers for inclusion into the JRuby source stream.
Download the corresponding latest pure Java zipped source code from http://vouters.dyndns.org/zip/DeccTranslateName.java.zip Refer to http://vouters.dyndns.org/tima/OpenVMS-Java-Unix-CRTL_API_decc$translate_name-Java_solution.html for the conditions under which this code has been written and tested.
This article includes various tested VMS style file specifications syntaxes along with the corresponding Unix style file specification syntaxes result the code produced. You will note you should not need any DECC$EFS_CHARSET logical enabled. This is unlike the C RTL decc$transate_vms routine as per stated at http://vouters.dyndns.org/tima/OpenVMS-Intel-Itanium-Assembler-Some_notes.html
However if you pay enough attention to the comments in the tests part, you'll notice that JAVA$FILENAME_CONTROLS logical may interact with this Java code.
Yours sincerely,
Philippe