Was ich nicht verstehe, warum lest Ihr eigenlich nie die Dokumentation bzw. selbst wenn man Ausschnitte aus der Dokumentation bringt werden diese noch ignoriert!

Nochmal für alle zum Mitschreiben:

1. Alle Programme, die mit Default-Aktivierungsgruppe DFTACTGRP(*YES) umgewandelt wurden sind OPM-Programme und verhalten sie wie solche. Beim RCLRSC werden diese aus dem Speicher entfernt.

2. Alle Programme, die mit Default-Aktivierungsgruppe DFTACTGRP(*NO) umgewandelt wurden sind ILE-Programme. ILE-Programme können nur durch das Schließen der Aktivierungsgruppe (RCLACTGRP), in der sie aktiviert wurden, aus dem Speicher entfernt werden.
RCLRSC hat auf die (benannten/*New) Aktivierungsgruppen keinen Einfluss.

3. Werden Programmemit Default-Aktivierungsgruppe DFTACTGRP(*NO) und Aktivierungsgruppe *CALLER von einem OPM-Programm aufgerufen, laufen diese ILE-Programme in der Default-Aktivierungsgruppe.
Wie zuvor gesagt kann ein ILE-Programm nur durch Schließen der Aktivierungsgruppe aus dem Speicher entfernt werden. Die Default-Aktivierungsgruppen können nur durch Beenden des Jobs beendet werden.
RCLRSC wirkt nur auf die Default-Aktivierungsgruppen und bewirkt dabei, dass die mit Return beendeten Programme (unabhängig davon ob ILE oder OPM) beendet werden. Ebenso werden alle für native I/O geöffneten Dateien in OPM und ILE Objekten (also auch Service-Programme, die in der Default-Aktivierungsgruppe laufen) geschlossen.
Aber da ILE-(Service-)Programme nur durch das Beenden der Aktivierungsgruppe komplett aus dem Speicher entfernt werden können, werden zwar die Dateien geschlossen, die Objekte bleiben weiterhin im Speicher und der statisch reservierte Speicherbereich für Variablen bleibt erhalten. Beim erneuten Aufruf werden die Variablen neu initialisiert.
Dieses Verhalten mag vielleicht bei echten Programmen keine Probleme darstellen, bringt aber rieseige Probleme, wenn Service-Programme (mit F-Bestimmungen) in der Default-Aktivierungsgrupe ausgeführt werden und dann die Dateien durch RCLRSC geschlossen werden.

Aus Erfahrung, kann ich sagen, dass viele Firmen (z.T. auch weil sie FALSCH beraten wurden) spätestens dann, wenn sie anfangen wollen Service-Programme richtig einzusetzen massive Probleme bekommen.

Deshalb gilt eigentlich die Regel (und damit stehe ich nicht allein, da kann ich jede Menge bekannter Größen z.B. Barbara Morris, Jon Paris, Susan Gantner, Scott Klement, Charlie Guarino, Bob Cozzi etc. ins Rennen schicken):
ILE-(Service-)Programme sollten in einer benannten Aktivierungsgruppe ausgeführt werden.

Solange man noch nicht alles 100% im Griff hat, genügt es sich für eine Aktivierungsgruppe z.B. QILE oder irgende einen anderen Namen (z.B. Firma-Namen), durch den Probleme mit Programmen, von anderen Firmen, die Ihre ILE-Programme ebenfalls in der QILE ausführen, vermieden werden.
Wenn man dann (zumindest am Anfang) den Override Scope und den Commitment Scope auf *JOB setzt, ziehen auch die Overrides, die z.B. in OPM-Programmen gesetzt wurden korrekt. Nach- und nach sollte man dann die Overrides auf *CALLLVL umsetzen, d.h. der Override gilt nur für den aktuellen Callstack.

Seit Release 6.1 ist es auch so, dass Programme mit sogenannten Linearen Main-Prozeduren erstellt werden können. Schlüssel-Wort MAIN in den H-Bestimmungen, die im Zusammenhang mit dieser Prozedur genannte Prozedur wird direkt aufgerufen. Bei "normalen" Main-Prozeduren wird immer der RPG Zyklus integriert, der einen rekursiven Aufruf (innerhalb der gleichen Aktivierungsgruppe) verhindert.

Bei linearen Main-Prozeduren wird der RPG-Zyklus nicht integriert, deshalb kann z.B. auch keine *INZSR integriert werden. Da der Zyklus nicht integriert wurde, können auch Programme innerhalb der gleichen Aktivierungsgruppe rekursiv aufgerufen werden.

Birgitta