JVAGATE offene Commits im Joblog

[itec01]

Moin Zusammen,
wir haben nun endlich mal JVAGATE aktiviert.
Umgebung:
MySQL DB

Der Zugriff funktioniert, leider wird beim Verlassen des Programmes bzw. Ende des Jobs ein Fehler protokolliert, weil pending commits offen sind. Dieses Phänomen hatte ich auch schon beim STRSQL.
Das RPG macht nichts anderes wie auf dem mysql eine Tabelle zu duplizieren. Später gibt es andere RPG Programme, die sich Daten aus mysql ziehen und auch entsprechend updaten.

RPG Auszug:
c/exec sql
c+ set option commit=*CHG
c/end-exec
c/exec sql
c+ connect to asap user :W_User using :W_Pw
c/end-exec
c/exec sql
c+ drop table centralno_test
c/end-exec
c/exec sql
c+ create table centralno_test like centralno
c/end-exec
c/exec sql
c+ insert into centralno_test select * from centralno
c/end-exec
c/exec sql
c+ release asap
c/end-exec
c/exec sql
c+ commit
c/end-exec
c/exec sql
c+ connect reset
c/end-exec

Fehlerbeschreibung Joblog
CPC2191 Completion 00 17/01/23 00:10:56,194444 QLIDLOBJ QSYS 06E6 Q
To module . . . . . . . . . : QC2SYS
To procedure . . . . . . . : system
Statement . . . . . . . . . : 13
Message . . . . : Object R830874 in JVAGATE type *DTAQ deleted.
CPI8351 Information 10 17/01/23 00:10:56,195598 QTNEND QSYS 1C16 Q
Message . . . . : 1 pending changes being rolled back.
CPF9801 Escape 40 17/01/23 00:10:56,196824 QCLRDTAQ QSYS 0269 J
To module . . . . . . . . . : JVAGATE
To procedure . . . . . . . : CLEARRETURNQ
Statement . . . . . . . . . : 476
Message . . . . : Object R830874 in library JVAGATE not found.
From module . . . . . . . . : QLEDEH
From procedure . . . . . . : Q LE leDefaultEh
Statement . . . . . . . . . : 179
To module . . . . . . . . . : CCEXIT
To procedure . . . . . . . : WORK
Statement . . . . . . . . . : 226
Message . . . . : Application error. CPF9801 unmonitored by JVAGATE at
statement 0000000476, instruction X'0000'.
*NONE Completion 17/01/23 00:10:56,200321 CCEXIT JVAGATE *STMT QTNROLLB
From module . . . . . . . . : CCEXIT
From procedure . . . . . . : JOBLOGOUT
Statement . . . . . . . . . : 257
Message . . . . : JDBCGATE: CCEXIT fired 2
CPF8356 Diagnostic 30 17/01/23 00:10:56,204489 QTNEND QSYS 1C16 QWTPITP2
Message . . . . : Commitment control ended with 1 local changes not
committed.
CPF1164 Completion 00 17/01/23 00:10:56,205512 QWTMCEOJ QSYS 0161 *EXT
Message . . . . : Job 830874/MARB/ASAPCOPY ended on 17/01/23 at 00:10:56;
0,013 seconds used; end code 0 .


Die SQL's wurden alle ausgeführt.
Im Dump von JVAGATE kann ich nichts erkennen. Da sieht alles gut aus. Die Frage ist woher der offene commit kommt. Eventuell AS/400 Umgebung spezifisch.

Vlt. hatte jemand ähnliche Probleme.

Danke.
Klaus

[BenderD]

Hallo Klaus,

erst mal sollte man immer die remote Verbindung beenden, bevor der Job endet. Am einfachsten und saubersten, macht man nach Beendigung der remote Aktion einen release, gefolgt von commit.
Weiterhin empfiehlt es sich, dafür zu sorgen, dass die remote Aktionen nicht in der DFTACTGRP stattfinden.
Näheren Aufschluss könnte noch das Javalog zeigen, dafür sollte man das loglevel in log4j.properties auf debug setzen, den Serverdienst neu starten und dann den Ablauf wiederholen.

Sendet man das logfile to "the wellknown email adress of the author", bekommt man meist recht schnell eine freundliche Antwort.

D*B

PS: hat die Aktion an sich geklappt?

[itec01]

Hallo Dieter,
sorry, hatte es oben vergessen und jetzt eingefügt. Ja, wir machen den release und dann den commit.
Ja, die Aktionen wurden auf dem mySQL ausgeführt und verarbeitet.
Das mit der Default activation group kann ich gerne testen. Das loglevel steht auf debug und ich kann leider nichts erkennen, dass irgendetwas unsauber mit dem commit ist.
Gibt es vlt. noch etwas beim umwandeln des RPG's zu beachten?
Gruß

[BenderD]

Hallo Dieter,
sorry, hatte es oben vergessen und jetzt eingefügt. Ja, wir machen den release und dann den commit.
Ja, die Aktionen wurden auf dem mySQL ausgeführt und verarbeitet.
Das mit der Default activation group kann ich gerne testen. Das loglevel steht auf debug und ich kann leider nichts erkennen, dass irgendetwas unsauber mit dem commit ist.
Gibt es vlt. noch etwas beim umwandeln des RPG's zu beachten?
Gruß

