Travis writes:

> Thanks, Wirt for your input.
>
>  Here's the information on the set:
>
>  SET NAME:
>     NDC,AUTOMATIC
>
>        ITEMS:
>           NDC,                  X12           <<KEY ITEM>>
>
>        CAPACITY: 200003          ENTRIES: 170979
>
>
>  The values range from: "00002010102 " to "99999999999 "
>
>  Finds like these cause the behavior:
>
>  >Find NDC.NDC=00000000000
>  >Find NDC.NDC=00000000001
>  >Find NDC.NDC=00000000011
>  >Find NDC.NDC=00000000111
>
>
>  None of those values are in the dataset.

As I say, I don't know whether what I'm telling you is the source of your
problem or not, but your data is at least consistent with the general hypothesis.
Better yet, there is an easy way to test the idea.

First, measure the time it takes to perform a

     >Find NDC.NDC=00000000001

as everything is now. Actually, do that five times to get an average. A
single run on a busy machine can be deceptive.

Once done, then enter a value of

   NDC.NDC=00000000000

into the dataset in order to establish a lower bound that is not a null
entry.

Now run the find above again five times. If you see a dramatic acceleration
in the return times, it will be because the b-tree is not running through every
unspecified null leaf in searching out your value.

If this proves to be true, I can't see that's there very much that you can do
to fix the problem at your end other than inserting a pseudovalue that will
establish a lower bound for your searches, thus making sure that looking for a
value such as

     >Find NDC.NDC=00000000111

will be constrained between the two real values (0000000000; your false lower
bound) and your true minimum (00002010102). The b-tree algorithm will quickly
deduce that there are no values in between these two limits.

Wirt Atmar

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