Re: vms argv[0] and exit status fixes.

[John E. Malmberg]

On 3/24/2014 3:07 PM, h.becker wrote:
> There are several problems with the checked-in old exit handling, which
> aren't resolved by the recently suggested new code.
>
> Old problems are:
> - the %NONAME-?-NOMSG messages, which are generated by VMS when a
> program returns a Unix style exit code; an exit code 2 shows as
> %NONAME-E-NOMSG, Message number 00000002.
> - VMS style warnings do not stop make.
>
> New problems are:
> - redirecting exit (and _exit, which seems wrong) to vms_exit, where the
> passed exit code is adjusted, doesn't really know whether this is a make
> exit code or one passed from an action routine, which can be of any style
> - in case of an error there are error numbers printed by make, with the
> adjusted exit codes, these numbers are no longer obvious.

That is because the conversion is not complete, only the parent handling 
has been fixed, not the child status.

Documented Make exit codes are 0, 1, 2 and VMS style exit codes are 0 
for success, and VMS style failure codes start at 8 for Access violation.

The CRTL decc$exit() and decc$_exit() are already doing a translation of 
exit code 0 to be SS$_NORMAL.

So 0 is passed through to decc$exit, and codes 1 through 7 need to be 
encoded as POSIX exit codes.

And after looking at how MAKE_TROUBLE works, as you had it, it does need 
to have an ERROR severity level.  A warning status should stop the make, 
but since the target actually got created, re-running make should 
continue.  Since MAKE_TROUBLE is returned when a target is not created, 
re-running the make should result in a failure again.

I am now able to run the complete test suite, and while not everything 
passes, I can now see the impact of using the POSIX encoding is, and 
where more adjustments are needed.

For programs that never see VMS status codes, the _POSIX_EXIT macro 
definition fixes almost everything.  But we can not use it on GNU make 
because we need the VMS exit codes and want the VMS severity codes for 
backwards compatibility.

I have not submitted my latest exit handling patch because I am waiting 
for the GNU copyright assignment.  It has been a week now, and I have 
not seen a response.

> It seems that having VMS specific codes for MAKE_SUCCESS, MAKE_TROUBLE
> and MAKE_FAILURE is the way to go. Easy, as long as these codes
> are always used. But there are hard coded numbers 0, 1 and 2 as well as
> EXIT_FAILURE, passed to die() and/or exit().

That may introduce other problems if Make or a child is using the hard 
coded number instead of the symbol.

It is safer to have the exit() do the encoding, and that is more 
transparent to majority of the maintainers to make.

The less VMS specific code they have to work around, the better.  And 
the less chance that they may break something VMS specific by accident.

> So I suggest to always use the MAKE_mumble macros and to define them for
> VMS as posix compatible exit codes. This avoids redirecting exit to
> vms_exit; this assumes that the exit status of a child process is VMS
> style, which makes checking for failure simpler; this allows to decode
> and print the known make error numbers.

If we were compiling /DEFINE=_POSIX_EXIT, then all this happens 
magically, except then we can not set the VMS severity bits.

> But it doesn't solve everything. The usual action routines will be VMS
> utilities which set the VMS style exit codes. Any program which adheres
> to the VMS style exit codes will work as an action routine as well. That
> includes all programs which make use of the posix compatible exit codes
> as well.

> Action routines, which just return a Unix style number, would need
> different checks. Although it seems simple to check for zero (when there
> is no VMS facility code set), it turns out that the child processes, as
> they are implemented today, never ever return zero. This way it is not
> possible to find out whether it was successful or not.

That is already being handled in the lib$spawn.  lib$spawn is returning 
the VMS status in a VMS specific variable, so the VMS status which 
includes POSIX encoded status.

There is some extra handling needed in the VMS specific code around 
LIB$SPAWN to decode the POSIX status back to the original UNIX code. 
That will make the numbers reported by Make look like they should.  Once 
that is done, then the original UNIX constants for MAKE_<mumble> will 
match the output.

The only case that is problematic to handle is when a child utility 
ported from Unix using UNIX exit codes is not compiled with 
/DEFINE=_POSIX_EXIT/MAIN=POSIX_EXIT.  In that case, 0 and 1 are both 
treated as 1, and the rest of the numbers get passed through.

I have been through this conversion on the VMS Perl project which has 
similar backwards compatibility issues.

Regards,
-John