Zitat Zitat von Tonazzo Beitrag anzeigen
@Fuerchau
Praktisches Beispiel: Artikelstammverwaltung
Der Artikelstamm besteht aus mehreren Dateien: Basisartikeldaten, Lieferantenbezogene Daten, Landbezogend Daten usw.
Für jede Datei gibt es eigene Verwaltungsprogramme - allerdings gibt es ein übergeordnetes Steuerprogramm. Alle CRUD auf die Dateien erfolgen über Serviceprogramm (Pro Datei ein Service) . Das ganze läuft innerhalb einer Transaktion d.h. einige Dateien sind obligatorisch zu füllen und nur wenn diese gefüllt werden, wird der Artikel angelegt sprich "commitet. Die Prüfung und Commit bersorgt das Steuerungsprogramm. Die einzelnen Verwaltungsprogramme liefern die Nachricht angelegt oder nicht angelegt - die wiederum bekommen die Nachricht von den jeweiligen Services.

Also laufen alle Serviceprogramm unter *CALLER (wie bereits mehrfach geschrieben)
und alle an der Artikelneuanlage beteiligten Hauptprogramme inklusive Steuerungsprogramm müssen unter einer ACTGRP (ARTIKELVERWALTUNG) laufen. Ansonsten könnte das übergeordnete Steuerungsprogramm kein Commit/rollback absetzten....Richtig?
... das mit dem Commitscope ACTGRP wirkt wie mehrere Connections zur selben Datenbank - und das ist auch gut so und das sollte man auch so lassen, sonst riskiert man großen Huddel (wieder mal was aus der Schachtel: no risc no fun).

Normalerweise hat man einen Commitmaster (das ist der, der die Transaktion steuert) und Commit slaves (das sind bei euch die Data Access modules). Die Commit slaves müssen unter *CALLER laufen, sonst kriegt man die nicht in die Transaktion rein.

Wenn man nun nicht sicher weiß unter welcher ACTGRP der Master läuft (weil er *CALLER hat) wird es kompliziert und das würde ich vermeiden, indem ich dem Master eine eigene ACTGRP gebe.

Kennt man den Status der vorherigen Transaktion nicht, will aber eine neue anfangen, startet man selbstredend mit ROLLBACK und keineswegs mit COMMIT (besser eien halbe Transaktion wegschmeißen als inkonsistente Daten commiten). (Alos so, wie oben skizziert).

Selbstredend darf keine Datenbank Transaktion mehrere Bildschirmtransaktionen umfassen (deshalb geht das unter CICS und Co. erst garnicht).

D*B