I've got a head-scratcher here. The following statement, in a CLLE program
that runs in batch...
RUNSQL SQL('Create Or Replace Sequence ARPROD/IQX004Hseq as bigint start
with 000000015982367 increment by 1 no cycle cache 10000000') COMMIT(*NONE)
... immediately issues CPF8351 "Commitment control already active" &
"Cause: A STRCMTCTL command was run to start commitment control for
commitment definition QDBAGILE when it was already active.", immediately
followed by CPF8361 "Cannot place resource under commitment control. Reason
code 4." RC4: "An attempt was made to place a resource under commitment
control, but commitment control was not active for the job-level commitment
definition nor the activation group in which the requesting program is
running.
Recovery: Start commitment control for the job-level commitment definition
or the activation-group-level commitment definition for which the
requesting program is running and retry the request." I mean, these two
errors seem to be in direct conflict with each other. The generic SQL9010
was issued after those messages.
Using the 'R'etry option on the error gave the same error. On a whim, I
issued the aforementioned RUNSQL statement interactively, and it completed
successfully, at which point, I responded to the error message with
'I'gnore. The job then completed normally.
I searched the v7r1 APAR database for CPF8351, and got exactly one hit (
https://www-01.ibm.com/support/docview.wss?uid=nas2SE55710). While the
abstract, error description, and problem summary seem to have no bearing on
our particular issue, the problem conclusion had an interesting statement:
"When certain operations run under COMMIT *NONE but we need the operation
to be atomic, we will create our own commitment definitions. In this case
called QDBAGILE. In certain cases where one operation occurs in an IASP and
a subsequent operation occurs in *SYSBAS, we did not detect that QDBAGILE
was already created and started. This resulted in CPF8351. We will now
check to see if QDBAGILE already exists and if so, use it." QDBAGILE was
mentioned in the CPF8351 error we got. The APAR identified the PTF to fix
this as SI50162, which is permanently installed on both of our systems.
FWIW, all of the RUNSQL statements in this program specify COMMIT(*NONE).
There were 28 other jobs using the same program (but different IQX00n*
objects) that completed successfully both before and after this job.
Rerunning the job that had the original error generated the same error
again. For now, we can run that RUNSQL statement interactively when it
fails in the batch job, but eventually this will be placed on the job
scheduler to run in the wee hours of the morning. So I need to figure how
how to manage this error in the future. I have already suggested to the
admin and our manager to open a new PMR for this.
Also, FWIW, we use journaling on our production data, and replication
software to sync our DR machine. I have no idea whether those last two
items have any bearing on this issue.
- Dan
midrange.com
