Travis writes about a BTREE problem he's having on master datasets:

> No Serial read. It "freezes" for a while... several minutes. During this
>  time, CTRL-Break works. But even in break mode the process shows up in
>  Showq;active. If aborted, it still takes several minutes to abort.
>
>  If it runs to completion, it does eventually return with "0 ENTRIES
>  QUALIFIED".

I have no idea if this is going to be the source of your problem or not, but
KSAM b-trees (which are the form of b-tree actually used in IMAGE's BTREEs)
can generate a very similar behavior to what you're describing.

If you build a KSAM b-tree to be 100,000 records big, but then only populate
it with 1,000 records, the full tree of 100,000 leaves (the plural of leaf)
still exists -- it's just that 99,000 of the leaves are filled with null
results. If you then perform a search looking for all values smaller than a specified
value, the search begins at that specified value and works its way downward
through the tree, *including all 99,000 null leafs* -- and it seem to take
forever.

If on the other hand, you look for all values larger than a specified value,
the search begins at the specified value and proceeds upwards through the
tree. In this circumstance, it only has to look at most through 1000 leaves (but
generally less) and the results come back nearly instantly.

So, without having very much information about your specific circumstance, or
even much of an idea about how Stan implemented BTREEs on an IMAGE master,
are you accessing a massively oversized master dataset that's most empty and are
you performing a "less than" search?

If so, I would presume that your idle time is being spent in searching
through a large number of those held-in-reserve, null leaves at the bottom of the
b-tree.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *