I remember seeing the blurb about OA18929 on IBM-Main several weeks ago:
"DFSMSdss has been changed in APAR OA18929 to perform a volume INIT
when FCWITHDRAW is specified on the DUMP when it is detected that it is
needed."
After verifying we had OA18929 installed, I decided to test out DFSMSdss
DUMP with FCWITHDRAW in one of our DR point-in-time backup job streams
(using IBM 2107 ESS with FlashCopy2).
Based on testing I am puzzled by the current DFSMSdss interpretation of
"is needed".
From my viewpoint I would think a re-initialization would be "needed" if
the data on the target volume is not consistent. Even if the VTOC,
VTOCIX, and VVDS have been completely copied, if some of the datasets in
the VTOC have not been completely copied, then the VTOC is telling lies
about the volume contents and it would seem better to re-initialize the
device than leave it in a misleading state.
I see evidence that suggests this is not the way DFSMSdss behaves with
OA18929. Converting a job stream that does 11 dss volume DUMPs to use
"DUMP FULL ... FCWD" instead of separate job steps to do explicit
FCWITHDR and ICKDSF INITs, I am seeing no INITs take place on one or two
volumes on which the explicit FCWITHDR used to always succeed
(indicating the volumes were normally still in FCNOCOPY status and
presumably incompletely copied). The only two volumes showing this
behavior have many small files, so the odds are probably higher that all
tracks of the VTOC will be changed (and thus copied) by the time the
DUMP is taken. Even more puzzling, on 3 of 3 days a re-initialization
took place on all the remaining 9 volumes, at least one of which used to
consistently fail (6 out of 7 days a week) on an explicit FCWITHDR
because the FCNOCOPY copy had completed prior to the DUMP. While it is
possible that slight differences in job timing using the "FCWD" option
might cause different volumes to complete or not complete the FCNOCOPY
copy, it seems unusual that no such failures would occur on those 9
volumes on the three consecutive nights I was testing.
The net effect of the observed behavior seems to be that depending on
DFSMSdss to re-initialize FCNOCOPY target volumes results in random,
unpredictable contents on the target volumes depending on activity on
the source volumes. Hopefully, the state of the few non re-initialized
volumes is such that varying the volume online will never cause problems
to z/OS as long, as one avoids referencing datasets on the volume; but
it seems likely that at least some of the datasets in the uncleared VTOC
will reside on tracks that were not copied and hence are invalid.
Random, unpredictable results are generally not a good thing in a DP
environment. I would think a much saner approach would be to always
re-initialize any FCNOCOPY volume after a "DUMP ... FCWD", or at least
provide some parameter option to force this, so that the user is
guaranteed a known FC target state at the end of the process and that
there is no misleading or inconsistent data left on the FC target.
I haven't seen anything to suggest that this somewhat bizarre (to me)
behavior of DFSMSdss will induce any failures in using FCNOCOPY and
DFSMSdss "DUMP FULL ... FCWD" as part of a DR point-in-time backup
strategy, but it does seem sub-optimal, as it randomly leaves
questionable "junk" behind. So far this appears to be more of a
cosmetic rather than functional issue, so it's probably not worth a
formal SHARE Requirement. It is enough to cause us to not use this
"feature" and instead retain the more cumbersome separate unconditional
ICKDSF INIT step just to keep the FC target volume contents consistent
from day to day.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
