David,
I think you need to study the "ILE Concepts" manual for your version and release of IBM i. It discusses these matters in some detail.
Commitment control is a tricky thing, especially if you have multiple activation groups involved. And it gets even more complex when you are using embedded SQL, because Db2i will attempt to create a commitment control boundary (equivalent of STRCMTCTL) for the activation group where the program is running, if one is not already established.
I think one suggested "best practice" is to issue the STRCMTCTL at the *JOB level, early on in the job, e.g. from the main program of the application in question,
That way, any files that get opened either at the *JOB level, e.g. any OPM-compatible programs in the *DFTACTGRP, will be opened using that job level commitment control boundary.
I hope that helps,
Mark S. Waterbury
On Friday, November 14, 2025 at 01:00:11 PM EST, David Gibbs via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
On Mon, Nov 10, 2025 at 12:04 PM David Gibbs <david@xxxxxxxxxxxx> wrote:
I have program 'A' that has *OWNER as it's 'user profile' attribute,
running in a specific named activation group. This program is calling a
procedure in a service program that has *USER as it's 'user profile' and
'use adopted authority' is *YES. The service program has it's own named
activation group.
I'm still struggling with this issue. I have a hypothesis, but need more
information.
Can anyone point me to a good explanation of a job's 'Commitment
Definition'? I've never used that before.
The job that's failing has a commitment definition and I'm thinking that
might be involved.
The file in question is first opened in an initialization procedure of the
service program. All the procs in the service program call the
initialization procedure and, if it was previously called, it's not called
again.
The program that calls the failing procedure is in a named activation group
and that ag's name corresponds to the commitment definition.
When the file is first opened, I **think**, it's not in the commitment
definition.
If a file is opened outside of the commitment definition and then updated
inside the commitment definition, could that cause an 'I/O Error' (CPF5134)?
Thanks!
david
As an Amazon Associate we earn from qualifying purchases.