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

[itec01]

Moin Zusammen,
um Daten-Veränderungen an Tabellen zu protokollieren, was nutzt Ihr so?
Meiner Meinung nach gibt es zwei Sachen:
1. Journal an die wichtigen Tabellen und alles protokollieren.
Nachteil:
- unschöne Darstellung mit vorher und nachher Abbild
- es wird alles protokolliert, meistens möchte man nur gewisse Felder protokolliert haben
- Plattenplatz kann schnell voll werden, wenn man die Daten mind. 1 Jahr vorhalten möchte
Vorteil:
- so gut wie kein Programmieraufwand, eventuell nur die Darstellung der Veränderungen ist aufzuzeigen

2. Trigger Programm an jede Datei
Nachteil:
- gezieltes Programm um die Veränderungen zu protokollieren. Geschrieben wird dann in eine neue Datei mit den nötigen Informationen
- deutlich höherer Programmieraufwand
Vorteil:
- gezielte Felder lassen sich protokollieren

3. Protokollierung in jedem Programm
- mit Abstand der höchste Aufwand

Wie macht Ihr das?
Danke.
Klaus

[Robi]

Wir verwenden deine Version 1 und 2.
Ursprünglich nur 2, aber wenn eh alle Felder zu beachten sind geht auch 1.

zusätzlich haben wir einen allgemein gülltigen Fehlersuchtrigger. Er wird drauf gelegt, wenn niemand die Datenentstehung erklähren kann. Der sucht aus einer Datei welches Feld(er) er überwachen soll. Dort können wir auch definieren, das er nur protokolliert wenn der Wert ein bestimter Inhalt (>, < =, <>) ist.
Dieser Trigger schreibt den Programmstapel in eine mail. zusätzlich kann er den auslösenden Job anhalten.
Wird zum Glück nur selten gebraucht, hilft aber, die unmöglichsten Sachen zu ermitteln.
Viel Erfolg mit deinem Plan.

[itec01]

Robi, danke Dir. Die Version 1 fällt vermutlich weg, da wir dann zusätzliche Platten kaufen müssten.

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