Even if the FC pairing always stays the same there is still the
possibility the VVDS might take another extent, or that there could be
VTOC or VVDS tracks that have never yet needed to be copied and would be
invalid if read from the target after a withdraw. With
flash-copy-no-copy you always have the exposure that after the FC
withdraw you may be left with inconsistent/invalid VTOC and/or VVDS data
on the target volume. If you always re-init the target, you don't have
to worry about special cases, and the overhead is so minor compared with
dumping a volume that there is no good reason not to re-INIT.
See earlier remarks in ibm-main re the INIT on a target volume also
forcing a FC Withdraw of no-copy relationship. If you are going to
re-init anyhow, this is probably a better way to do the withdraw than
with the DUMP. If you withdraw the copy relationship but leave the
device online, you are exposed to some occasionally bizarre (but
typically non-fatal) MVS error messages if some periodic system process
that checks all online volumes attempts to look at the online target
volume after the FCWITHDR but before it is reinitialized and sees
"strangeness".
JC Ewing
Scott Rowe wrote:
One of the issues I've noticed is that if the VTOC moves as a function of the FlashCopy, then you may have issues accessing the target volumes, particulrly on other systems. These can usually be solved by varying off/on the target volumes, so that the VTOC location can be refreshed in the UCB.
This is usually an issue only after the first copy of a volume - as long as the
source-target pairing remains the same, the VTOC will not appear to move after
the first time.
I suspect that your problem may be ralated to this.
Paul Jodlowski <[EMAIL PROTECTED]> 12/24/2007 11:54:37 AM >>>
We have a DS6800 with flashcopy 2. We use the following to flash 37 volumes
COPY FULL INDY(USERxx) OUTDY(FSERxx) PUR ADMIN -
DUMPCOND FCNC FR(REQ) ALLDATA(*) ALLEXCP
The job takes about 20 seconds and completes with a cond code of 0.
Then about 4 hours later run job to dump target to tape using following
DUMP INDD(DASD) OUTDD(BACKUP) FCWD
The job fininhes with cond code 0.
The next day when run Copy job again get cond code of 8 with System abend
code=0213 (but not on EVERY volume just on 9 of them).
If I init the target volumes this seems to fix it.
Just want to know if this is S.O.P. (copy,dump then init). Or is this WRONG.
os is 1.7
Cheers
...
--
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
