Vielleicht noch ein paar Anmerkungen:
1. Auch Programme mit Native I/O können unter Commit verarbeitet werden. Dazu muss in den F-Bestimmungen bei den Update/Output-Dateien das Schlüssel-Wort COMMIT angegeben werden.
Commit kann auch durch einen Indikator bedingt werden. In diesem Fall muss der Indikator vor dem Öffnen der Datei gesetzt sein. Nur dann wenn entweder das Schlüssel-Wort COMMIT (ohne Indikator) oder wenn der Indikator vor dem Öffnen der Datei auf *ON gesetzt wurde, wird die Datei unter Commitment Control verarbeitet.
Native I/O und SQL können durchaus unter der gleichen Transaktion Datensätze hinzufügen/ändern und/oder Löschen.

2. Sofern die Commitment Control vor Aufruf des Programms nicht gestartet ist und es sich bei dem Programm nicht um ein Programm mit embedded SQL handelt, jedoch native I/O unter Commit ausgeführt werden soll, stürzt das Programm ab.
Sofern es sich um ein embedded SQL mit Insert/Update oder Delete Operationen handelt und Commitment Control noch nicht gestartet ist, wird der Befehl STRCMTCTL automatisch (mit Default-Einstellungen, also auch CMTCTL *ACTGRPDFN) gestartet.

3. Bei der Einstellung ACTGRPDFN erfolgen COMMIT und ROLLBACK nur innerhalb der Aktivierungsgruppe! Deshalb sollte man (wenn möglich) alle (Service-)Programme mit Insert/Update/Delete-Operationen (unter Commit) immer mit Aktivierungsgruppe *CALLER umwandeln.
Etwaige (System-)Trigger-Programme sollten aus dem gleichen Grund ebenfalls mit Aktivierungsgruppe *CALLER erstellt werden.

... was allerdings in gewachenen Anwendungen, in denen es noch OPM-Programme (die in der Default-Aktivierungruppe laufen) zu Problemen führen kann. Werden Dateien (für Native I/O oder auch Display Files und Printerfiles) in der Default-Aktivierungsgruppe geöffnet, können sie vor Job-Ende nicht aus dem Speicher entfernt werden.
RCLACTGRP ist für die Default-Aktivierungsgruppe nicht erlaubt.
RCLRSC macht die Dateien zwar zu, jedoch jeder weitere Aufruf schlägt fehl, da es aktuell keine Möglichkeit innerhalb der RPG-Programme dies zu prüfen, weder mit %OPEN(), noch mit der Erweiterung (E), noch über die Monitor Group.

Deshalb haben viele Firmen angefangen mit benannten Aktivierungsgruppen zu arbeiten.
Jetzt kann es jedoch sein, dass die Insert/Update/Delete Operationen in unterschiedlichen Aktivierungsgruppen erfolgen und somit ein sauberer COMMIT oder ROLLBACK nicht möglich ist.

Ist die Commitment Steuerung einmal gestartet, kann sie nicht einfach geändert werden, sondern muss explizit beendet und wieder neu (mit anderem Commitment Scope) gestartet werden.

Deshalb empfehlen die "Banausen", beim STRCMTCTL den Commitment Scope auf *JOB zu setzen, so dass COMMIT und ROLLBACK auf Job-Ebene sauber funktionieren.

Kaum einer hat die Möglichkeit mit einer Anwendung auf der grünen Wiese anzufangen und dann alles sauber zu designen.
... von Fremdsoftware, die dann zusätzlich auf der Maschine oder im Job läuft ganz zu schweigen!

Was den Commitment Scope in den embedded SQL (Service-)Programmen angeht, so sollte man diesen explizit durch ein SET OPTION (SQL-)Statement am Anfang des Source Codes (globale C-Bestimmungen in RPG) setzten.
Dann ist es völlig egal, wie der Compile-Befehl eingestellt ist, das gewünschte Commitment Level wird verwendet.

Birgitta