Have you looked at the help text of STRCMTCTL? It mentions some requirements - among them, the file which will be processed under commitment control must be journaled. There is NO journaling of LFs - or of OPNQRYF or anything other than PFs, as far as files go.

OPNQRYF is not a real file - it is a virtual access path, one could say - no data contained therein, only a PATH to the data, known as an ODP or open data path.

Likewise, LFs are only an access path.

You should also look at the STRJRNPF command - more information there.

You should also look at the COBOL reference to see how to specify using commitment control on a file - in RPG it is on an F-spec - I don't know the equivalent.

It's all in the manuals at Infocenter - this is a pretty big topic, much going on around what might seem a simple question!!


On 5/30/2012 3:16 PM, Stone, Joel wrote:
Physical file changes under commitment control can be rolled back for errors.

Do Logical files behave the same way ie the underlying PF would roll back the same way that direct PF updates would? Or are there some restrictions on LF's that would cause programmers to use the LF to read the PF by primary key and update the PF directly?

Do OPNQRYF's behave the same way as PF's also? Ie will the based-on PF roll back on an error while under commitment control?

Does the file output method matter? Ie if a file is opened as OUTPUT vs UPDATE would both of these behave the same ? ie rollback on error under CC?

Some pgmrs here claim that PF updates roll back nicely, whereas LF updates do NOT roll back. Is this possible? (assuming all files are journalled properly and such)


This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].