Re: Record locking and CPF5027

On 01-Oct-2015 08:04 -0600, Jim Franz wrote:

V7r1
We have a batch process that updates and adds to a file.
It halted with CPF5027 with options C & I - and then "C" was
processed by QMHCHGEM

The message is of the type "Notify" for which the program was notified of the condition; something the coder of the HLL has no control, because the RPG Run-Time is what is notified. The RPG Run-Time responds appropriately to the Canceled condition, and the condition was appropriately canceled; if ignored, the RPG runtime is left unaware of the condition, and the compiled HLL program would not perform appropriately, so the Default Reply (DFT) for the msg CPF5027 must remain C=Cancel for programs to function properly.

In other posts there is discussion of this happening when code in a
sub-procedure, but this is an older RPGLE, no procedures, just a
block of mainline code.

Processing for the locked record is identical no matter where the failing I/O is coded.

The text of the messages says "561117/TRICHEMA/VPN7714A was not
waiting on a lock held by this job" which I don't understand.

IOW, the request was not an effective deadlock awaiting timeout by one of the parties.

The other job had no halt, and it is a similar old RPGLE with no
procedures. We can see where it would sit on a screen with a record
open for update.

Likely then, that other job was responsible for the long-held lock; held long enough, that the Maximum Record Wait Time (WAITREC) setting that was established [or overridden] for the file referenced in the failing job, was exceeded.

The first job below is a batch job was most likely attempting an
update (but not sure, there is a possible write to the file, we got
no dump option).

Statement 2240 of PDSCVT01 would reveal what [most likely an UPDAT or READ for update] was requested.

There is no system reply entry for CPF5027 or RNX1218

The former is not [sent as] an inquiry message, to the System Reply List does not play any role. The message is used only as a Notify message.

Batch job run from AJS (advanced scheduler) and no default replies
setup (that I can find).

RNX1218 does not appear to be an inquiry message; just a run-time failure. RPG uses the RNQ prefix for inquiries, and the msg RNQ1218 "Unable to allocate a record in file &7 (R C G D F)." seems to be the corresponding inquiry message. IIRC the I/O must be unmonitored for the RPG run-time handler to be invoked, for which the inquiry is sent; the failing I/O may be in a MONITOR block?

We have other jobs similar to this where we get a LCKW for the batch
job, and we normally get a retry option.
These are jobs the run many times a day (both the batch job and the
interactive maintenance)
Need to understand why this one time no retry...


CPF5027 Sender copy 30 09/30/15 18:01:11.127910
QDBSIGEX QSYS 0252 QDBSIGEX QSYS 0252
Message . : Record 337758 in use by job 561117/TRICHEMA/VPN7714A.
Cause . . : You cannot get record number 337758 record format
EMPLYR member number 1 in member EMPLYRL1 file EMPLYRL1 in library
KRMDATA because record number 337758 is being used by job
561117/TRICHEMA/VPN7714A. The error code is 2. If the error code is
1, then this error occurred when record number 337758 was locked by
job 561117/TRICHEMA/VPN7714A which was waiting on a lock held by
this job. If the error code is 2, then job 561117/TRICHEMA/VPN7714A
was not waiting on a lock held by this job.
Recovery : Try your request again when record number 337758 is
available. Possible choices for replying to message . . :
C-- The request is canceled. I -- The request is ignored.
CPF5027 Notify 30 09/30/15 18:01:11.127917
QDBSIGEX QSYS 0252 PDSCVT01 KRMMOD *STM
To module . . . . : PDSCVT01
To procedure . . : PDSCVT01
Statement . . . . : 2240
Message . : Record 337758 in use by job 561117/TRICHEMA/VPN7714A.
Cause . . : You cannot get record number 337758 record format
EMPLYR member number 1 in member EMPLYRL1 file EMPLYRL1 in library
KRMDATA because record number 337758 is being used by job
561117/TRICHEMA/VPN7714A. The error code is 2. If the error code is
1, then this error occurred when record number 337758 was locked by
job 561117/TRICHEMA/VPN7714A which was waiting on a lock held by
this job. If the error code is 2, then job 561117/TRICHEMA/VPN7714A
was not waiting on a lock held by this job.
Recovery : Try your request again when record number 337758 is
available. Possible choices for replying to message . . . . . . . . . . . .
: C -- The request is canceled. I -- The request is ignored.
*NONE Reply 09/30/15 18:01:11.132652
QMHCHGEM QSYS 0146 PDSCVT01 KRMMOD *STMT
To module . . . . : PDSCVT01
To procedure . . : PDSCVT01
Statement . . . . : 2240
Message . : C
*NONE Reply 09/30/15 18:01:11.132664
QMHCHGEM QSYS 0146 QDBSIGEX QSYS 0252
Message . : C
RNX1218 Escape 99 09/30/15 18:01:11.132717
QRNXIE QSYS *STMT PDSCVT01 KRMMOD *STMT
From module . . . : QRNXMSG

For lack of the inquiry following the 1218 error, I suspect there is either a cancel handler or a monitor coded in the HLL program; i.e. the programmer has decided to take responsibility instead of allowing RPG run-time to decide how to handle error(s) [at that point in the code]. If there had been an inquiry, irrespective the Inquiry Message Reply Handling (INQMSGRPY) established for the job, the above joblog snippet should have continued to include the details of the reply processing for the inquiry messaging.