ENDCMTCTL not allowed. Pending changes active

[Fuerchau]

Das kannst du ja in dem CLLE der *NEW-Actgrp machen.
Wobei STRCMTCTL nur bei Nicht-SQL-Programmen, die Commit in den F-Bestimmungen haben, gemacht werden muss. Du solltest auch, da du je eine ACTGRP startest, den CMTSCOPE(*ACTGRP) verwenden!

Wenn du aber ein SQLRPGLE mit *NEW verwendest und dort einen simplen "values(user) into :username" absetzt, wird dir SQL automatisch entsprechend der "set option commit = *chg;" den STRCMTCTL für die ACTGRP durchführen. Desweiteren kannst du da ja auch einen Commit am Ende absetzen.

Beim Verlassen der *NEW-Gruppe werden dann auch alle Dateien der ILE-Programme mit *CALLER geschlossen. OPM's laufen trotzdem wieder in der *DFTACTGRP(2) mit einem eigenen Commit-Scope!

[BenderD]

Danke, dann auch noch den STRCMTCTL auf CMTSCOPE(*ACTGRP) setzen? Wenn ja, dann wird es mir etwas mulmig bei der Größe der Anwendung.

... zuerst muss mal die ganze Transaktionslogik stimmen, insbesondere, wenn da noch Trigger mit im Spiel sind. Es gibt einen commit-Master, das ist der, der commit /rollback sagt und der dafür verantwortlich ist, dass commit gestartet ist; nutzt man SQL statt Rekord-Löffel-Ekzem, muss man da nix machen. Wenn es denn komplizierter werden soll, startet man beim ersten Aufruf commit mit strcmtlt. Alle commit slaves laufen in * caller (=> der Master in einer benamten), da die slaves auch von anderen Mastern aufgerufen werden könnten, muss commitscope zwingend *ACTGRP sein (so einfach ist die Welt auf der grünen Wiese und für Leute, die keinerlei Ahnung haben, folgt man Madame schlau-schlau).,

Den Verhau von itec (mit Triggern, die mit und ohne commit funktionieren solllen), diskutieren wir in einem anderen Thread).l

Der commit-Master sammelt alle Antworten der slaves ein und wenn alles ok ist, sagt er commit, andernfalls rollback.

So einfach ist die Welt der Datenbanken!!!

D*B

PS: und morgen diskutieren wir über remote connections, wenn man die denn hat.

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

[harkne]

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 :-)

[Fuerchau]

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.