CPF325E - Uncommitted changes

[Jonathan Ball]

Trying to save a file, and the file isn't saved. I get CPF325E -
message is "Uncommitted changes pending for file XXXXXXXXXX in library
YYYYYYYYYY".

There are no locks on the file; it isn't in use by anything. Is it
possible either to commit the changes or to roll them back? Not sure
how that would be done if I can't even find the uncommitted changes in a
job.

[Dieter Bender]

... wrkcmtdfn(*all) gives you the entrie point to investigate and solve this
problem (if there isn't one of the bugs waiting for install of a ptf)

Dieter

"Jonathan Ball" <jonb...@gmail.com> schrieb im Newsbeitrag
news:jsKdnWgkLtYKpnzT...@giganews.com...

[CRPence]

On 09-Dec-2011 00:05 , Dieter Bender wrote:
> ... wrkcmtdfn(*all) gives you the entry point to investigate and

> solve this problem (if there isn't one of the bugs waiting for
> install of a ptf)
>

> "Jonathan Ball" wrote:
>> Trying to save a file, and the file isn't saved. I get CPF325E -
>> message is "Uncommitted changes pending for file XXXXXXXXXX in
>> library YYYYYYYYYY".
>>
>> There are no locks on the file; it isn't in use by anything. Is it
>> possible either to commit the changes or to roll them back? Not
>> sure how that would be done if I can't even find the uncommitted
>> changes in a job.
>

Slight clarification: WRKCMTDFN JOB(*ALL) /* i.e. WRKCMTDFN
JOB(*ALL) STATUS(*ALL) ASPGRP(*ALLAVL) LUWID(*ALL) */

A backup copy of the data can be made by creating a new alternate
copy of the file from source [DDS or DDL] then copying the data from the
problem file to the new file. An interface which does not retrieve the
description of that file to effect that copy may be required; e.g. a
compiled HLL can use an alternate copy of the file for compile, then
OVRDBF to access the expected file.mbr to access the data.

If there is a problem for which a PTF is required [one possible
indication is that no work is registered for that symptom msgCPF325E],
then that PTF would only be preventive; i.e. the recovery actions will
still be necessary.

Regarding origin, collect and review spooled data from:

dspobjd thelib/thefile *file /* for both *service and *full */
dmpobj thelib/thefile *file
dmpsysobj 'thefile *' thelib 0D 50
dmpsysobj 'QDBDBDROBJ*' thelib 19 D4
dsplog qhst /* timeline hour before and a bit after the create
date\time of the object just dumped; both output(*prtseclvl)
and output(*print) */
past spooled joblogs from SCPF if date\time before a prior IPL
dspjrn /* audit logs and file journal for that time period */
joblogs & dumps from any jobs for which messaging related to
that file which are found in the history
dspfd thelib/thefile output(*print) /* may give same error */
dspjoblog output(*print) /* of job doing above data collect */

Recovery choices:

PwrDwn\IPL. Review the spooled SCPF joblog and history for
recovery or "not recovered"; verify file can be saved.

rclstg select(*all) omit( _whatever_ )

patch [IBM support\service; various tooling may enable vs
patching], get dspfd if not available before, optionally make backup
copy of data, DLTF, recover file object by create or restore from a
known good copy, recover data from a backup and optionally apply
journaled changes.

Regards, Chuck

[Jonathan Ball]

I opened a PMR with IBM, and in the end, we did these:

>
> dspobjd thelib/thefile *file /* for both *service and *full */
> dmpobj thelib/thefile *file
> dmpsysobj 'thefile *' thelib 0D 50

This one: > dmpsysobj 'QDBDBDROBJ*' thelib 19 D4

> dsplog qhst /* timeline hour before and a bit after the create
> date\time of the object just dumped; both output(*prtseclvl)
> and output(*print) */
> past spooled joblogs from SCPF if date\time before a prior IPL
> dspjrn /* audit logs and file journal for that time period */
> joblogs & dumps from any jobs for which messaging related to
> that file which are found in the history
> dspfd thelib/thefile output(*print) /* may give same error */
> dspjoblog output(*print) /* of job doing above data collect */
>
> Recovery choices:
>
> PwrDwn\IPL. Review the spooled SCPF joblog and history for recovery or
> "not recovered"; verify file can be saved.
>
> rclstg select(*all) omit( _whatever_ )
>

This one (more detail below) > patch [IBM support\service; various

tooling may enable vs patching], get

> dspfd if not available before, optionally make backup copy of data,
> DLTF, recover file object by create or restore from a known good copy,
> recover data from a backup and optionally apply journaled changes.
>

The IBM technician had me run:

call qsys/qdbchkro parm(<thelib>)

This produced a list of the files that had recovery objects. The
DMPSYSOBJ run above also identified the same files. After sending the
spool output from DMPSYSOBJ to IBM, they came back with a recommendation
to call qsys/qdbchkro again, passing an additional parameter. We did
that, and it recovered the objects.

I wanted to be sure the recovery really was achieved, so I called the
program one more time without the additional parameter, and I was a
little alarmed when it ran for several minutes. When I ran it the first
time (also with only the library name as parameter), it had run
virtually instantaneously, and when it ran for several minutes, I was
afraid something was amiss. But then I ran it one more time (one
parameter), and it ran quickly again.

[CRPence]

On 13-Dec-2011 08:41 , Jonathan Ball wrote:
> On 12/9/2011 10:41 AM, CRPence wrote:

>> <<SNIP>>

>>
>> If there is a problem for which a PTF is required [one possible
>> indication is that no work is registered for that symptom
>> msgCPF325E], then that PTF would only be preventive; i.e. the
>> recovery actions will still be necessary.
>>
>> Regarding origin, collect and review spooled data from:
>
> I opened a PMR with IBM, and in the end, we did these:
>
>>
>> dspobjd thelib/thefile *file /* for both *service and *full */
>> dmpobj thelib/thefile *file
>> dmpsysobj 'thefile *' thelib 0D 50
>
> This one: dmpsysobj 'QDBDBDROBJ*' thelib 19 D4
>

>> <<SNIP other doc collection recommendations>>

>>
>> Recovery choices:
>>
>> PwrDwn\IPL. Review the spooled SCPF joblog and history for recovery or
>> "not recovered"; verify file can be saved.
>>
>> rclstg select(*all) omit( _whatever_ )
>>
>
> This one (more detail below)
>
>> patch [IBM support\service; various tooling may enable vs
>> patching], get dspfd if not available before, optionally make
>> backup copy of data, DLTF, recover file object by create or restore
>> from a known good copy, recover data from a backup and optionally
>> apply journaled changes.
>>
>
> The IBM technician had me run:
>
> call qsys/qdbchkro parm(<thelib>)
>
> This produced a list of the files that had recovery objects. The
> DMPSYSOBJ run above also identified the same files. After sending
> the spool output from DMPSYSOBJ to IBM, they came back with a
> recommendation to call qsys/qdbchkro again, passing an additional
> parameter. We did that, and it recovered the objects.
>
> I wanted to be sure the recovery really was achieved, so I called
> the program one more time without the additional parameter, and I was
> a little alarmed when it ran for several minutes. When I ran it the
> first time (also with only the library name as parameter), it had
> run virtually instantaneously, and when it ran for several minutes, I
> was afraid something was amiss. But then I ran it one more time (one
> parameter), and it ran quickly again.

That is [a variant of] the tooling to which I was alluding. I
believe I may have made that tool available with the name QDBLSTRO
[perhaps also QDBPRCRO] as well [as the QDBCHKRO]. I am unsure why the
call being made when no recovery objects existed would have taken so
long, as compared to when some did exist. I do not recall the
invocation for just the library name [list-only invocation] being
anything other than very fast. Since its purpose was only tooling, I
could have easily made an error in the assumptions for the coding of the
MATCTX, though apparently in a way that still always produced the
necessary results in my experience; the request would be legitimately
slowed when in conflict with another MATCTX, such as for a concurrent
save or DSPFD *MBRLIST. Hmmm... I suppose if the variant used was of
the "process" variety [QDBPRCRO], then maybe a conflict-resolution CALL
to the QDBFIXIT program experienced its 120-second delay. Oh so long
ago... though perhaps if a snippet of the output had been included and
what the parameter specification was, might help me recall.

I want to emphasize though, that the optional parameter invocation of
the tooling is *not* recovery for the database *FILE; not implicitly,
except perhaps the "process" variety... though I am unsure, or simply do
not recall, how the CPF325E could be resolved. Maybe the tooling
pretends to be IPL database recovery.? If the tooling destroys the
recovery objects as effect, that is merely ignoring the origin for the
problem; i.e. having dismissed the pending recovery. IIRC, in general,
the affected files have been left pending some recovery which has since
been dismissed. Whatever processing was still pending was left undone,
and those other operations may still need to be done. The effect of
only the destruction of those x/19D4 objects is "recovery" only when the
IBM developer has properly reviewed the file objects, both attributes
and relations, and the system database cross reference for valid states;
i.e. to verify and know that no other actions were required. A full
reclaim would effect that as well.

Regardless, if no additional actions were required, then the origin
of the problem would presumably be known to the developer\reviewer, and
thus the known preventive PTF recommended to be applied or verified to
already have been applied after the incident.

Regards, Chuck

[Jonathan Ball]

On 12/13/2011 9:39 AM, CRPence wrote:
> On 13-Dec-2011 08:41 , Jonathan Ball wrote:

>> [...]

>
> That is [a variant of] the tooling to which I was alluding. I believe I
> may have made that tool available with the name QDBLSTRO [perhaps also
> QDBPRCRO] as well [as the QDBCHKRO]. I am unsure why the call being made
> when no recovery objects existed would have taken so long, as compared
> to when some did exist. I do not recall the invocation for just the
> library name [list-only invocation] being anything other than very fast.

The list-only invocation only took a long time to run the first time
following the corrective invocation, i.e.

1. list-only invocation - virtually instantaneous
2. corrective invocation - virtually instantaneous
3. list-only invocation - several minutes
4. list-only invocation - virtually instantaneous

I wouldn't have any idea why. It happened the same way for multiple
libraries, too.

Leaving the rest of your commentary below intact for readability, I'll
interject here that the database recovery objects were created last
April and persisted across weekly IPLs.

[Jonathan Ball]

On 12/13/2011 9:39 AM, CRPence wrote:

> [...]

One other thing that I forgot to ask the IBM pros before closing the
PMR...isn't the message (CPF325E) a bit misleading? The file was not
opened under commitment control at the time the recovery objects were
created.

[CRPence]

On 13-Dec-2011 10:16 , Jonathan Ball wrote:
> On 12/13/2011 9:39 AM, CRPence wrote:
>> On 13-Dec-2011 08:41 , Jonathan Ball wrote:
>>> [...]
>>
>> That is [a variant of] the tooling to which I was alluding. I
>> believe I may have made that tool available with the name QDBLSTRO
>> [perhaps also QDBPRCRO] as well [as the QDBCHKRO]. I am unsure why
>> the call being made when no recovery objects existed would have
>> taken so long, as compared to when some did exist. I do not recall
>> the invocation for just the library name [list-only invocation]
>> being anything other than very fast.
>
> The list-only invocation only took a long time to run the first time
> following the corrective invocation, i.e.
>
> 1. list-only invocation - virtually instantaneous
> 2. corrective invocation - virtually instantaneous
> 3. list-only invocation - several minutes
> 4. list-only invocation - virtually instantaneous
>
> I wouldn't have any idea why.

I would guess not... since I wrote the code ;-) Plus given that the
tooling is unpublished and not shipped with the OS; available only for
the duration of debug by an IBM developer to assist with investigating a
problem on a customer system. Any use outside of that purpose could be
truly disastrous to a system.

