Using the CL request WRKCMTDFN, then 5="Display status", and then F6="Display resource status", there are a variety of /resources/ that can be tracked under commitment control. One resource is "Record level"; i.e. Row data.

So from the given comments, it seems most likely the concern is "data" changes, not *FILE changes. Further comment inline to the quoted message.

On 30 May 2012 13:16, Stone, Joel wrote:
Physical file changes under commitment control can be rolled back for
errors.

The data is only in the PF. Records are locked and tracked to the PF, but obtained via an Open Data Path (ODP). Attempts to reference the physical records via an Open of a logical view [DDS LF, SQL VIEW, or INDEX] are just deferrals to the physical row; i.e. what impacts the access to the data in the PF impacts the access to the same row [data] via the LF. When a file.mbr is opened with commitment control, changes to the data will be rolled back with an error that is not handled, or when a ROLLBACK is issued.

Do Logical files behave the same way; i.e. the underlying PF would
roll back the same way that direct PF updates would?

Logical files do not have data. Changes to the physical data are reflected in the LF access path, including rolled back changes. This is true whether the access path is journaled or not [STRJRNAP, or implicitly via SMAPP]. If the logical file.mbr is opened with CmtCtl active, the changes to the data will be rolled back just as if\when the open were to a physical.

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?

Read by LF and update by PF is typically to have two ODPs where one is read-only and the other includes output and uppdate capabilities. I am not aware of anything specific with regard to CmtCtl that would make that same concept more desirable.

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

OPNQRYF has a COMMIT() parameter [with the OPNSCOPE and TYPE playing a role, along with OPTION] determines if the access to the physical rows is done with Commitment Control, and what level of participation\locking for the records selected from the file. So the OPNQRYF shared ODP is just a proxy for the F-Spec, and the operations should perform effectively the same as without the Open Query ODP, except the need to effect a CLOF [or equivalent; i.e. reclaim of resources or activation group] the shared ODP.

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

An implicit ROLLBACK is for the outstanding resources in the active commit definition. The data changes are rolled back irrespective of the open-type for any individual ODP registered with that CmtDfn.

Files open for OUTPUT-only may use sequential-only and blocking, such that some record put\insert activity might never be tracked; i.e. if the block was not forced before an implicit or explicit ROLLBACK.

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)

I do not recall, but there may be cases where an LF access path would be rebuilt instead of being maintained for a RollBack of changes.? If so, then that would surely be undesirable and also probably would be described aptly as not "nicely" effected.

Regards, Chuck

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 midrange.com 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].