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
midrange.com