SWAG that the "corrective invocation", instead of destroying the
recovery objects as I remember, must have "zeroed" the type, then the
next "list-only invocation" actually [though I can not fathom why except
a false perception of making the tooling safer on an active system]
called the recovery processing which caused QDBFIXIT to wait two-minutes
for each zeroed recovery object while it waited for a concurrent request
[which would not occur] to set the type; the only concurrent activity
would be another requester "tripping" over the un-typed recovery object,
for which all requesters need to handle the recovery object getting
destroyed.

No mention was made of the version\release\modification, so maybe
something about a release newer than v5r4 might have required [perhaps
just for the preference of the new developer\owner of the tooling]
changing how the tooling worked.? My curiosity about what the second
parameter was, is still unsatisfied :-)

> It happened the same way for multiple libraries, too.

Ugh. More than one library exhibited the issue? I am real curious
now, about the output from the listing invocation; i.e. what were the
recovery "types" listed across those libraries?

> <<SNIP>>the database recovery objects were created last

> April and persisted across weekly IPLs.

That means that the SCPF joblog [wrksplf (qsys *n *n scpf)] should
have logged errors for every IPL since the original incident. With each
IPL also there should have been error(s) sent to QSYSOPR informing of
the failure; could be available still to be seen in the history for
every IPL [using DSPLOG].

