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

I got a handout of one of her sessions when I attended the RPG Summit in
the fall of 2015. There she summarized what the 7 deadly sins are and also
has a link to the document but it's not reachable.

Summarizing, though, here's the 7 sins:

1. Run ILE programs in the Default ILE Activation Group (DAG)
Use ILE named Activation Groups instead (such as QILE)
2. Run Service Programs in the DAG
Can be an even bigger problem than #1
3. Use *NEW by default, rather than by design
Until V5R3, *NEW was the default on the CRTPGM command
4. Using *CALLER as the default Activation Group value
Tends to cause problem #1 if you're not careful
5. Failure to use RCLACTGRP only when necessary
5b. Using RCLACTGRP(*ELIGIBLE) in production code at all
6. Allow scoping parameters to default to system-shipped
defaults
7. Use of the RCLRSC command
Its impact is variable depending on where used and on what type of
programs

I do not have the full document, if there is one.

El jue, 25 jul 2024 a las 18:55, Alan Campin (<alan0307d@xxxxxxxxx>)
escribió:

Do you have a copy of The 7 Deadly Sins of ILE"? I have been looking for
one for years.

On Thu, Jul 25, 2024 at 5:44 PM Javier Sanchez <
javiersanchezbarquero@xxxxxxxxx> wrote:

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.

--
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.

--
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.