1. When working with Commitment Control, make sure you start Commitment Control (STRCMT) with Commitment Scope *JOB (Default for Commitment scope is *ACTGRP).
STRCMTCTL LCKLVL(*CHG)
CMTSCOPE(*JOB)
You should only start with the Default Value, if you have a 100% proper Activation Group Design, and do not mix RPGIII/CL (OPM) Programs and ILE (Service-)Programs.
If Commitment Control is started with Commitment Scope *ACTGRP a COMMIT and ROLLBACK will only work within the same Activation Group.
If you are calling multiple programs/procedures in different activation groups a ROLLBACK may only reset a part of the changes.
Keep in mind embedded SQL programs (compiled with a Commitment scope other than *NONE) will start commitment control automatically! ... with Commitment Scope *ACTGRP!!!!
If commitment control is started (for a job or activation group) it cannot be started again (for the job or the same activation group, i.e. it has to be ended first.
If commitment control is started on Job Level, it will not be started for Activation Groups.
The easiest solution is to start commitment control on *JOB Level immediately after the job/connection is started.
Except from the Documentation:
In a mixed OPM and ILE environment, jobs must use the job-level commitment definition if all committable changes made by all programs are to be committed or rolled back together.
An opened database file scoped to an activation group can be associated with either an activation-group-level or job-level commitment definition.
An opened database file scoped to the job can be associated only with the job-level commitment definition.
Therefore, any program, OPM or ILE, which opens a database file under commitment control scoped to the job needs to use the job-level commitment definition.
https://www.ibm.com/docs/en/i/7.5?topic=definition-commitment-names
2. Before your transaction starts, execute a COMMIT (just in case a previous transaction was not ended and a future rollback would then rollback the previous transaction)
Then execute your transaction. Design it in a way that you can see the ending COMMIT on the same page.
3. Do not perform COMMITs or ROLLBACKS in Sub-Programs or Functions.
4. Having a COMMIT in programs, it is easy to rerun the program after an error occurred and the data are fixed. (It is much more difficult if COMMIT and ROLLBACK are in procedures.
5. the transaction must be small (because modified rows are locked until the next COMMIT or ROLLBACK is executed), and you have to be able to rerun transactions.
... and keep in mind even with a very good design, it will happen that you run in a dead lock, i.e. one transaction hold a record that another transaction needs to update, while the second transaction holds another record that the first transaction also needs to update.
In this situation you must be able to end one of the transactions abnormally. Then a rollback will automatically performed, but you have to be able to reexecute the ended transaction.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
Modernization – Education – Consulting on IBM i
Database and Software Architect
IBM Champion since 2020
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
"Train people well enough so they can leave, treat them well enough so they don't want to. " (Richard Branson)
"Learning is experience … everything else is only information!" (Albert Einstein)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jay Vaughn
Sent: Friday, 26 July 2024 01:41
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: is this the correct understanding for commitment control running in ILE?
Given the following ILE program calling scenario, is this an accurate version of how commitment control will behave?
pgmA actgrp(*new)
monitor;
calls pgmB actgrp(*caller) // both running in *NEW now (along
with all other downstream calls)
on-error;
rolbk(e) or exec sql rollback (same results either way you specify
rollback)
endmon;
*NEW is the commitment control atomic boundary.
In this scenario, the pgmB makes calls to other *caller pgms with RLA files under commitment control as well as SQL tables under commitment control.
When pgmA is called, the commitment boundary starts for *NEW.
Any sql stored procedures that are issuing inserts/updates/deletes that contain WITH UR (meaning, use this lock level within a commitment control
boundary) are in play.
Any *caller pgms with COMMITMENT CONTROL (cobol) or COMMIT (RPG) that are defined for a file, can issue writes/updates/deletes to be considered for CC within this call scope of *NEW.
IF there is a critical error, the monitor in pgmA catches it and the rollback occurs – everything is rolled back, pgm ends as well as the *NEW actgrp commitment control boundary.
If pgmA finishes successfully, a commit does not even have to be specified, as *NEW defines the commitment boundary.
When pgmA ends, so does the *NEW actgrp boundary (as well as the commitment control boundary). – all i/o’s are committed.
tia
jay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
