ENDCMTCTL not allowed. Pending changes active

[itec01]

.. dann hast Du eines der ganze seltenen Systeme, die beim commit würfeln, ob sie den jetzt machen sollen!

D*B

Sorry, aber was soll die Aussage?
Schau Dir mal bitte den Auszug vom Joblog an, da steht klipp und klar, dass beim rollback nichts zurückgefahren wurde (weder auf Satz, API noch Job Ebene), ergo kann auch nichts offen gewesen sein.
Das muss irgendwo anders herkommen. Wir hatten das früher schon und konnten es uns nicht erklären. Selbst im Debug mode und DSPJOB haben wir gesehen, dass nichts offen war aber dennoch beim ENDCMTCTL der Abbruch kam.

Ich habe nun einen DSPJOB *PRINT im Abbruchsfall erzeugt. Hier wird bestätigt, dass es keine pending commits gibt, dennoch bricht der ENDCMTCTL ab.

[B.Hauser]

Was passiert, wenn Du vor dem ENDCMTCTL einen COMMIT ausführst und dafür den RCLRSC auslässt?

[itec01]

Was passiert, wenn Du vor dem ENDCMTCTL einen COMMIT ausführst und dafür den RCLRSC auslässt?

Kann ich machen, aber das ist halt gewagt. Normalerweise kontrollieren die Folgeprogramme den Commit und führen ihn auch aus.

Ich denke, durch die ACTGRP *NEW funktioniert der RCLRSC eh nicht mehr.

Ich habe nun mal gezielt die CPF Message nach dem ENDCMTCL geprüft und einen rollback gemacht, aber auch das ist nicht ideal.

Seltsam ist halt, dass der ENDCMTCTL offene commits meldet aber im job nichts offen rum steht. Nur wie findet man so etwas heraus? Prinzipiell kann in den Tiefen schon sein, dass manche Überschreibungen noch aktiv sind und diese erst durch einen RCLRSC verschwinden. Ebenso könnte es auch mit dem ILE Konzept und speziell der Nutzung der ACTGRP *NEW zu tun haben.
Ein interessanter Bericht hierzu ist: http://andabe.altervista.org/ILE/07....Questions_.htm

[BenderD]

... ich hab noch nie endcmtctl benötigt, wofür auch. Habe mal nachgesehen - es ist nicht der fehlende commit/rollback (sorry Harkne für die harten Worte). Es sind offene Ressourcen - in eurem Fall wohl offene Dateien, bzw. Zugriffspfade.
Weshalb willst du commit beenden?

D*B

[harkne]

(sorry Harkne für die harten Worte).
D*B

Das ist kein Problem, solange es produktiv bleibt :-)

[harkne]

Eine Frage noch. Wie gesagt rufen wir das Programm aus dem Menü heraus auf. Wenn also mein Startprogramm mit ACTGRP *NEW verlassen wird. Werden dann die Dateien innerhalb dieser Activation Group geschlossen, oder bekomme ich ein Problem damit wenn das Programm vom selben Job erneut aus dem Menü aufgerufen wird?

Und warum sind so viele Dateien offen wenn alle Unterprogramme mit *INLR beendet werden?

Ich kenne das Problem im Zusammenhang mit Funktionen bei denen nur ein RETURN möglich ist, aber die Dateien in unseren Funktionen sind alle nur INPUT eröffnet. Deshalb kann ich es nicht verstehen warum überhaupt noch Dateien außer diesen offen sind. Denn ich sehe auch offene Dateien die mit I/O eröffnet sind und beim ENDCMTCTL noch offen sind und das kann eigentlich nicht sein wenn der *INLR die Dateien schließt.

[BenderD]

Eine Frage noch. Wie gesagt rufen wir das Programm aus dem Menü heraus auf. Wenn also mein Startprogramm mit ACTGRP *NEW verlassen wird. Werden dann die Dateien innerhalb dieser Activation Group geschlossen, oder bekomme ich ein Problem damit wenn das Programm vom selben Job erneut aus dem Menü aufgerufen wird?

