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)....

Some suggestions:

Did anyone make program changes? change locking strategies in the
program -- locking data sets and/or data items and not DBUNLOCKing until
the program completes instead of DBUNLOCKing immediately after an update
DBPUT, DBDELETE,DBUPDATE) has completed... ?

If TurboIMAGE is the problem, based upon the info you supplied in your
posting, then you can investigate the possibilities of synonym entries in
your automatic and manual masters....

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.

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 *