Journaleinträge anlegen

[Wirnitzer]

Hallo Forum,

beim Befehl APYJRNCHG bringt das System einen Fehler beim RGZPFM. Habe keine Idee warum dieser Fehler auftritt.

Hat jemand Erfahrung mit diesem Problem ?
Kann ich bestimmte Journaleinträge beim APYJRNCHG ( Art = "RM" oder "RG" ) unterdrücken ?

Vielen Dank im Voraus

Jürgen Wirnitzer

[Fuerchau]

Der RGZPFM stellt bei Journalisierung immer ein Problem dar und sollte daher nie verwendet werden.
Sämtlich Bezüge zu den Sätzen gehen verloren, da die Einträge immer über die rel. Satznummer geführt werden.

Besser ist CHGPF FILE(DATEI) REUSEDLT(*YES) !

Damit wird ein RGZPFM nie mehr benötigt.
Sollte man die Eingangsfolge der Daten benötigen ist ein Timestamp oder indiv. Zähler und eine LF darüber sinnvoller.

[Bruno Jakob]

Das mit dem REUSEDLT(*YES) ist schon eine feine Sache. Aber ich würde es nur im Einzelfall verwenden. Die Datenbank wird dadurch langsamer, da das System dann ja immer schaut, wo ne Lücke ist.

Gruß Bruno

[rmittag]

außerdem kann man keine Zugriffswege mit doppelten Schlüsseln und FIFO/LIFO mehr anlegen, d.h. die Eingangsreihenfolge der Sätze geht verloren.

Gruß Rolf

[Fuerchau]

Dass die Datenbank mit REUSEDLT(*YES) langasamer wird kann ich absolut nicht bestätigen, da die freien Sätze nicht gesucht werden müssen sondern separat verwaltet werden und somit genauso schnell gefunden werden, wie am Ende der Datei.

Ausserdem entfällt die ständige Erweiterung der PF-Datei um x Sätze wenn sehr viele Sätze ständig hinzugefügt und wieder gelöscht werden.

Desweiteren habe ich mit RGZPFM das Problem, dass zu dieser Zeit ein weiterarbeiten mit der Anwendung nicht möglich ist. Wenn viele Dateien zu einer Anwendung gehören (was ja durchaus normal ist) kann der RGZPFM für die gesamte datenbank mitunter mehrere Stunden beanspruchen.

Ich habe mit REUSEDLT bisher nur allerbeste Erfahrungen ohne irgendwelche Performanceverluste.

Zum Thema LIFO/FIFO bei doppelten Schlüsseln: Auch dieses funktioniert weiterhin, da man ja bei einem RGZPFM auch die Keyfolge einer beliebigen zugehörigen LF angeben kann bleibt die LIFO/FIFO trotzdem erhalten.

Insbesonders bei Journalisierung bietet sich REUSEDLT(*YES) an, da ein RGZPFM per APYJRNCHG absolut nicht durchgeführt werden kann !

[Bruno Jakob]

Gut, dass man nicht nur seine eigene Suppe kochen muss, sonder auch Kontakt nach draussen hat. Mit REUSEDLT werde ich wohl in nächster Zeit mal experimentieren. Übrigends: CREATE TABLE setzt REUSEDLT ganz elektrisch auf *YES.

Gruß Bruno

[rmittag]

schon mal versucht, eine LF mit LIFO über eine PF mit REUSEDLT(*YES) zu erstellen? ansonsten sind alle PF's oder Tables, die ich erstelle mit REUSEDLT(*YES) und ich habe noch keine Probleme (außer LIFO/FIFO) gefunden. Das läßt sich allerdings mit RGZPFM und KEYFILE _nicht_ lösen, es sei denn man hat einen Schlüssel dafür, was im allgemeinen (KdNr, RechNr,...) nicht der Fall sein dürfte.

Gruß Rolf

[itec01]

Hallo,
der Beitrag ist schon etwas älter, aber dennoch aktuell. Ein Kunde von uns möchte, dass wir die physischen Dateien auf REUSEDLT *YES setzen. Meiner Meinung nach müssten alle Programme dahingehend untersucht werden, ob LIFO oder FIFO gelesen wird. Das wird ziemlich aufwendig. Selbst wenn eine LF gelesen wird, kann es sein, dass dies nicht in Reihenfolge geschieht (doppelte Schlüssel). Zusätzlich müssen die SQL's auf order by hin überprüft werden. Ich denke, da muss man höllisch aufpassen. Wie seht Ihr das?
Danke.
Gruß Klaus

[KingofKning]

Es gibt ganz bestimmt Fälle wo ich LIFO / FIFO benötige aber bei Stammdaten etc. vermutlich nicht. Wenn es keine Spezialanwendung ist die eingehende Daten sequentiell verarbeiten muß dürfte es nicht ins Gewicht fallen.

GG

[mk]

Hi,

wenn mit SQL die Daten per select ohne order by gelesen werden ist die Reihenfolge nicht gewährleistet.

[Fuerchau]

Ich denke auch, dass nur die Programme zu finden und zu prüfen sind, die Dateien rein sequentiell bearbeiten, hier könnte FIFO relevant sein.
Bei KEY-Verarbeitung sollte es auf FIFO/LIFO nicht ankommen, sonst ist es ein Designfehler.

[Fuerchau]

@Mike
Auch das ist nur bedingt richtig.
Wird ein Tablescan durchgeführt, ist die Reihenfolge nach Satznummer.
Kann auf Grund der Where-Klausel ein Index verwendet werden, so gilt dessen Reihenfolge.
Somit kann ich bei einer PF ohne jedwede Schlüssel von einer Satznummernfolge ausgehen.