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 starlink.jach.hawaii.edu::starlink.i386/ 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 m17_bright_extended_half2_600.more.smurf.itermaps.CH00I001
!    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 me.

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 problem


---- 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