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


This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2019 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].