@Hubert

Tut mir Leid das sagen zu müssen, aber diese Aussage ist GRUNDFALSCH !!!
Wenn du per SQL einen CREATE TABLE erstellst, wird diese PF IMMER mit REUSEDLT(*YES) erzeugt, da SQL keinen Reorg kennt !

Die Journalisierung funktioniert sogar sehr gut und damit auch COMMIT/ROLLBACK !

Ich habe allen meinen Kunden bisher immer empfohlen REUSEDLT(*YES) auf alle Dateien (auch Fremdanwendungen) anzwenden um die stundenlangen Reorgs (manchmal auch tagelangen) zu vergessen !
Je nach Anwendung entfällt auch die ständige Erweiterung der Datei da häufig in sog. Arbeitsdateien nur 1000de Sätze erstellt und wieder gelöscht werden.
Ich habe bereits Dateien gefunden, die mehrere Millionen gelöschte Sätze enthielten aber keinen echten Satz mehr.
Eine Sortierung nach Eingangsfolge wird eigentlich nicht mehr verwendet, da man doch immer über Schlüssel und damit sortiert auf die Daten zugreift.

Im Gegenteil:
RGZPFM stellt ein Problem bei der Journalisierung dar, da diese Anweisung nicht repliziert werden kann.
Also, wenn ich e.g. meine DB wiederherstellen muss um anschließend per Journal meine Daten wiederherstelle funktioniert das nur bis zum RGZPFM. Alle nachfolgenden Journaleinträge kann ich nicht mehr verwenden !

Dazu muss man verstehen, dass die Journaleinträge mit ihrer RRN auf die Datei verweisen um Sätze wiederherstellen zu können. Nach einem RGZPFM stimmen aber die RRN's nicht mehr.
Verschärft wird das Problem noch, wenn man beim RGZPFM eine LF für die Sortierfolge angibt. Dies wird im Journal nicht aufgezeichnet ! Zumal wenn die LF auch noch temporär angelegt wurde.

Fazit:
Mit REUSEDLT(*YES) spart man nicht nur Platz sondern auch jede Menge Zeit !