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.