Esmie, Let me give it a try. I think you're getting confused due to terminology and different views of the copies. From a z/OS point of view, both the examples you show are doing full volume copies of data from your IN to your OUT. Once the job is done, you have 2 full copies of the data, one on each volume. The difference is what's going on in the back-end disk array.
In example 1, you have FCNC which from the back-end array, the only thing that happens is that a set of pointers (a track table) gets built but no data gets copied. The only time data gets physically copied from source to target is when either the source or target data track is changed. If the source data gets changed, a copy of the track gets put on the target before the source is updated. In case of the target getting updated, the changed data is written to the target. If, for example, in this scenario you are doing this copy with the intent of doing a DUMP of the target to tape, most of the data for the DUMP is actually coming from the SOURCE, because unless the data changed, the SOURCE is the only place the physical data resides. In example 2, FCINCREMENTAL does NOT mean do an incremental backup. FC/DFDSS does a full background copy of all the data from the source to the target. It still looks like it ran really fast to z/OS because as soon as the track table is built on the array, the array signals to z/OS the backup is done. However, the back end is still copying all the data to the target. Why use FCINCR then? Under normal FC processing, if you don't use FCNC, the background copy is initiated, and then once all the data is copied to the target, the relationship between source and target is terminated, and the 2 volumes are now stand-alone. If FCINCR is specified like in your example, the relationship remains in place with the track table now indicating which tracks have changed since the FC ran. If you then come along and run another COPY command with the same source and target, the array uses the track table and only updates the changed tracks, thus (potentially) significantly reducing the load on the array if there wasn't much change in the data. So in short, FCNC only copies changed tracks from the source to the target, but FCINCR forces a full back-end copy of all the data from source to target on initial setup. Note in the DFDSS manual is that FCNC and FCINCR are mutually exclusive. HTH, Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Tuesday, July 19, 2016 6:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: FLASHCOPY QUESTION Gentle Readers, I was wondering if any of you can clear up understating about FlashCopy. In the following example COPY INDYNAM(SYS012) OUTDYNAM(DCN00) CANCELERROR - PURGE ALLEXCP ALLDATA(*) OPT(4) ADMIN FCNOCOPY - DUMPCOND FR(REQ) DEBUG(FRMSG(DETAILED)) My understanding is that an Incremental copy is being performed because FCNOCPY is specified. My understanding of Incremental is that only the updated tracks are copied over to the target volume. Please correct me if I am wrong. Also, I have this example. Is this for a FULL FlashCopy of a volume? However, I am confused that the FCINCREMENTAL parm is specified which would indicate that this is an incremental copy COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCINCREMENTAL DUMPCONDITIONING ADMIN PURGE Could someone clear up this for me? Thanks in advance. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
