Change Log auf der AS/400 für wichtige Tabellen

[Fuerchau]

Version 1 dient i.W. zur Transaktionskontrolle und ist da eher ungeeignet, da ja nun mal viele nicht benötigten Änderungen vorhanden sind.
Vesion 2 mag vielleicht aufwändig sein, ist aber die einfachste Lösung.
Zumal mit Qualified DS'n und einfachheit der RPG-Trigger, zum Protokoll ein Eval-Corr und Write reicht.
Um zu prüfen ob sich tzatsächlich was geändert hat, so ist dies auch einfach:


dcl-ds beforeDS extfile(...) qualified based(bPointer);
dcl-ds afterDS extfile(...) qualified based(aPointer);

dcl-ds beforeCmp qualified;
f1 like(beforDs.F1);
end-ds;
dcl-ds afterCmp likeds(beforCmp);

eval-corr beforCmp = beforeDS;
eval-corr afterCmp = afterDS;
if beforCmp <> AfterCmp;
write .....
endif;

SQL scheidet dabei leider aus, da SQL keine Strukturen kennt und jedes Feld explizit und mehrmals genannt werden muss.

[itec01]

Vielen Dank. So werde ich es machen.

[itec01]

ich muss doch noch einmal etwas fragen. Du handelst das alles mit einem Programm ab, richtig? D.h. dieses Programm wird beim ADDPFTRG bei *WRITE, *INSERT, *DELETE und *UPDATE bei allen PF Files eingetragen, die man überwachen möchte? Bei manchen Tabellen kann ich nicht die komplette Struktur prüfen, weil da Felder drin sind, die ich nicht überwachen möchte, daher muss ich die DS individuell anpassen, was ja kein Problem ist.

[Robi]

Baldur hat sicherlich ein Pgm für alles.

je zu überwachende Datei eine E DS und die angepasste BeforCmp / afterCmp datenstruktur,
in einer select gruppe die DS füllen, per movecorr die Cmp füllen vergleichen und schreiben

[itec01]

Eventuell ein ganz anderer Ansatz: https://www.ibm.com/docs/en/i/7.3?to...temporal-table
So wie ich es verstehe kann man temporale Tabellen anlegen, die quasi das Abbild aller Änderungen vorhalten. Habe ich das richtig verstanden? Problem ist dann vermutlich, dass man nicht auf einzelne Feldveränderungen eingehen kann.

[Fuerchau]

Das ist korrekt. Je nach häufigkeit der Änderung an diesen Tabellen wirst du dir bestimmt ein paar neue Platten kaufen müssen.
Bei diesen Tabellen kommen noch Felder hinzu (Art der Änderung, Timestamp) und du musst sämtliche Programme wandeln (da die Formatid sich ändert).

Ich habe nicht für alles fertige Programme;-), aber für vieles gedanklich fertige Lösungen.
Dieser Art habe ich schon einige Trigger geschrieben.
Der weitere Vorteil: Man kann auch zusätzliche Informationen aus anderen Tabellen prüfen und ggf. mit protokollieren.

[itec01]

Danke Dir. So hatte ich es auch verstanden.
Eine Frage noch, die output file, welche dann die Veränderungen beinhaltet, muss dann wohl eine Kopie der zu überwachenden File sein plus die Felder für Timestamp, User, etc.? D.h. ändert sich die Struktur der Haupttabelle, muss sich auch diese mit ändern. Sprich, etwas erhöhter Pflegeaufwand.

[Fuerchau]

Nein, die Temporaltabelle ersetzt deine aktuelle Tabelle und führt eben die Historytabelle automtisch mit.
Deine Programm bemerken davon gar nichts, außer der benötigten Umwandlung.
Erst mit einer erweiterten Select-Syntax kommt man dann an den Historyteil.

Der Nachteil dieser Tabellen ist aber auch, dass man sich überlegen muss, ob Felder hinzugefügt oder entfernt werden um die Anwendung zu erweitern da die gesamte History ebenso davon betroffen ist.

[itec01]

Aah, sorry, nein meine Frage bezog sich auf die Trigger Variante.

[Fuerchau]

Nein, die Zieltabelle muss nur deinen Bedürfnissen entsprechen. Diese hast du ja auch in deinem Programm incl. der neuen Felder:

dcl-ds ZielDS qualified name('ZIEL');
end-ds;

ZielDS.Zeit = %timestamp();
eval-corr ZielDs = beforeCmp;
write ZielDs ZielFormat;