Regards, Chuck

[CRPence]

On 13-Dec-2011 10:32 , Jonathan Ball wrote:
> On 12/13/2011 9:39 AM, CRPence wrote:
>> [...]
>
> One other thing that I forgot to ask the IBM pros before closing the

> PMR... Isn't the message (CPF325E) a bit misleading? The file was

> not opened under commitment control at the time the recovery objects
> were created.

There were at least two defects that I recall in V5, one involving
constraint activity and one ALTER TABLE [for CHGPF SRCFILE(specified)],
where the "running under cmtctl" indication for the pending "recovery"
was either accidentally left "on" or for which although properly left
"on" should have been disregarded by the recovery processor but was not.

One could presume that the preventive PTF for the origin of the
problem was applied since the original incident [noted to have taken
place in April?]. Nevertheless, IMO they should have told you what the
origin of the problem was [as they inferred from doc collections] and
what was the preventive; that either if from the long-ago nature of
having so-long ignored the errors or if insufficient details were
available, I can understand that they might have figured "Fix it and
forget it for this case, awaiting if\when the customer calls back with a
new incident"; i.e. there is only expense in more digging and
speculation, with almost no chance of payback in either finding the true
origin nor in knowing what specific code might need correction.

There are or at least may be, other cases [like ALTER and constraint
activity] whereby the OS database processing either implements or
simulates the user of commitment control in order to perform database
recovery which would otherwise not officially be running under
commitment control; aka isolation. When the DB properly tracks
recovery, the activity outside of commitment control which was
interrupted will effect CPF3245 [instead of CPF325E] when a later action
conflicts and detects that pending recovery. IIRC the indication that
the recovery is being performed under CmtCtl should have been turned
"off" when the activity was implicitly committed and de-registered from
the unit of work.... such that if the processing did not complete from
that point [unlike when running under isolation where the ROLLBACK is
possible, that is not possible without isolation], another DDL-like [or
"generic" object operation] requester\method wanted to act-on that file,
the request would fail with CPF3245 and a return code indicating what
the previous [but interrupted] request was.

Regards, Chuck

[George Plimpton]

I tried to reply to your e-mail address on this topic, but it bounced.

[CRPence]

On 01 Jun 2012 12:10, George Plimpton wrote:
> I tried to reply to your e-mail address on this topic, but it
> bounced.
>

I use one of my since-defunct email to keep some consistency in my
effective persona for Google Groups; for when I transitioned from using
the TeamIBM [or similar] shared moniker way-back-when.

I presume my attempts to contact your email would be just as
fruitless since most participating on USENET avoid showing their
legitimate email address [or even likely something close] to avoid
spammers collecting them.

Perhaps a specific question can be directed here? Otherwise join
news.midrange.com to [determine how to] send me a private message.

Regards, Chuck