Activation Group

[B.Hauser]

Da geht wohl einiges durcheinander:
1. Eine Aktivierungs-Gruppe wird nicht durch den *INLR geschlossen, sondern nur inaktiviert, d.h. der Speicher bleibt reserviert und beim nächsten Aufruf werden nur die Variablen neu initialisiert. Ausnahme ist die Aktivierungs-Gruppe *NEW, sie wird beim Programm-Ende geschlossen.
Alle anderen Aktivierungs-Gruppen werden mit Job-Ende geschlossen. Benannte Aktivierungs-Gruppen können ausserdem mit dem CL-Command RCLACTGRP oder einem C-API geschlossen werden.

2. Eine (Sub-)Prozedur oder Funktion wird immer mit RETURN beendet und niemals mit *INLR. Grund: *INLR ist Zyklus und nur Main-Procedures unterliegen dem Zyklus, nicht aber Sub-Prozeduren.

3. Ob ein Service-Programm mit Main-Prozedur mit CALL oder CALLP aufgerufen wird, hat keinen Einfluss auf die Aktivierungs-Gruppe. (Ich bin mir nicht einmal sicher, ob der CALL ohne P überhaupt funktionniert, da nur Programme dynamisch aufgerufen werden können).

3. Ein Binder-Verzeichnis hat mit einem Aufruf überhaupt nichts zu tun, sondern wird zur Compile-Zeit benötigt, um entweder die verwendeten Module oder die Signatur der eingebundenen Service-Programme zu finden und in das Programm-Objekt einzubinden.
(Man kann auch die Module und Service-Programme direkt beim CRTPGM anlisten)

4. Es macht auch durch aus Sinn Service-Programme in einer benannten Aktivierungs-Gruppe laufen zu lassen, nämlich dann, wenn diese Prozeduren in fast jedem Programm verwendet werden, z.B. Aufbereiten von numerischen Datumswerten.

Man sollte nur die Aktivierungs-Gruppe dann nicht schliessen.
Dies führt zu dem Problem von KM:

Ein Service-Program wird statisch (über Signatur) in ein Programm eingebunden, und beim ersten Programm-Aufruf (also PGMA) aktiviert. Wird das Service-Programm mehrfach aufgerufen, erfolgt keine neue Aktivierung. Wird also die Aktivierungs-Gruppe, in der das Service-Programm läuft, gelöscht. Läuft der nächste Aufuf in Leere (MCH3402 oder was auch immer).

Anders sieht es bei Programmen aus. Der Aufruf ist dynamisch, d.h. jedes Mal wenn das Programm aufgerufen wird läuft der Aktivierungs-Prozess. Ist die Aktivierungs-Gruppe bereits aktiv, werden nur die Variablen neu initialisiert. Ist die Aktivierungs-Gruppe nicht aktiv, wird sie aktiviert.

Birgitta

[kuempi von stein]

Hallo All,

ich quäle mich auch gerade seit ein paar Stunden durchs Handbuch : ILE-Concepts...

Habe gerade beschlossen mal ne Gedankenpause zu machen, weil es doch recht lustig wurde und die Begriffe wie BNDDIR und ACTGRP nur so um mich rumschwirren... und was sehe ich hier? Vom Regen in die Traufe ...

Schön zu lesen, dass ich nicht der einzige bin... :-))

Aber das wird schon werden...

Gruss an Alle

kuempi

[BenderD]

@Birgitta:

Serviceprogramme werden garnicht aufgerufen. Was aufgerufen wird, sind Procedures (die in SRVPGMs enthalten sein können) und das geht nur mit CALLB oder CALLP (das beim Compile über den EXTPROC Eintrag im Prototyp in ein CALLB umgesetzt wird).

Neben SRVPGMs, die man nie mit reclaim bearbeiten braucht, gibt es noch die Variante mit eigener Activation Group beim SRVPGM, wenn man eine eigene Commit Scope haben will.

Bei Activation Group *CALLER eines SRVPGMS kann es durchaus zu Mehrfach Aktivierungen kommen, wenn Procedures des SRVPGMs aus Programmen oder anderen Service Programmen referenziert werden, die in unterschiedlichen Aktivierungsgruppen laufen.

Dieter

Da geht wohl einiges durcheinander:

3. Ob ein Service-Programm mit Main-Prozedur mit CALL oder CALLP aufgerufen wird, hat keinen Einfluss auf die Aktivierungs-Gruppe. (Ich bin mir nicht einmal sicher, ob der CALL ohne P überhaupt funktionniert, da nur Programme dynamisch aufgerufen werden können).

4. Es macht auch durch aus Sinn Service-Programme in einer benannten Aktivierungs-Gruppe laufen zu lassen, nämlich dann, wenn diese Prozeduren in fast jedem Programm verwendet werden, z.B. Aufbereiten von numerischen Datumswerten.

Ein Service-Program wird statisch (über Signatur) in ein Programm eingebunden, und beim ersten Programm-Aufruf (also PGMA) aktiviert. Wird das Service-Programm mehrfach aufgerufen, erfolgt keine neue Aktivierung. Wird also die Aktivierungs-Gruppe, in der das Birgitta

[KM]

Vielen Dank für die ausführlichen Erklärungen !

KM

[ROT]

Gibt es eine Möglichkeit eine Aktivierungsgruppe in einem Job so zu beenden, dass sie nachher im selben Job wieder verwendet werden kann? Wie ich festgestellt habe ist das mit RCLACTGRP nicht möglich.

[Fuerchau]

Normalerweise wird die ACTGRP wieder initialisiert sobald das 1. Programm dieser ACTGRP aufgerufen wird.
Das betrifft allerdings keine Zeiger von Prozeduren, deren ACTGRP bestehen bleibt.
Man sollte dann den gesamten Kontext (ab. 1. Aufrufebene) beenden.

[BenderD]

Hallo,

auch hier ist wieder Präzision gefragt.
Aktiviert wird vom System nur beim dynamischen Call und dann neben der Activation Group des aufgerufenen Programms, alles was hinten dran noch gebunden wird; dabei können auch weitere Activierungsgruppen erzeugt werden (bei Bedarf) und auch Module in bestehenden Aktivierungsgruppen geladen werden.
Der RCLACTGRP haut eine ganze Aktivierungsgruppe raus, so dass dann Verweise auf aktivierte Procedures verloren gehen können.
Besser steuerbar wird das, wenn man die Aktivierung selber in die Hand nimmt, indem man für die CALLP Anweisungen Prototypen mit Procedure Pointern deklariert und dann beim ersten Aufruf (oder wann immer man will) per API Call aktiviert; damit fallen wesentliche Einschränkungen des automatischen aktivierens weg und man kann nach RCLACTGRP bei Bedarf erneut aktivieren.
Hierfür gibt es ein Service Programm auf meiner Open Source Seite. Ein positiver Nebeneffekt dieser Technik ist, dass die Ladezeiten deutlich optimiert werden, da nur bei Bedarf aktiviert wird.

mfg

Dieter Bender

Gibt es eine Möglichkeit eine Aktivierungsgruppe in einem Job so zu beenden, dass sie nachher im selben Job wieder verwendet werden kann? Wie ich festgestellt habe ist das mit RCLACTGRP nicht möglich.

[Fuerchau]

Wobei man den CALLP wohl mit Monitor dann überwachen muss, FALLS der Call nämlich fehlschlägt (wegen RCLACTGRP) um dann die Aktivierung zu wiederholen.

[BenderD]

Das ist eine der Möglichkeiten, das könnte aber auch ein Error Handler übernehmen, oder eine Initialisierungs Routine, die nach dem RCLACTGRP cascadierend aufgerufen wird und den Zustand der Module zurücksetzt und bei erneuter Verwendung wieder zum binden führt.

Wobei man den CALLP wohl mit Monitor dann überwachen muss, FALLS der Call nämlich fehlschlägt (wegen RCLACTGRP) um dann die Aktivierung zu wiederholen.