Re: is this the correct understanding for commitment control running in ILE?

Susan Gantner wrote "The 7 Deadly Sins of ILE". She states that it is NOT
advisable to use *NEW for an activation group. Better give a literal name
that identifies an application and the programs that work with it.

It's better to use a top, main program, be it interactive or batch, which
is the first program that will use a named, literal activation group. Then
be careful to write your called programs with *CALLER but make sure you
never call them from, say, the command line, because that would cause the
program to run in the Default Activation Group (DAG), and it is not
advisable to run ILE programs in the DAG. Avoid calling a program that has
*CALLER as the activation group from an OPM program, as the latter will
always run in the DAG and again, not advisable to run the called programs
in the DAG.

Scott Klement also wrote a handout called "A Beginner's Tour of Activation
Groups", but I have been unable to locate it. The original was at:

iprodeveloper.com/article/rpg-programming/a-beginners-tour-of-activation-groups-509

but it seems it is not found there now.

HTH
JS

El jue, 25 jul 2024 a las 17:41, Jay Vaughn (<jeffersonvaughn@xxxxxxxxx>)
escribió:

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.