Hello Cathlene:

<<Image btree option: >>SET database name [/maintword] BTREEMODE1=ON>

Yes, my app was using the BTREEMODE1=ON with DBFIND mode4 to locate a
full or partial string entered by the user. Unfortunately, as I discovered,
the DBFIND mode4 only finds the record if the value entered by the user
matches the record in the data set at position one. I needed to be able to
locate the record regardless of where the string starts in the record (like
Omnindex or Superdex will do). So then I opted to create my own indexing
system using KSMAXL files as index files. It works fine. The initial load
time was slow, updating is slow also, but the retrieval time is very fast.
I can live with it. My app works and that is just fine with me.

Brian.
On Wed, 3 Nov 2004 12:58:03 -0500, Cathlene Mc Rae <[log in to unmask]>
wrote:

>Ksam Btrees
>
>All KSAM files use B-trees and that's the real penalty of a load
>or update, balancing those trees.
>
>XM Overhead
>
>Fcopying to a new KSAM 64 file avoids the XM overhead.  So to avoid
>XM overhead the customer must do the following;
>
>File myfile;REC=,,,,KSAM 64;,,etc
>Fcopy from=KSAM/XL;to=(*myfile);NEW
>
>Building a file and then copying to it does not avoid the XM overhead.
>The following would have XM overhead.
>
>Build myfile;REC=,,,;KSAM 64,,,,etc
>Fcopy from=KSAM/XL;to=(myfile)
>
>Use OPTMBLK (better performance?)  All this option would really do is
>more efficiently use disk space
>
>Image btree option:
>>SET database name [/maintword] BTREEMODE1=ON
>
>C.09.11 uses ksamxl for the btree indices, c.10 uses ksam64 (available on
>c.75.00).
>
>Best Regards
>Cathlene Mc Rae
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

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