On 8/6/2014 2:48 AM, john.d...@compinia.de wrote:
Here my thoughts on the responses so far.
> What you've actually demonstrated here is that the behaviour 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.
Hmm, on Linux I see $? as 2 which is not generic in my point of view.
The %SYSTEM-F-ABORT looks generic and it is different from
%RMS-E-DNF which from John M's reply indicates it is not severe enough.
Fankly, I don't understand all this exit/return code mangling and I
don't think a Perl script writer needs to.
The exit/return code encoding is required to comply with the VMS
programing standard.
It is illegal on VMS to simply return the UNIX exit codes, and from a
system manager's point of view it wrecks havoc with programs that
monitor process accounting for unusual errors. And when I managed
commercial systems, I used those programs extensively.
It is a mostly undocumented feature of the CRTL on the details how it
encodes/decodes the values. So both the Perl VMS specific documentation
and the GNV Bash VMS release notes document it.
That feature of the CRTL was implemented long after Perl was first
ported to VMS, so originally Perl could not have taken advantage of it.
So someone made the decision to just return SS$_ABORT for all
non-success exit codes instead of violating the VMS programming standard.
With the traditional default VMS behavior, if you are in Perl and run a
perl script as a subprocess, and it fails with a die or other error
detected by Perl you get 42 or SYSTEM-F-ABORT returned to the parent as
the exit code regardless of what the actual error is.
With PERL_VMS_POSIX_EXIT defined, in the Perl parent, you get the actual
error code that the child exited with. Perl children processes then
behave just like on Unix.
If you are executing Perl as a subprocess from any correctly built C
program on VMS, including Perl, the PERL_VMS_POSIX_EXIT needs to be
defined to get the correct exit code from the child.
Only VMS scripts like DCL or MMS/MMK or non-C programs need to be
concerned with how to do the exit decoding to get the original value.
The only time PERL_VMS_POSIX_EXIT does not need to be defined is if you
do not care what the actual exit reason is.
PERL_VMS_POSIX_EXIT is not a default when running under DCL so that
existing DCL scripts that call perl scripts would not have to be changed.
IMHO, With Perl now being changed to support EFS character sets by
default, it should also now default to PERL_VMS_POSIX_EXIT by default so
that actual the die/exit status is not lost. Craig disagrees.
> Changing our implementation so it doesn't set errno also wouldn't
really help you because you'd still get whatever random value was in
vaxc$errno. Some of the time it would not be set and you'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.
Another "hmm", the value in vaxc$errno shouldn't be random, or? It
should be the result of a CRTL function which sets it. But from my point
of view it should be cleared or reset to the previous value of
vaxc$errno, whenever a CRTL function is called to implement a Perl
feature, which usually does not require a CRTL function to be called.
It is not really random, it is simply stale data.
The value of vaxc$errno is undefined unless errno is EVMSERR per the
CRTL documentation.
The VMS specific code in Perl follows that and only updates vaxc$errno
if it needs to set errno to EVMSERR, which is rare.
The code to lookup EVMSERR in Perl assumes that the Perl programmer
knows that what they are getting is stale data if errno is not EVMSERR.
Out of time to deal with the rest right now.
Regards,
-John
