Comments on: AS/400 Record Lock

By: philpl1jb

philpl1jb — Thu, 03 Jan 2013 03:40:27 +0000

Thanks Tom
I wasn’t aware of the
DSPJOB OPTION(*CMTCTL)
command. It’s exactly what I lacked in solving this issue.

Phil

By: TomLiotta

TomLiotta — Thu, 03 Jan 2013 00:36:14 +0000

The DSPJOB OPTION(*CMTCTL) option should show an indication when that happens. An unexpected commitment definition would be visible when that program started up. I don’t recall running under nested definitions before. It sounds like a potential mess when it’s not expected. — Tom

By: philpl1jb

philpl1jb — Wed, 02 Jan 2013 14:17:20 +0000

That’s got it .. thanks Tom
DSPPGM on the much earlier SQLRPGLE program has:

Commitment control . . . . . . . . . . . . . . : *CHG

Developer changed this program. removed sql call of stored procedure to an RPGLE program with appropriate code to do intended process and now subsequent commit processes perform to expectations.

By: TomLiotta

TomLiotta — Wed, 02 Jan 2013 04:31:14 +0000

Some of these cannot be open read locks.

It’s not clear what that means. Are there multiple files/records locked? Or is it that multiple programs read the record that is locked but most are simple reads?

I’d widen the journal tracking to include opens/closes. And I’d also verify that error reporting is happening for all locations that access the record. An error that is ‘handled’ but not logged could mislead any analysis.

Tom

By: TomLiotta

TomLiotta — Wed, 02 Jan 2013 00:50:10 +0000

For the SQLRPGLE program, what does DSPMOD DETAIL(*BASIC) show over the SQL module for ‘Commitment control’ in the ‘DB2/400 module attributes’ section? (Or look at the related program attributes.) — Tom

By: philpl1jb

philpl1jb — Wed, 02 Jan 2013 00:34:12 +0000

yes .. error occurs in a program after the commit and endcmtctlAll records and files remain locked after commit. 11 records in 5 files remain locked after the commit. Some of these cannot be open read locks.This happens when an SQLRPGLE program is run which contains an SQL command to run a stored procedure. The SQLRPGLE program does not have an Sql option commit = *NONE .. so I’m wondering if Commitment control started long before we expected it to start maybe at the activation group level.

By: TomLiotta

TomLiotta — Tue, 01 Jan 2013 06:49:58 +0000

Should I assume that “no error” means there is no error at the time of commit, but an error shows up at some later point when a record lock is reported? Again, I’m not aware that a commit will affect a record that is read-for-update but not actually updated. Any such lock should stay in place until something releases it. If it’s updated after the commit, it should be part of a different transaction requiring a different commit. — Tom

By: philpl1jb

philpl1jb — Tue, 01 Jan 2013 04:44:55 +0000

That’s the problem .. no error .. commit is issued but record locks don’t get unlocked and files continue to be locked. One difference in the flow is that before commitment control is started an SQLRPGLE program issues an SQL call is made to a stored procedure. Could there be two levels of Commitment control.

By: TomLiotta

TomLiotta — Mon, 31 Dec 2012 21:53:09 +0000

When it fails to commit ..

Is that the error? What exactly is the reported error? What is showing as the visible problem?

Tom

By: TomLiotta

TomLiotta — Mon, 31 Dec 2012 21:46:04 +0000

I assume by now that you know that the COMMITMENT_CONTROL_LOCK_LIMIT default is approx 500,000,000 for i 7.1. I didn’t look at earlier releases, but I suspect the values are also pretty high. — Tom