Ken has been kind enough to point out the following:

>
> I'm going to go out on a limb here, and correct one word that
> Craig used in his above:   He said ".... the Image team MAY
> make use of large files.... ".
...
> what Craig *meant* to say was something like:    ".... the Image
> team WILL make use of large files as the underlying technology
> behind their large databases sometime soon, .... ".       ;-)
>

Cool! I was able to verify that Ken is correct. Another case of the HP3000-L
(oh dear! do we need to rename it now? Maybe just an HPe3000-L alias? :-) )
bringing enlightenment to its members - even those inside CSY!

...
> Correct....   But one thing worth noting:  Since sorting records is
> essentially an exponential of the number of records involved, if
> you try and sort 70GB of data from an IMAGE Detail in a large
> MPE flat file you might be able to go out and have dinner while
> you are waiting for it to finish....   several times....
>

Oh fun! I actually opened up one of my college CS books - after dusting it
first, of course. The algorithmic complexity of a sorting algorithm depends
on the data being sorted. The average case for reasonable algorithms, like
the one used by SORT.PUB.SYS, is to complete the sort in O(n log n) time. Of
course this only addresses the computational complexity. Other factors such
as I/O performance, memory size and so on would affect the real life results
- usually even more so than the actual CPU time. Your point is still well
taken that when you're dealing with massive quantities of data, it'll take
some time to get through it all.

Take Care,
Craig