× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I’ve used a lot of auto-gen ID fields for this sort of thing. It works
pretty well as long as you understand the rules

On Wed, 26 Sep 2018 at 19:55, T. Adair <tadair@xxxxxxxxxxxxxxxx> wrote:

We are currently using RPG to do this. And we are using the
read-increment-update method, very tightly written. This works fine
99.9999% of the time. But last week we had the situation described in
the OP.

PGM A (batch) PGM B (interactive)
------------- -------------------
Reads record - (simultaneously) - Reads same record
Increments number
Updates record
Reads record Increments number
Increments number
Updates record
Updates record *

* with a number that has already been used by PGM A

No matter how tight we write the logic, there's still going to be a
miniscule window where this can happen. It may be only 1/1000 of a
second, but IT IS THERE. And it will eventually happen, like it did
last week. We have hundreds of programs accessing this file, and dozens
that update this control number record, on each system, and we have 18
systems (all 7.2). Sooner or later, it will happen.

I need something to lock the record so that nothing else can even read
it. You see how locking for update (which we do) does not help in this
situation.

Thanks for trying.

~TA~



On 9/26/2018 12:28 PM, Greg Wilburn wrote:
We have exactly the same thing.

If you use RPG instead of SQL, it will lock the record.

Can you change the logic in both processes to read-increment-update and
not move on to any other logic? If both processes are reading for update,
the second one there should go to LCKW during the read until the first
finishes the update, right?

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.