perl.vmsperl http://www.nntp.perl.org/group/perl.vmsperl/ ... Copyright 1998-2015 perl.org Thu, 27 Aug 2015 21:04:15 +0000 ask@perl.org VMS::Lock 1.03 available by Craig A. Berry I&rsquo;ve at long last obtained co-maintainership of Brad Hughes&rsquo;s VMS::Lock module and fixed the longstanding namespace pollution bug and a couple of other nits. Available at: <br/> <br/>&lt;http://search.cpan.org/~cberry/VMS-Lock-1_03/&gt; <br/> <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/07/msg15686.html Sat, 04 Jul 2015 22:05:39 +0000 Re: perl for VMS 7.3-2 on VAX (or rather the SIMH) by Dr Eberhard W Lisse Craig, <br/> <br/>thanks. Point noted :-)-O <br/> <br/>This (VAX/SIMH) is just a blast from the past, (from Medical School <br/>actually, 35 years ago) :-)-O, and I just thought I play with perl a <br/>little. <br/> <br/>And I run the emulator on OS X and could not find much for that :-)-O <br/> <br/>I found perl5_005_03_vmsvax6_2.zip on DECUSLIB (it is not on the FTP nor <br/>HTTP site) and that works. <br/> <br/>greetings, el <br/> <br/> <br/> <br/> <br/>On 2015-07-03 22:41 , Craig A. Berry wrote: <br/>&gt; <br/>&gt;&gt; On Jul 3, 2015, at 2:58 PM, Dr Eberhard Lisse &lt;nospam@lisse.NA&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt; I am currently playing with this on a Hobbyist license and wonder now if <br/>&gt;&gt; there is a perl kit (any version, really). <br/>&gt;&gt; <br/>&gt; <br/>&gt; A pedantic point, but there is no such thing as VMS v7.3-2 on VAX. <br/>&gt; v7.3 was the terminal release on VAX and v7.3-2 was Alpha only. <br/>&gt; <br/>&gt; For Perl versions up through 5.22, there is latent support for <br/>&gt; building on VAX but I haven&rsquo;t tried it in at least a couple <br/>&gt; years. There are so many essential features missing from VAX that <br/>&gt; it&rsquo;s just not worth the trouble. <br/>&gt; <br/>&gt; There are some ancient binary kits of Perl for VAX at <br/>&gt; &lt;http://www.sidhe.org/vmsperl/prebuilt.html&gt;. <br/>&gt; <br/>&gt; If you want to run more current software, my advice is to get away <br/>&gt; from VAX and run an Alpha emulator. There are free ones but no <br/>&gt; complete open source ones that I&rsquo;m aware of. <br/>&gt; <br/>&gt; ________________________________________ <br/>&gt; Craig A. Berry <br/>&gt; mailto:craigberry@mac.com <br/>&gt; <br/>&gt; &quot;... getting out of a sonnet is much more <br/>&gt; difficult than getting in.&quot; <br/>&gt; Brad Leithauser <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/07/msg15685.html Sat, 04 Jul 2015 06:22:53 +0000 Re: perl for VMS 7.3-2 on VAX (or rather the SIMH) by Craig A. Berry <br/>&gt; On Jul 3, 2015, at 2:58 PM, Dr Eberhard Lisse &lt;nospam@lisse.NA&gt; wrote: <br/>&gt; <br/>&gt; I am currently playing with this on a Hobbyist license and wonder now if <br/>&gt; there is a perl kit (any version, really). <br/>&gt; <br/> <br/>A pedantic point, but there is no such thing as VMS v7.3-2 on VAX. v7.3 was the terminal release on VAX and v7.3-2 was Alpha only. <br/> <br/>For Perl versions up through 5.22, there is latent support for building on VAX but I haven&rsquo;t tried it in at least a couple years. There are so many essential features missing from VAX that it&rsquo;s just not worth the trouble. <br/> <br/>There are some ancient binary kits of Perl for VAX at &lt;http://www.sidhe.org/vmsperl/prebuilt.html&gt;. <br/> <br/>If you want to run more current software, my advice is to get away from VAX and run an Alpha emulator. There are free ones but no complete open source ones that I&rsquo;m aware of. <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/07/msg15684.html Fri, 03 Jul 2015 20:41:16 +0000 perl for VMS 7.3-2 on VAX (or rather the SIMH) by Dr Eberhard Lisse Hi,<br/><br/>I am currently playing with this on a Hobbyist license and wonder now if<br/>there is a perl kit (any version, really).<br/><br/>greetings, el<br/>-- <br/>replace nospam by el if you want to email me directly<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/07/msg15683.html Fri, 03 Jul 2015 20:25:26 +0000 Perl 5.22.0 binary kits for OpenVMS available by Craig A. Berry Installation kits for OpenVMS Alpha and OpenVMS I64 v8.3 and later are available at: <br/> <br/>&lt;https://sourceforge.net/projects/vmsperlkit/files/&gt; <br/> <br/>The files are self-extracting archives and after downloading <br/>you must run them like so: <br/> <br/>$ run VMSPORTS-AXPVMS-PERL522-V0522-0-1.SFX_AXPEXE <br/> <br/>for Alpha, and: <br/> <br/>$ run VMSPORTS-I64VMS-PERL522-V0522-0-1.SFX_I64EXE <br/> <br/>for Itanium. Then, on either platform: <br/> <br/>$ product install perl522 <br/> <br/>and follow the usual installation prompts. Note that the major version is now included in the product name so this installation will not remove installations of previous versions (e.g., 5.18 or 5.20). <br/> <br/>The kits provided here are intended to be a convenient way to acquire a default build; there are many other configuration options available if you build your own Perl from the source at &lt;http://www.cpan.org/src/5.0/perl-5.22.0.tar.gz&gt;. <br/> <br/>Have an appropriate amount of fun. Anything related to these kits that turns out to be more fun than you can handle is probably best reported on the vmsperl mailing list.[1] <br/> <br/>Changes in this release can be found via typing &quot;perldoc perldelta&quot; after installation. <br/> <br/> <br/>[1] &lt;http://lists.perl.org/list/vmsperl.html&gt; <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/06/msg15682.html Thu, 04 Jun 2015 13:24:11 +0000 Re: Error Building OpenVMS perl 5.20.2 by Eric Robertson Craig A. Berry wrote:<br/><br/>&gt;&gt; Creating Makefile.PL in dist/ExtUtils-ParseXS for ExtUtils::ParseXS<br/>&gt;&gt;<br/>&gt;&gt; Running Makefile.PL in dist/ExtUtils-ParseXS<br/>&gt;&gt; DKB1:[usr.robertson.WebDownloads.perl.perl-5^.20^.2.][000000]MINIPERL.EXE;2 <br/>&gt;&gt;<br/>&gt;&gt; &quot;-I../../lib&quot; &quot;Makefile.PL&quot; &quot;INST_LIB=[--.lib]&quot; &quot;INST_AR<br/>&gt;&gt; CHLIB=[--.lib]&quot; &quot;PERL_CORE=1&quot;<br/>&gt;&gt; Generating a MMK-style Descrip.MMS<br/>&gt;&gt; Writing Descrip.MMS for ExtUtils::ParseXS<br/>&gt;&gt; Making all in dist/ExtUtils-ParseXS<br/>&gt;&gt; MMK all /DESCRIPTION=descrip.mms /MACRO=(&quot;PERL_CORE=1&quot;)<br/>&gt;&gt; %MMK-F-CANTUPD, cannot update target [.LIB.EXTUTILS]XSUBPP^.. - sources<br/>&gt;&gt; unknown<br/>&gt;&gt; %MMK-F-CANTUPD, cannot update target [.LIB.EXTUTILS]XSUBPP^.. - sources<br/>&gt;&gt; unknown<br/>&gt; <br/>&gt; Please check that you have extended parse enabled in the process, and <br/>&gt; please also check that you do not have DECC$EFS_CHARSET explicitly <br/>&gt; disabled in the process. This is just guessing. I&#39;ve never seen this <br/>&gt; particular error so I don&#39;t know for sure what&#39;s going on, but <br/>&gt; &quot;XSUBPP^..&quot; sure looks like something went wrong with handling <br/>&gt; extended characters.<br/>Thanks for the clue! I had not built perl since 5.18.2 and while the <br/>command procedure that builds perl had the SET <br/>PROCESS/PARSE_STYLE=EXTENDED/CASE_LOOKUP=BLIND as its first command, my <br/>LOGIN.COM had changed and no longer had this command in it. So in some <br/>cases MMK would create batch jobs which would not setup the EXTENDED <br/>parse style needed for ODS-5 extended file naming. After I added this <br/>command back to my LOGIN.COM, all was well and perl 5.22.0 built <br/>successfully.<br/><br/>Thanks again for the quick response!<br/><br/>Regards,<br/><br/>Eric<br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/06/msg15681.html Tue, 02 Jun 2015 20:32:44 +0000 Re: Error Building OpenVMS perl 5.20.2 by Craig A. Berry <br/> <br/>On Jun 02, 2015, at 11:39 AM, Eric Robertson &lt;eric.robertson@iqware.us&gt; wrote: <br/> <br/>&gt; I am currently attempting to build the perl 5.20.2 release on OpenVMS <br/>&gt; Alpha V8.3 and I get an error part way through the build. <br/> <br/>5.22.0 was released yesterday, so I&#39;d recommend starting there. I hope to get kits out soonish but I gather you have a reason to build your own from source so there&#39;s no reason to wait for me. <br/>&gt; I saw an earlier posting that <br/>&gt; indicated the CPAN.pm module for 5.20.x was not functional for OpenVMS. <br/>&gt; But when I compared the CPAN.pm modules from the 5.20.2 release with the <br/>&gt; supposedly patched versions contained in the <br/>&gt; VMSPORTS-AXPVMS-PERL--V0520-1-1 kit I did not see any differences <br/> <br/>This is odd but the CPAN problem would not have anything to do with building the core, only with installing additional extensions afterwards. And the problem there was with CPAN has been fixed in 5.22.0. <br/>&gt; As Always, any wisdom on how to investigate this problem would be <br/>&gt; appreciated. <br/> <br/>&#xFEFF; <br/>&gt; Creating Makefile.PL in dist/ExtUtils-ParseXS for ExtUtils::ParseXS <br/>&gt; <br/>&gt; Running Makefile.PL in dist/ExtUtils-ParseXS <br/>&gt; DKB1:[usr.robertson.WebDownloads.perl.perl-5^.20^.2.][000000]MINIPERL.EXE;2 <br/>&gt; &quot;-I../../lib&quot; &quot;Makefile.PL&quot; &quot;INST_LIB=[--.lib]&quot; &quot;INST_AR <br/>&gt; CHLIB=[--.lib]&quot; &quot;PERL_CORE=1&quot; <br/>&gt; Generating a MMK-style Descrip.MMS <br/>&gt; Writing Descrip.MMS for ExtUtils::ParseXS <br/>&gt; Making all in dist/ExtUtils-ParseXS <br/>&gt; MMK all /DESCRIPTION=descrip.mms /MACRO=(&quot;PERL_CORE=1&quot;) <br/>&gt; %MMK-F-CANTUPD, cannot update target [.LIB.EXTUTILS]XSUBPP^.. - sources <br/>&gt; unknown <br/>&gt; %MMK-F-CANTUPD, cannot update target [.LIB.EXTUTILS]XSUBPP^.. - sources <br/>&gt; unknown <br/> <br/>Please check that you have extended parse enabled in the process, and please also check that you do not have DECC$EFS_CHARSET explicitly disabled in the process. This is just guessing. I&#39;ve never seen this particular error so I don&#39;t know for sure what&#39;s going on, but &quot;XSUBPP^..&quot; sure looks like something went wrong with handling extended characters. http://www.nntp.perl.org/group/perl.vmsperl/2015/06/msg15680.html Tue, 02 Jun 2015 17:18:14 +0000 Error Building OpenVMS perl 5.20.2 by Eric Robertson I am currently attempting to build the perl 5.20.2 release on OpenVMS <br/>Alpha V8.3 and I get an error part way through the build. Taken at face <br/>value it would seem that not all of the needed dependencies for the perl <br/>module ExtUtils::ParseXS are present. But, there may be a deeper problem <br/>of which this error is but a symptom. What follows is an excerpt taken <br/>from near the end of the build log. I saw an earlier posting that <br/>indicated the CPAN.pm module for 5.20.x was not functional for OpenVMS. <br/>But when I compared the CPAN.pm modules from the 5.20.2 release with the <br/>supposedly patched versions contained in the <br/>VMSPORTS-AXPVMS-PERL--V0520-1-1 kit I did not see any differences (Under <br/>the assumption that the static versions of the files in the kit are <br/>used and not dynamically generated by the PCSI installation procedure). <br/>So, I assumed that the 5.20.2 release already contained the patched <br/>versions of CPAN.pm module.<br/><br/>As Always, any wisdom on how to investigate this problem would be <br/>appreciated.<br/><br/>Thanks,<br/><br/>Eric<br/><br/><br/>.<br/>.<br/>.<br/>Running Makefile.PL in cpan/Test-Harness<br/>DKB1:[usr.robertson.WebDownloads.perl.perl-5^.20^.2.][000000]MINIPERL.EXE;2 <br/>&quot;-I../../lib&quot; &quot;Makefile.PL&quot; &quot;INST_LIB=[--.lib]&quot; &quot;INST_AR<br/>CHLIB=[--.lib]&quot; &quot;PERL_CORE=1&quot;<br/>Generating a MMK-style Descrip.MMS<br/>Writing Descrip.MMS for Test::Harness<br/>Making all in cpan/Test-Harness<br/>MMK all /DESCRIPTION=descrip.mms /MACRO=(&quot;PERL_CORE=1&quot;)<br/>cp [.lib.App.Prove.State.Result]Test.pm <br/>[--.lib.App.Prove.State.Result]Test.pm<br/>cp [.lib.App.Prove.State]Result.pm [--.lib.App.Prove.State]Result.pm<br/>cp [.lib.App.Prove]State.pm [--.lib.App.Prove]State.pm<br/>cp [.lib.App]Prove.pm [--.lib.App]Prove.pm<br/>cp [.lib.TAP.Formatter.Console]ParallelSession.pm <br/>[--.lib.TAP.Formatter.Console]ParallelSession.pm<br/>cp [.lib.TAP.Formatter.Console]Session.pm <br/>[--.lib.TAP.Formatter.Console]Session.pm<br/>cp [.lib.TAP.Formatter.File]Session.pm [--.lib.TAP.Formatter.File]Session.pm<br/>cp [.lib.TAP.Formatter]Base.pm [--.lib.TAP.Formatter]Base.pm<br/>cp [.lib.TAP.Formatter]Color.pm [--.lib.TAP.Formatter]Color.pm<br/>cp [.lib.TAP.Formatter]Console.pm [--.lib.TAP.Formatter]Console.pm<br/>cp [.lib.TAP.Formatter]File.pm [--.lib.TAP.Formatter]File.pm<br/>cp [.lib.TAP.Formatter]Session.pm [--.lib.TAP.Formatter]Session.pm<br/>cp [.lib.TAP.Harness]Beyond.pod [--.lib.TAP.Harness]Beyond.pod<br/>cp [.lib.TAP.Harness]Env.pm [--.lib.TAP.Harness]Env.pm<br/>cp [.lib.TAP.Parser.Iterator]Array.pm [--.lib.TAP.Parser.Iterator]Array.pm<br/>cp [.lib.TAP.Parser.Iterator]Process.pm <br/>[--.lib.TAP.Parser.Iterator]Process.pm<br/>cp [.lib.TAP.Parser.Iterator]Stream.pm [--.lib.TAP.Parser.Iterator]Stream.pm<br/>cp [.lib.TAP.Parser.Result]Bailout.pm [--.lib.TAP.Parser.Result]Bailout.pm<br/>cp [.lib.TAP.Parser.Result]Comment.pm [--.lib.TAP.Parser.Result]Comment.pm<br/>cp [.lib.TAP.Parser.Result]Plan.pm [--.lib.TAP.Parser.Result]Plan.pm<br/>cp [.lib.TAP.Parser.Result]Pragma.pm [--.lib.TAP.Parser.Result]Pragma.pm<br/>cp [.lib.TAP.Parser.Result]Test.pm [--.lib.TAP.Parser.Result]Test.pm<br/>cp [.lib.TAP.Parser.Result]Unknown.pm [--.lib.TAP.Parser.Result]Unknown.pm<br/>cp [.lib.TAP.Parser.Result]Version.pm [--.lib.TAP.Parser.Result]Version.pm<br/>cp [.lib.TAP.Parser.Result]YAML.pm [--.lib.TAP.Parser.Result]YAML.pm<br/>cp [.lib.TAP.Parser.Scheduler]Job.pm [--.lib.TAP.Parser.Scheduler]Job.pm<br/>cp [.lib.TAP.Parser.Scheduler]Spinner.pm <br/>[--.lib.TAP.Parser.Scheduler]Spinner.pm<br/>cp [.lib.TAP.Parser.SourceHandler]Executable.pm <br/>[--.lib.TAP.Parser.SourceHandler]Executable.pm<br/>cp [.lib.TAP.Parser.SourceHandler]File.pm <br/>[--.lib.TAP.Parser.SourceHandler]File.pm<br/>cp [.lib.TAP.Parser.SourceHandler]Handle.pm <br/>[--.lib.TAP.Parser.SourceHandler]Handle.pm<br/>cp [.lib.TAP.Parser.SourceHandler]Perl.pm <br/>[--.lib.TAP.Parser.SourceHandler]Perl.pm<br/>cp [.lib.TAP.Parser.SourceHandler]RawTAP.pm <br/>[--.lib.TAP.Parser.SourceHandler]RawTAP.pm<br/>cp [.lib.TAP.Parser.YAMLish]Reader.pm [--.lib.TAP.Parser.YAMLish]Reader.pm<br/>cp [.lib.TAP.Parser.YAMLish]Writer.pm [--.lib.TAP.Parser.YAMLish]Writer.pm<br/>cp [.lib.TAP.Parser]Aggregator.pm [--.lib.TAP.Parser]Aggregator.pm<br/>cp [.lib.TAP.Parser]Grammar.pm [--.lib.TAP.Parser]Grammar.pm<br/>cp [.lib.TAP.Parser]Iterator.pm [--.lib.TAP.Parser]Iterator.pm<br/>cp [.lib.TAP.Parser]IteratorFactory.pm [--.lib.TAP.Parser]IteratorFactory.pm<br/>cp [.lib.TAP.Parser]Multiplexer.pm [--.lib.TAP.Parser]Multiplexer.pm<br/>cp [.lib.TAP.Parser]Result.pm [--.lib.TAP.Parser]Result.pm<br/>cp [.lib.TAP.Parser]ResultFactory.pm [--.lib.TAP.Parser]ResultFactory.pm<br/>cp [.lib.TAP.Parser]Scheduler.pm [--.lib.TAP.Parser]Scheduler.pm<br/>cp [.lib.TAP.Parser]Source.pm [--.lib.TAP.Parser]Source.pm<br/>cp [.lib.TAP.Parser]SourceHandler.pm [--.lib.TAP.Parser]SourceHandler.pm<br/>cp [.lib.TAP]Base.pm [--.lib.TAP]Base.pm<br/>cp [.lib.TAP]Harness.pm [--.lib.TAP]Harness.pm<br/>cp [.lib.TAP]Object.pm [--.lib.TAP]Object.pm<br/>cp [.lib.TAP]Parser.pm [--.lib.TAP]Parser.pm<br/>cp [.lib.Test]Harness.pm [--.lib.Test]Harness.pm<br/> Making Test (all)<br/><br/>Running pm_to_blib for cpan/Test directly<br/>cp lib/Test.pm ../../lib/Test.pm<br/> Making Test::Simple (all)<br/><br/>Running pm_to_blib for cpan/Test-Simple directly<br/>cp lib/Test/Builder/Tester.pm ../../lib/Test/Builder/Tester.pm<br/>cp lib/Test/Builder/Module.pm ../../lib/Test/Builder/Module.pm<br/>cp lib/Test/Builder/Tester/Color.pm ../../lib/Test/Builder/Tester/Color.pm<br/>cp lib/Test/Simple.pm ../../lib/Test/Simple.pm<br/>cp lib/Test/Builder.pm ../../lib/Test/Builder.pm<br/>cp lib/Test/More.pm ../../lib/Test/More.pm<br/>cp lib/Test/Tutorial.pod ../../lib/Test/Tutorial.pod<br/> Making Text::Balanced (all)<br/><br/>Running pm_to_blib for cpan/Text-Balanced directly<br/>cp lib/Text/Balanced.pm ../../lib/Text/Balanced.pm<br/> Making Text::ParseWords (all)<br/><br/>Running pm_to_blib for cpan/Text-ParseWords directly<br/>cp lib/Text/ParseWords.pm ../../lib/Text/ParseWords.pm<br/> Making Text::Tabs (all)<br/><br/>Running pm_to_blib for cpan/Text-Tabs directly<br/>cp lib/Text/Tabs.pm ../../lib/Text/Tabs.pm<br/>cp lib/Text/Wrap.pm ../../lib/Text/Wrap.pm<br/> Making Tie::RefHash (all)<br/><br/>Running pm_to_blib for cpan/Tie-RefHash directly<br/>cp lib/Tie/RefHash.pm ../../lib/Tie/RefHash.pm<br/> Making Time::Local (all)<br/><br/>Running pm_to_blib for cpan/Time-Local directly<br/>cp lib/Time/Local.pm ../../lib/Time/Local.pm<br/> Making version (all)<br/><br/>Running pm_to_blib for cpan/version directly<br/>cp lib/version/vpp.pm ../../lib/version/vpp.pm<br/>cp lib/version/Internals.pod ../../lib/version/Internals.pod<br/>cp lib/version/regex.pm ../../lib/version/regex.pm<br/>cp lib/version.pod ../../lib/version.pod<br/>cp lib/version.pm ../../lib/version.pm<br/><br/> Making Attribute::Handlers (all)<br/><br/>Running pm_to_blib for dist/Attribute-Handlers directly<br/>cp lib/Attribute/Handlers.pm ../../lib/Attribute/Handlers.pm<br/> Making autouse (all)<br/><br/>Running pm_to_blib for dist/autouse directly<br/>cp lib/autouse.pm ../../lib/autouse.pm<br/> Making base (all)<br/><br/>Running pm_to_blib for dist/base directly<br/>cp lib/fields.pm ../../lib/fields.pm<br/>cp lib/base.pm ../../lib/base.pm<br/> Making bignum (all)<br/><br/>Running pm_to_blib for dist/bignum directly<br/>cp lib/Math/BigFloat/Trace.pm ../../lib/Math/BigFloat/Trace.pm<br/>cp lib/bigint.pm ../../lib/bigint.pm<br/>cp lib/Math/BigInt/Trace.pm ../../lib/Math/BigInt/Trace.pm<br/>cp lib/bignum.pm ../../lib/bignum.pm<br/>cp lib/bigrat.pm ../../lib/bigrat.pm<br/> Making Carp (all)<br/><br/>Running pm_to_blib for dist/Carp directly<br/>cp lib/Carp.pm ../../lib/Carp.pm<br/>cp lib/Carp/Heavy.pm ../../lib/Carp/Heavy.pm<br/> Making constant (all)<br/><br/>Running pm_to_blib for dist/constant directly<br/>cp lib/constant.pm ../../lib/constant.pm<br/> Making Devel::SelfStubber (all)<br/><br/>Running pm_to_blib for dist/Devel-SelfStubber directly<br/>cp lib/Devel/SelfStubber.pm ../../lib/Devel/SelfStubber.pm<br/> Making Dumpvalue (all)<br/><br/>Running pm_to_blib for dist/Dumpvalue directly<br/>cp lib/Dumpvalue.pm ../../lib/Dumpvalue.pm<br/> Making Env (all)<br/><br/>Running pm_to_blib for dist/Env directly<br/>cp lib/Env.pm ../../lib/Env.pm<br/> Making Exporter (all)<br/><br/>Running pm_to_blib for dist/Exporter directly<br/>cp lib/Exporter/Heavy.pm ../../lib/Exporter/Heavy.pm<br/>cp lib/Exporter.pm ../../lib/Exporter.pm<br/> Making ExtUtils::CBuilder (all)<br/><br/>Running pm_to_blib for dist/ExtUtils-CBuilder directly<br/>cp lib/ExtUtils/CBuilder/Platform/aix.pm <br/>../../lib/ExtUtils/CBuilder/Platform/aix.pm<br/>cp lib/ExtUtils/CBuilder/Platform/Unix.pm <br/>../../lib/ExtUtils/CBuilder/Platform/Unix.pm<br/>cp lib/ExtUtils/CBuilder/Platform/dec_osf.pm <br/>../../lib/ExtUtils/CBuilder/Platform/dec_osf.pm<br/>cp lib/ExtUtils/CBuilder/Platform/android.pm <br/>../../lib/ExtUtils/CBuilder/Platform/android.pm<br/>cp lib/ExtUtils/CBuilder/Platform/darwin.pm <br/>../../lib/ExtUtils/CBuilder/Platform/darwin.pm<br/>cp lib/ExtUtils/CBuilder/Platform/Windows/BCC.pm <br/>../../lib/ExtUtils/CBuilder/Platform/Windows/BCC.pm<br/>cp lib/ExtUtils/CBuilder.pm ../../lib/ExtUtils/CBuilder.pm<br/>cp lib/ExtUtils/CBuilder/Platform/VMS.pm <br/>../../lib/ExtUtils/CBuilder/Platform/VMS.pm<br/>cp lib/ExtUtils/CBuilder/Platform/cygwin.pm <br/>../../lib/ExtUtils/CBuilder/Platform/cygwin.pm<br/>cp lib/ExtUtils/CBuilder/Platform/Windows/MSVC.pm <br/>../../lib/ExtUtils/CBuilder/Platform/Windows/MSVC.pm<br/>cp lib/ExtUtils/CBuilder/Platform/Windows/GCC.pm <br/>../../lib/ExtUtils/CBuilder/Platform/Windows/GCC.pm<br/>cp lib/ExtUtils/CBuilder/Platform/os2.pm <br/>../../lib/ExtUtils/CBuilder/Platform/os2.pm<br/>cp lib/ExtUtils/CBuilder/Platform/Windows.pm <br/>../../lib/ExtUtils/CBuilder/Platform/Windows.pm<br/>cp lib/ExtUtils/CBuilder/Base.pm ../../lib/ExtUtils/CBuilder/Base.pm<br/> Making ExtUtils::Command (all)<br/> <br/>Running pm_to_blib for dist/ExtUtils-Command directly<br/>cp lib/ExtUtils/Command.pm ../../lib/ExtUtils/Command.pm<br/> Making ExtUtils::Install (all)<br/><br/>Running pm_to_blib for dist/ExtUtils-Install directly<br/>cp lib/ExtUtils/Installed.pm ../../lib/ExtUtils/Installed.pm<br/>cp lib/ExtUtils/Install.pm ../../lib/ExtUtils/Install.pm<br/>cp lib/ExtUtils/Packlist.pm ../../lib/ExtUtils/Packlist.pm<br/> Making ExtUtils::Manifest (all)<br/><br/>Running pm_to_blib for dist/ExtUtils-Manifest directly<br/><br/>Creating Makefile.PL in dist/ExtUtils-Manifest for ExtUtils::Manifest<br/><br/>Running Makefile.PL in dist/ExtUtils-Manifest<br/>DKB1:[usr.robertson.WebDownloads.perl.perl-5^.20^.2.][000000]MINIPERL.EXE;2 <br/>&quot;-I../../lib&quot; &quot;Makefile.PL&quot; &quot;INST_LIB=[--.lib]&quot; &quot;INST_AR<br/>CHLIB=[--.lib]&quot; &quot;PERL_CORE=1&quot;<br/>Generating a MMK-style Descrip.MMS<br/>Writing Descrip.MMS for ExtUtils::Manifest<br/>Making all in dist/ExtUtils-Manifest<br/>MMK all /DESCRIPTION=descrip.mms /MACRO=(&quot;PERL_CORE=1&quot;)<br/>cp [.lib.ExtUtils]MANIFEST.SKIP [--.lib.ExtUtils]MANIFEST.SKIP<br/>cp [.lib.ExtUtils]Manifest.pm [--.lib.ExtUtils]Manifest.pm<br/> Making ExtUtils::ParseXS (all)<br/><br/>Running pm_to_blib for dist/ExtUtils-ParseXS directly<br/><br/>Creating Makefile.PL in dist/ExtUtils-ParseXS for ExtUtils::ParseXS<br/><br/>Running Makefile.PL in dist/ExtUtils-ParseXS<br/>DKB1:[usr.robertson.WebDownloads.perl.perl-5^.20^.2.][000000]MINIPERL.EXE;2 <br/>&quot;-I../../lib&quot; &quot;Makefile.PL&quot; &quot;INST_LIB=[--.lib]&quot; &quot;INST_AR<br/>CHLIB=[--.lib]&quot; &quot;PERL_CORE=1&quot;<br/>Generating a MMK-style Descrip.MMS<br/>Writing Descrip.MMS for ExtUtils::ParseXS<br/>Making all in dist/ExtUtils-ParseXS<br/>MMK all /DESCRIPTION=descrip.mms /MACRO=(&quot;PERL_CORE=1&quot;)<br/>%MMK-F-CANTUPD, cannot update target [.LIB.EXTUTILS]XSUBPP^.. - sources <br/>unknown<br/>%MMK-F-CANTUPD, cannot update target [.LIB.EXTUTILS]XSUBPP^.. - sources <br/>unknown<br/>Unsuccessful make(dist/ExtUtils-ParseXS): code=1024 at make_ext.pl line 561.<br/>%NONAME-F-NOMSG, Message number 0C14805C<br/>%MMK-F-ERRUPD, error status %X0C14805C occurred when updating target <br/>NONXSEXT<br/> ROBERTSON job terminated at 2-JUN-2015 10:20:50.81<br/><br/> Accounting information:<br/> Buffered I/O count: 66935 Peak working set <br/>size: 21104<br/> Direct I/O count: 48976 Peak virtual size: <br/>198240<br/> Page faults: 137869 Mounted <br/>volumes: 0<br/> Charged CPU time: 0 00:00:48.62 Elapsed time: 0 <br/>00:26:45.53<br/> http://www.nntp.perl.org/group/perl.vmsperl/2015/06/msg15679.html Tue, 02 Jun 2015 16:05:15 +0000 contact info for Brad Hughes? by Craig A. Berry The VMS::Lock module (&lt;http://search.cpan.org/~bhughes/VMS-Lock-1.02/&gt;) needs some TLC and both Carl Friedberg and I have made repeated attempts to contact its author Brad Hughes but can&#39;t find a working address. Does anyone know where he can be reached? <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/10/msg15678.html Thu, 30 Oct 2014 14:57:10 +0000 Perl 5.20.1 binary kits for OpenVMS available by Craig A. Berry Installation kits for OpenVMS Alpha and OpenVMS I64 v8.3 and later are available at: <br/> <br/>&lt;https://sourceforge.net/projects/vmsperlkit/files/&gt; <br/> <br/>The files are self-extracting archives and after downloading you must run them like so: <br/> <br/>$ run VMSPORTS-AXPVMS-PERL-V0520-1-1.SFX_AXPEXE <br/> <br/>for Alpha, and: <br/> <br/>$ run VMSPORTS-I64VMS-PERL-V0520-1-1.SFX_I64EXE <br/> <br/>for Itanium. Then, on either platform: <br/> <br/>$ product install perl <br/> <br/>and follow the usual installation prompts. <br/> <br/>Note that the kits provided here are intended to be a convenient way to acquire a default build; there are many other configuration options available if you build your own Perl from the source at &lt;http://www.cpan.org/src/5.0/perl-5.20.1.tar.gz&gt;. <br/> <br/>N.B. The version of CPAN.pm (the module that lets you install other modules) that ships with Perl 5.20.x is completely non-functional on VMS. The binary kits announced here include a patched version and those patches have been sent upstream to &lt;https://rt.cpan.org/Public/Bug/Display.html?id=98265&gt; but not yet included in a release. Don&#39;t upgrade your CPAN.pm without verifying that these problems have been fixed. <br/> <br/>Have an appropriate amount of fun. Anything related to these kits that turns out to be more fun than you can handle is probably best reported on the vmsperl mailing list.[1] <br/> <br/>Changes in this release can be found via typing &quot;perldoc perldelta&quot; after installation. <br/> <br/> <br/>[1] &lt;http://lists.perl.org/list/vmsperl.html&gt; <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/10/msg15677.html Tue, 14 Oct 2014 12:32:32 +0000 RE: Q: Can anyone explain this curious behaviour. by john.dite@compinia.de Hi,<br/><br/>again thanks for the replies to this thread.<br/><br/>The original OP was not about &quot;Unix/VMS error/exit codes&quot;, it was about <br/>the unexpected %SYSTEM-F-NOLOGNAM. The explanation given triggered<br/>some tests and examples shown for Linux and VMS, which included the exit <br/>codes.<br/><br/> From a perl viewpoint, I just expect one perl script to print the very <br/>same output no matter where it runs, especially as there is no OS <br/>specific code in the script.<br/><br/>As far as I understand, %ENV is or behaves like a perl hash. That is, <br/>&#39;defined $ENV{X}&#39; can be false and that is expected. But looking up a <br/>hash value should not cause any side effect. On VMS it does, so from my <br/>point of view the implementation of %ENV on VMS is incomplete, incorrect <br/>or broken.<br/><br/><br/>John<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/08/msg15676.html Thu, 07 Aug 2014 08:18:12 +0000 Re: Q: Can anyone explain this curious behaviour. by Craig A. Berry <br/>On Aug 6, 2014, at 2:48 AM, john.dite@compinia.de wrote: <br/> <br/>&gt; To me the question is still, why is errno set on VMS for $s=$ENV{X} ? <br/> <br/>This is a reasonable question and I could be persuaded that our getenv() implementation should not set errno (even though it has for twenty years). If anyone knows about whether the standard changed at some point or whether setting errno was common for getenv() before it was standardized not to, that would be helpful. <br/> <br/>Everything else in your post simply ignores the documentation and the explanations I&#39;ve already given you. I don&#39;t really have anything to add. <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/08/msg15675.html Wed, 06 Aug 2014 13:13:02 +0000 Re: Q: Can anyone explain this curious behaviour. by John E. Malmberg On 8/6/2014 2:48 AM, john.dite@compinia.de wrote:<br/>&gt;<br/>&gt; Here my thoughts on the responses so far.<br/>&gt;<br/>&gt; &gt; What you&#39;ve actually demonstrated here is that the behaviour on Unix<br/>&gt; and VMS is equivalent. A die after a failed syscall (such as chdir)<br/>&gt; causes a generic failure status to be passed to the operating system<br/>&gt; when Perl exits.<br/>&gt;<br/>&gt; Hmm, on Linux I see $? as 2 which is not generic in my point of view.<br/>&gt; The %SYSTEM-F-ABORT looks generic and it is different from<br/>&gt; %RMS-E-DNF which from John M&#39;s reply indicates it is not severe enough.<br/>&gt;<br/>&gt; Fankly, I don&#39;t understand all this exit/return code mangling and I<br/>&gt; don&#39;t think a Perl script writer needs to.<br/><br/>The exit/return code encoding is required to comply with the VMS <br/>programing standard.<br/><br/>It is illegal on VMS to simply return the UNIX exit codes, and from a <br/>system manager&#39;s point of view it wrecks havoc with programs that <br/>monitor process accounting for unusual errors. And when I managed <br/>commercial systems, I used those programs extensively.<br/><br/>It is a mostly undocumented feature of the CRTL on the details how it <br/>encodes/decodes the values. So both the Perl VMS specific documentation <br/>and the GNV Bash VMS release notes document it.<br/><br/>That feature of the CRTL was implemented long after Perl was first <br/>ported to VMS, so originally Perl could not have taken advantage of it.<br/>So someone made the decision to just return SS$_ABORT for all <br/>non-success exit codes instead of violating the VMS programming standard.<br/><br/>With the traditional default VMS behavior, if you are in Perl and run a <br/>perl script as a subprocess, and it fails with a die or other error <br/>detected by Perl you get 42 or SYSTEM-F-ABORT returned to the parent as <br/>the exit code regardless of what the actual error is.<br/><br/>With PERL_VMS_POSIX_EXIT defined, in the Perl parent, you get the actual <br/>error code that the child exited with. Perl children processes then <br/>behave just like on Unix.<br/><br/>If you are executing Perl as a subprocess from any correctly built C <br/>program on VMS, including Perl, the PERL_VMS_POSIX_EXIT needs to be <br/>defined to get the correct exit code from the child.<br/><br/>Only VMS scripts like DCL or MMS/MMK or non-C programs need to be <br/>concerned with how to do the exit decoding to get the original value.<br/><br/>The only time PERL_VMS_POSIX_EXIT does not need to be defined is if you <br/>do not care what the actual exit reason is.<br/><br/>PERL_VMS_POSIX_EXIT is not a default when running under DCL so that <br/>existing DCL scripts that call perl scripts would not have to be changed.<br/><br/>IMHO, With Perl now being changed to support EFS character sets by <br/>default, it should also now default to PERL_VMS_POSIX_EXIT by default so <br/>that actual the die/exit status is not lost. Craig disagrees.<br/><br/>&gt; &gt; Changing our implementation so it doesn&#39;t set errno also wouldn&#39;t<br/>&gt; really help you because you&#39;d still get whatever random value was in<br/>&gt; vaxc$errno. Some of the time it would not be set and you&#39;d get the<br/>&gt; generic failure exit, but anything at all that sets errno could give you<br/>&gt; a surprise value that has nothing to do with your %ENV lookup.<br/>&gt;<br/>&gt; Another &quot;hmm&quot;, the value in vaxc$errno shouldn&#39;t be random, or? It<br/>&gt; should be the result of a CRTL function which sets it. But from my point<br/>&gt; of view it should be cleared or reset to the previous value of<br/>&gt; vaxc$errno, whenever a CRTL function is called to implement a Perl<br/>&gt; feature, which usually does not require a CRTL function to be called.<br/><br/>It is not really random, it is simply stale data.<br/><br/>The value of vaxc$errno is undefined unless errno is EVMSERR per the <br/>CRTL documentation.<br/><br/>The VMS specific code in Perl follows that and only updates vaxc$errno <br/>if it needs to set errno to EVMSERR, which is rare.<br/><br/>The code to lookup EVMSERR in Perl assumes that the Perl programmer <br/>knows that what they are getting is stale data if errno is not EVMSERR.<br/><br/>Out of time to deal with the rest right now.<br/><br/>Regards,<br/>-John<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/08/msg15674.html Wed, 06 Aug 2014 12:48:33 +0000 RE: Q: Can anyone explain this curious behaviour. by john.dite@compinia.de Hi,<br/><br/>back from vacation.<br/>Thanks for all the responses.<br/><br/>Here my thoughts on the responses so far.<br/><br/> &gt; What you&#39;ve actually demonstrated here is that the behaviour on Unix <br/>and VMS is equivalent. A die after a failed syscall (such as chdir) <br/>causes a generic failure status to be passed to the operating system <br/>when Perl exits.<br/><br/>Hmm, on Linux I see $? as 2 which is not generic in my point of view. <br/>The %SYSTEM-F-ABORT looks generic and it is different from<br/>%RMS-E-DNF which from John M&#39;s reply indicates it is not severe enough.<br/><br/>Fankly, I don&#39;t understand all this exit/return code mangling and I <br/>don&#39;t think a Perl script writer needs to.<br/><br/> &gt; Changing our implementation so it doesn&#39;t set errno also wouldn&#39;t <br/>really help you because you&#39;d still get whatever random value was in <br/>vaxc$errno. Some of the time it would not be set and you&#39;d get the <br/>generic failure exit, but anything at all that sets errno could give you <br/>a surprise value that has nothing to do with your %ENV lookup.<br/><br/>Another &quot;hmm&quot;, the value in vaxc$errno shouldn&#39;t be random, or? It <br/>should be the result of a CRTL function which sets it. But from my point <br/>of view it should be cleared or reset to the previous value of <br/>vaxc$errno, whenever a CRTL function is called to implement a Perl <br/>feature, which usually does not require a CRTL function to be called.<br/><br/> &gt; The value you get is an accident resulting from whatever last set <br/>errno. This is true on any operating system. Here&#39;s bash on OS X:<br/> &gt;<br/> &gt; $ perl -e &#39;$! = 99; $s = $ENV{X} or die qq/no such environment <br/>variable: $!\n/;&#39;<br/> &gt; no such environment variable: Not a STREAM<br/> &gt; $ echo $?<br/> &gt; 99<br/><br/>I see a predictable behaviour. If I set #! to 99 it is still 99 after an <br/>attempt to retrieve a value from the hash. To me this demonstrates, that <br/>Perl on OS X doesn&#39;t show unwanted side effects as Perl on VMS does.<br/><br/> &gt; Since a lookup in %ENV is not a syscall, the value of errno is just <br/>whatever happens to be lying around and a call to die in these <br/>circumstances cannot produce a predictable exit status on any operating <br/>system (as indicated in the docs I quoted previously). In the specific <br/>case of an %ENV lookup, it&#39;s actually more predictable on VMS than it&#39;s <br/>supposed to be.<br/><br/>$ perl -e &quot;$s; defined $s or die &quot;&quot;undefined variable: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>undefined variable: &#39;, %SYSTEM-S-NORMAL, normal successful completion&#39;<br/>%SYSTEM-F-ABORT, abort<br/>$<br/><br/>To me the question is still, why is errno set on VMS for $s=$ENV{X} ?<br/><br/> &gt; use vmsish &#39;hushed&#39;;<br/><br/>I can even conditionalize that just for VMS or as has already been <br/>suggested clear $!, $^E and maybe even $?, which are all workarounds<br/>only required for VMS.<br/><br/>John<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/08/msg15673.html Wed, 06 Aug 2014 07:48:17 +0000 Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursiousbehaviour.) by Craig A. Berry <br/>On Jul 22, 2014, at 10:18 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote:<br/><br/>&gt; On 7/22/2014 7:13 AM, Craig A. Berry wrote:<br/>&gt;&gt; <br/>&gt;&gt; On Jul 21, 2014, at 7:41 PM, John E. Malmberg &lt;wb8tyw@qsl.net&gt; wrote:<br/>&gt;&gt; <br/>&gt;&gt;&gt; On 7/21/2014 7:06 PM, Craig A. Berry wrote:<br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.<br/>&gt;&gt; <br/>&gt;&gt; Well, I wouldn&#39;t think it did, but for some reason the two are wired together:<br/>&gt; <br/>&gt; The idea was that if you wanted UNIX filenames, you would also want UNIX exit statuses.<br/><br/>It&#39;s easy enough to ask for both, but if folks feel strongly it should stay the way it is, I&#39;ll leave it. If we separate them, we&#39;ll have to add posix exit to what gets turned on under bash, but that&#39;s easy to do.<br/>&gt; <br/>&gt;&gt; I think I&#39;m going to regard that as a bug and separate them.<br/>&gt; <br/>&gt; The logical GNV$UNIX_SHELL is defined when bash is running. It should be causing PERL_VMS_POSIX_EXIT to be in effect. That does not seem to be working on encompasserve.org.<br/><br/>Same bug as PERL_VMS_POSIX_EXIT:<br/><br/> gnv_unix_shell = 0;<br/> status = simple_trnlnm(&quot;GNV$UNIX_SHELL&quot;, val_str, sizeof(val_str));<br/> if ($VMS_STATUS_SUCCESS(status)) {<br/> gnv_unix_shell = 1;<br/><br/>If the length of the equivalence name is odd, then status will test as a successful VMS status and it will work. But that whole problem is now fixed in blead:<br/><br/>http://perl5.git.perl.org/perl.git/commitdiff/9bd30c63d934b70cf98e71983670d3e837ec38bb<br/><br/>I will try to get this into 5.20.1 but it will be in 5.22 in any case. Since &quot;bash&quot; has an even number of characters in it, I don&#39;t see a reasonable short-term workaround.<br/><br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15672.html Wed, 23 Jul 2014 12:17:59 +0000 Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursiousbehaviour.) by John E. Malmberg On 7/22/2014 7:13 AM, Craig A. Berry wrote:<br/>&gt;<br/>&gt; On Jul 21, 2014, at 7:41 PM, John E. Malmberg &lt;wb8tyw@qsl.net&gt; wrote:<br/>&gt;<br/>&gt;&gt; On 7/21/2014 7:06 PM, Craig A. Berry wrote:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.<br/>&gt;<br/>&gt; Well, I wouldn&#39;t think it did, but for some reason the two are wired together:<br/><br/>The idea was that if you wanted UNIX filenames, you would also want UNIX <br/>exit statuses.<br/><br/>&gt; I think I&#39;m going to regard that as a bug and separate them.<br/><br/>The logical GNV$UNIX_SHELL is defined when bash is running. It should <br/>be causing PERL_VMS_POSIX_EXIT to be in effect. That does not seem to <br/>be working on encompasserve.org.<br/><br/>Regards,<br/>-John<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15671.html Wed, 23 Jul 2014 03:19:58 +0000 Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursiousbehaviour.) by Craig A. Berry <br/>On Jul 21, 2014, at 7:41 PM, John E. Malmberg &lt;wb8tyw@qsl.net&gt; wrote:<br/><br/>&gt; On 7/21/2014 7:06 PM, Craig A. Berry wrote:<br/>&gt;&gt; <br/>&gt;&gt; DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.<br/><br/>Well, I wouldn&#39;t think it did, but for some reason the two are wired together:<br/><br/> s = decc$feature_get_index(&quot;DECC$FILENAME_UNIX_REPORT&quot;);<br/> if (s &gt;= 0) {<br/> decc_filename_unix_report = decc$feature_get_value(s, 1);<br/> if (decc_filename_unix_report &gt; 0) {<br/> decc_filename_unix_report = 1;<br/> vms_posix_exit = 1;<br/> }<br/> else<br/> decc_filename_unix_report = 0;<br/> }<br/><br/>I think I&#39;m going to regard that as a bug and separate them.<br/><br/>&gt; <br/>&gt; The perlvms documentation needs to be updated.<br/>&gt; <br/>&gt; http://perldoc.perl.org/perlvms.html<br/>&gt; <br/>&gt; The PERL_VMS_POSIX_EXIT needed to be 1 to get it active. &quot;ENABLE&quot; did not work. Perl VMS documentation only mentions &quot;ENABLE&quot;<br/><br/>The problem is that for this feature and several others we have code that looks like:<br/><br/> status = simple_trnlnm<br/> (&quot;PERL_VMS_POSIX_EXIT&quot;, val_str, sizeof(val_str));<br/> if ($VMS_STATUS_SUCCESS(status)) {<br/><br/>but simple_trnlnm does not return a VMS status. It returns zero on failure or the length the equivalence name on success. &quot;1&quot; has an odd length and is considered a success; &quot;ENABLE&quot; has an even length and is considered a failure. That is definitely a bug, apparently one I introduced at &lt;http://perl5.git.perl.org/perl.git/commit/8dc9d3390b257b55ff81dfb908f4621b80760d78?f=vms/vms.c&gt;. Sorry about that. I will fix it soonish, possibly even in time for 5.20.1.<br/><br/><br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15670.html Tue, 22 Jul 2014 12:14:05 +0000 Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursiousbehaviour.) by John E. Malmberg On 7/21/2014 7:06 PM, Craig A. Berry wrote:<br/>&gt;<br/>&gt; On Jul 20, 2014, at 3:50 PM, John E. Malmberg &lt;wb8tyw@qsl.net&gt; wrote:<br/>&gt;<br/>&gt;&gt; If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it<br/>&gt;&gt; is supposed to behave the way that you would normally expect.<br/>&gt;<br/>&gt; That depends on what you normally expect. PERL_VMS_POSIX_EXIT should<br/>&gt; more or less give you posixish behavior regarding exit codes. I can&#39;t<br/>&gt; think of a good reason to enable it unless you are running under bash.<br/>&gt; DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.<br/><br/>The perlvms documentation needs to be updated.<br/><br/>http://perldoc.perl.org/perlvms.html<br/><br/>The PERL_VMS_POSIX_EXIT needed to be 1 to get it active. &quot;ENABLE&quot; did <br/>not work. Perl VMS documentation only mentions &quot;ENABLE&quot;<br/><br/>&gt; Well it certainly does something:<br/>&gt;<br/>&gt; $ define PERL_VMS_POSIX_EXIT 1 $ perl -e &quot;$! = 66; die;&quot; Died at -e<br/>&gt; line 1. $ show symbol $status $STATUS == &quot;%X1035A212&quot;<br/>&gt;<br/>&gt; 66 is ENOTEMPTY. 66 might be embedded in that $STATUS value<br/>&gt; somewhere, transmogrified by various kinds of masking and shifting,<br/>&gt; but I&#39;m late for dinner and have no time to debug it at the moment.<br/><br/>$ x = %x212/8<br/>$ show sym x<br/> X = 66 Hex = 00000042 Octal = 00000000102<br/><br/>BASH-4.2$ alias perl=/perl_root/perl.exe<br/>BASH-4.2$ perl -e \<br/> &quot;\$s=\$ENV{X} or die \&quot;no such environment variable: &#39;\$!&#39;\n\&quot;&quot;<br/>no such environment variable: &#39;invalid argument&#39;<br/>BASH-4.2$ echo $?<br/>22<br/><br/>BASH-4.2$ perl -e \<br/> &quot;\$s=&#39;nosuchdir&#39;; chdir \$s or die \&quot;Can&#39;t cd to \$s: &#39;\$!&#39;\n\&quot;&quot;<br/>Can&#39;t cd to nosuchdir: &#39;no such file or directory&#39;<br/>BASH-4.2$ echo $?<br/>2<br/><br/>BASH-4.2$ uname -a<br/>OpenVMS EISNER 0 V8.3 AlphaServer_DS20_500_MHz Alpha Alpha HP/OpenVMS<br/><br/>Trying the DCL examples again:<br/><br/>$ perl -e &quot;$s=&#39;nosuchdir&#39;; chdir $s or die &quot;&quot;Can&#39;t cd to $s: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>Can&#39;t cd to nosuchdir: &#39;no such file or directory, %RMS-E-DNF, directory <br/>not found&#39;<br/>$ show sym $status<br/> $STATUS == &quot;%X1035A012&quot;<br/>$ unix = %x12/8<br/>$ show sym unix<br/> UNIX = 2 Hex = 00000002 Octal = 00000000002<br/><br/>$ perl -e &quot;$s=$ENV{X} or die &quot;&quot;no such environment variable: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>no such environment variable: &#39;invalid argument, %SYSTEM-F-NOLOGNAM, no <br/>logical name match&#39;<br/>$ show sym $status<br/> $STATUS == &quot;%X1035A0B2&quot;<br/>$ unix = %x0b2/8<br/>$ show sym unix<br/> UNIX = 22 Hex = 00000016 Octal = 00000000026<br/><br/>This feature setting also allows perl to spawn child perls and capture <br/>the original exit codes.<br/><br/>Regards,<br/>-John<br/><br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15669.html Tue, 22 Jul 2014 00:42:43 +0000 PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursiousbehaviour.) by Craig A. Berry <br/>On Jul 20, 2014, at 3:50 PM, John E. Malmberg &lt;wb8tyw@qsl.net&gt; wrote:<br/><br/>&gt; If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it is supposed to behave the way that you would normally expect.<br/><br/>That depends on what you normally expect. PERL_VMS_POSIX_EXIT should more or less give you posixish behavior regarding exit codes. I can&#39;t think of a good reason to enable it unless you are running under bash. DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.<br/><br/>&gt; From a quick test on Encompasserve with PERL 5.18, that feature does not appear to be working.<br/>&gt; <br/>&gt; When that feature is working from DCL scripts or Bash you can recover the original Unix error code unless it is a VMS specific error.<br/>&gt; <br/>&gt; I do not know why the PERL_VMS_POSIX_EXIT feature does not appear to be working, I have not built/tested perl on VMS for a few years.<br/><br/>Well it certainly does something:<br/><br/>$ define PERL_VMS_POSIX_EXIT 1<br/>$ perl -e &quot;$! = 66; die;&quot;<br/>Died at -e line 1.<br/>$ show symbol $status<br/> $STATUS == &quot;%X1035A212&quot;<br/><br/>66 is ENOTEMPTY. 66 might be embedded in that $STATUS value somewhere, transmogrified by various kinds of masking and shifting, but I&#39;m late for dinner and have no time to debug it at the moment.<br/><br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15668.html Tue, 22 Jul 2014 00:07:08 +0000 Re: Q: Can anyone explain this cursious behaviour. by Craig A. Berry <br/>On Jul 20, 2014, at 2:52 PM, John Dite &lt;john.dite@compinia.de&gt; wrote:<br/><br/>&gt; Hi,<br/>&gt; <br/>&gt; first of all thanks for all the replies.<br/>&gt; <br/>&gt; Either I don&#39;t understand or it doesn&#39;t make sense to me.<br/><br/>OK, let me try again.<br/><br/>&gt; For example, with perl on Linux:<br/>&gt; <br/>&gt; $ perl -e &quot;\$s=&#39;nosuchdir&#39;; chdir \$s or die \&quot;Can&#39;t cd to \$s: &#39;\$!&#39;\n\&quot;&quot;<br/>&gt; Can&#39;t cd to nosuchdir: &#39;No such file or directory&#39;<br/>&gt; <br/>&gt; $ echo $?<br/>&gt; 2<br/>&gt; <br/>&gt; $ perl -e &quot;\$s=\$ENV{X} or die \&quot;no such environment variable: &#39;\$!&#39;\n\&quot;&quot;<br/>&gt; no such environment variable: &#39;&#39;<br/>&gt; <br/>&gt; $ echo $?<br/>&gt; 255<br/>&gt; <br/>&gt; $<br/>&gt; and &quot;equivalent scripts&quot; with perl on VMS:<br/>&gt; <br/>&gt; $ perl -e &quot;$s=&#39;nosuchdir&#39;; chdir $s or die &quot;&quot;Can&#39;t cd to $s: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>&gt; Can&#39;t cd to nosuchdir: &#39;no such file or directory, %RMS-E-DNF, directory<br/>&gt; not found&#39;<br/>&gt; %SYSTEM-F-ABORT, abort<br/>&gt; <br/>&gt; $ sh symbol $status<br/>&gt; <br/>&gt; $STATUS == &quot;%X0000002C&quot;<br/><br/>&gt; perl -e &quot;$s=$ENV{X} or die &quot;&quot;no such environment<br/>&gt; variable: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>&gt; no such environment variable: &#39;invalid argument, %SYSTEM-F-NOLOGNAM, no<br/>&gt; logical name match&#39;<br/>&gt; %SYSTEM-F-NOLOGNAM, no logical name match<br/>&gt; <br/>&gt; $ sho symbol $status<br/>&gt; $STATUS == &quot;%X000001BC&quot;<br/>&gt; $<br/><br/>What you&#39;ve actually demonstrated here is that the behavior on Unix and VMS is equivalent. A die after a failed syscall (such as chdir) causes a generic failure status to be passed to the operating system when Perl exits. A die under other circumstances (such as a failed lookup in %ENV, which is not a syscall) causes an exit status to be concocted from errno or vaxc$errno or fall back to some other generic value if errno is not set. <br/><br/>One difference on VMS is that it&#39;s no problem to pass a full 32-bit condition value to the operating system, whereas on Unix there is various masking and shifting going on to try to encode a meaningful status in 8 bits. I think in your example, the 255 you see on Unix is a fallback for when errno is not set. The details are at &lt;http://perl5.git.perl.org/perl.git/blob/maint-5.20:/perl.c#l4947&gt;.<br/><br/>&gt; and regarding<br/>&gt; <br/>&gt; 1.) A failed lookup in %ENV sets errno / vaxc$errno in our getenv<br/>&gt; implementation (specifically Perl_vmstrenv in [.vms]vms.c). This is<br/>&gt; normal and as it should be.<br/>&gt; <br/>&gt; 2.) die() (specifically Perl_my_failure_exit in perl.c) retrieves the<br/>&gt; most recent value of vaxc$errno and uses it as the VMS exit status. This<br/>&gt; is also normal behaviour.<br/>&gt; <br/>&gt; In the first example vaxc$errno was set to %RMS-E-DNF but $status is<br/>&gt; %SYSTEM-F-ABORT.<br/>&gt; <br/>&gt; In the second example, a usual, aka C, getenv() doesn&#39;t set errno. Why<br/>&gt; setting errno to EINVAL and vaxc$errno to NOLOGNAM &quot;is normal and as it<br/>&gt; should be&quot; for the VMS implementation is not obvious to me.<br/><br/>You raise an interesting point, which is why our getenv() implementation sets errno whereas apparently the standard does not specify any errno values for it. We actively suppress the errno it sets when we&#39;ve called it for our own internal purposes, but leave it alone when called as part of satisfying a user request. This may not be correct but it&#39;s been this way for decades so I&#39;d need to think long and hard about changing it. <br/><br/>Changing our implementation so it doesn&#39;t set errno also wouldn&#39;t really help you because you&#39;d still get whatever random value was in vaxc$errno. Some of the time it would not be set and you&#39;d get the generic failure exit, but anything at all that sets errno could give you a surprise value that has nothing to do with your %ENV lookup.<br/><br/>&gt; Anyway, in the second example I expected a more generic return/exit code<br/>&gt; like %SYSTEM-F-ABORT and not an implementation specific one like<br/>&gt; %SYSTEM-F-NOLOGNAM.<br/><br/>The value you get is an accident resulting from whatever last set errno. This is true on any operating system. Here&#39;s bash on OS X:<br/><br/>$ perl -e &#39;$! = 99; $s = $ENV{X} or die qq/no such environment variable: $!\n/;&#39;<br/>no such environment variable: Not a STREAM<br/>$ echo $?<br/>99<br/><br/>Since a lookup in %ENV is not a syscall, the value of errno is just whatever happens to be lying around and a call to die in these circumstances cannot produce a predictable exit status on any operating system (as indicated in the docs I quoted previously). In the specific case of an %ENV lookup, it&#39;s actually more predictable on VMS than it&#39;s supposed to be.<br/><br/>&gt; Whether DCL should inhibit the message or not is most probably a<br/>&gt; different question.<br/><br/>use vmsish &#39;hushed&#39;;<br/><br/>at the top of your code will inhibit the message if you wish.<br/><br/>&gt; <br/>&gt; Anyway I&#39;m off on vacation for the next 2 weeks, so don&#39;t expect any<br/>&gt; quick responses.<br/>&gt; <br/>&gt; John<br/>&gt; <br/><br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15667.html Mon, 21 Jul 2014 12:26:11 +0000 Re: Q: Can anyone explain this cursious behaviour. by John E. Malmberg On 7/20/2014 2:52 PM, John Dite wrote:<br/><br/>&gt;<br/>&gt; 1.) A failed lookup in %ENV sets errno / vaxc$errno in our getenv<br/>&gt; implementation (specifically Perl_vmstrenv in [.vms]vms.c). This is<br/>&gt; normal and as it should be.<br/>&gt;<br/>&gt; 2.) die() (specifically Perl_my_failure_exit in perl.c) retrieves the<br/>&gt; most recent value of vaxc$errno and uses it as the VMS exit status. This<br/>&gt; is also normal behaviour.<br/>&gt;<br/>&gt; In the first example vaxc$errno was set to %RMS-E-DNF but $status is<br/>&gt; %SYSTEM-F-ABORT.<br/><br/>That is the default behavior of Perl because older programs expect this <br/>behavior per documentation, all perl error exit codes were translated to <br/>0x2c.<br/><br/>http://perldoc.perl.org/perlvms.html<br/><br/>If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it is <br/>supposed to behave the way that you would normally expect.<br/><br/> From a quick test on Encompasserve with PERL 5.18, that feature does <br/>not appear to be working.<br/><br/>When that feature is working from DCL scripts or Bash you can recover <br/>the original Unix error code unless it is a VMS specific error.<br/><br/>I do not know why the PERL_VMS_POSIX_EXIT feature does not appear to be <br/>working, I have not built/tested perl on VMS for a few years.<br/><br/>&gt; In the second example, a usual, aka C, getenv() doesn&#39;t set errno. Why<br/>&gt; setting errno to EINVAL and vaxc$errno to NOLOGNAM &quot;is normal and as it<br/>&gt; should be&quot; for the VMS implementation is not obvious to me.<br/><br/>Perl does not use getenv() for environment variables by default. It <br/>uses VMS system services to look up the current value.<br/><br/>&gt; Anyway I&#39;m off on vacation for the next 2 weeks, so don&#39;t expect any<br/>&gt; quick responses.<br/><br/>Regards,<br/>-John<br/>wb8tyw@qsl.network<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15666.html Sun, 20 Jul 2014 20:51:53 +0000 RE: Q: Can anyone explain this cursious behaviour. by John Dite Hi,<br/><br/>first of all thanks for all the replies.<br/><br/>Either I don&#39;t understand or it doesn&#39;t make sense to me.<br/>For example, with perl on Linux:<br/><br/>$ perl -e &quot;\$s=&#39;nosuchdir&#39;; chdir \$s or die \&quot;Can&#39;t cd to \$s: &#39;\$!&#39;\n\&quot;&quot;<br/>Can&#39;t cd to nosuchdir: &#39;No such file or directory&#39;<br/><br/>$ echo $?<br/>2<br/><br/>$ perl -e &quot;\$s=\$ENV{X} or die \&quot;no such environment variable: &#39;\$!&#39;\n\&quot;&quot;<br/>no such environment variable: &#39;&#39;<br/><br/>$ echo $?<br/>255<br/><br/>$<br/>and &quot;equivalent scripts&quot; with perl on VMS:<br/><br/>$ perl -e &quot;$s=&#39;nosuchdir&#39;; chdir $s or die &quot;&quot;Can&#39;t cd to $s: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>Can&#39;t cd to nosuchdir: &#39;no such file or directory, %RMS-E-DNF, directory<br/>not found&#39;<br/>%SYSTEM-F-ABORT, abort<br/><br/>$ sh symbol $status<br/><br/>$STATUS == &quot;%X0000002C&quot; perl -e &quot;$s=$ENV{X} or die &quot;&quot;no such environment<br/>variable: &#39;$!, $^E&#39;\n&quot;&quot;&quot;<br/>no such environment variable: &#39;invalid argument, %SYSTEM-F-NOLOGNAM, no<br/>logical name match&#39;<br/>%SYSTEM-F-NOLOGNAM, no logical name match<br/><br/>$ sho symbol $status<br/>$STATUS == &quot;%X000001BC&quot;<br/>$<br/>and regarding<br/><br/>1.) A failed lookup in %ENV sets errno / vaxc$errno in our getenv<br/>implementation (specifically Perl_vmstrenv in [.vms]vms.c). This is<br/>normal and as it should be.<br/><br/>2.) die() (specifically Perl_my_failure_exit in perl.c) retrieves the<br/>most recent value of vaxc$errno and uses it as the VMS exit status. This<br/>is also normal behaviour.<br/><br/>In the first example vaxc$errno was set to %RMS-E-DNF but $status is<br/>%SYSTEM-F-ABORT.<br/><br/>In the second example, a usual, aka C, getenv() doesn&#39;t set errno. Why<br/>setting errno to EINVAL and vaxc$errno to NOLOGNAM &quot;is normal and as it<br/>should be&quot; for the VMS implementation is not obvious to me.<br/><br/>Anyway, in the second example I expected a more generic return/exit code<br/>like %SYSTEM-F-ABORT and not an implementation specific one like<br/>%SYSTEM-F-NOLOGNAM.<br/><br/>Whether DCL should inhibit the message or not is most probably a<br/>different question.<br/><br/>Anyway I&#39;m off on vacation for the next 2 weeks, so don&#39;t expect any<br/>quick responses.<br/><br/>John<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15665.html Sun, 20 Jul 2014 19:53:48 +0000 Re: PCSI and versions (Re: Q: Can anyone explain this curiousbehaviour.) by Jeremy Begg Hi Craig,<br/><br/>Thanks for the clarification around the behaviour of &quot;die&quot; and how to avoid<br/>it.<br/><br/>&gt;&gt; Of course that is one approach, but seeing that someone has gone to all<br/>&gt;&gt; the trouble of &#39;packetizing&#39; perl it is a shame.<br/>&gt;&gt;<br/>&gt;&gt; Surely in the &#39;open source&#39; space one is never sure whether one&#39;s open<br/>&gt;&gt; source based application is going to work with a new version of, in this<br/>&gt;&gt; case perl, especially if one has compiled additional modules. So it would<br/>&gt;&gt; make sense, to let you switch environments, from old to new and back again.<br/>&gt;&gt; The way the PCSI works for perl at the moment, has become a nugatory<br/>&gt;&gt; activity.<br/><br/>&gt;I was dismayed when I prepared the 5.20 kits to discover that it removed<br/>&gt;the 5.18 installation. I looked long and hard in the docs for a way to make<br/>&gt;that optional and never found anything. If someone knows of a way to do<br/>&gt;that with PCSI, please fill me in.<br/><br/>PCSI is great for installing stuff into VMS$COMMON. As soon as you stray<br/>from that it gets trickier.<br/><br/>&gt;The difficulty here is that, for example, 5.18.2 really should remove<br/>&gt;5.18.1 before installing because (by default) they go in the same directory,<br/>&gt;but 5.20.0 should not remove 5.18.x. The only way I can see to do that with<br/>&gt;PCSI is to include the version number in the product name, so the product<br/>&gt;name, instead of &quot;PERL,&quot; would be &quot;PERL518,&quot; &quot;PERL520,&quot; etc. This is what<br/>&gt;HP has done with Java, where you have &quot;JAVA150&quot; and &quot;JAVA60.&quot; I guess the<br/>&gt;earliest that could happen now would be for 5.22 next March.<br/><br/>I would be happy with that.<br/><br/>&gt;Of course there is no requirement to use the PCSI kits. People can build<br/>&gt;from source and install wherever they like.<br/><br/>Your release announcement should include a pointer to the source files (even<br/>if it&#39;s the vanilla CPAN site).<br/><br/>Thanks for your good work!<br/><br/> Jeremy Begg<br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15664.html Sat, 19 Jul 2014 21:23:38 +0000 PCSI and versions (Re: Q: Can anyone explain this curious behaviour.) by Craig A. Berry <br/>On Jul 15, 2014, at 2:57 AM, john.dite@compinia.de wrote:<br/><br/>&gt; On 15.07.2014 03:24, Jeremy Begg wrote:<br/>&gt; <br/>&gt;&gt;&gt; PS. Why can&#39;t a PRODUCT INSTALL of PERL leave an older installation<br/>&gt;&gt;&gt; alone (ie. do not start deleting files in the directory tree), or at<br/>&gt;&gt;&gt; least offer an OPTION to leave the old installation as is?<br/>&gt;&gt; <br/>&gt;&gt; I&#39;m not sure, but I suspect it&#39;s a required by-product of the PCSI<br/>&gt;&gt; installation process. And somewhat annoying, too!<br/>&gt;&gt; <br/>&gt;&gt; Using a PCSI kit also has problems if you want to install Perl onto a<br/>&gt;&gt; cluster-common disk, which is not the boot disk, because you end up with<br/>&gt;&gt; PRODUCT SHOW PRODUCT listing the kit on one machine but not on the other(s).<br/>&gt;&gt; <br/>&gt;&gt; The kit itself is just a complete directory tree so perhaps a PRODUCT<br/>&gt;&gt; EXTRACT command would do the trick instead?<br/>&gt;&gt; <br/>&gt; Of course that is one approach, but seeing that someone has gone to all the trouble of &#39;packetizing&#39; perl it is a shame.<br/>&gt; Surely in the &#39;open source&#39; space one is never sure whether one&#39;s open source based application is going to work with a new version of, in this case perl, especially if one has compiled additional modules. So it would make sense, to let you switch environments, from old to new and back again. The way the PCSI works for perl at the moment, has become a nugatory activity.<br/><br/>I was dismayed when I prepared the 5.20 kits to discover that it removed the 5.18 installation. I looked long and hard in the docs for a way to make that optional and never found anything. If someone knows of a way to do that with PCSI, please fill me in.<br/><br/>Since the default install location has the version number in it, there is absolutely no reason a 5.18 installation and a 5.20 installation cannot happily coexist. One thing I haven&#39;t tried is re-installing 5.18 after installing 5.20. If someone wants to try that, please let us know how it goes.<br/><br/>The difficulty here is that, for example, 5.18.2 really should remove 5.18.1 before installing because (by default) they go in the same directory, but 5.20.0 should not remove 5.18.x. The only way I can see to do that with PCSI is to include the version number in the product name, so the product name, instead of &quot;PERL,&quot; would be &quot;PERL518,&quot; &quot;PERL520,&quot; etc. This is what HP has done with Java, where you have &quot;JAVA150&quot; and &quot;JAVA60.&quot; I guess the earliest that could happen now would be for 5.22 next March.<br/><br/>Of course there is no requirement to use the PCSI kits. People can build from source and install wherever they like.<br/><br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15663.html Fri, 18 Jul 2014 13:15:16 +0000 NOLOGNAM and die (Re: Q: Can anyone explain this curious behaviour.) by Craig A. Berry <br/>On Jul 15, 2014, at 2:57 AM, john.dite@compinia.de wrote:<br/><br/>&gt; On 15.07.2014 03:24, Jeremy Begg wrote:<br/>&gt;&gt; Hi John,<br/>&gt;&gt; <br/>&gt;&gt;&gt; we came across this curious behaviour. Here enclosed please find a<br/>&gt;&gt;&gt; reproducer.<br/>&gt;&gt; <br/>&gt;&gt; I see the same behaviour -- and also on Perl 5.10.0, so it&#39;s not new.<br/>&gt;&gt; Looks like inappropriate propagation of the last VMS error code.<br/>&gt;&gt; <br/>&gt; I have just joined this distribution list, so what do you reckon are the chances that this can be and will be resolved in the near future?Obviously for a customer script we have to suppress this misleading output, by other means.<br/><br/>I don&#39;t think there is a way to fix it. What&#39;s happening is the combination of two automatic behaviors:<br/><br/>1.) A failed lookup in %ENV sets errno / vaxc$errno in our getenv implementation (specifically Perl_vmstrenv in [.vms]vms.c). This is normal and as it should be.<br/><br/>2.) die() (specifically Perl_my_failure_exit in perl.c) retrieves the most recent value of vaxc$errno and uses it as the VMS exit status. This is also normal behavior.<br/><br/>The following is from the documentation for the die function and describes how exit codes work on Unix:<br/><br/>========<br/>as $! is the value of C&#39;s &quot;errno&quot;, which can be set by<br/>any system call, this means that the value of the exit code used<br/>by &quot;die&quot; can be non-predictable, so should not be relied upon,<br/>other than to be non-zero.<br/>========<br/><br/>The main difference on VMS is that you get (by default) a native 32-bit condition value rather than just a non-zero number, and die ends up using SS$_ABORT by default if vaxc$errno is not set. So what you&#39;re seeing is really the documented behavior of die.<br/><br/>Another way of looking at this is that your program dies without having encountered an error, so it picks up whatever previous error happens to be lying around. Just as in C errno is only valid immediately after a failed system call, the VMS exit code retrieved by die is also only valid immediately after a failed system call. <br/><br/>One way to solve your problem is to just clear errno ($! in Perl) and vaxc$errno ($^E in Perl) before calling die:<br/><br/>=======<br/>print $ENV{X}, &quot;\n&quot;;<br/><br/># Clear these so die isn&#39;t confused.<br/>$! = 0;<br/>$^E = 0;<br/><br/>my $whatever = shift @ARGV or die &quot;missing argument&quot;;<br/>exit 0; <br/>=======<br/><br/>However, it seems to me clearer to code exactly what you want rather than rely on the behavior of die, which really isn&#39;t what you want:<br/><br/>=======<br/>use constant SS_INSFARG =&gt; 276;<br/><br/>print $ENV{X}, &quot;\n&quot;;<br/><br/>my $whatever = shift @ARGV;<br/>exit SS_INSFARG unless $whatever;<br/><br/>exit 0;<br/>=======<br/><br/><br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15662.html Fri, 18 Jul 2014 12:30:51 +0000 Re: Q: Can anyone explain this curious behaviour. by Willem Grooters On Tue, 15 Jul 2014 09:57:42 +0200 &quot;john.dite@compinia.de&quot; &lt;john.dite@compinia.de&gt; wrote:<br/><br/>&gt;&gt; Using a PCSI kit also has problems if you want to install Perl onto a<br/>&gt;&gt; cluster-common disk, which is not the boot disk, because you end up with<br/>&gt;&gt; PRODUCT SHOW PRODUCT listing the kit on one machine but not on the <br/>&gt;&gt; other(s).<br/>&gt;&gt;<br/>&gt;&gt; The kit itself is just a complete directory tree so perhaps a PRODUCT<br/>&gt;&gt; EXTRACT command would do the trick instead?<br/>&gt;&gt;<br/>&gt;Of course that is one approach, but seeing that someone has gone to all <br/>&gt;the trouble of &#39;packetizing&#39; perl it is a shame.<br/>&gt;Surely in the &#39;open source&#39; space one is never sure whether one&#39;s open <br/>&gt;source based application is going to work with a new version of, in this <br/>&gt;case perl, especially if one has compiled additional modules. So it <br/>&gt;would make sense, to let you switch environments, from old to new and <br/>&gt;back again. The way the PCSI works for perl at the moment, has become a <br/>&gt;nugatory activity.<br/>&gt;<br/>&gt;Kind regards<br/>&gt;John<br/>&gt;<br/>ANY new environment should (imho) support code and programs develloped in an older environment. It&#39;s called backward compatbility<br/>(IIRC) and this is indeed a concept that is missing in many &#39;modern&#39; environments - mainly *X based, and not necessarily<br/>open-source (remember older versions of java?) or non-VMS (rememner SWS (AKA Apache?)).<br/>In some projects, there now is a fairly good awareness of the need, in many projects, though not always possible (OpenSSL 1.0 s.<br/>0.9.8)....<br/><br/>It is also common to install software of a predefined location - especially in the Linux world. The name _may_ include a version<br/>indication, in which case you will need ta adapt your references, eventually rebuild your software alltogether. <br/>Worst case however, it will be the same location as the previous version - like PCSI. Or even - as I have encountered - there is no<br/>choice than to use this &#39;default&#39; location.<br/>Using open-source that installes this way, I have run into severe trouble bacause the new version was not usable at all (it<br/>actually ruined the database). <br/><br/>The remedy is simple: Install default, rename the rootdirectory to include the version and adapt all code that refers to the<br/>environment to match this new name. Switching between versions is now easy by defining a one of just a few logicals.<br/><br/>But the best solution is - as always - to PREVENT this from happening. PCSI is fine for software that is REALLY backward<br/>compatible, or is at the base of the system. Otherwise, use other methods; for example delivering object files and all procedures<br/>and files needed to link them together locally - LINK is included in teh OpenVMS system. (the WASD webserver is distributed that<br/>way).<br/><br/>Willem<br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15661.html Tue, 15 Jul 2014 12:08:02 +0000 Re: Q: Can anyone explain this curious behaviour. by john.dite@compinia.de Jeremy,<br/><br/><br/>On 15.07.2014 03:24, Jeremy Begg wrote:<br/>&gt; Hi John,<br/>&gt;<br/>&gt;&gt; we came across this curious behaviour. Here enclosed please find a<br/>&gt;&gt; reproducer.<br/>&gt;<br/>&gt; I see the same behaviour -- and also on Perl 5.10.0, so it&#39;s not new.<br/>&gt; Looks like inappropriate propagation of the last VMS error code.<br/>&gt;<br/>I have just joined this distribution list, so what do you reckon are the <br/>chances that this can be and will be resolved in the near <br/>future?Obviously for a customer script we have to suppress this <br/>misleading output, by other means.<br/><br/>&gt;&gt; PS. Why can&#39;t a PRODUCT INSTALL of PERL leave an older installation<br/>&gt;&gt; alone (ie. do not start deleting files in the directory tree), or at<br/>&gt;&gt; least offer an OPTION to leave the old installation as is?<br/>&gt;<br/>&gt; I&#39;m not sure, but I suspect it&#39;s a required by-product of the PCSI<br/>&gt; installation process. And somewhat annoying, too!<br/>&gt;<br/>&gt; Using a PCSI kit also has problems if you want to install Perl onto a<br/>&gt; cluster-common disk, which is not the boot disk, because you end up with<br/>&gt; PRODUCT SHOW PRODUCT listing the kit on one machine but not on the <br/>&gt; other(s).<br/>&gt;<br/>&gt; The kit itself is just a complete directory tree so perhaps a PRODUCT<br/>&gt; EXTRACT command would do the trick instead?<br/>&gt;<br/>Of course that is one approach, but seeing that someone has gone to all <br/>the trouble of &#39;packetizing&#39; perl it is a shame.<br/>Surely in the &#39;open source&#39; space one is never sure whether one&#39;s open <br/>source based application is going to work with a new version of, in this <br/>case perl, especially if one has compiled additional modules. So it <br/>would make sense, to let you switch environments, from old to new and <br/>back again. The way the PCSI works for perl at the moment, has become a <br/>nugatory activity.<br/><br/><br/>Kind regards<br/>John<br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15660.html Tue, 15 Jul 2014 07:57:54 +0000 Re: Q: Can anyone explain this cursious behaviour. by Jeremy Begg Hi John,<br/><br/>&gt;we came across this curious behaviour. Here enclosed please find a<br/>&gt;reproducer.<br/><br/>I see the same behaviour -- and also on Perl 5.10.0, so it&#39;s not new.<br/>Looks like inappropriate propagation of the last VMS error code.<br/><br/>&gt;PS. Why can&#39;t a PRODUCT INSTALL of PERL leave an older installation<br/>&gt;alone (ie. do not start deleting files in the directory tree), or at<br/>&gt;least offer an OPTION to leave the old installation as is?<br/><br/>I&#39;m not sure, but I suspect it&#39;s a required by-product of the PCSI<br/>installation process. And somewhat annoying, too!<br/><br/>Using a PCSI kit also has problems if you want to install Perl onto a<br/>cluster-common disk, which is not the boot disk, because you end up with<br/>PRODUCT SHOW PRODUCT listing the kit on one machine but not on the other(s).<br/><br/>The kit itself is just a complete directory tree so perhaps a PRODUCT<br/>EXTRACT command would do the trick instead?<br/><br/>Regards,<br/><br/> Jeremy Begg<br/><br/> +---------------------------------------------------------+<br/> | VSM Software Services Pty. Ltd. |<br/> | http://www.vsm.com.au/ |<br/> |---------------------------------------------------------|<br/> | P.O.Box 402, Walkerville, | E-Mail: jeremy@vsm.com.au |<br/> | South Australia 5081 | Phone: +61 8 8221 5188 |<br/> |---------------------------| Mobile: 0414 422 947 |<br/> | A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |<br/> +---------------------------------------------------------+<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15659.html Tue, 15 Jul 2014 01:37:18 +0000 Re: Q: Can anyone explain this cursious behaviour. by Alan Winston If you don&#39;t run the perl startup script, PERLLIB is undefined. That&#39;s <br/>basically the guts of PERL. The PERL.EXE tries to load it using<br/>the logical and fails.<br/><br/>Are you running the startup you should?<br/><br/>-- Alan<br/><br/><br/>&#39;On 7/14/2014 6:10 AM, john.dite@compinia.de wrote:<br/>&gt; Hi,<br/>&gt;<br/>&gt; we came across this curious behaviour. Here enclosed please find a<br/>&gt; reproducer.<br/>&gt;<br/>&gt;<br/>&gt; When running the enclosed perl script without any logical definitions we<br/>&gt; get the message:<br/>&gt; $ perl x.pl<br/>&gt; Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5.<br/>&gt; %SYSTEM-F-NOLOGNAM, no logical name match<br/>&gt;<br/>&gt; When we define a logical name X we get:<br/>&gt; $ def/user X Y<br/>&gt; $ perl x.pl<br/>&gt; Y<br/>&gt; Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5.<br/>&gt; %SYSTEM-F-ABORT, abort<br/>&gt; $<br/>&gt;<br/>&gt; $ perl -v<br/>&gt;<br/>&gt; This is perl 5, version 20, subversion 0 (v5.20.0) built for VMS_IA64<br/>&gt;<br/>&gt;<br/>&gt; Kind regards<br/>&gt; John<br/>&gt;<br/>&gt; PS. Why can&#39;t a PRODUCT INSTALL of PERL leave an older installation<br/>&gt; alone (ie. do not start deleting files in the directory tree), or at<br/>&gt; least offer an OPTION to leave the old installation as is?<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15658.html Mon, 14 Jul 2014 21:32:21 +0000 Q: Can anyone explain this cursious behaviour. by john.dite@compinia.de Hi,<br/><br/>we came across this curious behaviour. Here enclosed please find a <br/>reproducer.<br/><br/><br/>When running the enclosed perl script without any logical definitions we <br/>get the message:<br/>$ perl x.pl<br/>Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5.<br/>%SYSTEM-F-NOLOGNAM, no logical name match<br/><br/>When we define a logical name X we get:<br/>$ def/user X Y<br/>$ perl x.pl<br/>Y<br/>Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5.<br/>%SYSTEM-F-ABORT, abort<br/>$<br/><br/>$ perl -v<br/><br/>This is perl 5, version 20, subversion 0 (v5.20.0) built for VMS_IA64<br/><br/><br/>Kind regards<br/>John<br/><br/>PS. Why can&#39;t a PRODUCT INSTALL of PERL leave an older installation <br/>alone (ie. do not start deleting files in the directory tree), or at <br/>least offer an OPTION to leave the old installation as is?<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/07/msg15657.html Mon, 14 Jul 2014 13:10:52 +0000 VMS:: modules on 5.20 by Carl Friedberg Hi, I&#39;ve built these modules on i64 with perl 5.20 (and VMS 8.4) <br/> <br/>x DATA-FIXEDFORMAT-0_04 (tar archive) <br/>x IndexedFile (has extra level of VMS; has tar archive) <br/>x rms <br/>x SMG unzips into top level directory! <br/>x VMS-CMS-0_3 <br/>x VMS-Device-0_10 <br/>x VMS-FILEUTILS-0_015 <br/>x VMS-FindFile-0_92 <br/>x VMS-FLATFILE-0_01 directory has extra periods in name after unzip VMS-FlatFile-0^.01.zip;1 needs indexedfile, data-fixedformat <br/>x vms-icc-0_02 <br/>x vms-librarian-1_07 <br/>x VMS-LOCK-1_02 <br/>x VMS-Logical-0_6 <br/>x VMS-Mail-0_06 <br/>x vms-misc-1_01 <br/>x VMS-Monitor-0_07 <br/>x VMS-Priv-1_32 <br/>x VMS-Process-1_09 <br/>x VMS-Queue-0_58 <br/>x vms-stat-0_03 some errors <br/>x VMS-System-1_05 <br/>x VMS-User-0_02 <br/> <br/>I have tested VMS::device; the others survived mmk, mmk test, and mmk install, more or less. <br/> <br/>Thank you, Craig and all of the Perl 5 porters. <br/> <br/>Carl Friedberg <br/>www.esb.com <br/>The Elias Book of Baseball Records <br/>2014 Edition <br/> <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/06/msg15656.html Mon, 09 Jun 2014 23:08:10 +0000 Re: Perl 5.20.0 binary kits for OpenVMS available by Jovan Trujillo Woo hoo! <br/> <br/>Sent from my iPhone <br/> <br/>&gt; On Jun 1, 2014, at 1:12 PM, &quot;Craig A. Berry&quot; &lt;craigberry@mac.com&gt; wrote: <br/>&gt; <br/>&gt; Installation kits for OpenVMS Alpha and OpenVMS I64 v8.3 and later are available at: <br/>&gt; <br/>&gt; &lt;https://sourceforge.net/projects/vmsperlkit/files/&gt; <br/>&gt; <br/>&gt; The files are self-extracting archives and after downloading <br/>&gt; you must run them like so: <br/>&gt; <br/>&gt; $ run VMSPORTS-AXPVMS-PERL-V0520-0-1.SFX_AXPEXE <br/>&gt; <br/>&gt; for Alpha, and: <br/>&gt; <br/>&gt; $ run VMSPORTS-I64VMS-PERL-V0520-0-1.SFX_I64EXE <br/>&gt; <br/>&gt; for Itanium. Then, on either platform: <br/>&gt; <br/>&gt; $ product install perl <br/>&gt; <br/>&gt; and follow the usual installation prompts. <br/>&gt; <br/>&gt; Have an appropriate amount of fun. Anything related to these kits that turns out to be more fun than you can handle is probably best reported on the vmsperl mailing list.[1] <br/>&gt; <br/>&gt; Changes in this release can be found via typing &quot;perldoc perldelta&quot; after installation. <br/>&gt; <br/>&gt; <br/>&gt; [1] &lt;http://lists.perl.org/list/vmsperl.html&gt; <br/>&gt; ________________________________________ <br/>&gt; Craig A. Berry <br/>&gt; mailto:craigberry@mac.com <br/>&gt; <br/>&gt; &quot;... getting out of a sonnet is much more <br/>&gt; difficult than getting in.&quot; <br/>&gt; Brad Leithauser <br/>&gt; <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/06/msg15655.html Sun, 01 Jun 2014 20:22:32 +0000 Perl 5.20.0 binary kits for OpenVMS available by Craig A. Berry Installation kits for OpenVMS Alpha and OpenVMS I64 v8.3 and later are available at:<br/><br/>&lt;https://sourceforge.net/projects/vmsperlkit/files/&gt;<br/><br/>The files are self-extracting archives and after downloading<br/>you must run them like so:<br/><br/> $ run VMSPORTS-AXPVMS-PERL-V0520-0-1.SFX_AXPEXE<br/><br/>for Alpha, and:<br/><br/> $ run VMSPORTS-I64VMS-PERL-V0520-0-1.SFX_I64EXE<br/><br/>for Itanium. Then, on either platform:<br/><br/> $ product install perl<br/><br/>and follow the usual installation prompts.<br/><br/>Have an appropriate amount of fun. Anything related to these kits that turns out to be more fun than you can handle is probably best reported on the vmsperl mailing list.[1]<br/><br/>Changes in this release can be found via typing &quot;perldoc perldelta&quot; after installation.<br/><br/><br/>[1] &lt;http://lists.perl.org/list/vmsperl.html&gt;<br/>________________________________________<br/>Craig A. Berry<br/>mailto:craigberry@mac.com<br/><br/>&quot;... getting out of a sonnet is much more<br/> difficult than getting in.&quot;<br/> Brad Leithauser<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/06/msg15654.html Sun, 01 Jun 2014 20:13:08 +0000 Re: Hey, congratulations! by bugzilla You must select/enter a product. <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/05/msg15653.html Fri, 30 May 2014 07:38:49 +0000 Re: rmdir('/unix_path/to/dir') not working with 5.18.1? by Craig A. Berry <br/>On Mar 7, 2014, at 6:49 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote: <br/> <br/>&gt; On 3/7/2014 8:18 AM, Craig A. Berry wrote: <br/>&gt;&gt; <br/>&gt;&gt; On Feb 26, 2014, at 11:35 PM, John E. Malmberg <br/>&gt;&gt; &lt;malmberg@Encompasserve.org&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt;&gt; On 2/25/2014 7:02 PM, Craig A. Berry wrote: <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; On Feb 24, 2014, at 11:33 PM, John E. Malmberg <br/>&gt;&gt;&gt;&gt; &lt;malmberg@Encompasserve.org&gt; wrote: <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt;&gt; I can not seem to do a rmdir() of an absolute or relative Unix <br/>&gt;&gt;&gt;&gt;&gt; path with Perl 5.18.1. <br/>&gt;&gt;&gt;&gt; <br/>&gt;&gt;&gt;&gt; It works unless DECC$FILENAME_UNIX_REPORT is defined. That&#39;s not <br/>&gt;&gt;&gt;&gt; particularly well tested and you definitely found a bug. If <br/>&gt;&gt;&gt;&gt; that&#39;s defined, when rmdir calls the internal stat routine, which <br/>&gt;&gt;&gt;&gt; calls fileify, then &#39;abc/xyz&#39; becomes &#39;abc/xyz.DIR;1&#39;. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; If fileify is converting &#39;abc/xyz&#39; to &#39;abc/xyz.DIR;1&#39;, that is a <br/>&gt;&gt;&gt; bug that will break a lot of stuff. With the DECC$EFS_CHARSET <br/>&gt;&gt;&gt; enabled, that should never happen anywhere. <br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; Not only should the ;1 not be present, the &quot;.DIR&quot; should not be <br/>&gt;&gt;&gt; present either. <br/>&gt;&gt; <br/>&gt;&gt; I think we&#39;ve had this discussion before. Fileify really has to <br/>&gt;&gt; append the .DIR;1 because there are too many things, rmdir being one <br/>&gt;&gt; of them, that simply cannot operate on a directory spec but only on a <br/>&gt;&gt; directory file. That&#39;s really the point of fileify and we wouldn&#39;t <br/>&gt;&gt; call it if we didn&#39;t have to <br/>&gt; <br/>&gt; In a UNIX format filespecification, the .DIR or .DIR;1 is always a bug. <br/> <br/>I suppose that&#39;s true if the user asked for Unix report mode and if we were reporting filespecs to the user. None of that has anything to do with the purpose of fileify, which is to provide the VMS-native filename of a directory so that it can be operated on by native services. Note in particular that readdir omits the extension and version when Unix report is in effect, so nothing should see the .DIR;1 that doesn&#39;t specifically ask for it by calling fileify. <br/> <br/>All uses of fileify in the core are in [.vms]vms.c. In fact there are only three uses: <br/> <br/>1.) Perl_flex_stat_int. This stores an expanded filename in native format in an extended version of the stat structure so that its callers have it available if needed, and if the file is a directory, it&#39;s fileified. <br/> <br/>2.) do_rmdir. This is ultimately based on SYS$ERASE. The format in which filenames are reported to the user is irrelevant; SYS$ERASE still has to have the .DIR extension to be able to delete a directory. <br/> <br/>3.) Perl_rename. This is based on LIB$RENAME_FILE. What I said about SYS$ERASE in #2 applies here too. <br/> <br/>That&#39;s it. And in fact #2 seldom kicks in as rmdir normally gets the pre-fileified spec from stat() and only calls fileify directly if the stat failed. <br/> <br/>It may be that we could do a vmsify first and then fileify, but I think I tried that once and ran into trouble. It may be that we could refactor some of this code so that fileify simply becomes a flag passed to int_tovmsspec or int_rmsexpand. There is certainly a great deal of redundant processing in these routines. But changing fileify to not do what it was designed to do would break (at least) rmdir and rename and probably other things that depend on a native fileified spec in the stat buffer. <br/> <br/> <br/>&gt; Neither DECC$EFS_CHARSET nor DECC$FILENAME_UNIX_REPORT has any impact <br/>&gt;&gt; on this. So I&#39;ve changed vmsify in Perl to do exactly the same thing <br/>&gt;&gt; the CRTL does. Well, not exactly because the CRTL honors <br/>&gt;&gt; DECC$FILENAME_UNIX_NO_VERSION by escaping the semicolon even if the <br/>&gt;&gt; version spec is valid: <br/>&gt; <br/>&gt; Then Perl should also be using that feature. <br/>&gt; <br/>&gt;&gt; $ DEFINE DECC$FILENAME_UNIX_NO_VERSION 1 <br/>&gt;&gt; $ mcr []to_vms <br/>&gt;&gt; abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file: <br/>&gt;&gt; [.ABC]XYZ.DAT^;32767 1 files found <br/>&gt;&gt; <br/>&gt;&gt; I haven&#39;t (yet) made Perl do this. It wouldn&#39;t be hard to do, but <br/>&gt;&gt; I&#39;m a little skeptical about trying to support the whole wilderness <br/>&gt;&gt; of feature logicals. <br/>&gt; <br/>&gt; It is something that IMHO is critical to add, and I encountered this in the test harness for GNU make and had to modify the code to work around it. <br/> <br/>OK, I&#39;ll add it. <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/03/msg15652.html Sat, 08 Mar 2014 19:42:05 +0000 Re: rmdir('/unix_path/to/dir') not working with 5.18.1? by John E. Malmberg On 3/7/2014 8:18 AM, Craig A. Berry wrote:<br/>&gt;<br/>&gt; On Feb 26, 2014, at 11:35 PM, John E. Malmberg<br/>&gt; &lt;malmberg@Encompasserve.org&gt; wrote:<br/>&gt;<br/>&gt;&gt; On 2/25/2014 7:02 PM, Craig A. Berry wrote:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; On Feb 24, 2014, at 11:33 PM, John E. Malmberg<br/>&gt;&gt;&gt; &lt;malmberg@Encompasserve.org&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt;&gt;&gt; I can not seem to do a rmdir() of an absolute or relative Unix<br/>&gt;&gt;&gt;&gt; path with Perl 5.18.1.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; It works unless DECC$FILENAME_UNIX_REPORT is defined. That&#39;s not<br/>&gt;&gt;&gt; particularly well tested and you definitely found a bug. If<br/>&gt;&gt;&gt; that&#39;s defined, when rmdir calls the internal stat routine, which<br/>&gt;&gt;&gt; calls fileify, then &#39;abc/xyz&#39; becomes &#39;abc/xyz.DIR;1&#39;.<br/>&gt;&gt;<br/>&gt;&gt; If fileify is converting &#39;abc/xyz&#39; to &#39;abc/xyz.DIR;1&#39;, that is a<br/>&gt;&gt; bug that will break a lot of stuff. With the DECC$EFS_CHARSET<br/>&gt;&gt; enabled, that should never happen anywhere.<br/>&gt;&gt;<br/>&gt;&gt; Not only should the ;1 not be present, the &quot;.DIR&quot; should not be<br/>&gt;&gt; present either.<br/>&gt;<br/>&gt; I think we&#39;ve had this discussion before. Fileify really has to<br/>&gt; append the .DIR;1 because there are too many things, rmdir being one<br/>&gt; of them, that simply cannot operate on a directory spec but only on a<br/>&gt; directory file. That&#39;s really the point of fileify and we wouldn&#39;t<br/>&gt; call it if we didn&#39;t have to<br/><br/>In a UNIX format filespecification, the .DIR or .DIR;1 is always a bug.<br/>Older CRTLs did that, but now you have to enable a DECC feature to get <br/>that mis-behaivor.<br/><br/>With DECC$EFS_CHARSET disabled, this bug can be detected and compensated <br/>for, and since existing code expects the bug, for DECC$EFS_CHARSET <br/>disabled, fileify should continue to put the .DIR on for now.<br/><br/>When I last updated fileify, I updated the documentation about this and <br/>that programs should not be written to depend on the .DIR being added <br/>because it is a bug, and they should not depend on the bug being present <br/>in future versions of Perl.<br/><br/>With DECC$EFS_CHARSET enabled, fileify must not add a .DIR to a UNIX <br/>file path. If you do that, you can not have /file.dir/xyz as a legal <br/>file specification, and that shows up quite a bit.<br/><br/>It seems that in build procedures foo/.dir/bar shows up a lot, so this <br/>bug is a big deal.<br/><br/>It is one of the reason that I could not make EFS character set <br/>processing enabled by default. The ODS-2 to UNIX conversions were doing <br/>several things wrong, and programs were expecting that.<br/><br/>But proper support of EFS character set prohibited doing the conversions <br/>wrong, so the perl self tests needed to know which mode to expect.<br/><br/>&gt;&gt;&gt; Then stat converts it to VMS format and we get something like<br/>&gt;&gt;&gt; &#39;D0:[craig.TEST.abc]xyz.DIR^;1&#39;.<br/>&gt;<br/>&gt; I tested this with decc$to_vms using the example in on-line help and<br/>&gt; it does not escape a semicolon that is part of a valid version spec.<br/>&gt; It does escape it if the version spec is not valid (or if the<br/>&gt; semicolon appears somewhere else in the name):<br/><br/>&gt; $ mcr []to_vms abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file:<br/>&gt; [.ABC]XYZ.DAT;32767 1 files found $ mcr []to_vms<br/>&gt; abc/xyz.dat;123456789 Translating: abc/xyz.dat;123456789 file:<br/>&gt; [.ABC]XYZ.DAT^;123456789 1 files found<br/><br/>The semicolon version delimiter is actually allowed by one of the <br/>Unix/Posix/Linux specifications that I read, but is rare in Unix because <br/>the shell uses it to terminate the command, and the file systems usually <br/>just treat it as part of the filename, not as a version.<br/><br/>So it is not illegal for decc$to_vms to treat it as a version, but it is <br/>probably not the behavior that a ported program would expect.<br/><br/>&gt; Neither DECC$EFS_CHARSET nor DECC$FILENAME_UNIX_REPORT has any impact<br/>&gt; on this. So I&#39;ve changed vmsify in Perl to do exactly the same thing<br/>&gt; the CRTL does. Well, not exactly because the CRTL honors<br/>&gt; DECC$FILENAME_UNIX_NO_VERSION by escaping the semicolon even if the<br/>&gt; version spec is valid:<br/><br/>Then Perl should also be using that feature.<br/><br/>&gt; $ DEFINE DECC$FILENAME_UNIX_NO_VERSION 1<br/>&gt; $ mcr []to_vms<br/>&gt; abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file:<br/>&gt; [.ABC]XYZ.DAT^;32767 1 files found<br/>&gt;<br/>&gt; I haven&#39;t (yet) made Perl do this. It wouldn&#39;t be hard to do, but<br/>&gt; I&#39;m a little skeptical about trying to support the whole wilderness<br/>&gt; of feature logicals.<br/><br/>It is something that IMHO is critical to add, and I encountered this in <br/>the test harness for GNU make and had to modify the code to work around it.<br/><br/>There is almost no reason that most users of UNIX format file <br/>specifications would want DECC$FILENAME_UNIX_NO_VERSION enabled any time <br/>that DECC$FILENAME_REPORT_UNIX is enabled.<br/><br/>And now that I have written this, my memory is coming back to me as to <br/>why I coded the conversion routines to always escape what looked like <br/>versions on UNIX.<br/><br/>The DECC$FILENAME_UNIX_NO_VERSION used to only affect the readdir() <br/>function and no other conversions. So that mean that you could do a <br/>readdir() of [foo]abc^.bar.123 with report Unix and get &quot;abc.bar.123&quot; as <br/>a filename, which when combined with the original path, resulted in <br/>foo/abc.bar.123.<br/><br/>But because decc$to_vms was not honoring the <br/>DECC$FILENAME_UNIX_NO_VERSION settings in the older VMS versions, the <br/>resulting foo/abc.bar.123 could not be used as a path, unless we <br/>converted it back to the original VMS format path.<br/><br/>Having the vmsify put the escape on extra dots or version delimiters <br/>allowed these file specifications to work in Perl. I just did not key <br/>the behavior off of the &quot;no_version&quot; feature.<br/><br/>At the time, I did not know that there was a UNIXY standard that allowed <br/>the ; in file specifications to support versions. I do not have that <br/>URL handy though.<br/><br/>Regards,<br/>-John<br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/03/msg15651.html Sat, 08 Mar 2014 00:49:30 +0000 opendir on search list (Re: rmdir('/unix_path/to/dir') not workingwith 5.18.1?) by Craig A. Berry <br/>On Feb 24, 2014, at 11:33 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote: <br/> <br/>&gt; I also noticed that opendir(&#39;/search_list/directory&#39;) fails when &#39;directory&#39; is only in the first member of the search list. I am not sure what the issue there is. I think the solution for that will be more complex. <br/> <br/>I have not been able to reproduce this. If you post a reproducer I&#39;ll look into it. <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/03/msg15650.html Fri, 07 Mar 2014 15:02:43 +0000 Re: rmdir('/unix_path/to/dir') not working with 5.18.1? by Craig A. Berry <br/>On Feb 26, 2014, at 11:35 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote: <br/> <br/>&gt; On 2/25/2014 7:02 PM, Craig A. Berry wrote: <br/>&gt;&gt; <br/>&gt;&gt; On Feb 24, 2014, at 11:33 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote: <br/>&gt; <br/>&gt;&gt;&gt; I can not seem to do a rmdir() of an absolute or relative Unix <br/>&gt;&gt;&gt; path with Perl 5.18.1. <br/>&gt;&gt; <br/>&gt;&gt; It works unless DECC$FILENAME_UNIX_REPORT is defined. That&#39;s not <br/>&gt;&gt; particularly well tested and you definitely found a bug. If that&#39;s <br/>&gt;&gt; defined, when rmdir calls the internal stat routine, which calls <br/>&gt;&gt; fileify, then &#39;abc/xyz&#39; becomes &#39;abc/xyz.DIR;1&#39;. <br/>&gt; <br/>&gt; If fileify is converting &#39;abc/xyz&#39; to &#39;abc/xyz.DIR;1&#39;, that is a bug that will break a lot of stuff. With the DECC$EFS_CHARSET enabled, that should never happen anywhere. <br/>&gt; <br/>&gt; Not only should the ;1 not be present, the &quot;.DIR&quot; should not be present either. <br/> <br/>I think we&#39;ve had this discussion before. Fileify really has to append the .DIR;1 because there are too many things, rmdir being one of them, that simply cannot operate on a directory spec but only on a directory file. That&#39;s really the point of fileify and we wouldn&#39;t call it if we didn&#39;t have to. <br/> <br/>&gt;&gt; Then stat converts it to VMS format and we get something like <br/>&gt; &gt; &#39;D0:[craig.TEST.abc]xyz.DIR^;1&#39;. <br/> <br/>I tested this with decc$to_vms using the example in on-line help and it does not escape a semicolon that is part of a valid version spec. It does escape it if the version spec is not valid (or if the semicolon appears somewhere else in the name): <br/> <br/>$ mcr []to_vms abc/xyz.dat;32767 <br/>Translating: abc/xyz.dat;32767 <br/>file: [.ABC]XYZ.DAT;32767 <br/>1 files found <br/>$ mcr []to_vms abc/xyz.dat;123456789 <br/>Translating: abc/xyz.dat;123456789 <br/>file: [.ABC]XYZ.DAT^;123456789 <br/>1 files found <br/> <br/>Neither DECC$EFS_CHARSET nor DECC$FILENAME_UNIX_REPORT has any impact on this. So I&#39;ve changed vmsify in Perl to do exactly the same thing the CRTL does. Well, not exactly because the CRTL honors DECC$FILENAME_UNIX_NO_VERSION by escaping the semicolon even if the version spec is valid: <br/> <br/>$ DEFINE DECC$FILENAME_UNIX_NO_VERSION 1 <br/>$ mcr []to_vms abc/xyz.dat;32767 <br/>Translating: abc/xyz.dat;32767 <br/>file: [.ABC]XYZ.DAT^;32767 <br/>1 files found <br/> <br/>I haven&#39;t (yet) made Perl do this. It wouldn&#39;t be hard to do, but I&#39;m a little skeptical about trying to support the whole wilderness of feature logicals. <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/03/msg15649.html Fri, 07 Mar 2014 14:18:46 +0000 Re: rmdir('/unix_path/to/dir') not working with 5.18.1? by John E. Malmberg On 2/25/2014 7:02 PM, Craig A. Berry wrote:<br/>&gt;<br/>&gt; On Feb 24, 2014, at 11:33 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote:<br/><br/>&gt;&gt; I can not seem to do a rmdir() of an absolute or relative Unix<br/>&gt;&gt; path with Perl 5.18.1.<br/>&gt;<br/>&gt; It works unless DECC$FILENAME_UNIX_REPORT is defined. That&#39;s not<br/>&gt; particularly well tested and you definitely found a bug. If that&#39;s<br/>&gt; defined, when rmdir calls the internal stat routine, which calls<br/>&gt; fileify, then &#39;abc/xyz&#39; becomes &#39;abc/xyz.DIR;1&#39;.<br/><br/>If fileify is converting &#39;abc/xyz&#39; to &#39;abc/xyz.DIR;1&#39;, that is a bug <br/>that will break a lot of stuff. With the DECC$EFS_CHARSET enabled, that <br/>should never happen anywhere.<br/><br/>Not only should the ;1 not be present, the &quot;.DIR&quot; should not be present <br/>either.<br/><br/>The &quot;.DIR&quot; should only be present with DECC$EFS_CHARSET disabled because <br/>that is what the older conversions expected, and on ODS-2 it could be <br/>removed on a reverse conversion.<br/><br/>&gt; Then stat converts it to VMS format and we get something like<br/> &gt; &#39;D0:[craig.TEST.abc]xyz.DIR^;1&#39;.<br/><br/>abc/xyz.dir would be converted to [.abc]xyz^.dir or [.abc]xyz^.dir.dir.<br/><br/>&gt; So we probably need to have fileify omit the version with unix<br/>&gt; report enabled.<br/><br/>And the .DIR in UNIX paths, unless is<br/> foo/bar.dir &lt;=&gt; [.foo]bar^.dir.dir.<br/><br/>Thanks,<br/>-John<br/><br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/02/msg15648.html Thu, 27 Feb 2014 05:35:06 +0000 Re: rmdir('/unix_path/to/dir') not working with 5.18.1? by Craig A. Berry <br/>On Feb 24, 2014, at 11:33 PM, John E. Malmberg &lt;malmberg@Encompasserve.org&gt; wrote: <br/> <br/> <br/>&gt; I can not seem to do a rmdir() of an absolute or relative Unix path with Perl 5.18.1. <br/> <br/>It works unless DECC$FILENAME_UNIX_REPORT is defined. That&#39;s not particularly well tested and you definitely found a bug. If that&#39;s defined, when rmdir calls the internal stat routine, which calls fileify, then &#39;abc/xyz&#39; becomes &#39;abc/xyz.DIR;1&#39;. Then stat converts it to VMS format and we get something like &#39;D0:[craig.TEST.abc]xyz.DIR^;1&#39;. <br/> <br/>So we probably need to have fileify omit the version with unix report enabled. <br/> <br/>&gt; I have worked around the issue by replacing the rmdir() builtin method with one that translates the filename to VMS format and then calls unlink(). <br/>&gt; <br/>&gt; LION&gt; perl --version <br/>&gt; <br/>&gt; This is perl 5, version 18, subversion 1 (v5.18.1) built for VMS_IA64 <br/>&gt; <br/>&gt; LION&gt; show log decc$* <br/>&gt; <br/>&gt; (LNM$PROCESS_TABLE) <br/>&gt; <br/>&gt; &quot;DECC$EFS_CASE_PRESERVE&quot; = &quot;ENABLE&quot; <br/>&gt; &quot;DECC$EFS_CHARSET&quot; = &quot;ENABLE&quot; <br/> <br/>For future reference, those two are on by default in Perl 5.18.x. <br/> <br/>&gt; &quot;DECC$FILENAME_UNIX_NOVERSION&quot; = &quot;ENABLE&quot; <br/>&gt; &quot;DECC$FILENAME_UNIX_REPORT&quot; = &quot;ENABLE&quot; <br/>&gt; &quot;DECC$READDIR_DROPDOTNOTYPE&quot; = &quot;ENABLE&quot; <br/>&gt; <br/>&gt; LION&gt; show log perl_* <br/>&gt; <br/>&gt; (LNM$PROCESS_TABLE) <br/>&gt; <br/>&gt; &quot;PERL_ROOT&quot; = &quot;LION$DKA0:[SYS0.SYSCOMMON.perl-5_18.]&quot; <br/>&gt; <br/>&gt; <br/>&gt; I also noticed that opendir(&#39;/search_list/directory&#39;) fails when &#39;directory&#39; is only in the first member of the search list. I am not sure what the issue there is. I think the solution for that will be more complex. <br/> <br/>Not sure what&#39;s going on there but I&#39;ll try to have a look soonish. <br/> <br/>&gt; I have worked around that issue by decoding the search list and recreating the path to used for opendir. <br/>&gt; <br/> <br/> <br/> <br/>________________________________________ <br/>Craig A. Berry <br/>mailto:craigberry@mac.com <br/> <br/>&quot;... getting out of a sonnet is much more <br/> difficult than getting in.&quot; <br/> Brad Leithauser <br/> <br/> http://www.nntp.perl.org/group/perl.vmsperl/2014/02/msg15647.html Wed, 26 Feb 2014 01:02:21 +0000