[Info-vax] completion status from LIB$SPAWN

[Bob Koehler]

In article <1ots69-i79.ln1 at news.sture.ch>, Paul Sture <paul at sture.ch> writes:
> On Fri, 27 Apr 2012 18:54:32 -0400, David Froble wrote:
> 
>> Many years ago the argument for the constants and masks was, "DEC could
>> change the value of something, and using the constants would mean your
>> code would still work".  I've never seen any thing like this change, and
>> I doubt I ever will, and if it happens it would be in my opinion a huge
>> mistake.  Regardless, DEC encouraged the use of the constants...
> 
> IIRC somewhere around the transition from V3 to V4, error message numbers 
> could and did change.  You were safe if you had used the constant names 
> in programs, but existing DCL procedures with hard coded error numbers 
> could break.

   Between VMS 2.5 and 3.0, IO codes (IO$xxx) changed.  If you followed
   DEC's API documentation for Macro, you recompiled, relinked, and all
   was well.  If you followed DEC's API documentation for Fortran, you
   might recompile a Macro file it taught you to write, then you
   relinked (many symbols could be picked up by the linker).

   If you ran the program with the out of date IO codes, you would get
   results like an IO$_READVBLOCK to a tape drive failing because the
   write ring was not in place.

   Guess what happened if you put the write ring in place.

   And if you didn't read the Release Notes, ...

   There were also changes to the values of several file header symbols
   when ODS-2 went from 9.3 to 49.49 file names.  I had to fix some
   lib$initialize code that "knew" where the user field was.  And the
   code that wrote to the user field trashed a bunch of files before I
   found and fixed it.

   But SS$_NORMAL is _documented_ in the API documents as having the 
   value 1.

   More to the point of the OP's issue.  We had a condition handler that
   changed the inhibit message bit to indicate that it had seen and
   processed the error once, which allowed it to pass the error on to
   other handlers on the stack even though the same handler might be
   in more than one frame on the stack.  The handler in question was
   part of implementing error count related requirements and thus did
   not double count an error.

   Also, RMS$_NORMAL is not SS$_NORMAL, and is not 1, but is also normal
   completion.  As just one example.