das ist dann wieder der Fall mit einem Commit Master, der Rest sind slaves. sprich: alles in einer ACTGRP, bei V5R4 (ab wann genau, findet man in der Reference) ist es der Möhre Wurscht in wievielen Journalen das journalisiert wird, selbst mit remote Datenbanken muss das gehen, wenn alle DUW (distributed Unit of Work) unterstützen. Dann hast du allerdings wieder dein set connection (was wohl nur mit DUW - ist default beim Compile - den entsprechenden Overhead generiert.
Der Master sagt dann am Ende Komm mit (Commit), oder lass es bleiben (Rollback) und die Updates machen dann die entsprechenden Datenzugriffsprogramme als slaves alle mit *CALLER gewandelt.

Sicherlich kann man das alles viel komplizierter machen, wenn man zusätzliche Probleme haben will, wie so vieles bei ILE.

D*B

D*B

Zitat Zitat von Fuerchau Beitrag anzeigen
Solange man sich in einer Applikation bewegt ist das ja auch handlebar.
Leider gibt es aber auch manchmal Schnittstellenprogramme zwischen verschiedenen ERP's, die natürlich in jeweils eigenen Journalen aufzeichnen.

Ich muss also z.B. aus ERPA mit JournalA daten lesen, als verarbeitet markieren (unter Commit) und in ERPB mit JournalB schreiben, natürlich auch mit Commit (2-Phase).
Hier hilft tatsächlich nur eine Trennung der Aktionen in 2 ACTGRP's, mit separatem Commit.

Vielleicht gibts ja inzwischen Erweiterungen, so dass ich auch auf der AS/400 ein 2-Phase-Commit über 2 (logische) DB's erreichen kann.

Birgitta sollte uns mehr dazu sagen können.

Zu COBOL sei noch gesagt, dass ich einen OPEN selber codieren muss. Wenn CMTCTL nicht gestartet ist, gibt der Open einen Status raus.
Wenn ich den ignoriere, kommts später dann zu MCH-Fehlern, da ich auf nicht angelegte Puffer zugreife.

Bei RPG/LE gibts bei impliziten oder explizenten Open ohne (E) eine Exception-Nachricht.

Allerdings gibts bei der Definition der Datei sowohl bei RPG als auch COBOL eine unterlassbare Angabe, dass diese Datei unter CMTCTL zu verarbeiten ist.
Ohne Angabe, erfolgt keine Prüfung auf aktives CMTCTL, so dass ggf. das übergeordnete Programm über Commit/Rollback oder nur Journalsierung entscheidet.