Brian Donaldson wrote:

> Friedrich:
>
> If, as you stated, the run time has significantly increased to process the
> SAME amount of data then the problem is NOT TurboIMAGE but something else
> going on you don't know about.... (yet)....

This is not necessarily so. In the case of non-hashing keys TurboIMAGE
performance may be fine until the key wraps around to reach a contiguous
stretch of previously used locations at which point the performance drops
considerably as each new addition involves a long serial read through the
dataset to look for the next available spot to place the new entry.

This situation sounds like it is exhibiting the classic symptoms.

<snip>

> HOWMESSY, however, is very general, vague and does not give you info
> regarding the offending entries causing the problem(s). It will just give
> you a percentage of synonyms in a particular data set, e.g. SET-A has 23%
> synonyms... Not very helpful if you want to find out the offending
> entry(ies) that caused the collision in the first place.
>

If it is a case of integer keys (particular if the keys are being generated
in numerical order such as an order-number) then the presence of even a
small percentage of synonyms could be indicative of a problem.


> 2nd for example:
>
> data-set-a (master), key item = data-item-a
> data-type= X4, key-value="ABCD"
>
> Hashes to Image record 1234. Record 1234 already occupied by key
> value "XXYY". So then Image has to go find a slot to place key
> value "ABCD".
>
> With each DBPUT this hashing/collision nightmare could slow you down
> immensely.
>
>
> If TurboIMAGE *is* your problem you can try changing the capacity(ies) on
> your offending automatic and manual master data sets.
>
> Integer keys on master sets work fine if the key value is between 1 and
the
> capacity of the data set.
> When a key value is > the capacity then watch out(!) -- the synonym
problem
> will bite you. Generally speaking, "X" type key items (search items in
> detail sets) work best.
>
> If your app uses integer keys you cannot just change the data types of
these
> keys without having to modify every piece of source code that manipulates
> these data sets. Then you have to recompile the entire application(!) Not
> exactly the optimum solution.
>
> If you determine that TurboIMAGE *is* your problem I suggest you go
straight
> to the big guns for assistance and call the gurus at Adager.
>
> Those guys will be able to help you best, I'm sure of it.
>
> Sorry I haven't been much help. Maybe you can give us more forensic
evidence
> before sending TurboIMAGE to the green room for execution.
>
>
> Brian Donaldson.
>
> On Wed, 22 Sep 2004 09:02:47 -0500, Friedrich Harasleben
> <[log in to unmask]> wrote:
>
> > Hello Image Gurus
> >
> >I face a serious situation on our HP3000.
> >A batch job which used to run for about 30-45 minutes (stores data in an
> >image detail with about 3.200.000 entries) runs now 4 hours and longer
> >to handle the same amount of data.
> >
> >I did a rough look with FLEXIBASE but not real idea at the moment as
> >wath to look for?
> >Any suggestion highly appreciated.
> >regards
> >Friedrich
> >
> >* 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 *

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