... so wie das Joblog aussieht, kommt die Fehlermeldung erst beim Ende des Jobs. Remote kann da nichts mehr offen sein, das stellt der Release/Commit sicher. Warum die lokale DB da meint, dass da was offen sein könnte, sehe ich erst mal nicht - es sei denn ihr habt lokal in dem Job noch irgendwas mit der Datenbank gemacht? Hin und wieder gab es da PTF Probleme mit dem Commit Handling und registrierten Commit Ressourcen - ist zwar unschön, aber wenn alles passt, würde ich da keinen Aufwand rein stecken und simpel warten, bis ein Datenbank PTF das korrigiert und bis dahin die Fehlermeldung ignorieren.

mfG

D*B

[itec01]

Ich glaube der Fehler kommt aus JVAGATE / CCEXIT. Ich versuche es aber noch mit der anderen Activation Group.
Ich hatte noch gefragt, ob es spezielle Umwandlungsparameter des SQLRPG's gibt.
Gruß

[BenderD]

... wenn wir da in die technischen Details gehen wollen: im Joblog kommt die Fehlermeldung CPI8351 nach dem DLTDTAQ, welches in der Exit Routine von JVAGATE durchgeführt wird (letztere wird über einen registrierten Exithandler aufgerufen). Die finale CPF8356 nennt explizit 1 local changes und wird (wahrscheinlich) bei der autoatischen Deregistrierung der Commit ressource ausgelöst. Falls ihr lokal nichts mit der Datenbank und commit gemacht habt, ist dies fehlerhaft seitens des Betriebssystems.

Was die Erstellung der SQLRPGs angeht, hält man sich am besten an die Beispiele, die in dem Zipfile auf Sourceforge zu finden sind. Wichtig sind dabei, COMMIT(*CHG oder *CS), naming(*SQL), DATFMT(*ISO), TIMFMT(*ISO), RDB(*LOCAL) und ACTGRP(some_name).

mfG

Dieter

[itec01]

... wenn wir da in die technischen Details gehen wollen: im Joblog kommt die Fehlermeldung CPI8351 nach dem DLTDTAQ, welches in der Exit Routine von JVAGATE durchgeführt wird (letztere wird über einen registrierten Exithandler aufgerufen). Die finale CPF8356 nennt explizit 1 local changes und wird (wahrscheinlich) bei der autoatischen Deregistrierung der Commit ressource ausgelöst. Falls ihr lokal nichts mit der Datenbank und commit gemacht habt, ist dies fehlerhaft seitens des Betriebssystems.

Was die Erstellung der SQLRPGs angeht, hält man sich am besten an die Beispiele, die in dem Zipfile auf Sourceforge zu finden sind. Wichtig sind dabei, COMMIT(*CHG oder *CS), naming(*SQL), DATFMT(*ISO), TIMFMT(*ISO), RDB(*LOCAL) und ACTGRP(some_name).

mfG

Dieter

OK, Danke Dir. So machen wir es.
Gruß Klaus

[Fuerchau]

Wenn die ACTGRP benannt ist hat man eine eigene Commit-Umgebung und beim Verlassen des Programmes / der ACTGRP wird bereits aufgeräumt.
Übrigens verwende ich Ardgate mit ACTGRP(*NEW) damit die ACTGRP nicht irgendwie offen bleibt (*INLR = *OFF).
Auch ein häufiges Erstellen neuer ACTGRP's dauert ja nicht mehr lange.

[itec01]

Wenn die ACTGRP benannt ist hat man eine eigene Commit-Umgebung und beim Verlassen des Programmes / der ACTGRP wird bereits aufgeräumt.
Übrigens verwende ich Ardgate mit ACTGRP(*NEW) damit die ACTGRP nicht irgendwie offen bleibt (*INLR = *OFF).
Auch ein häufiges Erstellen neuer ACTGRP's dauert ja nicht mehr lange.

Mal eine Laienfrage, weil wir selten die ACT Groups manipulieren.
Was muss ich machen, damit das RPG (mySQL Access) unter einer eigenen ACTGRP läuft?
SBMJOB call CL, call RPG (mySQL).
Dankeschön.
Gruß Klaus

[BenderD]

Mal eine Laienfrage, weil wir selten die ACT Groups manipulieren.
Was muss ich machen, damit das RPG (mySQL Access) unter einer eigenen ACTGRP läuft?
SBMJOB call CL, call RPG (mySQL).
Dankeschön.
Gruß Klaus

... die ACTGRP hängt am Programm, bzw. SrVPGM und wird beim CRTPGM, bzw. CRTSRVPGM festgelegt. Beim SBMJOB muss/kann man da nix machen.

D*B

[Fuerchau]

Im Header der Quelle definieren:
ACTGRP('NAME') DFTACTGRP(*NO)

Serviceprogramme sollten nach Möglichkeit (bis auf gezielte Ausnahmen) nur *CALLER haben, was der Default ist.

[itec01]

Danke, aber die Änderungen der Activation Group hat das Problem nicht gelöst. Wir schauen nun, welche Commits offen sind.