×
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.
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?
midrange.com
