Starlink development wrote on :
> [I should ask, what happens if no-one who remains on this
> mailing list has any clue what the issue with these error
> codes is? Is Alan still on the list? In that case, I would be
> inclined to "fix" things how I see fit, on the assumption
> that these codes will hardly ever be used and the values
> should never be used explicitly, and it would make sense to
> make them consistent rather than unparseable. I will take
> silence to indicate that no-one cares and/or knows what to do]
Tim,
I can explain how the error codes are used and can surmise why PGP and GRERR
are not using this system. The whole system is based on the VAX/VMS system
of a 32 bit integer error code which was bit-masked to extract a "facility
code", a "severity code" (0-3 I think for Informative, Warn, Error and
Fatal)- this isn't used on the Unix systems at all, and an "error number".
This was reported to the user in Vax days in the form of:-
RMS-F-EOF, end of file
Facility is (RMS), short error code (EOF) and the associated text of "end of
file" were located in some binary format file somewhere I think. It was
possible for users to add their own error codes by putting a text file
through some equivalent of MESSGEN.
On the Unix system the exact same format of numeric error codes are created
by messgen and then used in all Starlink software using inherited STATUS.
Eventually these Integer numbers will be unpacked again to report errors.
The model I used was that the numeric "facility code" is used to look for a
file called fac_<facility code>_err in /star/help. The numeric "error code"
is further used to extract the short-form error name (EOF) in my example
above and the long-form text from within this (text) file.
DTASK will report the final task exit status based on this scheme while
ERR/EMS can also obtain these text strings from a running program.
PGP and some other software were always outside the inherited STATUS scheme
and have obviously been left with their existing error scheme. In these
cases the subsystem itself would have its own means of indicating an error
and normally a subroutine/function call to get at the assocated text of what
had gone wrong.
Does this help?
Brian
----------------------------------------------------------------------
Brian McIlwrath, e-mail: [log in to unmask]
Astrogrid/Starlink, Tel: +44 (0)1235 446254
Space Science & Technology Department, Fax: +44 (0)1235 446362
Rutherford Appleton Laboratory, UK.
----------------------------------------------------------------------
|