Image: Re: TurboIMAGE B-Tree indices - Hewlett Packard

This is a discussion on Image: Re: TurboIMAGE B-Tree indices - Hewlett Packard ; If it can't find the value I am looking for *anywhere* in the string/search value lookup then it *is* flawed and isn't worth the time and effort of adding these keys to a TurboIMAGE database. Then, you also have to ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Image: Re: TurboIMAGE B-Tree indices

  1. Image: Re: TurboIMAGE B-Tree indices

    If it can't find the value I am looking for *anywhere* in the
    string/search value lookup then it *is* flawed and isn't worth the time and
    effort of adding these keys to a TurboIMAGE database. Then, you also
    have to take into account the time it takes to build the keys, rebuild the
    keys when they trashed/whacked and so on. Not worth the effort in my book..


    Better off spending the time and $$$ on something like Omnidex or Superdex
    that will find the record(s) with the value you are looking for. Of course,
    you are getting into the ludicrous expense of buying these TPI keys software...

    If I had the choice and $$$ was not an issue, I would buy Omindex from DISC.
    Lookup a string value such as "SMITH" will find it regardless of where the
    value is in the record.

    And no, I have absolutely no affiliation with DISC at all and I don't get
    paid by them for promoting their product.

    Ecometry sites use Omnidex and as far as I am concerned it is the only
    TPI key software to use.

    The B-tree indices are definitely *not* the way to go.

    As I stated in a previous posting on this topic, I got fed up with the
    B-tree indices not giving me what I totally wanted I ended up writing
    my own indexing app attached to the app I was writing. Works just like
    Omnidex without having to spend the ludicrous amount of $$$ for it.

    As far as Walter's original posting goes, B-Tree indices will fix his problem
    if he only wants to retrieve a key value that starts in position one of
    the string; if he wants to find a key value starting in position > 1 well,
    watch out...


    Brian Donaldson.


    On Mon, 29 Sep 2008 15:59:03 -0700, Steve Cooper wrote:

    >I would hardly call that "flawed". It works exactly as it is supposed
    >to work, and as it is documented to work. If it doesn't give you what
    >you are expecting 100% of the time, as you say, then I think your
    >expectations are flawed.
    >
    >Steve
    >
    >> -----Original Message-----
    >> From: HP-3000 Systems Discussion
    >> [mailto:HP3000-L@RAVEN.UTC.EDU] On Behalf Of Brian Donaldson
    >> Sent: Monday, September 29, 2008 3:53 PM
    >> To: HP3000-L@RAVEN.UTC.EDU
    >> Subject: Re: [HP3000-L] TurboIMAGE B-Tree indices
    >>
    >> We (gasp) don't us(e) Adager -- (even bigger gasp)
    >>
    >> How dare you not use Adager!?
    >>
    >> Anyway, I digress--
    >>
    >>
    >> The DBFIND with the wildcarding is flawed. It will not give
    >> you what you
    >> may be expecting 100% of the time.
    >>
    >>
    >> From my own experience of using these B-tree indices I can
    >> tell you this --
    >>
    >> Example: I want to find all the entries with the value "SMITH" in it.
    >>
    >> DBFIND will find those entries where "SMITH" starts in column one, but
    >> will not find those "SMITH" entries that do not start in
    >> column one, e.g.
    >>
    >> "SMITH-JONES" will be found but "JONES-SMITH" will not be found.
    >>
    >> It obviously doesn't do the same type of looking up as
    >> Omnidex and Superdex
    >> both do.
    >>
    >> I became so frustrated and disillusioned with it I ended up
    >> writing my own
    >> indexing sub whereby my DBFIND's will get me the "SMITH"
    >> value regardless
    >> of its position in the string.
    >>
    >>
    >> Brian Donaldson.
    >>
    >>
    >>
    >> On Mon, 29 Sep 2008 13:27:36 -0700, Dave Powell, MMfab
    >> wrote:
    >>
    >> >Query "knows". You can do things like
    >> >find my-indexed-key = "abc@"
    >> >on either a master or a detail set under it., and the

    >> results will be in
    >> >sorted order, better than what you might get with a find matching.
    >> >
    >> >Only trap I encounted was long enough ago so I don't

    >> remember exactly.....
    >> >One app that I *thought* was coded correctly gave incorrect

    >> results. IIRC, I
    >> >did a btree find on the master, read the results one at a

    >> time, and for each
    >> >master entry it got, I did an old-fashioned dbfind and read

    >> the entries in a
    >> >detail set under it. Then image losts its place somehow --

    >> I think it
    >> >reported end-of-chain when it should have read the 2nd

    >> master entry from the
    >> >wildcard dbfind. My fix was to move the find & read on the

    >> detail into a
    >> >subroutine with its own separate dbopen.
    >> >Short version, be careful of wildcard on masters and

    >> accessing detail under
    >> >those masters.
    >> >
    >> >No problems with performance or integrity. We (gasp) don't

    >> us Adager or
    >> >Dbgeneral.
    >> >
    >> >----- Original Message -----
    >> >From: "Walter J. Murray"
    >> >To:
    >> >Sent: Sunday, September 28, 2008 20:01
    >> >Subject: [HP3000-L] TurboIMAGE B-Tree indices
    >> >
    >> >
    >> >> 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: Image: Re: TurboIMAGE B-Tree indices

    I presume the site has had an HP3000 or HP3000s for a long time.

    Perhaps it is possible they have Omnidex or Superdex and may not know
    it?

    A "lost" implementation after personnel turnover perhaps?

    For Omnidex, check for a DISC account on the system.

    For Superdex, unsure, but probably in a BRADMARK account.

    Tracy Johnson
    Business Analyst
    Measurement Specialties, Inc.
    1000 Lucas Way
    Hampton, VA 23666
    Office 1-757-766-4318
    tracy.johnson@meas-spec.com
    www.meas-spec.com

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


  3. Re: Image: Re: TurboIMAGE B-Tree indices

    Hi All
    Also, a "quick" LISTF for any file with DISC in any part of the file,
    group or account name wouldn't be a wasted idea to let you know if there
    ever might have been a DISC installation/usage?

    Art "just a thot " 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 Johnson, Tracy
    Sent: Tuesday, September 30, 2008 6:53 AM
    To: HP3000-L@RAVEN.UTC.EDU
    Subject: Re: Image: Re: TurboIMAGE B-Tree indices

    I presume the site has had an HP3000 or HP3000s for a long time.

    Perhaps it is possible they have Omnidex or Superdex and may not know
    it?

    A "lost" implementation after personnel turnover perhaps?

    For Omnidex, check for a DISC account on the system.

    For Superdex, unsure, but probably in a BRADMARK account.

    Tracy Johnson
    Business Analyst
    Measurement Specialties, Inc.
    1000 Lucas Way
    Hampton, VA 23666
    Office 1-757-766-4318
    tracy.johnson@meas-spec.com
    www.meas-spec.com

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


  4. Re: Thanks: TurboIMAGE B-Tree indices

    Walter, after a DBFIND, check the value in the status array of the
    CHAIN-COUNT element(4th) for zero. If so, there are no records in that chain
    in the detail. I always do this to avoid an unnecessary DBGET and the
    associated disk I/O.


    ************************************************** *************
    CDR Paul Edwards USNR Ret. HP 3000 Certified Consultant
    Paul Edwards & Associates
    1506 Estates Way Phone: (972) 242-6660
    Carrollton TX 75006 Cel : (214) 384-8728
    Email: pedwards@gte.net Web : www.peassoc.com
    ************************************************** *************
    -----Original Message-----
    From: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU] On Behalf
    Of Walter J. Murray
    Sent: Sunday, October 12, 2008 3:53 PM
    To: HP3000-L@RAVEN.UTC.EDU
    Subject: [HP3000-L] Thanks: TurboIMAGE B-Tree indices

    Thanks to all who responded to my questions about TurboIMAGE B-Tree indices.
    I have been investigating them further, and the feature seems to work
    exactly as documented. There is a good chance I will use them in a project
    I am working on currently.

    The fact that partial key searches don't work on values like "@SMITH@"
    doesn't bother me. I never expected that they would.

    I have encountered only one performance-related surprise. As I thought
    about it, I understood the reason. I was traversing a super-chain in a
    detail data set that was associated with an automatic master.
    Occasionally, the mode-5 DBGET would take much longer than I expected to
    find the next entry. Then I realized that the master was linked to a number
    of other details, and there were big "gaps" in the key values, where there
    were entries in the master (and therefore in the index file) that had
    non-empty chains in the other detail data sets, but no corresponding entries
    in the detail data set that I was reading. IMAGE was doing a lot of work
    reading in logical sequence through the index file, and looking up the
    corresponding entries in the master, only to find empty chains in the detail
    of interest. So it was not a flaw with IMAGE--just a design consideration
    to be aware of.

    Thanks again to everyone who offered advice.

    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 *


  5. Re: Thanks: TurboIMAGE B-Tree indices

    Paul wrote:

    > Walter, after a DBFIND, check the value in the status array of the
    > CHAIN-COUNT element(4th) for zero. If so, there are no records in that


    > chain in the detail. I always do this to avoid an unnecessary DBGET

    and
    > the associated disk I/O.


    A couple of thoughts here.

    1. In the situation I was describing, I had done a high-speed (mode 24)
    B-Tree DBFIND, followed by a traversal of the super-chain. I don't
    think the technique Paul describes would apply in that case.

    2. In the case of a non-B-Tree DBFIND, yes, checking the chain count
    can help avoid an unnecessary call to DBGET. But I wonder whether that
    would actually avoid any disc I/O. Since the internally maintained
    forward (and backward) pointer would be zero, I would expect IMAGE to
    return immediately with an end-of-chain status, with no need for any
    disc I/O.

    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 *


+ Reply to Thread