AFAIK, record lock failure will not cause the file pointer to get lost.
Correct, I do not want my RPG program to see any uncommitted record at all.
During testing of my program, I'm getting record lock error, which surprised
me because this is a work file, there is no program, other than mine,
accesses it for update. All other program simply perform output only.
After some research, I found out that the record lock was caused by
uncommitted record.
"Charles Wilt" <charles.wilt@xxxxxxxxx> wrote in message
news:mailman.6078.1286551110.2702.rpg400-l@xxxxxxxxxxxxxxx
On Fri, Oct 8, 2010 at 9:06 AM, hockchai Lim
<lim.hock-chai@xxxxxxxxxxxxxxx> wrote:
The file is actually open for updated. My program gets a record lock error
on the record that has not been commited by another job.
That's how it's supposed to work
I've tried what
you suggested below and it didn't work for me.
I changed my program to do (Just wonder if there is a better way than
below):
read(e) MYFILE;
if %status() = @locked;
read(n) MYFILE; // use read with no lock extender to skip the
uncommitted record.
endif;
I'm a little surprised this is working, hopefully Scott, Jon, Barbara
will jump in with a better reply but according to the manual..
"If a READ operation is successful, the file is positioned at the next
record that satisfies the read. If there is an error or an end of file
condition, you must reposition the file (using a CHAIN, SETLL, or
SETGT operation)."
I guess I'm a little confused...your original message seemed to
indicate the you wanted your RPG program isolated from uncommited
transactions like SQL's WITH *CS/*UR/*RR. But from your reply, it
seems your looking more for an RPG equivalent to SQL's SKIP LOCKED
DATA clause which was added at 6.1.
I honestly don't know how to do that....which is something of a
surprise to me :)...it seems as if a failed read isn't leaving the
file pointer in limbo as the manual implies. That being the case,
what you're doing is the only thing I can think of to do.
HTH,
Charles
Charles
midrange.com
