Joel, Thanks for helping me understand DUMPCONDITIONING. With your help I am able to increase my understanding. -------------------------------------------- On Sat, 12/3/16, Joel C. Ewing <[email protected]> wrote:
Subject: Re: FLASHCOPY QUESTION To: [email protected] Received: Saturday, December 3, 2016, 11:18 AM On 12/03/2016 07:58 AM, esmie moo wrote: > Gentle Readers, > > I have a question about FLASHCOPY using ADRDSSU and COPY. In my first example I was told that the job is using FLASHCOPY. However I do not see any evidence. > > COPY FULL INDYNAM (SDB000) OUTDYNAM (MDB000) DUMPCONDITIONING > ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' > > >From my understanding it is performing a full volume copy of a source volume. If my understanding of the parm DUMPCONDITIONING is correct, it (DUMPCONDITIONING) allows to make a copy of the source volume and while keeping the target volume online. > > I have done a full volume copy of a source to target without the DUMPCONDITIONING parm and it worked - the volume was fully copied (see below). Am I missing something? Aren't both examples doing the same thing? > > COPY INDDNAME(DASD1) OUTDDNAME(DASD2) - > ALLDATA(*) ALLEXCP COPYVOLID PURGE > /* > > However I do not see any evidence of FLASHCOPY being invoked because the FCNC parm is not present. > > Here is a my second example: > > COPY FULL IDY(PROM70,3390) ODY(SNAP63,3390) DUMPCOND FCNC- > ALLDATA(*) ALLEXCP CANCELERROR PURGE FCTOPPRCPRIMARY - > FCSETGTOK(FAILRELATION) > > In the above example FLASCHOPY is being performed because of the FCNC. > > Could you correct my understanding of all 3 examples? > > Thanks. > > If you do a full volume copy without DUMPCONDITIONING and with COPYVOLID, that means when the copy is complete the target volume will now have the same VOLSER as the source volume and dss will force it offline, as you can't have two volumes with identical VOLSER online to the same MVS system. If your goal was just to make a point-in-time copy on DASD, that may be sufficient. But if your goal was to then back up that target volume to removable tape media, you would not be able to do that with dss from the same system because the volume is offline because of the duplicate VOLSER. It also means that if you for some reason needed to IPL at that point, the system will complain about finding two volumes with the same VOLSER and there could be some confusion about which of the two volumes should be placed online and the wrong one could be chosen. With DUMPCONDITIONING the original different target volume VOLSER is preserved so both volumes can be online to the same system and there is no later confusion about which is the original and which is the point-in-time copy. DSS is smart enough when restoring from a tape dump of the volume with the DUMPCONDITIONING copy to also restore the original VOLSER (this used to require either an VTOCINDEX or VVDS dataset on the volume to supply the correct VOLSER). There are other vendor utilities that will allow one to dump an offline DASD volume with a duplicate volser to tape, but this seems to me a perversion of the meaning of "offline", which was intended to mean access by the system was impossible and that the device could safely be taken physically offline for hardware maintenance. Assuming there is still a dss FASTREPLICATION parameter, it used to default to "PREFERRED", which meant if flashcopy wasn't available for some reason, dss would default to an ordinary copy but still do the COPY command successfully (just m-u-c-h slower). If you wanted the copy to fail if flashcopy were not possible, you had to explicitly request FASTREPLICATION(REQUIRED). It should be obvious from the time required for the COPY command to complete whether flashcopy has been used: a fraction of a second for the dss COPY command to complete with fastcopy, versus minutes without fastcopy. Joel C. Ewing -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
