Re: Record Lock under Commitment Control

On Wed, Feb 23, 2022 at 11:43 AM Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:

Thanks Steve. But this job has no SQL procedures, all programs are set to
*CALLER and the Scope of commitment control is *JOB. So as long as Program
A and Program B are both opening the file under commitment control,
shouldn't Program B be able to update the same record which was updated by
Program A, even though it is kept locked for other jobs or programs not
opening the file under the same commitment control?

yes, the same job can have progam A read and update a record. Then
progam B reads and updates the same record. Followed by a commit to commit
both updates. Until the commit is done, the record is locked to the job in
which program A and program B did the updates.

When you have the lock problem, run the WRKJOB command on the job that
cannot get the lock. Use option 12. work with locks. Then F10 display
record locks. Also use the DSPRCDLCK command.

I hear what you are saying about scope of commitment control is *JOB. I
gave up on that setting. Just made sure all my programs ran in same
activation group

Tracking down a lock under commitment control problem with the same job is
a bit of a challenge. The system does not show that the record is locked in
a separate activation group. I ended up stepping thru the code and would
run WRKJOB option 11 every step of the way to see the call stack. F11
shows the activation group. In my case, since all my code is
ACTGRP(*CALLER) the activation group always shows as *DFTACTGRP.

-Steve