Barely relevant but possibly interesting?:
After I read the help text which suggested looking at fab$l_stv to
get an I/O status value, I looked at some old UnZip code to see if/how
we were using it. It all made sense -- many places where sys$whatever()
returned a bad status, and then the relevant fab$l_stv was used to add
information to the error message. And then I noticed this statement
(in [.vms]vms.c:check_for_newer()), unchanged for decades:
sys$dassgn(fab.fab$l_stv);
which made very little sense to me.
After too much reading, I discovered that $OPEN with
fab$v_ufo/FAB$M_UFO set (as it was here) does not set fab$w_ifi, but
does return the I/O channel in fab$l_stv (not a completion status value
in the usual sense).
So, that apparent nonsense code actually did make sense. Of course,
it was followed immediately by this:
sys$close(&fab); /* be sure file is closed and RMS knows about it */
If anyone had ever checked the status from that, he might have
noticed what I did:
ITS $ exit %x00018564
%RMS-F-IFI, invalid internal file identifier (IFI) value
When I think of all the nanoseconds that were wasted over all those
years...
Moral: Sometimes it can pay (at least a little) to check the status
of a function which can't possibly fail. If nothing else, it can be
educational.
