home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / hp / 14756 < prev    next >
Encoding:
Text File  |  1993-01-12  |  4.7 KB  |  129 lines

  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!portal!sieler
  3. From: sieler@shell.portal.com (Stan Sieler)
  4. Subject: Re: Bad escape codes on 9000/720?
  5. Message-ID: <C0qAsy.Dr3@unix.portal.com>
  6. Sender: news@unix.portal.com
  7. Nntp-Posting-Host: jobe
  8. Organization: Portal Communications Company
  9. X-Newsreader: TIN [version 1.1 PL7]
  10. References: <1icvuuINNo4s@fido.asd.sgi.com>
  11. Date: Tue, 12 Jan 1993 06:46:10 GMT
  12. Lines: 115
  13.  
  14. Shankar Unni (shankar@sgi.com) wrote:
  15. : Richard Johns P205 (rjohns@brtph46.BNR.CA) wrote:
  16. : > Ok, some more investigation and I find that there's a Pascal include file,
  17. : > /usr/include/pasesc.ph, that maps these "huge numbers" to reasonable numbers.
  18. : > For example, escape code 39321792 maps to error PasErr_600, which means I
  19. : > can look up error 600 in /usr/lib/paserrs.  SO, NOW:
  20. : The reason they are done that way was to provide a crude way of
  21. : distinguishing escapes from different libraries on the system (not too
  22. : important on Unix, where few of the libraries are in Pascal, but vital
  23. : on MPE/XL, where the kernel, and most of the system libraries, are
  24. : written in Pascal).
  25. Actually, this is a critically important concept on any OS, in any
  26. language.  Of course, this differs radically from the Unix & X Windows
  27. concept of "error? what error?".
  28. : > 2.  What's the recommended way of translating the constant PasErr_600?
  29. : The exact encoding is an artifact of the system error encoding in the
  30. : MPE/XL operating system, where the *lower* half (16 bits) is a
  31. : "subsystem number", and the *upper* half is the error number.  Seems
  32. : a**-backward, and I never got a good explanation from anyone why it
  33. : was done that way.
  34. :
  35. You probably never read the "Error Standards" document, which Pascal
  36. manages to violate anyway.
  37.  
  38. I was helped to decide that error numbers are in the upper, and
  39. subsystems in the lower for the simple reason that Dennis Handly
  40. mentions: a trivial means to check the entire 32 bit result to differentiate
  41. beteen an ERROR (a negative value), a warning (positive value) and OK (0).
  42.  
  43. However, by the official definition, all Pascal run-time errors should have
  44. had negative values in the upper 16 bits.  Oh well, I doubt anyone will
  45. fix it now!
  46.  
  47. Note: if a subsystem wishes to say "ok", it most specifically is forbidden
  48. to return a value of [0, subsystem#].  Instead, it must return all 32-bits
  49. 0.
  50.  
  51. BTW: the placing of the info in the upper-16 bits, and the subsystem in
  52. the lower-16 should now be obvious.  The next question is: why are
  53. errors negative and warnings positive instead of vice-versa?  The answer
  54. is: the TurboIMAGE database returned negative values for errors, and
  55. positive values for errors, and I felt that more users were familiar
  56. with that than with the few counter examples we could find (e.g.: CREATEPROCESS)
  57.  
  58. WARNING:  I don't have access to the HP-UX file which lists all of the
  59. PasErr values, but the MPE/iX file (PASESC.PUB.SYS) has incorrect values
  60. (or names?) starting with PasErr 905 (they are all off by one in the
  61. info field).
  62.  
  63. I.e.: 
  64.    PasErr_905 = 59309367 is misleading.  PasErr_904 would actually be
  65. that value (i.e.: the upper 16-bits of 59309367 = 904).  Now, 
  66. I don't know if 904 or 905 is InvalidProcFunc.  (In other words, is the
  67. vale 59309367 wrong or is the PasErr_905 wrong?)
  68.  
  69. : Thus, 39321792 == 0x25800c0, which translates to subsystem number 0xc0
  70. : (192 == Pascal) and error number 0x258 (600).
  71.  
  72. The recommended way is:
  73.  
  74.    type    
  75.       hpe_status   = record
  76.          info      : shortint;
  77.          subsys    : shortint;
  78.          end;
  79.  
  80.    var
  81.       status       : hpe_status;
  82.  
  83.    ...
  84.    recover
  85.       begin
  86.       status := escapecode;    {always pick up immediately!}
  87.       ...
  88.       if status.subsys = subsys_pascal then 
  89.          if status.info = ..whatever..
  90.  
  91. Or, if you want "status" to be an integer:
  92.  
  93.    $type_coercion 'representation'$
  94.  
  95.    recover
  96.       begin
  97.       status := escapecode;
  98.       ...
  99.       if hpe_status (status).info = ...
  100.  
  101.  
  102. : > 3.  Is there anything useful I can do with the error message catalog,
  103. : >     /usr/lib/nls/$LANG/pc_msgs.cat?
  104. : If I remember right, the /usr/lib/nls/$LANG/pc_msgs.cat catalog has
  105. : the text for the errors in pasesc.ph. If you know how to read a
  106. : message catalog, you can retrieve the text for these messages from
  107. : there.  I *think* the message set number (for catread/catgetmsg et.
  108. : al.) is "5".
  109. If the set number is *not* the subsys number, then someone screwed up
  110. HP-UX.  In MPE, it is defined as being the subsys number...which removes
  111. the need for any a-priori definition.
  112. : --
  113. : Shankar Unni                E-Mail:    shankar@sgi.com
  114. : Silicon Graphics Inc.            Phone:    +1-415-390-2072
  115.  
  116. In short, the concept of the 32-bit hpe_status is a valuable one, when
  117. used correctly.         
  118.  
  119. Stan Sieler
  120. sieler@allegro.com
  121.  
  122.