This will be slanted toward QUERY and Superdex, although I presume it may
also affect other TPI products and possibly the forthcoming HP b-tree access.
 
Some months ago we went "live" with a Superdex index on one master dataset,
adding a b-tree type index to the existing master dataset key item.  To set
the scenario, the dataset was a course master in our student records system
and the purpose of the index was to provide handy access to all sections of
a course, or all courses in a department, etc., which wasn't previously
possible.  We had some programs doing sequential reads (!) to emulate this
access, and other smarter programs loading a table with record numbers to
do the same, but bottom line was b-tree type access was easier.
 
We were pleasantly surprised when Query responded in kind to generic key
access, finding the masters by values like "<term><department>@" to get
all courses in a given department.  Everything was wonderful.  Until...
 
We had a batch job that "cleans" out completed semesters from the active
database.  It bombed off when trying to find "old" courses by doing a
query FIND COURSE.NUMBER < term.  When this wasn't a TPI key field, but
just a master key, it worked fine.  And our existing programs that do this
type of search (doing it sequentially) continue to work fine.  But QUERY
fails, leading me to believe there's some "TPI awareness" built into QUERY.
 
Can someone elaborate on this a bit?  I'm rather confused, and the existing
documentation is rather vague with respect to TPI access.  Neither HP nor
the TPI vendor seems to elaborate on this much (though I admit I haven't
memorized the manuals).  Is there an easy way to differentiate the access
to the item to Query so that it does a serial read when necessary as
opposed to a DBFind on this TPI indexed master data item?
 
I specifically would like to hear the Superdex answer; but other TPIs and/or
HP's coming b-tree specs would be welcome too for the general readership.
 
Jeff Kell <[log in to unmask]>