On Thu, 25 Mar 2004, Norman Gray 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
> > [...]
> >
> > 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.
>
> I'm not sure I'm fully understanding the error code problem. Is it just
> that some libraries have had error codes added by hand, by someone who
> simply got them wrong, in the sense that the codes are illegal according
> to the EMS system?
>
> Could we not just then junk them, and create a new .msg file with the
> same error names and facility code? That _should_ be invisible to the
> application, since that's the whole point of the error codes and the
> include files. If this breaks the library, because it's using magic
> values rather than the error code names, then the library is simply
> broken and we just didn't know it, but it would bite us or someone else
> sooner or later.
>
> The same goes for the IDI__OK: it looks as if whoever added that error
> code just thought that 0 was a good-looking success status, but was
> otherwise well-behaved. If you grep through the Fortran it does appear
> that the status is explicitly tested against IDI__OK each time, rather
> than the magic value 0.
>
> If IDI is using codes without the IDI__ prefix, wouldn't that be
> fixable with a bit of sedding (OK, Tim, a line of Perl).
>
> Thus fixing the applications to use correct MESSGEN output seems a better
> strategy in the long run than adding features to messgen to accomodate
> badly behaved applications. I can see why CHR needs to have some extra
> codes added (presumably CHR__WRDNOTFND and CHR__WNOTF are both documented
> so we need the duplicate; though why do we need a magic CHR__ERROR?),
> but this seems a very special case.
Tim & Norman,
take my silence as I don't know much either (Brian is the remaining person
from the ADAM support group, so if he doesn't know, then we are stuffed),
but here's couple of comments anyway.
IDI is a funny package. This is deprecated as it only works for 8 bit
displays (it's now gone from KAPPA and CCDPACK) and was written to conform
to the standard:
http://ukads.nottingham.ac.uk/cgi-bin/nph-bib_query?bibcode=1988A%26AS...76..263T
The weirdness you see is just it trying to remain independent of the SSC
(hence it's own IDI__OK error code for non-UK facilities).
Re: PGP, peeking at GRERR, I'd say what's happened is that someone thought
that it has ran out of error codes, and has gone back to use values half
way between (filling in the *4 intervals). In fact I believe you can have
more (512 or 4096 looks about right). Try asking Dave Terrett, he wrote
PGP and may remember.
Cheers,
Peter.
|