View Full Version : ENDCMTCTL not allowed. Pending changes active
... eine Programm in einer benannten Aktivierungsgruppe verhält sich bei erneutem Aufruf wie ein OPM Programm, das man offen hält (return ohne LR).
Schließen einer Aktivierungsgruppe schließt alles mit ein, was innerhalb der Actgrp liegt, auch alles, was mit *CALLER aufgerufen wurde. *NEW schließt immer automatisch, RCLACTGRP nur auf Anforderung.
Bei Rekursion (gewollt oder ungewollt) schmiert ein Programm mit benannter ACTGRP ab (wie OPM), bei *NEW gibt es dann mehrere (mit allen Konsequenzen).
D*B
Wenn man mit Main-Prozedur arbeitet, gibts kein Abschmieren mehr. Die Rekursionsprüfung machte die Zyklus-Runtime und die gibts da ja nicht mehr.
Wenn dann das 1. Main einer ACTGRP endet, wird aufgeräumt. INLR interssiert da niemand mehr.
Bei COBOL bin ich da schon mal reingefallen. Die Anweisung STOP RUN beendet die Cobol-Rununit auch von der untersten Callebene aus. Will man schrittweise in der Aufrufebene zurück, muss man GOBACK verwenden.
COBOL ist übrigens auch rekursiv aufrufbar, da die Runtime das hier nicht prüft.
Allerdings mit ähnlichen Konsequenzen wie bei RPG.
Ein EXSR / Perform ruft keine Unteroutine auf, sondern setzt eine Sprungmarke auf den Befehl danach und am Ende von EXSR/Perform gibts ein GOTO Sprungmarke.
Das erklärt auch, warum EXSR/Perform nicht rekursionsfähig ist.
Wenn das Programm dann nochmal aufgerufen wird, werden diese Sprungmarken initialisiert.
Ruft man also ein Programm aus EXSR/Perform heraus rekursiv auf, dann läuft das Programm nach dem untergeordneten return geradeaus weiter.
Das hat auch bei ILERPG mit Main() dieselben Konsequenzen, wenn man da noch EXSR verwenden sollte.
Benannte ACTGRP's haben den Vorteil, dass man Anwendungen strikt trennen kann.
Ich hatte früher schon mal Schwierigkeiten, wenn aus Anwendung A, z.B. ERP, Anwendung B, z.B. Buchhaltung aufgerufen werden sollte.
ERP und Buchhaltung haben unterschiedliche Libs, Dateien, Journale, Commitgrenzen.
Wie Dieter schon schrieb, ILEProgramme mit Zyklus verhalten sich wie OPM in der ACTGRP. Bei *INLR = *OFF bleibt die ACTGRP erhalten. Bei *INLR = *ON wird aufgeräumt.
Bei Main() wird (fast) immer aufgeräumt.
Wird ein Main-Programm mit Escape-Message abewürgt, wird nicht aufgeräumt.
Hallo zusammen. Erst mal vielen Dank für alle Antworten.
Ich schreibe es mal wie ich es verstanden habe. Allerdings möchte ich auf rekursive Aufrufe erst mal nicht eingehen, denn die machen wir nicht.
Gehen wir von Program C1 aus mit ACTGRP(C1)
Programm C1 ruft Programm R1 auf. ACTGRP(*CALLER) (R1 endet mit *INLR = *on)
Programm R1 ruft Programm R2 auf. ACTGRP(*CALLER) (R2 endet mit RETURN)
Jetzt bin ich am Ende des C1. Was genau muss ich machen, damit die Dateien aus R2 geschlossen werden.
So wie ich DBender verstehe, bleiben dann die Dateien aus R2 offen.
Um sie zu schließen muss ich einen RCLACTGRP machen. Aber dann sind sie auch zu.
Bitte einmal abnicken :-)
Wenn eine ACTGRP endet, mit dem ersten Programm dass diese gestartet hat, wird aufgeräumt.
Bei OPM ist das ja genauso, nur dass das 1. Programm im Job die DFTACTGRP erstellt und diese erst geschlossen wird, wenn der Job endet.
So einfach ist das.
Ah ok, jetzt ist der Groschen gefallen. Danke
So jetzt habe ich den DEBUG vor dem ENDCMTCTL im CL stehen und warum sind jetzt alle Dateien noch offen obwohl ich das Programm was aus dem CL aufgerufen wird mit *INLR beende?
Weil die Dateien erst mit der ACTGRP geschlossen werden.
Kann ärgerliche efekte haben wenn du ohne abmelden zwischen Echt und Test und Echt wechselst!!!
Daher: aus dem Menü eine Weiche rufen die in *new läuft.
Diese 'weiche' ruft das eigendliche Pgm in *caller.
Dann klapps auch mit dem Nachbarn!
Weil irgend ein Unterprogramm (OPM) aufgerufen wurde, dass in der DFTACTGRP läuft.
Ich habe auch schon gesehen, dass man CLP's schreibt, dei aus Performancegründen eben jede menge OPNDBF's machen, damit schon mal alles auf ist.
Sind sog. File-Handler als OPM noch aktiv?