On 10/22/2013 01:45 PM, Pommier, Rex wrote: > Hi list, > > I just dug thru the Advanced Copy Redbook and the Advanced Copy Services > regular document, as well as looking thru the archives to no avail. > > Here's my question. I have a large VSAM dataset that I am backing up with > DFDSS COPY services using Flashcopy (full copy, not NOCOPY) right before > running batch against the source dataset. Hypothetical situation is that the > batch job updates a couple records in the source dataset then abends > immediately, before the background copy has completed. What happens if I try > to submit a DFDSS COPY job to copy the target VSAM dataset back on top of the > original source VSAM dataset? I know this is an illegal operation while the > original Flashcopy relationship is in place, but the manuals don't tell me > what kind of result I can expect. > > Will the second copy job fail due to the original FC relationship still being > there? This is my guess but would like some verification. If so, what kind > of error can I expect? > > Will the second copy job just wait until the original background copy is > complete (I doubt this)? > > Will it try to copy the dataset back and destroy the data? > > > TIA, > > Rex > > ...
If this were to work like flash copy of a full volume and the 2nd "restore" copy operation is just an ordinary copy (not a flash copy) I would expect this to restore the original VSAM data set contents without any problem. With full volume flash copy, if you read from the target volume before the physical background copy to that track is done, the DASD subsystem is smart enough to know it really needs to read that track from the source volume. If you try to update a track on the source volume before it has been copied to the target volume, it is smart enough to copy that track from source to target before allowing the original source track to be overwritten. Establishing a flash copy relationship is designed to give the same effect as if the physical copy actually completes in the time it takes just to establish the relationship (which completes in the time it takes to record the intended relationship between tracks on the two devices). Reading from the target, and writing to the source, after that point in time is supposed to produce the same end result as if the physical copy also completed at the same time the flash copy establishment was completed. I would expect flash copy at the data set level to behave similarly. If there are any restrictions on what you can do with source and target while the first physical copy is still incomplete, those restrictions should be on establishing other flash copy relationships involving the same tracks, not on ordinary reads and writes involving the tracks of either the source or target. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
