Commitment Control und Trigger Programme.

[Tonazzo]

Du sagst doch, dass die History journalisiert wird.
Dann sollte der Rollback diese doch auch löschen.


Habe mich wohl falsch ausgedrückt.
Das Verwaltungsprogramm ändert eine Kopf.- sowie eine Positionsdatei.
An der Positionsdatei hängt ein Trigger, der die Änderungen in eine History schreibt.
Das Triggerprogramm selbst hat keine Commitsteuerung (es fehlt das Schlüsselwort in der F-Anweisung).
Im Verwaltungsprogramm wird beim Löschen einer Position ein Fehler festgestellt, so dass ein Rollback
initiiert wird. D.H alle bis dahin gelöschte Positionssätze werden in der PosDatei wiederhergestellt.
Also dachte ich, dass das Triggerprogramm die Änderung (die ja keine ist - habe ich jetzt gelernt)
auch mitbekommt, so dass in der History ersichtlich wird, dass eine Wiederherstellung erfolgt ist.
Da es aber kein Rollback-Event gibt, wird scheinbar das Triggerprogramm gar nicht angestossen.

Mein nächster Schritt wäre jetzt:
Aus dem Trigger ein SQLRGPLE zu machen und die Fortschreibung in die History per SQL durchzuführen.
Da der Trigger unter ACTGRP(*CALLER) läuft - sollte das Schreiben der History auch unter der
"Commithoheit" des Verwaltungsprogramm laufen oder?!?

Viele Grüße

[Fuerchau]

Dies ist egal, ob du den Trigger per SQL oder native schreibst.
Wichtig ist lediglich, dass deine History im selben Journal aufgezeichnet wird und dein Trigger mit Commitsteuerung für die Datei in derselben ACTGRP läuft ohne selber Commit/Rollback durchzuführen.
Dann wird im Rollbackfall die History auch zurückgedreht.

Kleiner Nachteil: Ohne Journal erfährt man nicht, dass da was hätte passieren können.

Es gibt noch den Befehl "Add Commitressource". Mit dessen Hilfe kannst du zusätzlich auf Commit/Rollback-Ereignisse reagieren.

[Tonazzo]

Mein Trigger Programm ist jetzt auf SQL umgestellt. Es hat keine Commit/Rollback Anweisungen.
Es macht bei jedem EVENT einen einfachen INSERT in die History Datei.
Es reagiert auf die Commit/Rollback Steuerung des Verwaltungsprogramm --> Alles gut.

Wenn ich jetzt aber in der Positionsdatei per UPDDTA ein Satz ändere - wird er zwar in der
Historydatei nachgezogen - aber beim Abmelden der Session aus der History wieder entfernt,
weil keine Commitanweisung durchgeführt wurde.

Oh mann wenn das alles so einfach wäre:(

[Fuerchau]

Eigentlich ist es das!
Wenn im SQLTrigger Commit definiert ist, durch Option Commit=*CHG, wird automatisch ein STRCMTCTL durchgeführt wenn dieser noch fehlt.
Anschließend wird deine Operation durchgeführt.
Sollte z.B. vor dem Update deiner Hauptdatei noch keine Commitdefintion existieren kann es nun 2 Verhalten geben:

Before-Trigger: Beide Updates werden in den Commitzyklus gepackt und werden mit Commit bestätigt/Rollback gelöscht.
After-Trigger: Der Update der Hauptdatei läuft noch ohne Commit, der Trigger-Update dann mit commit. Beim Rollback wird dann nur die History gelöscht.

Deshalb ist es gefährlich, z.B. nur After-Trigger zu haben.
Programme wie UPDDTA, die kein Commit unterstützen dürfen nicht so einfach verwendet werden.
Auch STRSQL startet im Regelfall mit Commit(*NONE), kann aber per F13 geändert werden.

Sicherlich ist ein Before-Trigger (Achtung: alle 3!) sinnvoll um im Zweifel fehlende Commitsteuerung zu aktivieren!

Klar ist auch, dass bei normalem Jobende eine Commit und bei abnormalem Jobende ein Rollback durchgeführt wird.
Wenn eine Commit-Definition auf ACTGRP geht, dann wird die ACTGRP abnormal beendet, was einen Rollback auslöst.

Übrigens bleiben bei fehlendem Commit alle Satzsperren erhalten!