Serviceprogramm und Speicher

[B.Hauser]

Ein Service-Programm kann auch ACTGRP(*CALLER) haben. Dann wird das Programm eben zusammen mit der ACTGRP des Aufrufers rausgeschmissen.
Das hat auch den Effekt, dass das Programm mehrfach, eben je ACTGRP, im Speicher liegen kann.
Zu bedenken ist, dass Serviceprogramme ja von verschiedenen Hauptprogrammen aufgerufen werden und somit SQL-Cursor vom Einen durch Andere zerstört werden können.

... und wenn man Pech hat, wird das Service-Programm, das mit Aktivierungsgruppe *CALLER erstellt wurde von einem Programm aufgerfuen, das ebenfalls mit *CALLER erstellt wurde.
Wird nun das rufende Programm seinerseits von einem OPM-Programm (RPGIII oder RPGIV, das mit DFTACTGRP *YES erstellt wurde) aufgerufen, läuft alles in der Default-Aktivierungsgruppe und kann nur durch Beendigung des Jobs aus dem Speicher entfernt werden.
RCLRSC entfernt übrigens weder ein ILE-Programm noch ein Service-Programm aus dem Speicher! Es werden lediglich die in den ILE-(Service-)Programmen geöffneten Dateien geschlossen und der reservierte statische Speicher initialisiert.

Wird ein Service-Programm (bzw. Prozeduren aus diesem Service-Programm), das Aktivierungsgruppe *CALLER aktiviert wird, von mehereren Programmen mit unterschiedlichen Aktivierungsgruppen aufgerufen, so wird das Service-Programm mehrfach aktiviert.

Ob der "gleiche" SQL-Cursor mehrfach in unterschiedlichen Aktivierungsgruppen oder in der gleichen Aktivierungsgruppe angesprochen wird, stellt kein Problem dar. Jedes SQL-Statement, das ausgeführt wird, erhält seinen eigenen ODP (Open Data Path). Wird also der gleiche Cursor in mehreren Aktivieru ngsgruppen aktiviert, so werden auch mehrere ODPs geöffnet. Was dabei allerdings zu berücksichtigen ist, ist, dass der FULL OPEN, also das erste Öffnen eines ODPs ein zeitaufwändiger Prozess ist. (Wesentlich zeitaufwändiger als eine Datei für native I/O zu öffnen!)
Deshalb sollte versucht werden die FULL OPENs bzw. die Anzahl der ODPs zu minimieren.

Service-Programme, die allerdings Insert/Update/Delete-Prozeduren beinhalten, sollten immer mit Aktivierungsgruppe *CALLER erstellt werden, wegen der Commitment-Steuerung (wird per Default mit Commitmentscope *ACTGRP gestartet!)

Ein RCLACTGRP ACTGRP(*ELIGIBLE) hat ggf. bei Triggerprogrammen in eigenen ACTGRP's die Auswirkung, dass der Job beendet werden muss.
Die weitere Ausführung der Trigger ist nicht mehr möglich. Dies könnte jedoch releaseabhängig und durch PTFs behoben sein.

Von einem RCLACTGRP ACTGRP(*ELIGIBLE) sollte man die Finger lassen und allenfalls in Testumgebungen verwenden.
Trigger-Programme sollten nicht in benannten Aktivierungsgruppen, sondern in Aktivierungsgruppe *CALLER erstellt werden (SQL-Trigger werden automatisch mit Aktivierungsgruppe *CALLER erstellt).

Die Probleme mit den Triggern sind i.d.R. hausgemacht, d.h. falsche Aktivierungsgruppen und die Ausführung von RCLRSC und RCLACTGRP *ELIGIBLE, die man auf alle Fälle überdenken sollte.

Birgitta