[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]

Just had a look at GRERR and PGP_ERR. The early entries in GRERR parse
correctly, it's the last few that are weird:

*  Not a valid fill area style
      INTEGER GRILFS
      PARAMETER (GRILFS = 124 + IBASE)

*  PGPLOT Device is output only
      INTEGER GROUON
      PARAMETER (GROUON = 132 + IBASE)

*  PGPLOT Device does not have a keyboard
      INTEGER GRNOKE
      PARAMETER (GRNOKE = 140 + IBASE)

*  Error allocating dynamic memory
      INTEGER GRDYNE
      PARAMETER (GRDYNE = 148 + IBASE)

*  Append qualifier not supported
      INTEGER GRNOAP
      PARAMETER (GRNOAP = 156 + IBASE)

*  Unknown qualifier
      INTEGER GRUNKQ
      PARAMETER (GRUNKQ = 164 + IBASE)

These (and the ones in PGP_ERR) all have a severity of 6 which is not
valid at all. The early (valid) codes have a severity of 2 (Error) but the
message numbers clash. Are you allowed to have error codes that correspond
the same message number but with different severities? I don't see how
that can work given that the message number is written to the fac_xxx_err
file so that the text string can be located.

My current plan is to assume the severity=6 error codes are really
severity=4 [SEVERE] and add 100 to the message number. This will mean that
the 10 codes will no longer correspond to the same value as before but I
can't see this is a problem.

Tim


On Wed, 24 Mar 2004, Tim Jenness wrote:

>
> What's the deal with PGP_ERR (in GRAPHPAR)? The codes are simply not valid
> messgen codes at all. As they stand cremsg complains about an illegal
> severity error.  Subtracting 4 from all the codes fixes them and makes
> them compliant but then again I don't really understand how the severity
> maps to the final number. I also note that no facility error is installed
> for 1508 in the normal /star and so they will never get translated
> correctly either.
>
> Any objections if in the CVS version I "fix" the error codes and make sure
> the fac file gets installed? Or can someone explain why the codes are
> broken? Looking at GRERR things get confusing since 176 to 192 are used by
> GRERR but 172 to 196 are reserved for pgppar.
>
> The obvious thing to do is what SGS does, and that is to put the PGP
> ADAM error codes into the PGP error file itself (called grerr in PGP).
> Then we just install "grerr" as pgp_err with all the error codes and
> everything works. (does it really matter that the first few error codes
> will be "private"? At least we can work out how to trranslate them if they
> leak out).
>
>

--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj