Lebensdauer von static Variablen

[BenderD]

... das ist auf Seite 119 (Abteilung Pathologie) der RPG Reference so beschrieben:
"Static storage in the main procedure is subject to the RPG cycle, and so the value
changes on the next call if LR was on at the end of the last call. However, local
static variables will not get reinitialized because of LR in the main procedure."

D*B

[dschroeder]

Hallo Dieter,
vielen Dank. Den Text hatte ich auch schon gelesen. Ist schon wahr, da steht, dass LR auf static Variablen nicht wirkt. Aber direkt davor steht "If the keyword STATIC is specified, the item will beinitialized at module initialization time.". Deshalb die Frage: Was ist denn genau der "module initialization" Zeitpunkt?
Dieter

[BenderD]

... auch das steht in der Reference, auf Seite 98:
"First time
subprocedure
has been called?"
"Initialize static variables"

Man beachte den feinsinnigen Unterschied:
- static Variablen werden beim anlegen initialisiert
- LR initialisiert die globalen Variablen beim verlassen des Programms

Vom Design her ist das mit dem static local frei nach Fred Feuerstein Dummfug der dummfugigsten Sorte, mit Zustand behaftete Variablen gehören global definiert (damit das Modul seinen eigenen Zustand kennt) alles andere verhindert Modularisierung!

D*B

[dschroeder]

Danke für die Info. Wenn ich mir eine Implementierung wünsche könnte, würde ich die statischen Variablen ebenfalls mit LR initialisieren. Dann würden sie sich genauso wie globale Variablen verhalten. Dann würde static Sinn machen. So macht es auch für mich keinen Sinn.
(Ich spreche hier nur von Variablen, die in internen (nicht exportierten) Procedures definiert sind).

Dieter

[BenderD]

...der Haken an der Sache beginnt da, wo so eine Procedure wächst und es sinnvoll wird sie zu teilen, dann muss man die lokale static Variable als Parameter durchschleifen, was dazu führt, dass weitere Modularisierung komplizierter wird oder sogar unterbleibt. Wenn ein Modul zu viele Zustandsgrößen (sprich globale Variablen hat), dann ist es zu groß!

D*B

[Fuerchau]

Bzgl. STATIC muss man allerdings den Kontext sehen.

Wenn ein Prozedur mit Return verlassen wird, bleibt eine STATIC-Variable mit ihrem Inhalt bestehen.
Wenn das Programm mit Return (oder automatisch am Ende) mit LR *on verlassen wird, wird das Programm aus der ACTGRP deaktiviert und entfernt.
Beim nächsten CALL wird das Programm neu initialisiert und somit auch alle Static's in allen Modulen die vorkommen.
Auch die *INZSR-Subroutine (falls vorhanden) wird erneut aufgerufen.
An diesem Verhalten hat sich nichts geändert.

Die Doku geht da etwas schwammig damit um, da sie sich nur auf Module bezieht.
Aber ein Modul muss die Startprozedur enthalten, die für das LR zum Beenden entscheidend ist.

LR = *ON initialisiert keine Variablen sondern entscheidet beim Return, ob Dateien geschlossen und Locks aufgehoben werden.

[BenderD]

... simply wrong!

[B.Hauser]

Ich denke die Dokumentatin ist eindeutig:
1. Nur echte Main-Procedures (alle Statements vor dem ersten P-Statement) unterliegen dem RPG-Zyklus.
Der RPG-Zyklus wird immer integriert, auch dann wenn Dateien nicht mit IP oder UP definiert und verarbeitet werden.
Variablen, die in den globalen D-Bestimmungen definiert werden, gehören zu der Main-Procedure und können somit mit und durch den RPG-Zyklus gesteuert werden.
Wird eine Main-Procedure mit LR beendet, werden alle Variablen, die in der Main-Procedure definiert wurden beim nächsten Aufruf initialisiert. (So war es schon immer und das wurde nicht geändert)

2. Wird eine Main-Procedure mit RETURN (ohne LR) beendet, werden in der Main-Procedure definierten Variablen beim nächsten Aufruf nicht initialisiert, sofern der Aufruf in der gleichen Aktivierungsgruppe erfolgt.
Die in der Main-Procedure definierten Variablen werden immer beim ersten Aufruf innerhalb einer Aktivierungsgruppe initialisiert.
Da die Main-Procedure dem Zyklus unterliegt kann der Zyklus auch die Initalisierung der Variablen steuern.
(Das wurde seit Einführung von ILE so gehandelt!)

3. Procedures unabhängig davon, ob nur intern definiert oder exportiert oder als lineare Main-Procedures hinterlegt, unterliegen nicht dem Zyklus und folglich kann auch der Zyklus die Initialisierung der Variablen (weder der "normalen" lokalen, noch der statischen lokalen) nicht steuern.
Die Initialisierung der statischen Variablen hängt von der Aktivierungsgruppe ab, d.h. nur beim ersten Aufrfu innerhalb einer Aktivierungsgruppe werden die Variablen initialisiert. Alles andere muss manuell (im Programm-Code) gehandelt werden.

Birgitta

[dschroeder]

Vielen Dank für alle Antworten.
Das, was Birgitta sagt, deckt sich mit meinen Erfahrungen.

Dieter.

[Fuerchau]

Nun denn, da hat ja IBM am Speichermodell massiv geändert.
Aus MI-Sicht gibt es eben 2 Speicher, Static und Auto.
Bei der Deklaration von Variablen gibt man per INZ die Initialisierung beim Start an.
Beim Verlassen eines Programmes wurde die MI-Anweisung "Deaktivere Programm" vor dem Return ausgeführt.
Damit wurde das Programm aus dem Speicher entfernt, so dass beim nächsten Aufruf die Initialisierungen durch das MI wieder erfolgten.

Mit dem ILE hat sich das wohl geändert, so dass globale und statische Variablen nicht mehr per INZ sondern per Code initialisiert werden, anders lässt sich das nämlich nicht erklären.

Ein ILE-Programmobjekt wird wohl jetzt erst entfernt, wenn die ACTGRP beendet wird.
Innerhalb der DFTACTGRP reicht dann ein RCLRSC.

Damit erklärt sich nun auch der z.T. erhebliche Speicherverbrauch bei ILE.
Im Lebenszyklus eines Dialogjobs werden ja mitunter 1000de Programme aufgerufen.
Auch wenn also jedes Programm mit *INLR = *ON verlassen wird, so verbleibt es wohl doch im Speicher bzw. alle statischen Variablen bleiben aktiv.
Das ist schon eine ganze Menge.

Ein weiterer Effekt ist nun, dass eine benannte ACTGRP nun nicht mehr beendet wird, wenn das oberste Programm mit LR = *ON endet, siw wird nur als inaktiv aufgeführt!
Das funktioniert nun nur bei ACTGRP(*NEW).
Wenn ich also meinen Job sauber aufräumen will muss ich also tatsächlich bei benannten ACTGRP's einen RCLACTGRP anfordern damit der Speicher aufgeräumt wird, *INLR reicht nicht mehr.

Jetzt frage ich mich allerdings, wie man denn tatsächlich ein Programm gezielt aus einer ACTGRP entfernen kann. Unter OPM gab es dafür die Anweisung "FREE", die in ILE nicht mehr erlaubt ist.

[BenderD]

... das einzige, was sich da geändert hat, ist das Handling von LR!
bei OPM: Programm wird aus dem Speicher gelöscht
bei ILE: Programm wird nicht gelöscht, sondern global (static) Vars initialisiert (bei SRVPGM keine Auswirkung)
Das war aber bei ILE von Beginn an so!

ACTGRP *NEW für Programme ist keineswegs ein Allheilmittel, das führt nämlich dazu, dass alles, was untendrunter mit *CALLER läuft neu aktiviert wird, auch wenn es bereits anderweitig im Speicher ist.

Irgendwo in der Mitte bewegt man sich, wenn man bei Programmen ACTGRP = Programmname verwendet, dann kann man wenigstens gezielt deaktivieren, wenn man RCLACTGRP Programmname macht. Bei klarem ILE Design, wo man in einem Job nur 1 Programm aktiv hat und alle Subfunktionen in SRVPGMs sind, ist dies auch meine Empfehlung.

Speicherverbrauch ist auf einer AS/400 eigentlich eher unkritisch (->Single level store), die Aktivierung ist da meist dominierend, sprich große Speichermengen zu holen ist teuer, da das einpagen in kleinen Dosen erfolgt und nicht sehr effizient ist. Meist ist drinlassen und verdrängen lassen die bessere Wahl.

Noch eine Anmerkung zu ACTGRP und SRVPGM: Für Zustandsbehaftete SRVPGMs ist *CALLER am Besten, Zustandslose ACTGRP = SRVPGMName oder gleich fester Wert (bei mir NORECLAIM)

D*B