Re: High level record lock

You're missing the point...

If you're using RPG RLA (CHAIN (or READ)/UPDATE)...

Then the record is locked unless your using the (N) extended to not lock.

The lock will be held till you do an UPDATE or another read...

Another RPG program will not be able to READ the record till the lock is
released.

Thus, what you are describing is not possible.

SQL is a different matter. If your SQL process is doing a SELECT INTO, it
will be able to read the record even if it's locked by another RPG program.

Your SQL process would need to be changed to use
DECLARE CURSOR
FETCH INTO
UPDATE WHERE CURRENT OF CURSOR

Now the SQL process will wait to read till the record is released.

Charles


On Wed, Sep 26, 2018 at 2:52 PM T. Adair <tadair@xxxxxxxxxxxxxxxx> wrote:

I realize that. I should have said "virtually simultaneously". Within
a honkosecond of each other.

And this is exactly why a high-level-record lock would be great. No
matter how small the time difference, the first pgm to read the record
needs to lock the entire universe out of it until it releases it. Then,
and only then, can someone else grab it.

Thanks.

~TA~



On 9/26/2018 3:26 PM, Charles Wilt wrote:

PGM A (batch) PGM B (interactive)
------------- -------------------
Reads record - (simultaneously) - Reads same record

Not possible with RPG RLA.... unless you are doing a READ(N) and not
locking the record...

Charles

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