RRN trotz RGZPFM merken

[BenderD]

... das ganze Konzept humpelt doch an der Aktualisierung dieser Informationen. Der Eingangspunkt mit dem RGZPFM deutet doch schon daraufhin, dass in den originären Informationen Sätze gelöscht werden, mit der Konsequenz, dass dieser Datenmoloch zur Müllhalde verkommt.

Wo siehst Du denn den Aufwand bei einer saubereren Lösung?

D*B

[dholtmann]

Naja das Zumüllen versuchen wir über Trigger zu vermeiden.
Ich sehe das Problem einfach in der Fülle der Dateien, die dann erstellt werden müssten.
Kann nicht mal eben mehrere hundert neue Physische einbauen.

[BenderD]

Kann nicht mal eben mehrere hundert neue Physische einbauen.

... was meinst Du jetzt mit "einbauen". Du brauchst doch dann ohnehin für jede Datei einen Trigger, Logik für die Verhuddelung des Keys, Logik für die Enthuddelung der angehängten Information und irgendwoher müssen dann die anzuhängenden Daten ja auch kommen.

D*B

[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