Lebensdauer von static Variablen

[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

[Fuerchau]

"Bei klarem ILE Design, wo man in einem Job nur 1 Programm aktiv hat..." ist ja in Dialogjobs nicht durchführbar. Aus einem Menü heraus kann ich zig Programme aufrufen, die nun ja nach ILE alle im Speicher bleiben.

[BenderD]

... natürlich ist das durchführbar, pro Anwendung reicht ein main, der Rest sind SRVPGMs. Wenn allerdings im Callstack mehrere Programme übereinander liegen, die dann wieder gemeinsam dieselben SRVPGMs nutzen, spätestens dann kann von klarem ILE Design keine Rede mehr sein.

D*B

[AG1965_2]

Das klingt aber mehr nach einem nachprogrammierten DFU als nach einer feinen 5250-Anwendung.
Aus der Auftragserfassung im Matchcode einen Fehler bei einem Kunden entdecken und in der Kundenstammwartung beheben - ich kenne mehrere Pakete, in denen so etwas möglich ist, ohne wieder ins Menü zurückzusteigen.
Wäre dann nur das Menü das Programm und alles andere in Serviceprogrammen, um als echte ILE-Anwendung durchzugehen?