Andrew,
Re your DFSMSdss remarks,
does FlashCopy (or z/OS) "remember" all the tracks it was initially
asked to copy, or just those tracks that are still in a "pending copy"
state? If just those still pending copy, then I would think VTOCIX or
VVDS tracks would also be an issue. If the basis for dss DUMP
FCWITHDRAW behavior is the original track-copy list, then presumably a
knowledgeable user wouldn't be copying VTOCIX or VVDS without also
copying the the VTOC, so basing the FCWITHDRAW INIT action on presence
of VTOC tracks alone would prevent getting unreadable VTOCIX and VVDS as
well.
In particular, on a full volume COPY with NOCOPY and Dump Conditioning,
are you guaranteed that a dss volume DUMP with FCWITHDRAW will always do
the ICKDSF INIT; or does it do the INIT only in the case where there are
still VTOC tracks in pending-copy state and a potentially unreadable
VTOC on the target? From our standpoint it would obviously be more
useful if the final state of the target volume were deterministic -
e.g., always in an initialized state with no datasets in the VTOC. If
that is indeed how it works, that would definitely make point-in-time
backups much simpler: making vary offline, ICKDSF INIT (forcing
FCWITHDR), and vary online steps after the DUMP always unnecessary.
We have had a few rare cases in the past (may have been IBM 2105 with FC
version 1?) where the dss volume copy attempt to use FastCopy was
rejected by the DASD subsytem (some kind of internal timing issue),
where dss COPY completed successfully but did a much slower physical
copy. Do you know whether a subsequent dss DUMP with FCWITHDRAW will
fail or produce a nonzero return code, if there was never a successful
FCESTABL in the first place.
Joel C. Ewing
Data-Tronics Corp., Ft Smith, AR
Andrew N Wilt wrote:
When you use ICKDSF to init a volume, it will issue an FCWITHDRAW for
that volume just as Joel said. Since the volume is newly inited, then there
is no reason to have a relationship as all those tracks are free space.
If you are using DFSMSdss to dump, we have an FCWITHDRAW keyword
that requests us to issue the FCWITHDRAW against the volume after we
have successfully dumped. For full volume dumps, this keyword was
enhanced in APAR OA18929 so that if the VTOC tracks are the target of
a FlashCopy relationship, we would have ICKDSF do an init of the volume
instead of the FCWithdraw. Previously, simply withdrawing the relationship
could make the volume unusable until it was initialized because track 0
would point to the location of the FlashCopied VTOC which no longer
was there due to the relationship withdrawal.
This APAR would only save you steps if you were doing Dump Conditioning
Full volume copies with DFSMSdss followed by full volume dumps of the
copy.
Thanks,
Andrew Wilt
IBM DFSMSdss Architecture/Development
Tucson, Arizona
...
--
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
