Re: TurboIMAGE B-Tree indices - Hewlett Packard

This is a discussion on Re: TurboIMAGE B-Tree indices - Hewlett Packard ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: TurboIMAGE B-Tree indices

  1. 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
    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 *


  2. Re: TurboIMAGE B-Tree indices

    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
    Arthur.Bahrs@Providence.org
    Phone: 503-216-2722

    -----Original Message-----
    From: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU] On
    Behalf Of Brian Donaldson
    Sent: Monday, September 29, 2008 11:25 AM
    To: HP3000-L@RAVEN.UTC.EDU
    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

    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 *


+ Reply to Thread