Nun ja, die ERP-Anwendung arbeitet aus Sicherheitsgründen (da ja kein Journal läuft) auf jeder Datei mit FRCRATIO(1)!
Bei einigen Batchprogrammen konnte ich Laufzeiten von mehreren Stunden auf wenige Minuten reduzieren in dem ich einfach auf FRCRATIO(*NONE) gestellt hatte.
Bei RAID-Platten macht FRCRATIO(1) auch wenig Sinn.

Die Filehandler arbeiten beim "Lesen ohne Lock" mit CHAIN/UPDATE anstelle mit CHAIN(N), also ob die Programmierer damals (ca. 15 Jahre) das CHAIN(N) nicht kannten.

Batch-Programme, die wenig ändern lesen die Dateien mittels Filehandler mit CHAIN->UPDATE USER/JOBNAME->CHAIN löschen USER/JOBNAME um eben eine logische Sperre zu setzen um vielleicht eine Änderung durchzuführen. Dies führt natürlich zu hohem Journalaufkommen obwohl keine relevanten Daten geändert werden. Auf diese Weise werden komplette Stammdaten zum Teil mehrfach am Tag "geändert" ohne tatsächliche Änderungen durchzuführen.
Diese ERP-Anwendung ist nicht zu modernisieren (Never Change ...) und führt eben zu diesen gigantischen Journalen.

Auch das Datenbankmodell ist natürlich nicht optimiert. So enthalten Stammdatentabellen auch Bewegungsdaten (z.B. Lagerbestand). Hier muss natürlich intensiv über Sperren nachgedacht werden da sich Bestände am häufigsten ändern.
Wie gesagt, alte Anwendung die aber stabil läuft.