RE: RPGLE SETLL / READE for update getting record lock on different key (private reply) -- RPG400-L

Here's a thought.
When you do a READE, the next not equal is actually read, but not used.
So the lock would remain on that record.
In a single threaded environment, this would have no impact.
But in multi-threaded environment it would.

Paul

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mohammad Tanveer
Sent: Friday, October 26, 2018 11:00 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: RPGLE SETLL / READE for update getting record lock on different key (private reply)

You question is valid about wait but its the blessing of legacy code which
has been working for 20 years in a single thread :) we just broke it with
multi threading it...

Program sometimes keep the record lock over 60 seconds for some complex
logic and SOUNDEX like multiple searches on a table which has millions of
records and no body wants to touch it.. as this logic will be replaced in
future..

On Fri, Oct 26, 2018 at 9:48 AM Bradley Stone <bvstone@xxxxxxxxx> wrote:

My question would be why is the program making the read successfully
locking that record for so long.

Bradley V. Stone
www.bvstools.com
Need to interface with Braintree with your IBM i? Contact me
<https://www.bvstools.com/contact.html> for more information!

On Fri, Oct 26, 2018 at 9:37 AM Mohammad Tanveer <surgum@xxxxxxxxx> wrote:

Thanks Mark.. what you said make sense... kind of strange though.. After
reading your note I did some google for READE and it does sounds like

what

you said is correct :)

NoteIf a file is defined as update and the N operation extender is not
specified, occasionally a READE operation will be forced to wait for a
temporary record lock for a record whose key value does not match the
search argument. Once the temporary lock has been obtained, if the key
value does not match the search argument, the temporary lock is released.

In most cases, RPG can perform READE by using system support that does

not

require obtaining a temporary record lock to determine whether there is a
matching record. However, in other cases, RPG cannot use this support,

and

must request the next record before it can determine whether the record
matches the READE request.
Some of the reasons that would require RPG to obtain a temporary lock on
the next record for a READE operation are:

- the key of the current record is not the same as the search argument
- the current record is not the same as the requested record
- there are null-capable fields in the file
- ALWNULL(*USRCTL) was specified for the module
- the file has end-of-file delay

On Fri, Oct 26, 2018 at 9:22 AM Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Mohammad:
* (pr**ivate reply)*

Read very carefully the description of READE vs. READ in the RPG manual

...

Chances are very good that READE does *not* do what you *bel**ieve* it
does. READE does a READ and *then* compares the key for "equal" and

if

not equal, it does another READ ... *(lather**, r**inse**, repeat...)*

So,

these implicit READs can and will read the same records that are

already

locked by other jobs and will "hang" waiting on the lock. =-O

Rather than SETLL / READE try using CHAIN instead ...

Hope that helps ...

Mark S Waterbury

On 10/26/2018 9:21 AM, Mohammad Tanveer wrote:

I have 4 async jobs running, reading data from a data que and calling

same

program A with order number.

JOB1 --> Read Data Que --> Call Program A to read File X and update for

the

order#
JOB2 --> Read Data Que --> Call Program A to read File X and update for

the

order#
JOB3 --> Read Data Que --> Call Program A to read File X and update for

the

order#
JOB4 --> Read Data Que --> Call Program A to read File X and update for

the

order#

Order File X:
RRN ( X ) Primary Key Order number

3,561,503 55,008,465 19,083,706
3,561,505 55,008,467 19,083,707
3,561,507 55,008,469 19,083,708
3,561,509 55,008,471 19,083,709

Program A --> Does SETLL and READE on a conditional logical file using
order# as the key field.

- JOB1 processed order# 19,083,706 and giving MSGW record in use

for

RRN(X) 3561509
- JOB2 processed order# 19,083,709 and kept the lock on RRN(X)

3561509

for over 60 seconds
- JOB3 processed order# 19,083,707 and giving MSGW record in use

for

RRN(X) 3561509
- JOB4 processed order# 19,083,708 and giving MSGW record in

use

for RRN(X) 3561509

Is there a bug in READE that for some reason its trying to read/lock a
record for a different key or I say next record? logic is simple

order#

setll , order# reade.. When we get MSGW we just do a RETRY and all

works

fine.

I noticed that someone had a similar issue but there is no clear answer

of

this behaviour of READE.

article >>>>>>>>

https://itknowledgeexchange.techtarget.com/itanswers/rpgle-setll-reade-for-update-getting-record-lock-on-different-keying/

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

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