IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Difference between Three disk copy services in DFSMS


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Tue Nov 10, 2009 8:18 pm
Reply with quote

HI
I want to know the difference between three disk copy services that are provided by DFSMS:

Concurrent copy
Snapshot copy
Flash copy

I read it from some manual, but i could not get the basic concept behind each one. can anyone explain me.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Nov 10, 2009 8:28 pm
Reply with quote

SNAPSHOT is a function of a RAMAC Virtual Array (RVA) -- a specific type of disk subsystem used by IBM. The term does not apply if you are not using an RVA. It is a very quick copy of the data.

Concurrent copy is a copy that is consistent even though updates are occurring while the copy is underway (i.e., the updates are not applied to the concurrent copy of the data).

Flash copy is a point-in-time copy of the data -- updates are not reflected in it since updates occur over time and flash copy is at a single point in time.
Back to top
View user's profile Send private message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Tue Nov 10, 2009 8:39 pm
Reply with quote

Robert Sample wrote:

Concurrent copy is a copy that is consistent even though updates are occurring while the copy is underway (i.e., the updates are not applied to the concurrent copy of the data).

Flash copy is a point-in-time copy of the data -- updates are not reflected in it since updates occur over time and flash copy is at a single point in time.


As per your statement both concurrent and Flash copy wont reflect the updates. Then what is the differnece?
I cant find any difference between these two copy techniques.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Nov 10, 2009 8:55 pm
Reply with quote

Concurrent copy starts the copy immediately but it takes time to complete. Until the copy is complete and the system notification is generated, you cannot guarantee the backup is valid. One reason the backup may fail is that so many updates are applied so quickly that the disk subsystem cannot record them all in the available space for application after the backup is done.

Flash copy is a volume-level "instant" copy method. Which means the data is not physically copied, just the pointers to the data. This can be done very quickly (typically under a minute) but has implications for application recovery. Any updates done after the flash copy would not be reflected in the copy.
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Thu Dec 31, 2009 8:48 pm
Reply with quote

Suggest you read the IBM Advanced Copy Services manual where all is revealed.

Note: Flashcopy can operate at both the volume and dataset level these days when using DFDSS
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Mon Jan 04, 2010 10:28 pm
Reply with quote

This is a bit more of an explanation, but not exhaustive. Disclaimers apply!

IBM Flashcopy (and similar for HDS Shadow Image)

When you Flashcopy a volume or dataset, depending on the mode of Flashcopy the DASD controller will first set up a bit-map of the source volume or dataset track addresses, then the same for the target volume or dataset. The DASD controller will then begin a 'background copy' of the data from the source to target tracks, ticking them off as it progresses, but from a ZoS or MVS perspective the file has been copied as soon as the bit-map is set up so appears to be near instant. Until the copy is completed, any reference to the target volume or dataset may actually be accessing either the source or target tracks depending on whether they have been copied or not. If before the background copy is completed you update the source volume/dataset, the controller will first copy the unchanged tracks to the target equivalent to maintain the point in time status of the target, and then update the source. Note that there are some variations on this for other modes of Flashcopy, and some restrictions for PPRC mirrors.

SNAPSHOT

Similar principle to Flashcopy, except the controller never actually does the background copy and just maintains the bit-map pointers. Until either source or target change only the capacity of the source will be actually used. However, as either source or target volume/dataset tracks change they are written to new locations and the pointers updated. As both source and target change the actual amount of capacity used increases because each have more new unique tracks using separate locations. Old tracks are invalidated and released for reuse by the automatic 'scrubbing routines' that maintains the NCL (Net Capacity Load) of the controller. This is how the RVA (or Iceberg) controllers can fit larger capacity than is physically available from a ZoS perspective, along with the fact they compress the data at around 2.6 to 1 by default. ~

Warning: Some functions such as ICKDSF REFORMAT and INITIALISE are not recognised by the 'scrubbing routines' so initialising or renaming a large number of volumes for example can see the NCL suddenly climb. If it gets over about 85% you'll start to get degraded performance. To overcome this you should run a batch version of the 'scrubbing process' immediately afterwards which will release the affected tracks.

CONCURRENT COPY

Concurrent Copy uses the SDM (System Data Mover) (can be monitored via modify commands to the ANTASnnn address spacesa). It would set up DASD controller AND Host processor sessions ('side-files') to maintain a bit-map of the source dataset(s) track locations which are then used for copying to the backup copy as a point in time copy. Meanwhile if the source dataset is updated the SDM intercepts those updates and holds them in the side-file until the original source tracks are copied to the backup before destaging and updating the original track.
Note: The SDM can also used by XRC (eXtended Remote Copy or Metro Copy) and XRC also creates sessions (sidefiles) in DASD cache so these can compete with eachother for resources, especially in a very highly write active subsystem.
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Tue Jan 05, 2010 8:23 pm
Reply with quote

Further reference...this Redbook has some good explanations in it...

www.redbooks.ibm.com/redbooks/pdfs/sg245680.pdf
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts How to access web services/website? Mainframe Interview Questions 4
No new posts VB to VB copy - Full length reached SYNCSORT 8
No new posts CA Disk LISTD SQL CA Products 1
No new posts Need COBOL COPY Help in MVS Environment COBOL Programming 4
No new posts Issue after ISPF copy to Linklist Lib... TSO/ISPF 1
Search our Forums:

Back to Top