FlashCopy from IBM

Overview

Flashcopy works on IBM ESS subsystems. In Flashcopy terminology, you copy from a Source volume to a Target volume.

Flashcopy has three phases, Establish, Copy and Termination.

The Establish phase is very fast, it just involves setting up new pointers. Once it is complete, the source and target disks can be accessed independently. From the application’s point of view, the copy is complete once the Establish phase is over

The Copy phase has two modes, Background Copy and Nobackground Copy.
The Background Copy mode will initially set up the copy relationship with pointers, then it will physically copy all the data from the source to the target. Once the data copy is complete, the relationship between source and target is broken. While the copy is in progress, if a process requires data that has not been copied over, it is read from the source disk using the pointer.
Nobackground Copy mode will only copy data that is updated on the source disk. Data that has not been updated is read from the source. The subsystem writes out updated target data to the target disk. When using NoCopy, the relationship between source & target is maintained until it is manually terminated, or all the data on the target disk has been updated. GDPS and FDRinstant both use Nocopy mode.

The Termination phase either happens automatically once all the source data has been copied over, or as a response to a FCWITHDRAW command.
You can specify that a Flashcopy is ‘persistent’ so it is not withdrawn automatically, but has to be withdrawn with manual commands. This is to prevent an accidental overwrite of a target volume, as you cannot have two flashcopy sessions going to the same target volume (just imagine how much fun that would be!).

A single disk can be both Flashcopy source and PPRC primary, but you also cannot use a PPRC primary disk as a Flashcopy Target. The trouble is, if you use a batch job to establish a Flashcopy onto a PPRC source the job will appear to work as it will end condcode=0. However, if you try an FCQUERY against the disk, you will see that there is no flashcopy relationship, and in fact the command did not work.

There are two versions of Flashcopy.

Flashcopy V1 only works at volume level, the volumes need to be in thesame logical subsystem, have the same logical track format, the target volume must be the same size, or bigger than the source, and any volume can only be in one Flashcopy relationship at at time.

FlashCopy V2 is a chargeable upgrade from Flashcopy version 1.

FlashCopy V2 uses extents to manage the relationship between the source and the target, rather than volumes. These extents can range from a single track to an entire volume. This means that the source and target volumes do not need to be the same size, and the target volume extents can map to different locations within the source volume. This allows Flashcopy V2 to have the following extra features

• Its possible to copy data sets, as well as volumes, as a source can be any size from one track upwards
• Its possible to have up to 12 copies of any source active at a time, though a target can only have one source. At any given time, a volume or data set can be either a source or target, but not both. This is called Multiple Relationship FlashCopy.
• The source and target volumes must be in the same ESS, but can be in different logical subsystems
• Flashcopy commands can be sent over a PPRC link, instead of requiring network links to the remote site
• It takes 2-3 hours to make a full Background copy of 10 terabytes of data. If you do this regularly for rapid recovery, then a new function, Incremental FlashCopy, lets you just refresh the target data with tracks that have changed since the last copy was made. You define and invoke this from the ESS Copy Services Web user interface panels. You must specify that this is a persistent relationship to allow the ESS to continue tracking updates to source and target extents. It works at volume level only, not for dataset FlashCopy.
• While the FlashCopy Establish phase is fast, if you are copying several hundred disks, it will take a minute or so to do them all. Databases require their data to be at a consistent point-in-time, and a minutes difference between two database components can make the database unusable. The FlashCopy Consistency Group uses the freeze function to put all the FlashCopy source volumes in an extended long busy state until the FlashCopy completes over all disks.

Invoking FlashCopy

DFDSS

If the conditions are right, a DFDSS copy job will invoke Flashcopy automatically, whether you ask for it or not. If this happens, you should see a message

 ADR806I  (001) – VOLUME COPIED USING A FAST REPLICATION FUNCTION

This will also happen if you are copying datasets within an ESS with Flashcopy version 2 installed.

TSO commands

To explicitly invoke flashcopy you can use TSO commands. FCESTABL, FCQUERY, FCWITHDR

FCESTABL

Establish flashcopy relationship

 
 FCESTABL SDEVN(X'nnnn') TDEVN(X'nnnn') MODE(COPY/NOCOPY) 
          ONLINTGT(NO/YES)

SDEVN is the source UCB, the one you are flashing from
TDEVN is the target UCB, the one you are flashing to
MODE can be COPY or NOCOPY. COPY will copy all the data to the target, then terminate the flash pair.
NOCOPY will only copy changed tracks. The flash pair will exist until it is terminated by the FCWITHDR command
ONLINTGT can be NO or YES. If you specify YES, then the data on the volume will be overwritten, and the volume forced offline, because the VOLSER will be a duplicate. You need to be careful with this.

Flashcopy Version 2 – the 4 character unit addresses above can be simply specified as SDEVN(2345), no need for the hex marker. There is a new parameter, XTNTLST which specifies a list of source and target extent pairs. Each pair describes a FlashCopy relationship between a source volume begin and end track extent, and the corresponding target volume begin and end track extent.You can specify as many extent pairs as allowed by the TSO command line limitation.

 XTNTLST (01000004 0357000A 13000001 15570007,
 		  02AC0006 02FF000C 18A00000 18F30006)

Now, can you honestly see anyone dumping a VTOC to get the extent information for a file, then using that to create an xtntlst as above? This command will be used by value added applications like DFDSS.

FCQUERY

Query flashcopy status

FCQUERY DEVN(X'nnnn')

Flashcopy v1 output looks like

 
 FCQUERY Formatted 
 DEVN   SSID 	LSS   	CCA   CU    SERIAL        STATUS 
 9010 	E700  	00   	10    2105  000110017449  FC
 FCQUERY COMMAND COMPLETED FOR DEVICE 9010. COMPLETION CODE: 00

Flashcopy v2 output is

 FCQUERY Formatted -2  
 DEVN    SSID  LSS  CCA   CU    SERIAL          ACT  MAX   XC   PC  CC 
 A200    EC02  02   00   2105   0000001106118   4    A719  N    S   N
 FCQUERY COMMAND COMPLETED FOR DEVICE A200. COMPLETION CODE: 00

FCWITHDR

Explicitly withdraw a flashcopy relationship

 FCWITHDR SDEVN(X'nnnn') TDEVN(X'nnnn')

For Flashcopy v1, this withdraws the Flashcopy session. For Flashcopy v2, this will withdraw any active sessions which are active to the specified target device, but will keep active sessions to other targets. I f no target is specified, all sessions from the source are withdrawn. You can also withdraw Flashcopy sessions to specific extents

 FCWITHDR SDEVN(9400)TDEVN(9470)
 XTNTLST(00000000 0100000E 20000000 2100000E)

Applications

Several applications invoke flashcopy through the API. Examples are GDPS or FDRinstant, see the relevant sections for details.

Storwatch

You can use Storwatch. Go into Copy Services, left click on your source volume, right click on your target, and blue & red triangles appear, indicating FlashCopy is in progress. Storwatch was really intended for Open systems use. Its possible to overwrite active z/OS disks quite easily with Storwatch, and there is no check to see if disks are online, and no link to the z/OS enqueing mechanisms.

back to top

By entering and using this site, you accept the conditions and limitations of use