Generelles zu commit und Transaktionen:

Transaktionen sind immer in einem Kontext zu sehen, d.h., alles was zu einem Kontext gehört muss in einer Transaktion abgeschlossen sein.
Randbedingung: eine Transaktion darf nie durch eine Userinteraktion unterbrochen werden, also z.B. auf eine Bildschirmeingabe warten.

Transaktionen laufen grundsätzlich nur innerhalb einer ACTGRP.
Durch entsprechende Aufrufdefinitionen *CALLER muss also dafür gesorgt werden, dass diese im Kontext in einer ACTGRP passieren.

Wenn man ILERPG/ILECOBOL/CLLE/CLE verwendet, ist ein STRCMTCTL grundsätzlich nicht mehr erforderlich, das erledigt die SQL-Runtime für uns. Dabei wird immer eine Commit-Gruppe der ACTGRP erstellt.

Commit beenden die Transaktion und alle Daten bleiben erhalten. Dies passiert ausschließlich innerhalb der ACTGRP.

Im Job gibt es mehrere Standard-ACTGRP's:
*DEFAULT 1: System-ACTGRP
*DEFAULT 2: User ACTGRP
QILE: 1. automatische ACTGRP für ILE-Programme
"Benannte": durch Programme benannte ACTGRP
*NEW: temporäre ACTGRP

Alle Update/Insert Daten bleiben bei einer aktiven Transaktion gesperrt.
Delete wird ja sofort ausgeführt und ist daher bereits weg.
Bei einem "Select .... for Update" wird beim Lesen beeits gesperrt.
*CHG: Jede Veränderung wird gesperrt.
*CS: Jeder gelesene Satz wird zusätzlich gesperrt
*ALL: Alle gelesenen Sätze werden zusätzlich gesperrt, also Vorsicht!

Ein Commit ist sehr schnell, weil die Commit-Definition geschlossen wird und alle Sperren aufgehoben werden.
Ein Rollback liest nun rückwärts die Daten wieder aus dem Journal und stellt die Daten wieder her.
Danach wird wie beim commit die Commit-Definition geschlossen und alle Sperren aufgehoben.
Ein IDENTITY-Counter wird nie zurückgesetzt.

Zu deiner Frage:
Wenn also alle Programme mit *CALLER erstellt werden, läuft alles in der selben ACTGRP, allerdings mit einer Ausnahme: Jedes Programm muss ILE können!

Wird z.B. ein CLP oder RPGIV aufgerufen, also ein OPM Programm, läuft dieses immer in *DEFAULT 2, hat also eine andere Commit-Ebene.

Hat nun ein Programm oder Service-Programm eine eigene ACTGRP werden hier getrennte Transaktionen durchgeführt. Beim Auflösen der ACTGRP (verlassen der obersten Ebene) wird automatisch ein ROLLBACK gemacht.
Somit kann also ein Service z.B. Protokollsätze schreiben, die auch durch einen Rollback nicht verschwinden. Oder eben eine eigene Transaktion über mehrere Aktionen erstellen.

Trigger:
Es ist per Definition nicht erlaubt, dass ein Trigger eine Transaktion abschließt.
Dies gilt auch für aus dem Trigger aufgerufenen Programme innerhalb derselben Transaktion.
Wenn ein Trigger eine andere ACTGRP aufruft, kann diese wiederum eigene Transaktionen durchführen.
Achtung vor Rekursion:
Standard ILERPG ist nicht rekursionsfähig. Um eine Rekursion zu ermöglichen, muss das Programm über eine MAIN-Funktion verfügen und hat dann keinen Zyklus.
Eine endlose Rekursion gibt es nicht, da stirbt dann die ACTGRP.

Deadlocks:
Durch die ACTGRP's kann es auch innerhalb eines Jobs bereits zu Deadlocks kommen, also nicht nur jobübergreifend.

So, für einen groben Überblick sollte das reichen.