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