JVAGATE offene Commits im Joblog

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