From: sieler@shell.portal.com (Stan Sieler)
Subject: Re: Bad escape codes on 9000/720?
Organization: Portal Communications Company
X-Newsreader: TIN [version 1.1 PL7]
Date: Tue, 12 Jan 1993 06:46:10 GMT

Shankar Unni (shankar@sgi.com) wrote:
: Richard Johns P205 (rjohns@brtph46.BNR.CA) wrote:
: 
: > Ok, some more investigation and I find that there's a Pascal include file,
: > /usr/include/pasesc.ph, that maps these "huge numbers" to reasonable numbers.
: > For example, escape code 39321792 maps to error PasErr_600, which means I
: > can look up error 600 in /usr/lib/paserrs.  SO, NOW:
: 
: The reason they are done that way was to provide a crude way of
: distinguishing escapes from different libraries on the system (not too
: important on Unix, where few of the libraries are in Pascal, but vital
: on MPE/XL, where the kernel, and most of the system libraries, are
: written in Pascal).
Actually, this is a critically important concept on any OS, in any
language.  Of course, this differs radically from the Unix & X Windows
concept of "error? what error?".
: 
: > 2.  What's the recommended way of translating the constant PasErr_600?
: 
: The exact encoding is an artifact of the system error encoding in the
: MPE/XL operating system, where the *lower* half (16 bits) is a
: "subsystem number", and the *upper* half is the error number.  Seems
: a**-backward, and I never got a good explanation from anyone why it
: was done that way.
:
You probably never read the "Error Standards" document, which Pascal
manages to violate anyway.

I was helped to decide that error numbers are in the upper, and
subsystems in the lower for the simple reason that Dennis Handly
mentions: a trivial means to check the entire 32 bit result to differentiate
beteen an ERROR (a negative value), a warning (positive value) and OK (0).

However, by the official definition, all Pascal run-time errors should have
had negative values in the upper 16 bits.  Oh well, I doubt anyone will
fix it now!

Note: if a subsystem wishes to say "ok", it most specifically is forbidden
to return a value of [0, subsystem#].  Instead, it must return all 32-bits
0.
 
BTW: the placing of the info in the upper-16 bits, and the subsystem in
the lower-16 should now be obvious.  The next question is: why are
errors negative and warnings positive instead of vice-versa?  The answer
is: the TurboIMAGE database returned negative values for errors, and
positive values for errors, and I felt that more users were familiar
with that than with the few counter examples we could find (e.g.: CREATEPROCESS)

WARNING:  I don't have access to the HP-UX file which lists all of the
PasErr values, but the MPE/iX file (PASESC.PUB.SYS) has incorrect values
(or names?) starting with PasErr 905 (they are all off by one in the
info field).

I.e.: 
   PasErr_905 = 59309367 is misleading.  PasErr_904 would actually be
that value (i.e.: the upper 16-bits of 59309367 = 904).  Now, 
I don't know if 904 or 905 is InvalidProcFunc.  (In other words, is the
vale 59309367 wrong or is the PasErr_905 wrong?)

: Thus, 39321792 == 0x25800c0, which translates to subsystem number 0xc0
: (192 == Pascal) and error number 0x258 (600).

The recommended way is:

   type    
      hpe_status   = record
         info      : shortint;
         subsys    : shortint;
         end;

   var
      status       : hpe_status;

   ...
   recover
      begin
      status := escapecode;    {always pick up immediately!}
      ...
      if status.subsys = subsys_pascal then 
         if status.info = ..whatever..

Or, if you want "status" to be an integer:

   $type_coercion 'representation'$

   recover
      begin
      status := escapecode;
      ...
      if hpe_status (status).info = ...


: > 3.  Is there anything useful I can do with the error message catalog,
: >     /usr/lib/nls/$LANG/pc_msgs.cat?
: 
: If I remember right, the /usr/lib/nls/$LANG/pc_msgs.cat catalog has
: the text for the errors in pasesc.ph. If you know how to read a
: message catalog, you can retrieve the text for these messages from
: there.  I *think* the message set number (for catread/catgetmsg et.
: al.) is "5".
: 
If the set number is *not* the subsys number, then someone screwed up
HP-UX.  In MPE, it is defined as being the subsys number...which removes
the need for any a-priori definition.
: 
: --
: Shankar Unni				E-Mail:	shankar@sgi.com
: Silicon Graphics Inc.			Phone:	+1-415-390-2072

In short, the concept of the 32-bit hpe_status is a valuable one, when
used correctly.         

Stan Sieler
sieler@allegro.com