RE: Q: Can anyone explain this curious behaviour.

[john...@compinia.de]

Hi,

back from vacation.
Thanks for all the responses.

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.

> 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.

> The value you get is an accident resulting from whatever last set
errno. This is true on any operating system. Here's bash on OS X:
>
> $ perl -e '$! = 99; $s = $ENV{X} or die qq/no such environment
variable: $!\n/;'
> no such environment variable: Not a STREAM
> $ echo $?
> 99

I see a predictable behaviour. If I set #! to 99 it is still 99 after an
attempt to retrieve a value from the hash. To me this demonstrates, that
Perl on OS X doesn't show unwanted side effects as Perl on VMS does.

> 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's actually more predictable on VMS than it's
supposed to be.

$ perl -e "$s; defined $s or die ""undefined variable: '$!, $^E'\n"""
undefined variable: ', %SYSTEM-S-NORMAL, normal successful completion'
%SYSTEM-F-ABORT, abort
$

To me the question is still, why is errno set on VMS for $s=$ENV{X} ?

> use vmsish 'hushed';

I can even conditionalize that just for VMS or as has already been
suggested clear $!, $^E and maybe even $?, which are all workarounds
only required for VMS.

John

[John E. Malmberg]

On 8/6/2014 2:48 AM, john...@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

[Craig A. Berry]

On Aug 6, 2014, at 2:48 AM, john...@compinia.de wrote:

> To me the question is still, why is errno set on VMS for $s=$ENV{X} ?

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.

Everything else in your post simply ignores the documentation and the explanations I've already given you. I don't really have anything to add.

________________________________________
Craig A. Berry
mailto:craig...@mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser

[john...@compinia.de]

Hi,

again thanks for the replies to this thread.

The original OP was not about "Unix/VMS error/exit codes", it was about
the unexpected %SYSTEM-F-NOLOGNAM. The explanation given triggered
some tests and examples shown for Linux and VMS, which included the exit
codes.

From a perl viewpoint, I just expect one perl script to print the very
same output no matter where it runs, especially as there is no OS
specific code in the script.

As far as I understand, %ENV is or behaves like a perl hash. That is,
'defined $ENV{X}' can be false and that is expected. But looking up a
hash value should not cause any side effect. On VMS it does, so from my
point of view the implementation of %ENV on VMS is incomplete, incorrect
or broken.


John