<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Native java implementation of decc$translate_vms? in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/native-java-implementation-of-decc-translate-vms/m-p/4788289#M36283</link>
    <description>&lt;!--!*#--&gt;I'm working on adding more support for VMS to JRuby, starting with the work by Phillipe Vouters and Thierry Uso at &lt;A href="http://vmsfree.ouvaton.org/freen/index.php?s=jruby," target="_blank"&gt;http://vmsfree.ouvaton.org/freen/index.php?s=jruby,&lt;/A&gt; merging their patches one at a time and submitting them upstream so they will be included in subsequent releases. So far, I have submitted (and they have accepted) just the one simple patch for the IS_OPENVMS platform check:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="https://github.com/bg/jruby-vms" target="_blank"&gt;https://github.com/bg/jruby-vms&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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:&lt;BR /&gt;&lt;BR /&gt;  "JAVA$FILENAME_CONTROLS" = "-1"&lt;BR /&gt;&lt;BR /&gt;$ jruby disk:[dir]file.rb&lt;BR /&gt;Error opening script file: /DSA0/BG/disk:[dir]file.rb (no such file or directory (errno:2))&lt;BR /&gt;&lt;BR /&gt;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?&lt;BR /&gt;&lt;BR /&gt;Ben&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Mon, 16 May 2011 13:06:35 GMT</pubDate>
    <dc:creator>Ben Armstrong</dc:creator>
    <dc:date>2011-05-16T13:06:35Z</dc:date>
    <item>
      <title>Native java implementation of decc$translate_vms?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/native-java-implementation-of-decc-translate-vms/m-p/4788289#M36283</link>
      <description>&lt;!--!*#--&gt;I'm working on adding more support for VMS to JRuby, starting with the work by Phillipe Vouters and Thierry Uso at &lt;A href="http://vmsfree.ouvaton.org/freen/index.php?s=jruby," target="_blank"&gt;http://vmsfree.ouvaton.org/freen/index.php?s=jruby,&lt;/A&gt; merging their patches one at a time and submitting them upstream so they will be included in subsequent releases. So far, I have submitted (and they have accepted) just the one simple patch for the IS_OPENVMS platform check:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="https://github.com/bg/jruby-vms" target="_blank"&gt;https://github.com/bg/jruby-vms&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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:&lt;BR /&gt;&lt;BR /&gt;  "JAVA$FILENAME_CONTROLS" = "-1"&lt;BR /&gt;&lt;BR /&gt;$ jruby disk:[dir]file.rb&lt;BR /&gt;Error opening script file: /DSA0/BG/disk:[dir]file.rb (no such file or directory (errno:2))&lt;BR /&gt;&lt;BR /&gt;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?&lt;BR /&gt;&lt;BR /&gt;Ben&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 16 May 2011 13:06:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/native-java-implementation-of-decc-translate-vms/m-p/4788289#M36283</guid>
      <dc:creator>Ben Armstrong</dc:creator>
      <dc:date>2011-05-16T13:06:35Z</dc:date>
    </item>
    <item>
      <title>Re: Native java implementation of decc$translate_vms?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/native-java-implementation-of-decc-translate-vms/m-p/4835625#M36284</link>
      <description>&lt;P&gt;Dear Ben,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Download the corresponding latest&amp;nbsp; pure Java zipped source code from &lt;A target="_blank" href="http://vouters.dyndns.org/zip/DeccTranslateName.java.zip"&gt;http://vouters.dyndns.org/zip/DeccTranslateName.java.zip&lt;/A&gt; Refer to &lt;A target="_blank" href="http://vouters.dyndns.org/tima/OpenVMS-Java-Unix-CRTL_API_decc$translate_name-Java_solution.html"&gt;http://vouters.dyndns.org/tima/OpenVMS-Java-Unix-CRTL_API_decc$translate_name-Java_solution.html&lt;/A&gt;﻿ for the conditions under which this code has been written and tested.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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&amp;nbsp;&lt;A target="_blank" href="http://vouters.dyndns.org/tima/OpenVMS-Intel-Itanium-Assembler-Some_notes.html"&gt;http://vouters.dyndns.org/tima/OpenVMS-Intel-Itanium-Assembler-Some_notes.html&lt;/A&gt;﻿&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Yours sincerely,&lt;/P&gt;&lt;P&gt;Philippe&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 21 Jul 2011 15:10:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/native-java-implementation-of-decc-translate-vms/m-p/4835625#M36284</guid>
      <dc:creator>Ph Vouters</dc:creator>
      <dc:date>2011-07-21T15:10:59Z</dc:date>
    </item>
  </channel>
</rss>

