RE: Record lock issue -- RPG400-L

If you want to get around this all the time you could do the READE with no lock, if you do not get eof on then CHAIN to the same record with a lock using a different filename, do your code and then UPDATE. If your updating every record read this can add a little overhead but if you only updating some of the records this will actually save overhead since you don't get journal entries for data that has not been updated.

READE with no lock
If not eof
If Logic to decide if record needs updated
CHAIN
Modify data
UPDATE
Endif
Endif

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Hockchai Lim
Sent: Wednesday, June 29, 2011 12:23 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Record lock issue

It is clearly noted in the RPG Reference manual (See below):
Note: Note: If 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: v the key of the current record is not the same as the search argument v the current record is not the same as the requested record v there are null-capable fields in the file v the file has end-of-file delay

"Schadd" <list@xxxxxxxxxxxxx> wrote in message news:mailman.1067.1309363835.5212.rpg400-l@xxxxxxxxxxxx...

If I make it not fail on the first READE (i.e. put in one record that
meets the criteria), it makes it into the loop and performs the second
READE. The second READE does not have a record lock issue. The only
reason I can come up with for this is that the database i/o handler
determines the number of records after the first read and knows that
there is not another to look for.

Thank you,
Schadd Gray
Damon Technologies, Inc.
www.damontech.com
-----Original Message-----
From: Hockchai Lim
Sent: 06/29/2011 10:44 AM Newsgroups: midrange.rpg400-l
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Record lock issue

huh? If it failed on the first reade, how does it ever get to the
second reade?

"Schadd" <list@xxxxxxxxxxxxx> wrote in message
news:mailman.1055.1309361803.5212.rpg400-l@xxxxxxxxxxxx...

Then why does it only fail on the READE following a SETLL. The
second READE will not fail on a record lock.

Thank you,
Schadd Gray
Damon Technologies, Inc.
www.damontech.com
-----Original Message-----
From: Hockchai Lim
Sent: 06/29/2011 10:13 AM Newsgroups: midrange.rpg400-l
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Record lock issue

Not an OS issue. RPG READE has always behavious like this.

READE will always read the next record and attempt to lock it first
before it checks if the record it has read matches the key. So, on
your example, it will attempt to read and lock 1133 first. After
that, it checks if the record it read matches the key. In this case,
it does not, %eof is then set on. (I wish RPG compiler team can so
how get this fix...)

"Schadd" <list@xxxxxxxxxxxxx> wrote in message
news:mailman.1038.1309358980.5212.rpg400-l@xxxxxxxxxxxx...
I have a very strange issue occurring. This is happening on V7R1 and
on V5R4. I have a program aborting on a record lock for a record it
should not be trying to access. I am assuming this is an OS issue,
however I thought I would check with the community before opening a
ticket. I am probably just having a senior moment or maybe it has
always been this way and I have just never ran into it before.

The first program chains to a file and locks the record.

FSrlMast01 UF E K Disk
D W_Cust S Like(SLCust#)
/Free
W_Cust = 1133;
Chain (W_Cust) SrlMast01;
If %Found(SrlMast01); //Stop the program here in debug to
cause
record lock
//Do something here
EndIf;
*Inlr = *On;
/End-Free

The second program does a SETLL and a READE to the file. The key
value does not exist in the file. If the key value exists in the
file, no record lock happens.

FSrlMast01 UF E K Disk
D W_Cust S Like(SLCust#)
/Free
W_Cust = 1131;
Setll (W_Cust) SrlMast01;
Reade (W_Cust) SrlMast01; //Record lock occurs here
Dow Not %Eof(SrlMast01);
//DO something here
Reade (W_Cust) SrlMast01;
EndDo;
*Inlr = *On;
/End-Free

Data:

SLCust#(Key) SLName SLAddr
1129 John Smith 111 Main
1130 John Doe 222 Main
1133 Jane Doe 555 W. 7th

Thank you,
Schadd Gray
Damon Technologies, Inc.
www.damontech.com

--
This is the RPG programming on the IBM i / System i (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.