Bei STRSQL musst du vorher einen STRCMTCTL absetzen sonst gehts da auch nicht.
Das stimmt nicht! SQL (interaktives oder auch embedded SQL) führen den STRCMTCTL (mit Unterlassungswerten aus), sofern mit Commitment Control gearbeitet wird und der STRCMTCTL in dem Job noch nicht ausgeführt wurde!

Dateien, die nicht aufgezeichnet werden, können beim Rollback auch nicht zurückgedreht werden.
Wird mit SQL und Commitment Control gearbeitet und wird die Datei nicht aufgezeichnet, führt SQL den Insert, Update oder Delete nicht durch, sondern bringt die Fehlermeldung:
MyTable in MyLib für Operation ungültig.

Wenn man nur eine Transaktionssicherheit gewährleisten will, kann man die Journal-Receiver so definieren, dass sie sobald sie abgehängt werden gelöscht werden. Ein Journal-Receiver bleibt solange geöffnet, bis die letzte angefangene Transaktion beendet wird.

Im interaktiven SQL (nach STRSQL) kannst Du Deine Session-Attribute mal mit F13 ändern, und zwar den Commitment-Level auf *ALL oder so setzen. Danach kannst Du sofort ROLLBACK und COMMIT ausprobieren. Anschließend bitte mal mit den Alternativen zu *ALL beschäftigen, denn *ALL blockiert geänderte Sätze, bis der aktuelle COMMIT-Zyklus beendet wird (ROLLBACK oder COMMIT).
Ich würde nicht gerade mit dem höchsten Commitment-Level *ALL anfangen, bei dem ich mir alles dicht mache, sondern mit dem niedersten UR (uncommitted read) oder *CHG. Ein unter Commit gesperrter Satz kann nur durch den nächsten Commit oder Rollback im gleichen Job wieder freigegeben werden, z.B. der RPG-Befehl UNLOCK oder die Erweiterung (N) ziehen nicht!

... "Schmalspur"-Journaling mit Gewährleistung der Transaktionssicherheit sollte man auf alle Fälle fahren.

Birgitta