JVAGATE offene Commits im Joblog

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

[BenderD]

... zumindest für den local change (letzte Meldung), müsste das im Journal zu finden sein.

D*B

[itec01]

Hallo,
es ist so, dass JVAGATE offene API commits stehen lässt und zwar aus dem Program CCEXIT kommend. Beim Beenden des Jobs werden die dann zurückgefahren.
Schon bei dem Connect zur fremden DB tauchen die Commits auf und verschwinden bis zum Ende des Programmes nicht.
Anbei die hardcopies:

[BenderD]

... JVAGATE registriert eine externe Commit Ressource per API QTNADDCR, um commit Operationen auf die externen Connects auszuführen, wenn lokal eine commit Operation angefordert wird. Der Commit Handler CCEXIT wird dann von der Datenbank nach jeder Commit Operation automatisch aufgerufen und propagiert die commit Operation auf die remote Datenbanken. Wenn dabei lokale Commit Definitionen offen bleiben, ist das eine Defektproblem von OS/400 bzw. neudeutsch I.

D*B

[itec01]

... wenn lokal eine commit Operation angefordert wird. Der Commit Handler CCEXIT wird dann von der Datenbank nach jeder Commit Operation automatisch aufgerufen und propagiert die commit Operation auf die remote Datenbanken. Wenn dabei lokale Commit Definitionen offen bleiben, ist das eine Defektproblem von OS/400 bzw. neudeutsch I.

D*B

Wie ist das mit den lokalen db's zu verstehen? In meinem Beispiel gibt es keine lokalen DB's und wie in meiner Beschreibung zu erkennen, ist auch nur das JVAGATE API offen, sonst nichts. Daher verhält sich JVAGATE meiner Meinung nicht sauber und lässt Commits offen.