View Full Version : ENDCMTCTL not allowed. Pending changes active
Ggf. kann ein ENDCMTCTL auch nicht ausgeführt, wenn eine explizit benannte ACTGRP noch besteht, die kann man allerdings nicht sehen, wenn die oberste Ebene verlassen wurde.
... ein endcmtctl wirkt immer nur auf die aktuelle commit definition, dem siind die anderen egal. ENDCMTCTL ist eigentlich nur erforderlich, wenn man den scope (*JOB/*ACTGRPDFN) wechseln will und da ich von dem scope *JOB ohnehin abrate, rate ich auch von ENDCMTCTL ab. Das gehört alles zu den Problemen, die man sich ersparen kann!!!
D*B
... ein endcmtctl wirkt immer nur auf die aktuelle commit definition, dem siind die anderen egal. ENDCMTCTL ist eigentlich nur erforderlich, wenn man den scope (*JOB/*ACTGRPDFN) wechseln will und da ich von dem scope *JOB ohnehin abrate, rate ich auch von ENDCMTCTL ab. Das gehört alles zu den Problemen, die man sich ersparen kann!!!
D*B
Danke, dann auch noch den STRCMTCTL auf CMTSCOPE(*ACTGRP) setzen? Wenn ja, dann wird es mir etwas mulmig bei der Größe der Anwendung.
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!
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.
(sorry Harkne für die harten Worte).
D*B
Das ist kein Problem, solange es produktiv bleibt :-)
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.
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.
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.
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
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?