20010218: McIDAS question about AREA and DIRFILE (cont.)

>From: 10 <address@hidden>
>Organization: NMSU/NSBF
>Keywords: 200102182128.f1ILSbL25380 McIDAS ADDE named datasets IMGCOPY

Robert,

>Well, of course what I wanted to do was save several hundreds
>of images..so that trick won't work.  I'll ponder on it a bit..
>I can't get around the AREA9999 limit can I?

At one point I thought that the number of AREA files had been increased
from 9999 to 999999.  This would mean that the AREA file naming would
be:

AREAnnnn
AREnnnnn
ARnnnnnn

I don't know if this really happened or not, but you might want to play
with it.

>From address@hidden Sun Feb 18 16:19:15 2001

>Duh...The 9999 limit is per dataset isn't it?

If it still exists, yes.

>Not total as long
>as the REDIRECT points to a different directory that AREA #'s
>with the same number.  Aargh...

I agree Aargh!

Let me know what you find out about the ARnnnnnn possibility.  The way
I would do this is by upping the range of AREA file numbers in the
beg end portion of a DSSERVE:

DSSERVE ADD TEST/IMAGES AREA 1 999999 ...

Tom

>From: 10 <address@hidden>
>Subject: 20010218: 20010218: McIDAS question about AREA and DIRFILE (cont.)

Robert,

>Answer:
>
>DSSERVE: Invalid Ending file number.
>DSSERVE: 5th positional argument is too big --> 999999
>DSSERVE: Must be valid integer value within range 1 thru 9999.
>DSSERVE:

OK.  The "funny" thing is that when you do a DSSERVE command
and use DIRFILE for an image dataset that does not use AREAs (name or
format), then the R1 and R2 entries in RESOLV.SRV get set to 1 and
999999 respectively.  Looks like that is some thinking towards
expanding the AREA file naming in the future.

>So the way around this right now is to write it to MYDATA/IMAGES,
>where I can go 1-9999.  I have about 4GB available in that slice..
>enough for several days.

OK.