Tom writes:

> Aren't you forgetting basic IMAGE design criteria?  "SEQNUMBER" should
>  actually be declared as the last field (since it is a sort field)
>
>  Although it would signify a deeper problem, a situation where the SEQNUMBER
>  failed to increment per chunk would cause the "chunks" to be sorted based
on
>  the contents of the chunk -- highly unlikey you'll ever reconstruct it
again
>  (remember, for a sort key, if the "key" value is the same as another item,
>  the next and successive fields are used until the end of the set

If SEQNUMBER ever failed to increment, we'd simply have a badly designed
application -- and a lot more than sorting order would be screwed up.

As to where SEQNUMBER should be in the dataset, personally, I'm not that
picky. Because we can depend on SEQNUMBER being properly incremented (after
all, you have to have faith in something, God, Man or machine :-), and thus
properly sorted, the subsequent dataitems should never come into play in a
sorting decision.

To be absolutely honest, I'm not sure about the internal organization of the
IMAGE chain sorting code nowadays. I don't know if it sorts by only the
specified dataitem first -- and failing that -- sorts by the second, third,
fourth, etc. as discretely measured dataitems, taken one at a time from its
root file as miniature segments of the entire data record, or whether it just
grabs a pile of bits (of some maximum length) from the data record and sorts
on that. It's always been my strong prejudice that the first procedure is the
actual method used.

If that's the case, then the position of SEQNUMBER is basically irrelevant.

Wirt Atmar