Hi Brian and Walter :)
Brian covered the answers pretty well ... :) I have a quick alibi on
Question #5 tho... I believe Don Knuth did publish some info on
Searching techniques (theoretical) that covered Threaded Binary Trees
but it could have been in another text from college (I am at the office
and the text books are at home :( ) Maybe Rich or Chip remember??
Art "we all know about MY memory!! Hehe " Bahrs
Art Bahrs, CISSP
Security Engineer
Providence Health & Services
[log in to unmask]
Phone: 503-216-2722
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Brian Donaldson
Sent: Monday, September 29, 2008 11:25 AM
To: [log in to unmask]
Subject: Re: TurboIMAGE B-Tree indices
I have implemented B-Tree indices on all the databases I have created
and I can give you some info based upon my experience. Maybe it will
help you, maybe not.
1) Does IMAGE do a good job of reliably keeping the index in sync?
Haven't had any problems so far
2) Is there ever a need to rebuild an index?
As with Omnidex and Superdex if indices get trashed/lost the only
way
to recover them is to rebuild them. These indices would be rebuilt
via
DBUTIL /ADDI. The time to do this can be quite significant based
upon
the caps/entry counts on your datasets.
3) I read that DBSTORE doesn't know about the index files (but then who
uses DBSTORE anyway?). Does everything else work O.K.?
I never use DBSTORE to store TurboIMAGE databases. It is antiquated
and buggy. It updates the date/time stamp in the root file prior to
the
DBSTORE completing its task. I use the :STORE command always.
4) Will I get any nasty surprises relative to performance?
I haven't seen any problems so far.
5) Are there any tutorials on B-Tree indices that would be worth
reading?
The TurboIMAGE reference manual is the only one I know of.
6) Does QUERY know anything about or take advantage of B-Tree indices?
Never used QUERY, I always use Suprtool.
7) I think I found one documentation error. The manual says that IMAGE
uses KSAM XL files for the indexes, but it looks to me like it's
using
KSAM64. Are there other documentation errors I should know about?
No idea.
I used this indexing on
However, if you try to do Omnidex/Superdex type of lookups (DBFIND modes
<> 1) you may/will encounter problems finding items. Lookup example:
Lookup the value: SMITH will be retrieved ok
Lookup the value "JONES-SMITH will *NOT* be retrieved
HTH,
Brian Donaldson.
On Sun, 28 Sep 2008 20:01:44 -0700, Walter J. Murray
<[log in to unmask]>
wrote:
>Greetings,
>
>Being on the cutting edge of HP-3000 technology here at the Department
>of Corrections, we are looking into this new-fangled thing in
TurboIMAGE
>called B-Tree indices. :-)
>
>I've read the chapter in the IMAGE manual, and it all seems well
>documented and straightforward. What surprises might we encounter when
>we start using this feature?
>
>Some specific questions:
>
>* Does IMAGE do a good job of reliably keeping the index in sync? Is
>there ever a need to rebuild an index?
>
>* I read that DBSTORE doesn't know about the index files (but then who
>uses DBSTORE anyway?). Does everything else work O.K.?
>
>* Will I get any nasty surprises relative to performance?
>
>* Are there any tutorials on B-Tree indices that would be worth
>reading?
>
>* Are there any gotchas with B-Tree indices in DBGENERAL or ADAGER?
>
>* Does QUERY know anything about or take advantage of B-Tree indices?
>
>* I think I found one documentation error. The manual says that IMAGE
>uses KSAM XL files for the indexes, but it looks to me like it's using
>KSAM64. Are there other documentation errors I should know about?
>
>If B-Tree indexes (I hate writing "indices" in this context!) work
well,
>they might provide a perfect way to implement something I'm working on
>right now.
>
>Thanks for any helpful suggestions.
>
>Walter
>
>Walter J. Murray
>
>* 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 *
DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
