Re: flash copy and relationships, using HSM for dump to tape.
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
Re: flash copy and relationships, using HSM for dump to tape.
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 IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/12/2007 06:04:18 PM: Interesting. I have always thought in terms of stopping the COPY relationship and any unnecessary track copy activity as soon as possible when the target was no longer needed, so it had never occurred to me to re-initialize the FlashCopy target first and then try to do the FCWITHDR. We always do it in the sequence FCESTABL-NOCOPY, dump, vary offline, FCWITHDR, then re-initialize. That works without any problems 99.9% of the time, but occasionally a FlashCopy even with NOCOPY will have already completed normally, and the FCWITHDR will get a failure that must be tolerated. The FCESTABL NOCOPY can apparently terminate on its own (at least on the IBM 2107) if no further action is required because all in-use tracks on the source volume at the time of the FCESTABL have been over-written on either the source volume (forcing a physical copy of the track to the target) or on the target volume (making the original source volume track irrelevant to the target). I would also swear that I have seen instances on our IBM 2107 with FlashCopy V2 where it seems as if the controller decided it was cheaper to just copy the few remaining tracks than maintain the copy relationship. Perhaps z/OS is smart enough to recognize when you re-initialize the target volume and destroy the VTOC that you have logically overwritten all tracks on the target volume, and that is the point at which the COPY relationship gets terminated. If that is indeed the case, then perhaps we can simplify our procedures by relying on the INIT to accomplish the withdrawal (if it hasn't already terminated on its own), and at the same time eliminate the need to handle the occasional random FCWITHDR failure. Is there anyone at IBM that can verify the hypothesis that a re-initialize of the FlashCopy target volume is sufficient to always terminate a FCESTABL NOCOPY relationship under FlashCopy V2? -- 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
Re: flash copy and relationships, using HSM for dump to tape.
Interesting. I have always thought in terms of stopping the COPY
relationship and any unnecessary track copy activity as soon as possible
when the target was no longer needed, so it had never occurred to me to
re-initialize the FlashCopy target first and then try to do the FCWITHDR.
We always do it in the sequence FCESTABL-NOCOPY, dump, vary offline,
FCWITHDR, then re-initialize. That works without any problems 99.9% of
the time, but occasionally a FlashCopy even with NOCOPY will have
already completed normally, and the FCWITHDR will get a failure that
must be tolerated.
The FCESTABL NOCOPY can apparently terminate on its own (at least on the
IBM 2107) if no further action is required because all in-use tracks on
the source volume at the time of the FCESTABL have been over-written on
either the source volume (forcing a physical copy of the track to the
target) or on the target volume (making the original source volume track
irrelevant to the target). I would also swear that I have seen
instances on our IBM 2107 with FlashCopy V2 where it seems as if the
controller decided it was cheaper to just copy the few remaining
tracks than maintain the copy relationship.
Perhaps z/OS is smart enough to recognize when you re-initialize the
target volume and destroy the VTOC that you have logically overwritten
all tracks on the target volume, and that is the point at which the COPY
relationship gets terminated. If that is indeed the case, then perhaps
we can simplify our procedures by relying on the INIT to accomplish the
withdrawal (if it hasn't already terminated on its own), and at the same
time eliminate the need to handle the occasional random FCWITHDR failure.
Is there anyone at IBM that can verify the hypothesis that a
re-initialize of the FlashCopy target volume is sufficient to always
terminate a FCESTABL NOCOPY relationship under FlashCopy V2?
pdc wrote:
Here's my current scenario:
1. Run FCESTABL commands with NOCOPY to set up a relationship between source
volumes and target volumes.
2. Target volumes are varied online to our 'backup/recovery' system. The
volumes are considered part of one of the SMS storage groups on that system
(OFFSITE.)
3. HSM is requested to dump the volumes in that storage group to tape, using
the following command
HSEND BACKVOL SG(OFFSITE) DUMP(DUMPCLASS(OFFSITE)) UNIT(3390)
where the ARCCMDxx parmlib member shows
DEFINE DUMPCLASS(OFFSITE -
AUTOREUSE -
DAY(7) -
DSRESTORE -
FREQUENCY(28) -
STACK(99) -
HWCOMPRESS(YES)-
NORESET -
RETPD(84) -
UNIT(HOMER) -
VTOCCOPIES(2) -
DISP('OFFSITE COMPLETED'))
This all seems to run quite well, the various tape mounts were requested and
data appears to be dumped successfully to tape.
4. At the end of the dumps, I varied the target volumes offline to the
system and ran dsf inits back to their original names.
ie.
//INIT2 EXEC PGM=ICKDSF,PARM='NOREPLYU'
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
INIT UNIT(1701) NVAL VFY(AWZ047) VOLID(TG1701) -
VTOC(0,1,90) INDEX(10,1,90) SG
5. The final step is to issue FCWITHDR commands to end the relationship.
it is at this point that the system tells me that there is no relationship.
ANTF8804I FCWITHDR SDEVN(X'DF1C') TDEVN(X'1701')
ANTF0335I FLASHCOPY WITHDRAW SOURCE DEVICE DF1C NOT ACTIVE FLASHCOPY
SOURCE DEVICE
ANTF0001I FCWITHDR COMMAND UNSUCCESSFUL FOR DEVICE DF1C. COMPLETION
CODE: 08
My question is, did HSM withdraw the relationship once it had finished the
dump to tape? I don't think it would since it is not responsible for the
establish in the first place.
Did the dsf init cause the relationship to end? I guess the tracks would
all have been updated and so the relationship would no longer be required.
Is this the case?
--
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
