ENDCMTCTL not allowed. Pending changes active

[Fuerchau]

Zu RCLRSC, siehe auch hier:
https://www.ibm.com/docs/en/i/7.4?to...ources-command

Wenn ACTGRP *NEW verlassen wird, wird diese auch aufgeräumt, ein RCLRSC ist nicht mehr erforderlich.
https://www.ibm.com/docs/en/i/7.2?to...ation-deletion

Und bei SQL wird unterschieden zwischen normalen (commit) und abnormalem (rollback) Ende unterschieden.
https://www.ibm.com/docs/en/i/7.1?to...tion-group-end

Überschreibungen wirken nur auf die ACTRGRP wenn nicht *JOB angegeben wird. Sie wirken auch nur ab der aktuellen Callebene. Wird diese verlassen, verschwinden auch die OVR's außer den *JOB-OVR's, was man sowieso vermeiden sollte. Ansonsten reicht da auch ein DLTOVR FILE(*ALL) LVL(*JOB).
Wenn man dann immer noch unsicher ist, kann auch ein TFRJOB an QINTER mit dem Startprogramm durchführen.

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.
Diese kann man tatsächlich mit RCLACTGRP(*ELIGIBLE), allerdings mit nicht zu verachtenden Konsequenzen, ins besonders bei Triggern mit Named ACTGRP.

Ob offene commits relevant sind, kann man an z.B. den Satzsperren des Jobs ansehen. Sind da keine aktiv, ist ein ENDCMTCTL sowieso unnötig.

[itec01]

Ich denke inzwischen auch, dass es an den offenen Dateien hängt. Nur das wäre nun blöd, weil wir dann gezielt die Files schließen oder die Programme mit *INLR beenden müssen,
Im DSPJOB gibt es eine Menge von Files, die noch offen sind. Alle zwar ohne offene Commits, aber noch offen.
Vlt. noch einmal eine kurze Info zu der aktuellen Logik:
PGM 1 CLLE mit ACTGRP *NEW, STRCMTCTL LCKLVL(*CHG) CMTSCOPE(*JOB)
Aufruf PGM 2 RPGLE (ACTGRP *CALLER) plus viele weitere andere Programme, inkl. SQLRPGLE.

Zurück zu PGM 1 mit ENDCMTCTL, ohne RCLRSC.

Das müsste doch so passen, oder?

Wir analysieren nun mal die Folgeprogramme, welche von denen mit RETURN beendet werden.
Zurück zur alten Logik mit RCLRSC ist leider auch keine Option, weil dann das Trigger Problem wieder auftritt.

Danke für die Hinweise.

[BenderD]

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

[itec01]

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

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