I don't know of any overt sign of flash copy invocation, but for me there is strong circumstantial evidence: lightning fast volume copy. We periodically migrate maintenance via full DSS volume copy. Done this for years. Then one time the copy job ran in only seconds instead of minutes. I thought for sure something had failed. Nope, all was A-OK. It happened that the source and target volumes were in the same DS8* DASD subsystem with the flash copy feature installed, so (I was told) flash copy got invoked automatically. When we copy between DASD subsystems, it still takes minutes.
BTW I have a narrower view of 'online/offline' than Joel does. I take 'online' to be an MVS status involving OS control blocks. A volume is either online or offline on that basis. The trouble with bringing in 'reachable' is that it introduces a scale of 'accessibility' with many nuances. Is the device physically connected at all? If it is connected, is it genned to a chpid? If it is genned, is the chpid in the access list for that LPAR? If it is not in the list, can the IODF be updated to include it? These questions all cloud the issue. So, a volume is either online or offline to the OS at any given moment. Duplicate volsers are not allowed to be OS-online concurrently. No other restrictions. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Joel C. Ewing Sent: Saturday, December 03, 2016 8:18 AM To: [email protected] Subject: (External):Re: FLASHCOPY QUESTION 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
