[Info-vax] completion status from LIB$SPAWN

[jbriggs444]

On Apr 27, 2:25 am, StGallen <sengupta.su... at gmail.com> wrote:
> 1. For the benefit of anyone reading this thread, the above is described in the C manual.
>
> 2. The value 268435457 (in decimal) is same as %X10000001 in HEXA and 1 in decimal is same as 1 in HEXA.
>
> $ say F$message(%X00000001)
> %SYSTEM-S-NORMAL, normal successful completion
>
> $ say F$message(%X10000001)
> %SYSTEM-S-NORMAL, normal successful completion
>
> So both 268435457 & 1 are status codes for normal completion. However, the constant SS$_NORMAL is defined to be 1.
>
> So the question remains: why would VMS return 2 values for Normal Completion?
> How are programmers expected to handle it without going the route of the procedure posted by Briggs above.

Steven Schweda has given you his answers to these questions.  Let
me give you my take on it.

First question:  Why 2 values for normal completion?

Consider a program that runs, prints an error message and
exits with a completion status indicating failure.

Consider a second program that runs, prints no error
message and exits with a completion status indicating
a failure.

Both are reasonable behaviors.

But now the command shell (or command language
interpreter as it is referred to in VMS lingo) has a problem.
Should it display the error message corresponding to the
completion status?  Or should it remain silent?

The VMS convention is that the command language
interpreter should examine the STS$V_INHIB_MSG bit in
the completion status to make this determination.

Another way to answer is that SS$_NORMAL is a value
that is expected to match the low order 28 bits of the
completion status -- the facility, error code and severity.
There is only one value for SS$_NORMAL.  The fact that
there are multiple 32 bit condition values which match
SS$_NORMAL in the low order 28 bits is perfectly
reasonable and natural.

Now your second question: "How are programmers expected to handle it"?

Normally a programmer does not particularly care why a
library call failed.  All he needs to know is whether it failed.
The low order bit (success/failure) or maybe the low order three
bits (severify) are all that matter.

It is not good practice to write a case statement that looks for
all the possible failure possibilities and generates a different
error message for each one.  Let the machine do the hard work
of looking up the message text corresponding to the status
code -- there are various facilities to do that.

For instance, you could just exit from your program, using the
returned status as your completion status.  Let the command
language interpretor display the associated message text.

Or you could use SYS$GET_MSG or SYS$PUT_MSG to display
the message text associated with the message code.

Or you could use LIB$SIGNAL to convert the completion status
to an exception and let the default exception handling facility
display the error message (if you have no declared exception
handlers, you'll get a stack dump along with the error message).

If you feel that you must identify individual conditions, simply
test the correct bits of the status code instead of comparing the
whole thing to a fixed value.

I programmed on VMS for a lot of years.  I don't think that I
ever used LIB$MATCH_COND.  I can count on the fingers
of one hand the number of times I cared about a particular status
code (SS$_WASSET and SS$_WASCLR are the obvious
exceptional cases).

I cannot count the number of times I used a construct like

      if ( .not. status ) then
          type *, "Failed to mumble mumble"
          call sys$exit ( %val(status) )
      end if