Re: RPGLE SETLL / READE for update getting record lock on different key (private reply)

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