It is possible that your online program is normally deleting/re-adding
your data item, only to have the batch program re-delete it (in this case,
the batch program may not know to re-add the data). Your programs may not
be at fault, simply running them at the same time may be the culprit.
Changing your locking strategy so that they aren't both hitting the same
data at the same time may solve your problem.

----------

In message <[log in to unmask]>, Friedrich
Harasleben <[log in to unmask]> writes
> Hi listers
>
>I need the help of the Image/Powerhouse gurus out there.
>
>We have a batch progam (Powerhouse) which updates a dataset twice a day
>(12:00 and 20:00). Its is a bulk update from a remote system with
>several thousand entries.
>
>During the last two weeks we had the following situation twice: an
>online program trying to update the same database too (trying to update
>a key item), ended up rigth in the middle of nowhere.

Has either the online of the batch program been changed recently?

Same database, but same or different datasets?
If same datasets, possibly the same records?

How do you mean, 'ended up right in the middle of nowhere'?
How did this appear to the user?
A hang? A blank screen where they expected data?
What, exactly?

>The update seemed
>to delete the entry but it could not add the new/updated entry.

How do you know this? (I'm sure you do, but how, exactly? Examination
afterwards with Query, or what?)

This update: is it an 'atomic'  CI DBUPDATE, or a DBDELETE and a DBPUT?

If the former, that's one for HP. But if the latter, well....

>But neither the batch nor the online program gave any error message.

No special reason that the batch program should give an error...

But that DBPUT. Do you test the return from it? What does the program do
if the DBPUT fails?

>Now where can I start to track down the problem?

With the answers to the above. Plus a few on locking....

What's the locking strategy of each program?

What's the lock/locks under which the DBDELETE and the DBPUT (If that's
what they are) take place? Base, Set, or Record?

Is it a 'clean' lock (record locked even before the DBGET that fetches
it) or a 'dirty' lock (do the DBGET, decide the Update is needed, only
then lock the record/set/base just prior to the Delete?)

Most cases I've seen where programs work on their own, but clash when
run together, are because the locking is inadequate, or 'dirty'.

Image locking guarantees that you can't update something that you don't
have sole write access to for the duration, and therefore that you can't
break the integrity of your database at the 'Image consistency' level,
but you have to ensure for yourself that your locking strategy will
protect it at the 'application consistency' level.

Regards



>The programs run more than 2 1/2 years without any problem.
>
>regards
>friedrich
>
>P.S. If someone needs more info I will provide them in a personal mail,
>to save bandwidth.
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  Wm Morris

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

**********
Posted from www.3kworld.com

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