[comp.software-eng] Status codes in VMS

sommar@enea.se (Erland Sommarskog) (04/09/89)

Since there seems to be some confusion by some contributors to this 
group, I post this here. However it does not really belong here. I 
couldn't really decide which group I should direct followups to.
Comp.os.vms/INFO-VAX would be the most logical, but this is probably
well-known stuff for readers in this high-traffic group, so I  
hesitate. Another idea would be comp.os.misc, which I don't read
myself, so mail me a copy if you post there.


G.M. Harding (gm@mitisft.Convergent.COM) writes:
>     The last time I used VMS (4.3? 4.4? Am I thinking of some other
>software product?) code ported from Unix with a standard "return (0)"
>at the end of main() would cause VMS to display a particularly
>unaesthetic error message on the screen at process termination.
>The system did not, however, crash or otherwise behave abnormally.
>Perhaps zero has the connotation you mention at the driver level,
>but I don't think such is the case at the application level. The
>way I discovered what was happening was peculiar: I noticed that
>the VMS termination-error message went away if my program had an
>internal error! In that case, it would return 1 from main(), which
>VMS thought was just fine.

One should beware of that the status codes on VMS are more than 
simply exit codes. A typical VMS message looks like:

      %RMS-E-FNF, file not found

This corresponds to a 32 bit code which consists of four parts.
You define these code with help of the MESSAGE facility that
is part of the standard kit to VMS. You can compile and link
these message definitions with your application. You can also
place them in a shareable image.
  When you define a set of messages, you normally first give the
facility which you assign a number and a prefix. Then you give 
the severity for the next suite of codes. Finally you set a base 
to start from if you want anything else than zero. For each message 
you give a identification and a text. MESSAGE then assigns the ids
numbers increasing one for each id and translates them to 32-bit 
codes and stores the texts somewhere. (The text can include $FAO
directives, thus they can be parameterized.)
  If we start from left, I must begin to confess my ignorance.
The four first bits are used for something I don't remember. The
next 12 bits is the facility code. I.e., who is sending the message.
In the example above, the facility is RMS (the file system) which
has number one. Zero, is the code for VMS itself, normally known
as SYSTEM here.
  Bits 17-29 contains the id number, in this case FNF. In your 
program you refer to the code with the facility prefix included.
The prefix for RMS is RMS$_, so we get RMS$_FNF in our example. 
Beside being something you use in your program, the id is also
the key you use when you look in the system messages manual to
get further explanation.
  Finally, the three lowest bits is the severity of the message.
Their meanings are:
  0: Warning
  1: Success
  2: Error
  3: Informational
  4: Fatal error
  5-7: Unused. (Reserved to Digital I guess.)
The severity is seen as the one-letter second part of the error message.
The letters for the levels are in order W, S, E, I, F and ?.
  Since a pentanary translation is too tiresome to have in all programs,
there is a binary interpretation as well, which is: odd => OK, even
=> not OK. So if a programs exits with an even code, VMS displays
the corresponding message. VMS doesn't actually look at how the severity 
was defined originally, so if I exit with RMS$_FNF - 2, I get 
%RMS-W-FNF instead. There is one exception, though, and that is status 
0 and 2-7. 1 is SS$_NORMAL or "normal successful completion". Since
zero is not an unexpected code from an ignorant programmer, zero
doesn't give "%SYSTEM-W-NORMAL, normal successful completion" which
would be misread. Instead, zero is considered as undefined and you get
the default message:
   %NONAME-W-NOMSG, message number <code in hex>
Apparently this is the opposite of Unix, so a simple way to go when   
porting C program would be as suggested and live with the strange
message above. If you want more sophisticated messages, you could
write your own message file and use that one. (And with a little
planning you could probably stuff the numbers in a header file
to use in your Unix environment. That is beyond my knowledge though.) 
  Is there really a meaning of the five severity levels?, beside
the communication to the user? Yes. At least for the even ones.
If a compiler gives you warning for something, it will still give
you an object file. If you get an error, it will continue to analyze
the code, but will give you an empty object file. (So that the linker
not will use an obsolete object file is you are casual.) But if
you get a fatal error, it will stop immediately. 
  In your DCL procedure you can say ON WARNING, ON ERROR, ON SEVERE
("severe" is a synonym for "fatal") to tell what you to happen in
case you get such a status. What is left as a beau art for the 
programmer is to use the appropriate severity levels on his messages.
Too often I've seen fatal where it should have been warning or 
error.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
I used to say "It could have been worse, it could have been Pepsi",
then I drank a Diet Coke...