JVAGATE offene Commits im Joblog

[BenderD]

... so wie beschrieben! Du startest ein Programm unter commit, das erstellt eine lokale commit Definition, ArdGate hängt einen exit handler dran und propagiert genau die commit Operationen, die Dein Programm ausführt. Nicht mehr und nicht weniger. Das Problem liegt entweder in Deinem Programm oder der Datenbank fehlt ein PTF. ArdGate startet weder transactions, noch schreibt ArdGate irgendwas, was Dein Programm nicht anfordert.

D*B

[itec01]

Ok, Dieter, wir lassen das erst mal so. Die SQL's funktionieren ja.
Danke Dir.

[itec01]

Noch eine Frage an die Profis bezüglich JVAGATE und Commit für beide Welten.
Anforderung:
Tabellen stehen in MySQL und auf der AS/400.
1. Step: mysql tabellen lesen und Sätze sperren
2. gelesene Informationen verarbeiten und mit zusätzlichen Information aus AS/400 Tabellen in eine AS/400 Tabelle schreiben (RPG WRITE). Diese liegt auch unter Commit
3. Wenn die AS/400 Tabelle sauber erzeugt wird, erfolgt der SQL update auf die MySQL Tabellen
4. Wenn OK, SQL commit auf MySQL und RPG Commit auf AS/400 Tabelle

Dies haben wir in einem RPG Programm versucht, leider bricht das Programm beim OPEN der AS/400 Tabelle ab. Ich habe hier etwas gelesen, dass es wohl besser wäre 2 Programme in unterschiedlichen Aktivierungs Gruppen zu machen, bin mir aber nicht sicher.
Wir macht Ihr das?
Danke.
Gruß Klaus

[BenderD]

Noch eine Frage an die Profis bezüglich JVAGATE und Commit für beide Welten.
Anforderung:
Tabellen stehen in MySQL und auf der AS/400.
1. Step: mysql tabellen lesen und Sätze sperren
2. gelesene Informationen verarbeiten und mit zusätzlichen Information aus AS/400 Tabellen in eine AS/400 Tabelle schreiben (RPG WRITE). Diese liegt auch unter Commit
3. Wenn die AS/400 Tabelle sauber erzeugt wird, erfolgt der SQL update auf die MySQL Tabellen
4. Wenn OK, SQL commit auf MySQL und RPG Commit auf AS/400 Tabelle

Dies haben wir in einem RPG Programm versucht, leider bricht das Programm beim OPEN der AS/400 Tabelle ab. Ich habe hier etwas gelesen, dass es wohl besser wäre 2 Programme in unterschiedlichen Aktivierungs Gruppen zu machen, bin mir aber nicht sicher.
Wir macht Ihr das?
Danke.
Gruß Klaus

... vom Mix SQL mit RLA ist unter commit generell abzuraten! Commitscope ist unter SQL die ACTGRP, es muss also die ganze Transaktion in derselben ACTGRP stattfinden.
Am einfachsten ist satzweise Verarbeitung:
- lesen MySQL
- Wechsel des Connects zur lokalen Datenbank mit set connection
- Verarbeitung auf der AS/400
- set connection zur remote DB
- schreiben auf MySQL
- wenn alles geklappt hat commit, sonst rollback

Das ganze dann in einer Schleife bis man fertig ist.
Am Anfang remote connect, am Schluss release und commit.

D*B

PS: bricht ab ist ein wenig zu unspezifisch, um dazu was zu sagen.

[itec01]

Danke, dann sollte vermutlich auch der Commit/Rollback der AS/400 Tabelle mit SQL verarbeitet werden und nicht mit nativem RPG Chain, update, Commit oder wäre das egal? Wir würden gerne nicht mit SQL auf die AS/400 die commits machen.
Fehlermeldung beim open der AS/400 Tabelle:
CPF4326 Commitment Definition *N not valid for open of ASAP999P.

[BenderD]

Danke, dann sollte vermutlich auch der Commit/Rollback der AS/400 Tabelle mit SQL verarbeitet werden und nicht mit nativem RPG Chain, update, Commit oder wäre das egal? Wir würden gerne nicht mit SQL auf die AS/400 die commits machen.
Fehlermeldung beim open der AS/400 Tabelle:
CPF4326 Commitment Definition *N not valid for open of ASAP999P.

... der commit sollte per sql erfolgen! Ob gerne oder nicht gerne, ich kann nur empfehlen das alles mit SQL zu machen. Mit dem Mix holt man sich nur Peobleme, die man nicht haben muss.

CPF4326 liegt daran, dass commit nicht gestartet ist. SQL erledigt das automatisch.

D*B

[itec01]

OK, danke, dann auch den Insert und update auf die AS/400 per SQL?
wenn Commit/Rollback, dann 1 je Datenbank oder reicht einmal und alles ist gut?

[BenderD]

OK, danke, dann auch den Insert und update auf die AS/400 per SQL?
wenn Commit/Rollback, dann 1 je Datenbank oder reicht einmal und alles ist gut?

... alles per sql! Einmal commit/rollback am Ende der Transaktion und gut ist!

D*B

[itec01]

... alles per sql! Einmal commit/rollback am Ende der Transaktion und gut ist!

D*B

Dann aber mit SQL commit/rollback, richtig?

[Fuerchau]

Das ist korrekt. Mit RPG Commit/Rollback klappt es nicht.
Ich verwende i.Ü. immer den exec SQL für commit/rollback.
Dann kommt man keinen Fehler von der RPG-Runtime.
Übrigens:
Auch bei reinen Lesevorgängen ist häufig bei fremden DB's ein Commit erforderlich, da hier gerne Autotransaction verwendet werden.

[itec01]

@Baldur, vielen Dank, hat nun geklappt. Ein Commit / Rollback hat gereicht und beide Welten wurden schön zurückgefahren.
@Dieter, auch Dir vielen Dank, aber noch eine Frage:
In deinem Beispiel Programm verwendest Du *SQL als naming convention. Muss das so sein? Wir haben das Problem mit der Bibliotheksliste, weil die im CL zuvor dementsprechend nach test / live Umgebung gesetzt wird.
Bei *SQL greift diese Liste ja nicht und es wird stattdessen das Schema genommen, welches dem User entspricht.
Danke.
Klaus

[Fuerchau]

Letzteres ist falsch, da man auch bei der Erstellung sowie zur Laufzeit die sog. Standardcollection setzen kann.
Da eine DB i.d.R. in einer Lib zu sein hat, andere nennen das Schema, gibts für dieses Argument eigentlich keine Begründung.
Da nun jede ACTGRP seine eigene SQL-Sitzung hat, kann eben jede ACTGRP auch sein eigenes Standardschema verwenden.
Bei Oracle z.B. kann ich mit *SYS gar keine Verbindung aufmachen bzw. auf irgendeine Tabelle zugreifen.