I have a file created by SMURF with a huge number of extensions
representing iterations of the map-maker (900 to be exact!) The problem is
using an rsync of 32-bit starlink from the JAC:

rsync -avz --delete --exclude=local --exclude=lost+found star/

Checking the time stamps on bin/smurf it looks pretty recent:

-rwxr-xr-x 1 echapin users   16993 Jun  2 06:17 jcmtstate2cat

I find that SMURF:STACKFRAMES, and even KAPPA:NDFCOPY all fail to open even
one of the extensions, e.g.

[echapin@xmmwl6 data]$ ndfcopy
m17_bright_extended_half2_600.more.smurf.itermaps.CH00I001 map1
!!   Cannot access
!    Please give a new value for parameter IN

However, HDSTRACE lists all 900 of them (e.g. hdstrace
m17_bright_extended_half2_600.more.smurf.itermaps), and I can even HCOPY
them out:

hcopy m17_bright_extended_half2_600.more.smurf.itermaps.CH00I600 map600

Gaia also works, i.e. gaia
m17_bright_extended_half2_600.more.smurf.itermaps.CH00I900 loads up the
full set of 900 extensions in the selector window, and plots the 900th for

This is a huge file (7 gigs or so), but I can put it somewhere if needed.
Presumably it would be easy to make a test file locally with a large number
of (small!) extensions to test this out.

I have another file with 108 extensions and don't have any problem (so the
magic number is between 109 and 900...).

I also have a bleeding-edge 64-bit build, and it does not exhibit this


Starlink User Support list
For list configuration, including subscribing to and unsubscribing from the list, see