I strongly suspect the 20-MAY-2004 change made to rec1_unpack_hcb.c by
BKM. The history comment is "Do not attempt to unpack HCB for invalid HDS
files". The change causes an error status to be returned if the file is
not a valid HDS file, whereas before a success status was returned
(presumably with garbage HCB values). Without this change, the call to
rec_locate_hcb within rec_attach_file would return a good error status for
an invalid HDS file, thus causing the following checks on hcb->stamp and
hcb->version to be run. These would have detected that the file was not
an HDS file, reported an error, and called rec_close_file.

However, with the BKM change to rec1_unpack_hcb.c, the call to
rec_locate_hcb within rec_attach_file will return a bad error status,
causing the checks on hcb->stamp and hcb->version to be skipped, resulting
in the file not being closed.

I think my solution of adding an extra call to rec_close_file into
rec_attach_file is reasonable, since the intention of RFWS was obviously
that the file should be closed if no HCB info is available (as evidenced
by the presence of the other two rec_close_file calls).

David


On Mon, 18 Sep 2006, Peter W. Draper wrote:

> On Mon, 18 Sep 2006, David Berry wrote:
>
> > On Wed, 13 Sep 2006, Peter W. Draper wrote:
> >
> > > there's more to this problem that Mark identified than a simple setup
> > > issue. It seems that some ADAM tasks are no longer able to open the same
> > > FITS file for on-the-fly conversion more than once.
> > >
> > > Try this out (the ngc1275.fits file is in $GAIA_DIR/demodata.tar, not that
> > > that matters):
> > >
> > > ---------------------------------------------------------------------------
> > > % icl
> > > ICL> kappa
> > > blah...
> > > ICL> stats ../../demodata/ngc1275.fits
> > > Loading /export/pwda/pdraper/starlink_cvs/build/bin/kappa/kappa_mon into kappa_mon16454 (attached)
> > >
> > >    Pixel statistics for the NDF structure
> > >
> > >    and so on...
> > >
> > > ICL> stats
> > > NDF - Data structure to analyse /@../../demodata/ngc1275.fits/ >
> > > !!   Cannot access ../../demodata/ngc1275.fits
> > > !    Please give a new value for parameter NDF
> > > !
> > > NDF - Data structure to analyse /@../../demodata/ngc1275.fits/ > !
> > > !! A null group of NDFs was given for parameter NDF.
> > > !  STATS: Error computing simple statistics for an NDF's pixels.
> > > OBEYW unexpected status returned from task "kappa_mon16454", action -
> > > "STATS"
> > > ADAMERR  %PAR, Null parameter value
> > >
> > > ----------------------------------------------------------------------------
> >
> > As far as I can tell this is an HDS problem rather than ARY or NDF.
> > Backtracking to earlier versions of ARY/NDF does not fix it. Chasing the
> > bug through HDS points the finger at rec_attach_file.c. When running
> > STATS, it is initially called in an attempt to open the fits file
> > directly, and correctly fails. However, the second time STATS is called,
> > rec_attach_file is again called to open the fits file directly and this
> > time it fails to report an error, leading to all sorts of subsequent
> > problems. This seems to be because the file is not closed after the
> > first invocation of rec_attach_file discovers that it is not an HDS
> > file. Consequently, the second call to rec_attach_file finds the file
> > already open, and assumes it is a legal HDS file.
> >
> > I've modified rec_attach_file so that the file is closed if it is found
> > not to be an HDS file. This fixes the problem.
>
> Hi David,
>
> thanks that seems to work for me too. Sorry this took you into the depths
> of HDS, but you're right about how old this one is. Back-tracking to the
> HDS64 merge last year I see the problem is still present. This file gave
> us some problems around then, with the call to rec1_open_file suddenly
> returning invalid slot numbers, that I patched (note removing that patch
> doesn't fix this problem). Clearly something has changed we still don't
> understand.
>
> Cheers,
>
> Peter.
>