>> rm ~/adam/ndf2fits.sdf
> Any explanation, or pointers to documentation on this?
This is a frequently encountered problem usually caused when you break into a running task
with CTRL/C in the old VMS days and CTRL/Z on UNIX. The HDS file isn't closed properly
and upon accessing the file again HDS complains when all the ducks aren't in a row---the file
is corrupt. That's the DAT__INCHK, Integrity check.
While it can occur to any HDS file, the most usual victim is the parameter file, as happened to you.
If you're responding to prompts for parameters and want to exit cleanly, enter !! at a prompt.
Do not break in.
How do you know which HDS file is bad? The clue here is the
> ! Locator refers to an object 'OUT' which no longer exists (possible
> ! programming error or corrupted HDS container file).
OUT is the name of an NDF2FITS parameter. A parameter name can occasionally be an NDF
component too. Try HDSTRACE to see which fails. It should be easier than that. I thought we
had improved the parameter system to recommend the user remove a named parameter file, if
the parameter system encounters a DAT__INCHK.
Another one to watch for is the graphics database (usually ~/agi_<computer_name>.sdf). That's
another file which should be removed periodically.
There is advice in SUN/95 "Exiting an Application", some details about DA__INCHK in SUN/92.
I should add a new item into the SUN/95 "Problems, problems" section with DAT__INCHK in the
title so that findme will locate it quickly.
Don't get stuck for two days. There's a lot to learn in Starlink software and we can help. This
error is one we veterans immediately recognise.
Malcolm
via the JISCMail website
----
Starlink User Support list
For list configuration, including subscribing to and unsubscribing from the list, see
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STARLINK
|