Commitment Control und Trigger Programme.

[Tonazzo]

Hallo,

Ich habe ein Erfassungsprogramm zur Verwaltung von Parametern geschrieben. Die Parameter werden in eine Kopfdatei und dazugehörige Positionsdatei geschrieben/geändert/gelöscht. Die Dateizugriffe sind jeweils in unterschiedliche Prozeduren eines Serviceprogrammes ausgelagert. Das Serviceprogramm läuft unter der ACTGRP(*CALLER) und alle Dateizugriffe sind mit SQL realisiert.

An der Positionsdatei hängt ein Trigger Programm dran. Dieses läuft ebenfalls unter ACTGRP(*CALLER) - allerdings wird in diesem Programm kein SQL benutzt. Die Änderungen/Neuanlage/Löschungen der Sätze aus der Positionsdatei werden in eine History Datei (mit write) aufgezeichnet.

Mein Verwaltungsprogramm läuft unter der ACTGRP(Name des Programmes). In diesem Programm wird mit commit(e) bzw. rolBk gearbeitet.

Jetzt folgender Fall:
Der Benutzer will im Verwaltungsprogramm den Kopfsatz löschen - in diesem Fall sollen zuerst alle Positionen gelöscht werden. Ist das Löschen der Positionen fehlerfrei gelaufen, wird danach der Kopfsatz gelöscht und ein Commit wird abgesetzt - im Fehlerfall wird ein rolBk abgesetzt und alle bis dahin gelöschten Positionen werden wiederhergestellt.

Um das zu testen habe ich eine Position gesperrt, so dass diese nicht gelöscht werden konnte. Das Programm hat 4 Positionen gelöscht bis es auf ein LCKW stehen blieb - Wartezeit 60Sek - In der History standen die 4 gelöschten Sätze. DSPFD auf Positionsdatei = Anzahl gelöschter Sätze = 4. Nach Ablauf der Dateiwartezeit wurde das rolBk ausgeführt.
Die 4 Positionen wurden wiederhergestellt. DSPFD auf Positionsdatei = Anzahl gelöschter Sätze = 0.
In der History standen die 4 gelöschten Sätze noch drin - ich hätte jetzt aber erwartet das diese Sätze aber noch zusätzlich als Neuanlage auftauchen würden, da die Löschung durch das rolBk rückgängig gemacht wurden.
Ich kann verstehen, dass das Trigger Programm den commit/rolbck nicht mitmacht - da ja auch keine commitanweisung in der F-Bestimmung steht. Aber das Wiedereinstellen der Sätze in die Positionsdatei durch das rolbck wurde aber vom Trigger Programm auch nicht registriert.

Wo liegt das Problem bzw. wäre in diesem Fall Best Practice?

Für die Hilfe bedanke ich mich im Voraus und sorry für den Roman.

Viele Grüße

[BenderD]

... warum nicht einfach eine referential constraint mit cascade?

BTW: SQL und RPG commit sollte man nicht mixen.
und achaj: ein Rollback auf ein delete ist kein insert.

D*B

[Fuerchau]

Das Triggerprogramm sollte (aus dem Bauch heraus) auch in ACTGRP(*CALLER) laufen.
Die Logdatei wird wohl nicht journalisiert sonst müsstest du in deinem Triggerprogramm Commit/Rollback bei eigener ACTGRP durchführen.

Ich denke, im Rollbackfall wird der Trigger nicht aufgerufen.

[Tonazzo]

... warum nicht einfach eine referential constraint mit cascade?

BTW: SQL und RPG commit sollte man nicht mixen.
und achaj: ein Rollback auf ein delete ist kein insert.

D*B

Hallo,
ein Rollback auf ein delete ist kein insert. Aber eine Änderung am Satz.
Und somit sollte das Triggerprogramm darauf reagieren.

[Tonazzo]

Das Triggerprogramm sollte (aus dem Bauch heraus) auch in ACTGRP(*CALLER) laufen.
Die Logdatei wird wohl nicht journalisiert sonst müsstest du in deinem Triggerprogramm Commit/Rollback bei eigener ACTGRP durchführen.

Ich denke, im Rollbackfall wird der Trigger nicht aufgerufen.

Das Triggerprogramm läuft bereits unter ACTGRP(*CALLER). Die Logdatei bzw. Historydatei wird
ebenfalls laut DSPFD journalisiert.

Aber warum soll im Rollbackfall der Trigger nicht aufgerufen werden. Ereignisbedingung des Trigger an der Positionsdatei: TRGEVENT *INSERT/*UPDATE/*DELETE

[Fuerchau]

Nur gibt es keinen Trigger für UNDELETE, UNINSERT, UNUPDATE.
Und deine Logdatei müsste auch gelöscht sein.

[BenderD]

Hallo,
ein Rollback auf ein delete ist kein insert. Aber eine Änderung am Satz.
Und somit sollte das Triggerprogramm darauf reagieren.

ein rollback ist eine nicht-Satzänderung!

[Tonazzo]

Nur gibt es keinen Trigger für UNDELETE, UNINSERT, UNUPDATE.
Und deine Logdatei müsste auch gelöscht sein.

Was meinst du mit Logdatei?
Ich habe meine Positionsdatei, in der die gelöschten Sätze wiederhergestellt wurden.
Ich habe meine History Datei, in der die Löschungen aufgezeichnet worden sind.

[Pikachu]

Nimm deine History noch mit unter COMMIT-Steuerung.
Dann werden durch den ROLLBACK alle Spuren verwischt.

[Fuerchau]

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

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