ENDCMTCTL not allowed. Pending changes active

[harkne]

Hallo zusammen,

ich beziehe mich auch auf mein vorheriges Problem
http://newsolutions.de/forum-systemi-as400-i5-iseries/threads/23112-MCH3402-Get_Random_DB_Record

Nachdem ich ja nun das aufrufende CLP Programm in ein CLLE Programm geändert und mit ACTGRP(*NEW) umgewandelt habe, bekomme ich nun wieder den im Titel angegebenen Fehler.

Wir hatten diesen Fehler bereits vor längerer Zeit und haben dann vor dem ENDCMTCTL den RCLRSC rein gemacht, seit dem war Ruhe.
Nachdem ich nun ein CLLE daraus gemacht habe tritt der Fehler wieder auf.
Aber nur ganz selten, denn das Programm wird zig-fach am Tag aufgerufen

Ich poste hier mal das CL



PGM PARM(&PI@RESULT &PI@PRCI)
DCL VAR(&PI@RESULT) TYPE(*CHAR) LEN(1)
DCL VAR(&PI@PRCI) TYPE(*CHAR) LEN(3)
DCLPRCOPT DFTACTGRP(*NO) ACTGRP(*NEW) BNDDIR(SPE)
STRCMTCTL LCKLVL(*CHG) CMTSCOPE(*JOB)
MONMSG MSGID(CPF8351)
CHGJOB DEVRCYACN(*MSG)
CALL PGM(PBS05R) PARM(&PI@RESULT &PI@PRCI)
MONMSG MSGID(CPF0000)
CHGJOB DEVRCYACN(*ENDJOB)
RCLRSC
ENDCMTCTL
MONMSG MSGID(CPF8350)
ENDPGM


Es kommen nun beim ENDCMTCTL folgende Fehler im Joblog

ENDCMTCTL not allowed. Pending changes active.

0 pending changes being rolled back.
Pending changes were found for local resources while ending commitment definition *JOB with logical unit of work identifier APPN.SIEGER1.X'3241D283F7E5'.00011. There are 1 journals with a total of 0 record level changes. There are 0 pending object level changes. There are 0 API commitment resources. The system attempts to roll back these changes
before commitment control is ended. If all resource counts are zero, then the roll back was the result of a cursor positioning after the last successful commit or rollback.

Commitment control ended with 0 local changes not committed.



Wenn also keine offenen Commits mehr offen sind, was bedeutet der Satz
if all resource counts are zero, then the roll back
was the result of a cursor positioning after the last successful commit or rollback.

Hier sind die letzten Journaleinträge vor dem Absturz



3218466629 R UP USTRNP SPEFIL CK10156522 17:33:19
3218466630 R UB SCSYSP SPEFIL CK10156522 17:33:19
3218466631 R UP SCSYSP SPEFIL CK10156522 17:33:19
3218466634 R PT CDTRNP SPEFIL CK10156522 17:33:19
3218466635 R UB PKTRNP SPEFIL CK10156522 17:33:19
3218466636 R UP PKTRNP SPEFIL CK10156522 17:33:19
3218466637 R DL UPTRNP SPEFIL CK10156522 17:33:19
3218466638 C CM CK10156522 17:33:19
3218486320 R DL BIDTRNP SPEFIL CK10156522 17:36:14
3218486322 R DL RLMSTP SPEFIL CK10156522 17:36:14
3218486323 C EC CK10156522 17:36:14


Den eigentlichen ENDCMTCTL wegen dem er abgestürzt ist, sieht man hier nicht, er wurde nach dem CM um 17:33:19 ausgeführt.

Als Anmerkung die letzten beiden Deletes laufen nicht unter COMMIT

Die Auszüge aus dem Joblog was ich weiter oben gepostet habe waren vom EC den man hier sieht.

Ich bin jetzt in einen laufenden Job rein und habe diesen CALLSTACK

659

Habe ich ein Problem mit dem QDMACCIN?

Vielen Dank für Eure Hilfe

Viele Grüße Harald

[BenderD]

... du hast ein Problem mit deinem Programm! Es gibt ganz offenkundig Abläufe, wo der commit/rollback nicht erreicht wird. Dein RCLRSC hat dann einen Rollback vorausgeschickt, der RCLACTGRP hat einen commit vorausgeschickt. Ohne Sanierung des Wackelhaufens wird das nix!!!

D*B

PS: Du musst Dir die Commit Cycle IDs im Journal mit anschauen.

[harkne]

Ich habe keinen RCLACTGRP. Nirgendwo
Der RCLRSC erfolgt vor dem ENDCMTCTL und es sind keine Commits offen.

[BenderD]

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

D*B

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

[Fuerchau]

Zu RCLRSC, siehe auch hier:
https://www.ibm.com/docs/en/i/7.4?topic=management-reclaim-resources-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?topic=group-non-default-activation-deletion

Und bei SQL wird unterschieden zwischen normalen (commit) und abnormalem (rollback) Ende unterschieden.
https://www.ibm.com/docs/en/i/7.1?topic=scoping-commitment-control-during-activation-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.