On 07-Jun-2010 10:42, James H. H. Lampert wrote:
This morning, we found a strange error while saving IFS objects
on our V4R4 development box.
First, we got eight CPDA09F messages ("An APAR condition has
occurred in module Qp0fVLck. The reason number is 1").
Then we got eight sequences of CPFA0D4 ("File system experienced
an unexpected error. Error number 3418 was received.") and
CPD376C ("Not able to save object /xxx/yyy/zzz/qqq.xml."), two
each for four different objects in the same directory. The reason
codes given on the latter were "0 9 90080."
There are no system operator messages.
There is no reason to believe there are any locks on any of
these objects.
Can anybody shed any light on this?
On 07-Jun-2010 12:10, James H. H. Lampert wrote:
The actual SAV command is generated by, and QCMDEXC'd from, an
RPG program, to save IFS trees in parallel with similarly named
libraries (dealt with earlier in the process). It is, roughly:
SAV DEV('QSYS.LIB/TAP01.DEVD') OBJ('/xxx/yyy') LABEL('YYY')
ENDOPT(*LEAVE) SAVACT(*YES)
where xxx is a parent directory containing these parallel IFS
directories, and yyy is the name of the library whose parallel
IFS directory we're saving. Near as I can tell, everything else
contained in this particular /xxx/yyy was saved.
There was a tape volume change, probably in the middle of this
particular SAV.
I am not sure how accurate the v4r4 reference is; regardless...
Having logged an error which suggests the failure is an "APAR
condition", I would expect that IBM would be able to comment. The
OS file system developers coded the abnormal condition to be
diagnosed with the symptom msgCPDA09F RC1 with text suggesting that
the error should be reported with the listed documents "to your
service provider."
A past message on this list records the same initial symptom, and
also mentions "End of volume"; presumably CPF4901. Apparently they
reported the issue to IBM, but no followup here:
http://archive.midrange.com/midrange-l/200309/msg00961.html
FWiW:
A supersede to a fix for the same original symptom [but issued
during restore, and corrected in the base-OS] was eventually
superseded by performance changes to save processing; thus the code
included in the PTF also affects save-related code. After that fix
came another which is not available on a cumulative for v5r4 and
newer releases, and which rather than suggesting the problem has
UNPRED [unpredictable] symptoms, suggests some specific symptoms
including a VLog which your message does not mention. However that
APAR does mention several other tid-bits that seem to make it a
likely match, at least correlating with the text from your post and
the superseded PTF:
"While saving integrated file system objects
the system save failed to complete. Common
symptoms include <<SNIP>>
This problem was caused because of a lock
conflict on an integrated file system object
during tape end-of-volume processing. This PTF
changes synchronization techniques so that
integrated file system objects can be shared
more frequently when they are being saved."
Correlate that text with the original APAR MA32583 with its PTF
MF37693 which was resaved into the v5r4:
"When restoring integrated file system objects,
some objects may fail to be restored and the
following message may be received:
MSGCPDA09F (An APAR condition has occurred
in module Qp0fVLck)
Restore operations were incorrectly synchronized.
This PTF corrects the problem. <<SNIP>>"
http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/MA38339
http://www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/MF47773
The above APAR lists the latest superseding PTF for each of the
other current\supported releases; the above PTF is for v5r4m0, and
its latest supersede is MF49730.
Regards, Chuck
midrange.com
