Re: Retry for Record Lock in subprocedure...

On 31/05/2008, at 7:01 AM, Robert Rogerson wrote:

We recently had a record lock in one of or new program (which uses
subprocedures and no exception error handling) and the program ended.
(Normally as I was to learn after reading related parts from the Redbooks
Who Knew You Could Do That with RPG IV and RPG Exception and Error Handling
as well as checking this list's archives.

If it ended normally then something handled the exception.

From my understanding of what I have read once an exception is handled there

is no way to retry the failing statement. In OPM programs, when a record
lock was encounter a retry option was available to the operator.

Same thing happens with ILE:

Message ID . . . . . . : RNQ1218 Severity . . . . . . . : 99
Message type . . . . . : Inquiry
Date sent . . . . . . : 31/05/08 Time sent . . . . . . : 08:27:36

Message . . . . : Unable to allocate a record in file FILEA (R C G D F).

However, when the error occurs in a procedure (rather than mainline code) the exception is percolated up the call stack to the first control boundary. Because nothing in your code handles the RNQ1218 exception it is converted to a Function Check which is also percolated. If nothing in your code handles this then the OS default exception handler sends RNQ0202 indicating an error occurred in the procedure. The job log should look something like:

2>> call rcd_lock
Record 1 in use by job 781120/SHC/QPADEV0007.
? C
Record 1 in use by job 781120/SHC/QPADEV0007.
? C
Unable to allocate a record in file FILEA.
Function check. RNX1218 unmonitored by RCD_LOCK at statement 0000000015,
instruction X'0000'.
The call to READ ended in error (C G D F).
The call to READ ended in error (C G D F).

Much of
what I read in the archives suggested fixing the program which was causing
the lock in the first place but I could not find any information on how
others were handling the record lock scenario in the program attempting the
lock.

If a batch job attempts to read a record for update and that record is
locked is there any way to retry the read so that the program doesn't
continue on with the next record.

Yes, it's called error handling.

I have seen examples of messages issued stating that the record is locked
and what job is locking the record. So the user who locked the record
completes his job releasing the lock. How or can the batch job now attempt
to reread the record? From what I have read I don't believe so but I would
like some confirmation or advise.

Attempt the I/O:
READ(E) FILEA

Catch for the error:
IF %ERROR

Test for record lock:
IF %STATUS(FILEA) = 1218

(NOTE:- You would use a named constant instead of the 1218 magic value.)

Do something about it such as delay then retry the read. This would be a loop for N times as appropriate before giving up and complaining to the user about the record being locked. Use the other examples you found to extract the information about the job holding the lock and display a message (or window) to the user telling them who has the lock and let them worry about resolving it.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------