ACTGRP *NEW wird bei verlassen des Programms komplett abgebaut, mit allem, was in derselben ACTGRP aufgemacht wurde. Bei erneutem Aufruf fängt alles wieder vollständig frisch von vorne an. Der Unterschied zu einer benamten ACTGRP besteht dann darin, dass man sich von Aufruf zu Aufruf nix merken kann. Falls nicht alles, was dann noch kommt ACTGRP *CALLER hat, kann es zu harten Abbrüchen kommen (muss aber nicht).

D*B, der kein Freund von ACTGRP *NEW ist.

[Fuerchau]

Bei der successiven Umstellung von Alt nach Neu hat sich *NEW nach meiner Erfahrung als pragmatische Übergangslösung bewährt.
Häufig findet man in alten Programmen Commit in den F-Bestimmungen aber beim Verlassen eines Programmes wird schon mal ein Commit-Aufruf vergessen.
Da wundert man sich jahrelang, warum ein Job, der nur ein Menü anzeigt immer noch Satzsperren hält.
Auch wenn man keinen, bzw. kaum, Zyklus anwendet, so ist *INLR beim Verlassen eines Programmes ohne Main() immer noch wichtig, was aber ebenso häufig nicht angewendet wird.
Klar, zu OPM-Zeiten war der Open noch teuer, ins besonders als dei Platten noch langsam waren und z.T. mehr als 100 Dateien geöffnet wurden.
Ins besonders sog. File-Handler, die ihre Dateien geöffnet halten müssen, da sie im Jobleben aus zig anderen Programmen aufgerufen werden und den anderen Aufrufern z.T. die Dateipointer verbogen.
Da hat man dann dankenswerter weise den RCLRSC aufgerufen und alles war erst mal wieder OK.
Im OPM-Umfeldfunktionierte das dann auch.

Nun schnell noch alle Programme und Copystrecken mit CVTRPGSRC umgewandelt und alles neu erstellt. Der RCLRSC bleibt erhalten und die ACTGRP ist immer *CALLER, denn da hat man ja nicht gedreht.
Nur, die Programme laufen nun in QILE und RCLRSC ist erst mal wirkungslos.

Verwendet man dann aber z.B. RCLRSC *CALLER, kann man sogar dem Aufrufer aller Ressourcen wegnehmen ohne dass das Programm das mitbekommt. Wenn es dann auch noch weitermacht, wirds ganz fatal.

Um also nicht neu konzeptionieren zu müssen und so nach und nach neue Verfahren einzuführen hat sich ein SQL-Wrapper mit *NEW aus dem Menü bewährt.
Sobald das eine oder andere neue Programm erstellt wird, fängt man langsam mit benannten ACTGRP's an, baut Services mit *CALLER und sorgt dafür, dass beim Verlassen des Programmes aufgeräumt wird.

Soweit nun die Theorie.

[BenderD]

Bei der successiven Umstellung von Alt nach Neu hat sich *NEW nach meiner Erfahrung als pragmatische Übergangslösung bewährt.

... ich habe noch keine Übergangslösung gesehen, die nicht Endlösung blieb. Später heißt es dann: "Das ist eine gewachsene Lösung" und/oder für "schön" geben wir kein Geld aus. Die entstehenden Wackelhaufen kosten dann ständig Geld für endlose Zyklen von Ein-Fehler-raus-ein anderer-Fehler-den-wir-schon-mal-hatten-rein.

Software wächst nicht! Software schrumpft! Wie einige Fragen in diesem Forum eindrucksvoll illustrieren.

D*B

[harkne]

Eine Frage noch. Was genau macht den Unterschied zwischen *NEW und einer benamten Aktivierungsgruppe aus.
Ich verstehe schon, dass wenn ich mit *NEW ein CL aufrufe, dass es immer einen neuen Namen für eine Activation Group gibt. Wenn ich das Programm mit z.B. ACTGRP(meinName) aufrufe, dass es immer in dieser Activation Group mit neinName läuft. Aber was ist der Vorteil? Bzw. verhält es sich anders wenn ich die Aktivierungsgruppe verlasse und erneut das Programm aufrufe?

[BenderD]

... 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

[Fuerchau]

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.