Tim
we certainly cannot assume Alan is around.
Go for it!
...David
-----Original Message-----
From: Tim Jenness
To: [log in to unmask]
Sent: 24/03/2004 23:29
Subject: Re: PGP_ERR
[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
|