<<There clearly is not the 'order of magnitude' of more space needed to
use a b-tree to index a detail for sorted-sequention access.  Overlooked
is the fact that with IMAGE, the b-tree simply provides the next master
key. From that master key is obtained the pointers to the corresponding
details.  These IMAGE pointer chains require 6 half-words for the master
and another 4 half-words for each detail entry.>>


Apples and oranges, I think.

This is only true when the item that is to receive the B-Tree index is
not already a search item in the detail set. I submit that the majority
of databases where we will be using the new sorted-sequential index
capabilities are configured such that the bulk of the newly-indexed items
are already search items. Obviously there will be cases where people will
create new automatic masters purely to get the SS-index capability, but I
think it will be a minority usage. Certainly for our databases here, the
existing 40-or-so automatic masters will probably not increase by more
than a half-dozen at the most. For detail sets with existing search items
that will now have SS-index capability, I reiterate that the alternative
of an Omindex/Superdex index directly on the detail set would require the
"orders of magnitude" more disk space than the B-Tree index on the
automatic master set.

As mentioned, someone who needs full-text indexing or something similar
should look at using one of the TPI products. In fact, if they "really,
really" need the capability, they are probably already using one of them.

Steve