Journalisierung und Commit hat nichts damit zu tun, ob die Daten sicher auf der Platte sind.
Die AS/400 puffert hier alles (im Normalfall) und schreibt das irgendwann auf die Platte.
Das ist auch der Grund, dass die Maschine massiv langsamer wird, wenn die Cachebatterie leer ist, da hie immer sofort physisch geschrieben werden muss.

In einer PF kann man sicherlich mit FRCRATIO(1) das physische Schreiben zu lasten der Performance erzwingen.
Dies sollte man unterlassen und genug Saft bei Stromausfall zu haben, der alle Puffer schreibt und die Maschine dann runterfährt.

Mit Journalisierung und Commit werden beim plötzlichen Runterfahren und neuem IPL die Commitgrenzen ermittelt und die Daten konsistent wiederhergestellt.
Das enthebt niemanden davon festzustellen, was denn gerade so gemacht wurde um "fehlende" Transaktionen (die also vom System zurückgedreht wurden) nachzuarbeiten.
Allerdings ist das während meinem Arbeitsleben mit der AS/400 noch nie vorgekommen.

Ansonsten ist eben alles, was zu einer "Transaktion" gehört mit einem Commit abzuschließen.
Über den Begriff Transaktion lässt sich wieder herrlich streiten.
Wichtig ist hier allerdings, dass eine Transaktion nicht durch einen Benutzereingriff (also warten am Bildschirm) unterbrochen werden darf.
Z.B.
Auftragerfassung - Positionsteil
- Position schreiben
- Auftragsbestand schreiben
- Lagerbestand prüfen, bei Sofortlieferung (Kasse) gleich buchen
- sonstige Aktivitäten in diesem Context
- Commit

Tritt nun z.B. beim Lagerbestand ein Problem auf kann ich einen Rollback machen und alle vorherigen Aktivitäten bis zum letzten Commit/Rollback werden rückgängig gemacht.

Was also eine Transaktion genau ist liegt in der Funktion der Anwendung.