RRN trotz RGZPFM merken

[dholtmann]

Meinte mehr "anlegen".
Der Trigger auf eine der bestehenden Dateien löst aus, ermittelt anhand des Dateinamens die Keyfelder, kettet diese zusammen und schreibt bzw. löscht damit den Satz der neuen Datei.
Anzeige des Satzes der neuen Datei erfolgt nach gleichem Prinzip.
So der Ansatz bisher. Da dürfte dann nichts Dateispezifisches dabei sein.

[BenderD]

... und was soll der dann schreiben?

[dholtmann]

Den geänderten Wert der bestehenden Datei vor & nach dem update.

[BenderD]

Den geänderten Wert der bestehenden Datei vor & nach dem update.

... was du da nachbauen willst, gibt es schon: Journale und Receiver und das eigentliche Problem ist dabei das entstehende Datenvolumen.

[dholtmann]

Ja, so ähnlich soll das werden. Leider passt ein Journal nicht ganz.

[Fuerchau]

Alleine schon der Aufwand, einen "allgemeinen" Trigger zu schreiben.
Da nun mal RPG nicht so dynamisch mit variablen Feldlisten und variablen Feldlängen umgehen kann, bist du doch sowieso gezwungen je Datei einen eigenen Trigger zu machen.
Dieser kennt dann die Datei und Struktur die er verarbeitet und kann seine Triggerdaten in die korrespondierende Datei übertragen.
Die Anzahl der Dateien ist da überhaupt kein Problem zumal die Daten dann so spezifisch sind, dass durch die Individualisierung je Datei auch mal die eine oder andere Änderung der Rucksackdatei möglich ist ohne alle anderen Dateien zu beeinflussen.
Und auch wenn die RRN eindeutig ist, so kann nur der Schlüssel die Daten tatsächlich eindeutig identifizieren. Es soll Anwendungen geben, die gerne beim Update die Kombination Delete/Write verwenden, was wiederum die Wahrscheinlichkeit der RRN-Änderung mit sich bringt.
Da hat dann der Trigger gelitten, da er ohne Key keinen Bezug zwischen alter und neuer RRN hat und die Rucksackdatei dann mit der geänderten RRN updaten muss.

Und nochmal:
Ein Trigger verhindert RGZPFM, die Dateien sollten auf REUSEDLT(*YES) umgestellt werden.

[BenderD]

Ja, so ähnlich soll das werden. Leider passt ein Journal nicht ganz.

... was passt da nicht?

[dholtmann]

@BenderD Naja wie du sagst, die Menge an Daten ist zu groß. Vieles brauche ich einfach nicht.
@Fuerchau Du hast Recht, von der RRN Lösung sind wir ab.

[BenderD]

... bei ausreichender Selektivität, würde ich auch die Trigger Variante bevorzugen, würde allerdings die Daten in spezifischen Dateien - je Herkunft eine eigene - ablegen. Die Varianten der Trigger und die erforderlichen Dateien lassen sich per Generator erzeugen. Das ist einfacher, stabiler und die Auswertbarkeit der Daten ist besser.

D*B

[dholtmann]

ja, das mit den Generatoren habe ich auch überlegt! Gute Idee

[Fuerchau]

Aber bitte nicht die SQL-Sequenz, die ist nicht sonderlich performant, da sie in einer DTAARA abgebildet wird.
Eine separate Tabelle mit Key und Wert sowie Bereitstellung von SQL-/Service-Funktionen ist da erheblich performanter (Idee geklaut von D*B).

[dholtmann]

Nein Sequence ist auch raus. Wenn dann wie du sagst "richtig" mit Key.