Chapter 2.

Copy Services architecture
In this chapter, we provide an overview of the structure of the Copy Services communication architecture in either an open or System z environment. We cover the following topics: Introduction to the Copy Services structure The structure of Copy Services management System z communication path for Copy Services
2.1 Introduction to the Copy Services structure
The Copy Services architecture for the IBM ESS 800 used a construct called a Copy Services Domain to manage Copy Services. The communications architecture for the DS6000 and DS8000 is noticeably different. Instead of a Copy Services Domain, we now use the concept of Storage Complexes. You can perform Copy Services operations both within or between DS8000, DS6000, and ESS Storage Complexes. An ESS 800 Copy Services Domain (at the correct firmware level), can, for management purposes, appear to a DS8000 as an independent Storage Complex. Within a Storage Complex, you will find management consoles, storage units, and in the case of DS8000, storage facility images. First, we define each of these constructs.
2.1.1 Management console defined
A management console is a PC that is used to manage the devices within a Storage Complex. In the case of the DS8000, it is a dedicated PC that comes with a pre-installed Linux-based operating system and pre-installed management software. The DS8000 console is called a Hardware Management Console (HMC). The end-user interacts with the management console using either the Web browser based DS GUI or the Command-Line Interface (DS CLI). It is possible using the DS GUI to manage Copy Services operations on multiple Storage Complexes.
2.1.2 Storage Unit defined
A Storage Unit is the physical storage device (including expansion enclosures) that you see when you walk into the computer room. If you open a frame door and look at a DS8000 sitting on the floor (with any attached expansion frames), then you are looking at a DS8000 Storage Unit. An example would be a 2107-922 or 932 with an attached 2107-92E. Another example would be a 2107-9A2 with an attached 2107-9AE. In each example you would have a single DS8000 Storage Unit.
2.1.3 Storage Facility Image (SFI) defined
The Copy Services architecture for the IBM ESS 800 used a construct called a Copy Services Domain to manage Copy Services. The communications architecture for the DS6000 and DS8000 is noticeably different. Instead of a Copy Services Domain, we now use the concept of Storage Complexes. When using the DS GUI or the DS CLI to manage a DS8000, you have to distinguish whether you are working with the Storage Facility Image (SFI) or with the Storage Unit. Some commands operate on the Storage Unit. For most operations, you always work with an SFI. You can tell the difference very easily. The serial number of the Storage Unit always ends with a 0. The serial number of the first SFI always ends with a 1. If you have ordered a model 2107-9A2 or 2107-9B2, then you will also have a second SFI. The serial number of the second SFI always ends with a 2.

7.4.7 Failover/failback terminology
There is often a misconception about what failover/failback commands do. Figure 7-3 illustrates the failover/failback two-step process. The process is as follows: 1. When the replication process between primary (P) and secondary (S) is suspended as a result of a planned or unplanned outage, you might want to access the S volumes immediately without any checking on the P volumes. The failover command always points to the S volumes and turns the S volumes from SECONDARY state into a PRIMARY SUSPEND state, making the volumes immediately available to the application. This state change for the S volumes at the remote site happens without any communication or any checking of the P volumes at the local site, which keep the status they had before the failover command was issued.
Local DS6000 / DS8000 Suspends due to planned or unplanned event Replication direction Remote DS6000 / DS8000
Primary Primary Primary Primary Primary
Primary Primary Primary Primary

Secondary

1. Failover command 2. Failback command

PRIMARY SUSPENDED

SECONDARY PENDING SECONDARY DUPLEX

Resynchronisation

PRIMARY PENDING PRIMARY DUPLEX

2. Failback command

Figure 7-3 Failover/failback terminology
2. When the outage is over and you decide to resume replicating data between the sites, you have a choice as whether to re-synchronize from the remote site to the local site or vice versa. This depends on what is required after updating one of the two sites or even updating both sites after the suspend action. a. When you decide to re-synchronize from the remote site to the local site the failback command is pointing to the remote volumes. You need a PPRC path from the remote site to the local site before you can perform the corresponding commands. Doing this will resynchronize both sites with the level of data as it is at the remote site. Only the data that changed at the remote site, from the moment the replication was suspended and until the failover happened, is replicated from remote to local volumes. Figure 7-3 assumes a Metro Mirror (MM) environment that puts the corresponding MM pair in PENDING state during re-synchronization, and once everything is replicated the MM pair goes into DUPLEX state.
b. If you want to re-synchronize both sites with the data level at the local site, issue the failback command towards the volumes at the local site. This replicates the changed data since the suspend from the local site to the remote site. Also, this resets the tracks that were potentially changed at the remote site after the failover. Figure 7-3 on page 53 assumes an MM environment that places the MM pair in PENDING state during the re-synchronization phase. When all changed data is replicated, the MM pair goes into DUPLEX state. The option to re-synchronize from either site is possible due to the availability of change bitmaps maintained by the DS6000 or DS8000 at both sites.

Metro Mirror primary volume H1 from copy set 3 in the second storage server, and volumes H1(copy set 1 and 2) in the first storage server with their corresponding Metro Mirror secondary volumes are grouped together in a session, Session 1. Such a session can contain copy sets that span across storage server boundaries. Metro Mirror primary volumes H1 with their counterparts H2 at the remote site belong to a different session, Session 2. Copy set 4 and copy set 5 belong to Session 2. Note that all application-dependent copy sets must belong to the same session to guarantee a successful management and to provide consistent data across all involved volumes within a session. In this context we recommend having application-dependent volume granularity within the scope of an LSS. Or, in other words, volumes or copy sets that require consistent data and can be subject to a freeze trigger ought to be grouped in one or more LSSs and that LSS must not contain other copy sets. This because the scope of the freeze function is at the LSS level and affects all volumes within that LSS.
7.7 TPC for Replication session types
There are three TPC for Replication licenses, which include different levels of Copy Services functions, as described in the following sections.
7.7.1 TPC for Replication Basic License
The Basic License includes Metro Mirror and Global Mirror, in addition to FlashCopy. However, Metro Mirror and Global Mirror are only configured to replicate data in a uni-directional fashion.
FlashCopy includes all functional levels of FlashCopy. This includes FlashCopy with these capabilities: Background copy or no background copy. Convert no background copy to background copy. Add persistent to a FlashCopy relationship. Establish incremental FlashCopy to apply only changed data since a previous FlashCopy operation. In a FlashCopy relationship, the target volumes can be Space Efficient volumes.
Metro Mirror is between a local site (site 1) and a remote site (site 2) in a uni-directional fashion. It allows the system to failover to the remote site for testing, but mirroring can only be restarted in the direction defined in the session (from site 1 to site 2). This can happen through failover/failback operations.
Global Mirror implies three volumes for each Global Mirror copy set. Again, this happens between a local site (site 1) and a distant site (site 2) in a uni-directional way. It is not possible to reverse the replication direction; a restart of mirroring can only be done from site 1 to site 2.

source data t0 tx t0 tz t0 t0 t0

target data t0

before physical write to the source: copy time-zero data from the source to the target
Figure 8-3 Reads from source and target volumes and writes to source volume
Reading from the source: The data is read immediately (see Figure 8-3 or Figure 8-4 on page 88). Writing to the source: Whenever data is written to the source volume while the FlashCopy relationship exists, the storage subsystem makes sure that the time-zero-data is copied to the target volume prior to overwriting it in the source volume. To determine if the data of the physical block on the source volume should be copied to the target volume, the bitmap is analyzed. If it determines that the time-zero data is not available on the target volume, then the data will be copied from source to target. When the target volume is a Space Efficient volume, the data is actually written to a repository (see Figure 8-4 on page 88). If it states that the time-zero data has already been copied to the target volume, then no further action is done (see Figure 8-3 or Figure 8-4 on page 88). It is possible to use the target volume immediately for reading data and also for writing data.
Reading from the target: Whenever a read-request goes to the target while the FlashCopy relationship exists, the bitmap is used to identify if the data has to be retrieved from the source or from the target. If the bitmap states that the time-zero data has not yet been copied to the target, then the physical read is directed to the source. If the time-zero data has already been copied to the target, then the read will be performed immediately against the target (see Figure 8-3 on page 87 or Figure 8-4 here).
Writing to the source volume in an IBM FlashCopy SE relationship and reading from the source and the target volume
t0 tx ty tz time read 1 read 2
time-zero data not yet available in target volume: read it from source volume.

bitmap 1

source volume data t0 tx t0 tz t0 t0 t0
Virtual target volume data t0
before physical write to the source volume: copy time-zero data from the source volume to the target volume
Repository for space efficient volumes
Figure 8-4 Reads from source and target volumes and writes to source volume for IBM FlashCopy SE relations
Writing to the target: Whenever data is written to the target volume while the FlashCopy relationship exists, the storage subsystem makes sure that the bitmap is updated. This way the time-zero data from the source volume never overwrites updates done directly to the target volume (see Figure 8-5 on page 89).

We can see the Metro Mirror pair has established and the volume is in Pending state, with 51% of tracks copied so far.
19.4 Defining a Metro Mirror path using ICKDSF
Example 19-12 shows an ICKDSF job that is defining a Metro Mirror path.
Example 19-12 ICKDSF PPRCOPY ESTPATH example //EPATH EXEC //SYSPRINT DD //DD01 DD //SYSIN DD PGM=ICKDSF SYSOUT=* UNIT=3390,VOL=SER=RS4000,DISP=SHR *
/* --------------------------------------------------------- */ /* ESTABLISH PPRC PATH FROM 00/ABTV1 TO 90/BYGT1 */ /* --------------------------------------------------------- */ PPRCOPY DDNAME (DD01) ESTPATH PRI (X'4000' ABTV1) SEC (X'9000' BYGT1) LSS (X'00' X'90') FCPPATHS (X'00420242') WWNN (5005076303FFC663 5005076304FFC671) /*
Notice that the PPRCOPY ESTPATH command replaces any path definitions that currently exist. In Example 19-13, we show the output from the ESTPATH command.
Example 19-13 ICKDSF PPRCOPY ESTPATH output ICKDSF - MVS/ESA DEVICE SUPPORT FACILITIES 17.0 TIME: 13:35:01
/* --------------------------------------------------------- */ /* ESTABLISH PPRC PATH FROM 00/ABTV1 TO 90/BYGT1 */ /* --------------------------------------------------------- */ PPRCOPY DDNAME (DD01) ESTPATH PRI (X'4000' ABTV1) SEC (X'9000' BYGT1) LSS (X'00' X'90') FCPPATHS (X'00420242') WWNN (5005076303FFC663 5005076304FFC671) ICK00700I DEVICE INFORMATION FOR 4000 IS CURRENTLY AS FOLLOWS: PHYSICAL DEVICE = 3390 STORAGE CONTROLLER = 2107 STORAGE CONTROL DESCRIPTOR = E8 DEVICE DESCRIPTOR = 0A ADDITIONAL DEVICE INFORMATION = 4A00003C ICK04000I DEVICE IS IN SIMPLEX STATE ICK02201I PPRCOPY ESTPATH FUNCTION COMPLETED SUCCESSFULLY ICK00001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
Example 19-14 shows the output from the PPRCOPY QUERY PATHS command. You can see that the path is in state 13, which indicates an established path.
Example 19-14 ICKDSF PPRCOPY QUERY PATHS output ICKDSF - MVS/ESA DEVICE SUPPORT FACILITIES 17.0 TIME: 13:35:01
PPRCOPY DDNAME(DD01) QUERY PATHS ICK00700I DEVICE INFORMATION FOR 4000 IS CURRENTLY AS FOLLOWS: PHYSICAL DEVICE = 3390 STORAGE CONTROLLER = 2107 STORAGE CONTROL DESCRIPTOR = E8 DEVICE DESCRIPTOR = 0A ADDITIONAL DEVICE INFORMATION = 4A00003C ICK04000I DEVICE IS IN SIMPLEX STATE QUERY REMOTE COPY - PATHS PRIMARY CONTROL UNIT SERIAL NUMBER SSID ------- ---ABTVINFORMATION LSS WORLD WIDE NUM NODE NAME --- ---------------00 5005076303FFC663

This situation might get even worse when involving multiple storage disk subsystems at the primary site. As Figure 25-6 shows, when using Global Copy, dependent writes are not preserved at the recovery site when a failure occurs. This characteristic happens both at a particular storage disk subsystem pair as well as across multiple storage disk subsystems.
Secondary remote site Storage Disk Subsystem 2 3C00
Primary Primary Primary Log Primary

non synchronous

Figure 25-6 Global Copy non-synchronous data replication involving multiple disk subsystems
Notice that the numbers in Figure 25-6 indicate the transfer of data as well as the sequence of its corresponding write I/Os. Record 3 might be replicated to storage disk subsystem 2 before record 1 arrives to storage disk subsystem 2. Record 2 might never make it to storage disk subsystem 4 due to the connectivity problem between storage disk subsystem 3 and storage disk subsystem 4, which in turn might be the beginning of a rolling disaster. So, when using a non-synchronous technique like Global Copy, consistent data cannot be guaranteed at the remote site without any additional measures, functions, and procedures. The challenge is to provide data consistency at the distant site at any time and independent of the combination of storage disk subsystems involved. One solution is to combine Global Copy with FlashCopy and create a three-copy solution. This requires a series of additional steps that have to be organized and carried out: 1. At the local site, temporarily pause the application write I/Os on the primary A volumes. 2. Wait for and make sure that the primary A volumes and the secondary B volumes become synchronized. Note the challenge to manage all volumes. 3. Using FlashCopy, create a point-in-time (PiT) copy of the B volumes at the remote site. 4. The FlashCopy targets, that is the C volumes, will then hold a copy of the A volumes at the time the application was paused or stopped. In this manner data consistency is kept at the remote site. 5. Restart or resume the application write I/O activity to the A volumes
Global Mirror asynchronous technique
If we could incorporate the previous five basic steps into the storage disk subsystem internal microcode, and we could count with the corresponding management interface, then this would basically be an efficient asynchronous mirroring technique that would allow the replication of data over long distances, without impacting the application I/O response time, its operation would be transparent and autonomic from the users point of view, and most importantly would provide a consistent copy of the data at the remote site at all times. All this is what basically Global Mirror is about. To accomplish the necessary activities with minimum impact on the application write I/O, Global Mirror introduces a smart bitmap approach in the primary storage disk subsystem. With this, Global Mirror can resume the application I/O processing immediately after a very brief serialization period for all involved primary storage disk subsystems this brief serialization periodically occurs at the very beginning of a sequence of events that resemble the ones outlined above. In the following chapters we explain in detail the characteristics of Global Mirror, how it operates, and how can you manage it.

ICKDSF used to be a disk management tool to initialize and diagnose disk volumes. Over time it evolved, and today ICKDSF contains functional support to manage all available Copy Services functions. ICKDSF supports all System z based operating systems including z/OS, z/VM, and VSE/ESA. Therefore ICKDSF is a common platform for all System z operating systems to provide an interface to the DS8000, DS6000, and ESS 800 Copy Services functions. This includes all of Metro Mirror, Global Copy, Global Mirror, and FlashCopy.
27.5.1 Establishing a Global Mirror environment
In the following sections we discuss how to set up a Global Mirror environment with ICKDSF. The sequence of steps we follow in our discussion, although not mandatory, is the recommended one for the creation of a Global Mirror environment (refer to Figure 27-7).
Query All Establish Paths
Manage Global Mirror Sessions

Establish Pairs

Define, Pause, Resume, Terminate Global Mirror Sessions

z/OS z/VM VSE

Host I/O
Long Distance Global Copy

Global Copy paths

Global Mirror Session paths

LSS LS S

Master Local Site
Figure 27-7 ICKDSF support for Global Mirror
Figure 27-7 provides the complete picture of a Global Mirror session. ICKDSF is used to: Establish Global Mirror and Global Copy paths Establish Global Copy pairs Create FlashCopy relationships Manage Global Mirror session: Add and remove volumes. Manage Global Mirror session: Pause and resume, start and stop Global Mirror session. In the following sections, we discuss the setup of a Global Mirror session using ICKDSF.

27.5.2 Defining paths

There is no change in how to define paths on the DS8000, or the DS6000, as compared to the ESS 800. Note: For remote copy functions, only Fibre Channel links are supported on the DS8000. Also notice that when you utilize more than a single primary storage disk subsystem at the local site, you have to define paths between them, for the Global Mirror session communication between the Master and the Subordinates. Also, you have to define the paths between the primary LSSs at the local site and the secondary LSSs at the remote site, so the Global Copy pairs can be established. Figure 27-8 illustrates the paths required for a Global Mirror environment.

29.3.1 Defining paths

First you define paths from A to B; see Example 29-7 on page 443. These are the paths that will be used for data transmission between the Global Copy pairs.
Example 29-7 Define paths for Global Copy from A to B //* ---------------------------- TSO ----------------------------- *** //* ESTABLISH PATH(S) for Global Copy pairs *** //* -------------------------------------------------------------- *** //EPATHS EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DDNAME=SYSIN CQUERY CESTPATH DEVN DEVN PRIM SEC LINK (X'2C00') PATHS (X'2C00') + (X'2C00' 5005076303FFC228 X'0C') + (X'3C00' 5005076303FFC422 X'0C') + (X'00300030' X'01300130' + X'02300230' X'03310330') CGROUP(NO) DEVN (X'2C00') PATHS DEVN DEVN PRIM SEC LINK (X'2D00') PATHS (X'2D00') + (X'2D00' 5005076303FFC228 X'0D') + (X'3D00' 5005076303FFC422 X'0D') + (X'00300030' X'01300130' + X'02300230' X'03310330') CGROUP(NO) DEVN (X'2D00') PATHS

CQUERY CQUERY CESTPATH

Verify, using query commands, that all paths have been defined and are operational. In our case, despite that the previous paths definition commands had completed successfully, a subsequent CQUERY reveals that there is a problem with one of the paths, see Example 29-8.
Example 29-8 Verify successful path creation *************** PPRC REMOTE COPY CQUERY - PATHS ******************** * PRIMARY UNIT: SERIAL#= 000000027131 SSID= 2C00 SS= 2107 LSS= 0C * * FIRST SECOND THIRD FOURTH * * SECONDARY SECONDARY SECONDARY SECONDARY * *SERIAL NO: 000000073081.. * * SSID LSS: 3C00 0C. * * PATHS: * * PFCA SFCA S* SAID DEST S* SAID DEST S* SAID DEST S* * * --------- -- --------- -- --------- -- --------- -- * * 1: 13 ---- ---- 00 ---- ---- 00 ---- ---- 00 * * 2: 13 ---- ---- 00 ---- ---- 00 ---- ---- 00 * * 3: 13 ---- ---- 00 ---- ---- 00 ---- ---- 00 * * 4: 14 ---- ---- 00 ---- ---- 00 ---- ---- 00 * * SUBSYSTEM WWNN LIC LEVEL * * ----------- -------------------------* * PRIMARY. 5005076303FFC228 5.0.03.0097 * * SECONDARY.1 5005076303FFC422 * * * * S* = PATH STATUS: * * 00=NO PATH 01=ESTABLISHED ESCON 02=INIT FAILED * * 03=TIME OUT 04=NO RESOURCES AT PRI 05=NO RESOURCES AT SEC* * 06=SERIAL# MISMATCH 07=SEC SSID MISMATCH 08=ESCON LINK OFFLINE * * 09=ESTABLISH RETRY 0A=PATH ACTIVE TO HOST 0B=PATH TO SAME CLUSTR* * 10=CONFIG ERROR FF=UNABLE TO DETERMINE * * 13=ESTABL FIBRE PTH 14=FIBRE PATH DOWN 15=FIBRE RETRY EXCEED * * 16=SEC ADPTR INCPBL 17=SEC ADPTR UNAVAIL 18=FIBRE LOGIN EXCEED * ********************************************************************

Source WWNN Source SAID Target WWNN Target SAID
Figure 31-6 ICKDSF ANALYZE Fibre Channel connection information
31.3.2 Step 1: Set up all Metro Mirror and Global Mirror paths
Based on the PPRC links which are discovered, the paths have to be created for each LSS pair in the Metro/Global Mirror configuration. Two prerequisites have to be fulfilled to create PPRC paths successfully: The physical connection must be available, either by an appropriate zone in a storage area network or by point-to-point links. The LSSs must exist in both storage devices, and at least one CKD volume must exist in each of the designated LSSs. It is a good practice to create the PPRC paths for both directions. In case of a disaster, all paths in all directions are available and do not have to be created in the critical situation of the disaster. Example 31-3 shows the setup of Metro Mirror paths between the local and intermediate sites using the TSO CESTPATH command.
Example 31-3 Set up PPRC paths between local and intermediate sites //STEP1 //SYSTSPRT //SYSUADS //SYSLBC //SYSTSIN CESTPATH EXEC PGM=IKJEFT01,REGION=256K DD SYSOUT=* DD DSN=SYS1.UADS,DISP=SHR DD DSN=SYS1.BRODCAST,DISP=SHR DD * DEVN(X'3200') PRIM(X'3200' 5005076303FFCE63 SEC(X'4200' 5005076303FFC663 X'02') LINK(X'02330033',X'03010102') CGROUP(YES) CESTPATH DEVN(X'3300') PRIM(X'3300' 5005076303FFCE63 SEC(X'4300' 5005076303FFC663 X'03') LINK(X'02330033',X'03010102') CGROUP(YES) CESTPATH DEVN(X'4200') PRIM(X'4200' 5005076303FFC663 SEC(X'3200' 5005076303FFCE63 X'82') LINK(X'00330233',X'01020301') CGROUP(YES) CESTPATH DEVN(X'4300') PRIM(X'4300' 5005076303FFC663 SEC(X'3300' 5005076303FFCE63 X'83') LINK(X'00330233',X'01020301') CGROUP(YES)

X'82') -

X'83') -

X'02') -

X'03') -
Note: To ensure consistency of the Metro Mirror, the PPRC paths have to be created with the option CGROUP(YES). Between the intermediate site and the remote site, the Global Mirror is responsible for the creation of the Consistency Group. This means that the paths for the Global Copy must not be set up with the CGROUP(YES) option. Example 31-4 on page 521 shows the TSO CESTPATH command to set up Global Mirror paths between intermediate and remote sites.
Example 31-4 Setup PPRC paths between intermediate and remote sites //STEP1 EXEC PGM=IKJEFT01,REGION=256K //SYSTSPRT DD SYSOUT=* //SYSUADS DD DSN=SYS1.UADS,DISP=SHR //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR //SYSTSIN DD * CESTPATH DEVN(X'4200') PRIM(X'4200' 5005076303FFC663 X'02') SEC(X'9200' 5005076304FFC671 X'92') LINK(X'00420242') CESTPATH DEVN(X'4300') PRIM(X'4300' 5005076303FFC663 X'03') SEC(X'9300' 5005076304FFC671 X'93') LINK(X'00420242') CESTPATH DEVN(X'9200') PRIM(X'9200' 5005076304FFC671 X'92') SEC(X'4200' 5005076303FFC663 X'02') LINK(X'02420042') CESTPATH DEVN(X'9300') PRIM(X'9300' 5005076304FFC671 X'93') SEC(X'4300' 5005076303FFC663 X'03') LINK(X'02420042') /*

The SDM writes CG to journal data sets: Having created a group of records that can be safely written together, the SDM then writes this group to the journal data sets at the secondary site. Thus the SDM can harden the updates as quickly as possible in one I/O to a single data set. The SDM writes the updates to the secondary volumes: After the CG has been written to the journal data set, the SDM immediately writes out the individual records to their appropriate secondary volumes. This transfer takes place from the SDMs real storage buffers (the journal data sets are only read during recovery using the XRECOVER command). Updating the secondary volumes could involve several I/Os, because the record updates could be directed to several volumes located behind several LCUs. In this example, the CG comprises five records directed to two volumes attached to two LCUs. The figure illustrates that the five records have been successfully copied to their corresponding secondary volumes 10:19, 10:22, and 10:25 written to the first volume of LCU(A), and 10:09 and 10:12 written to the first volume of LCU(B). Figure 39-6 concludes the example on update sequence consistency by stepping forward in time and describing how the dependent write updates are copied to the secondary site.

10:28 10:29

10:30 10:33

10:27 10:31 10:35

10:31 10:35

10:27 10:28 10:29 10:29

Done! C' LCU
10:19 10:27 10:22 10:31 10:25 10:35

10:09 10:28 10:12 10:29

Figure 39-6 Creation of Consistency Group - CG2
The SDM copies data in real time, so it constantly transfers updated records from perhaps multiple LCUs in a z/OS Global Mirror session. In our example, we simulate moving the clock forward in time and tracing the steps taken by the SDM in the production of its second CG. Notice that LCU(A) and LCU(B) at the primary site now have different times indicating when the SDM reads the updated records. We proceed as before: The SDM reads from LCU(A) at 10:35:
At 10:35, the SDM reads three records from LCU(A) (10:27, 10:31, and 10:35). Notice that the log update (10:27) has now been read. This group of three records has been designated GRP1 in the diagram. The SDM reads from LCU(B) at 10:36: At 10:36, the SDM reads one record from LCU B (10:29). This record can now keep the database update record (10:28) company in SDM real storage (these two records are in GRP2 in the diagram). Remember that the database update record (10:28) was not included in the previous CG and was kept in real storage by the SDM along with other residual records. The SDM detects NULL response from LCU(C): Finally, the SDM completes its cycle of updated records collection by establishing that the third LCU(C), which also connects volumes in this z/OS Global Mirror session, has nothing to report. The NULL response must be sent even if the LCU has no updates, because it indicates that the LCU has not suffered an outage, thus the record groups retrieved to date from other LCUs can be used to build a valid CG. The SDM creates CG: The SDM creates the second CG using the same algorithm as before. We can see that the two dependent writes (the log update at 10:27 and the database update at 10:28) have been captured in this CG. Notice that the record group transferred from LCU(B) produced a maximum time stamp, which also turns out to be the smallest of the three GRP maximums. Notice also that this value (10:29) enabled all records written before or at this time to be included in the CG thus allowing the log update and the database update to accompany each other on the journey to the secondary site when written to the journal data sets. The diagram shows that when the SDM writes the records to the secondary volumes, the relationship between the contents of the log and the database, which is vital for recovery, has been protected. The record residue (10:31 and 10:35 from GRP1, and 10:30 and 10:33 from GRP3) will be processed during the next SDM record group collection cycle.

40.19.4 Automation testing
If you follow our automation recommendations, you have to test the automation code to ensure that it operates correctly, generates complete and useful reports, intercepts error messages, and initiates the required actions.

40.19.5 Walk-through

If you are planning to use z/OS Global Mirror for Disaster Recovery or workload migration, you might not have the facilities to test in a production equivalent environment. In these cases it can be a useful option to do a walk-through of the critical procedures. This can identify problems such as ownership of responsibilities, and access to critical data. If you rely on manual intervention for go or no-go on Disaster Recovery, then the process must be clearly documented at both the primary and recovery sites.

40.19.6 Dress rehearsal

The proof of a disaster recovery test is a full-scale dress rehearsal, preferably one that can be initiated without warning. Because z/OS Global Mirror supports SUSPEND/RESUME processing, you can test recovery at a secondary site without disruption to your production environment. When the test is complete, changes that have been accumulated at the primary site can be propagated to the secondary site, restoring disaster protection. If it is essential to maintain disaster protection during a disaster recovery test; FlashCopy provides an ideal tool to take a quick backup of data at the secondary site. The disaster test can proceed against the FlashCopy of the secondary devices, while z/OS Global Mirror between the primary and secondary devices is resumed. When a disaster recovery plan has been successfully validated by a full-scale test, it is important to make sure that documentation is maintained, and that the test is repeated at regular intervals.
40.19.7 ICKDSF and z/OS Global Mirror volumes
It is not necessary to XDELPAIR z/OS Global Mirror volumes prior to relabeling DASD volumes. This allows for concurrent management and operations, as well as increasing z/OS Global Mirrors readiness as a disaster recovery solution. When ICKDSF is used to initialize a volume, the updates will be captured by z/OS Global Mirror and not written to the secondary DASD. z/OS Global Mirror will update its control blocks so that a subsequent recovery will reflect the new volser of the primary volume. The V<volsername> member of the State dataset is not updated until the next time the volume is suspended and XADDPAIR SUSPENDED. The volser in the z/OS UCB control block is not updated until the next VARY OFFLINE/ONLINE is performed. It is also recommended that an XRC CONFIG be performed to resync GDPS. We no longer have to do an XDELPAIR/XADDPAIR full volume copy, but we do still have some operations to sync up z/OS Global Mirror, z/OS, and GDPS.

Consideration: You cannot use the ESS Copy Services Server Web GUI to manage Copy Services relationships between an ESS 800 and a DS8000. The Volumes tab will only show ESS 800 volumes, not DS8000 volumes. The Paths tab will not shows paths between an ESS 800 and a DS8000. It will only show paths between ESS 800s. If you are using PPRC between a DS8000 and an ESS 800, all management of that PPRC relationship must be done with DS CLI or via the DS GUI.

Storage management

You cannot use the DS8000 DS GUI to perform storage configuration on an ESS 800. Likewise you cannot use the ESS 800 Web Specialist to perform storage configuration on a DS8000. You can only perform Copy Services management tasks on the alternative device. If you are logged onto the DS8000 DS GUI and wish to configure some storage on the ESS 800, you will have to log on to the ESS 800 Web Specialist.
46.2.8 Volume size considerations for PPRC
When using PPRC to copy the contents of a CKD volume from one storage device to another, it is possible for the PPRC target volume to be larger than the PPRC source volume. However, if an attempt is made to reverse the relationship so that the source becomes the target, then this attempt will fail because the source is now larger than the target. For this reason it is always recommended that the source and target volumes be the same size. Prior to creating a PPRC relationship, check the volumes sizes to ensure they are the same on each storage device.
Determining DS6000 and DS8000 CKD volume size
When CKD volumes are created on a DS6000 or DS8000, the size must be specified in cylinders. In Example 46-3, two CKD volumes of 3339 cylinders are created. This means that if we use these volumes in a PPRC relationship, their partner volumes should also be 3339 cylinders.
Example 46-3 CKD volume size in DS CLI dscli> mkckdvol -extpool P2 -cap 3339 -name av_6K_CKD_#h 0600-0601 Date/Time: 8 November 2005 22:58:31 IBM DSCLI Version: 5.1.0.204 DS: IBM.1750-1300247 CMUC00021I mkckdvol: CKD Volume 0600 successfully created. CMUC00021I mkckdvol: CKD Volume 0601 successfully created. dscli> lsckdvol -lcu 06 Date/Time: 9 November 2005 3:58:42 IBM DSCLI Version: 5.1.0.204 DS: IBM.1750-1300247 Name ID accstate datastate configstate deviceMTM voltype orgbvols extpool cap (cyl) ================================================================================================ av_6K_CKD_Online Normal Normal 3390-3 CKD Base Pav_6K_CKD_Online Normal Normal 3390-3 CKD Base P2 3339

48.2.2 PPRC and HyperSwap
Exclusive to GDPS in the PPRC environment is HyperSwap. This function is designed to broaden the near continuous availability attributes of GDPS/PPRC by extending the Parallel Sysplex redundancy to disk subsystems. HyperSwap provides the ability to transparently switch primary Metro Mirror disk subsystems with the secondary disk subsystems for a planned or unplanned reconfiguration. The HyperSwap function can help significantly reduce the time required to switch to the secondary set of disks while keeping the z/OS systems active together with their applications. HyperSwap can be implemented as part of the full GDPS/PPRC offering, or through the GDPS/PPRC HyperSwap Manager offering, which provides HyperSwap functionality without the host system management capabilities of the full GDPS/PPRC offering. GDPS/PPRC V3.2 the HyperSwap function exploits the Metro Mirror Failover/Failback (FO/FB) function. For planned reconfigurations, FO/FB might reduce the overall elapsed time to switch the disk subsystems, thereby reducing the time that applications might be unavailable to users. For unplanned reconfigurations FO/FB allows the secondary disks to be configured in the suspended state after the switch and record any updates made to the data. When the failure condition has been repaired, resynchronizing back to the original primary disks requires only the changed data to be copied, thus eliminating the necessity of performing a full copy of the data. The window during which critical data is left without Metro Mirror protection following an unplanned reconfiguration is thereby minimized.
48.2.3 RCMF/PPRC overview
Remote Copy Management Facility/PPRC (RCMF/PPRC) is the name given to a subset of the GDPS/PPRC offerings. It includes the storage interface management functions only. RCMF/PPRC provides windows and code that execute under NetView and provides an operator interface for easier management of a remote copy configuration in setup, initialization, and any planned outage operational mode. This provides benefits for businesses looking to improve their management of PPRC for normal running circumstances. Notice that RCMF/PPRC does not provide any monitoring capability and is not designed to notify the operator of an error in the remote copy configuration. Thus RCMF does not support the Freeze function for GDPS/PPRC, FlashCopy automation, or the unplanned outage functions available through the other versions of GDPS. RCMF/PPRC is positioned as a remote copy management control tool, designed to make much easier the task for operators to stop and start remote copy sessions. The highlights of RCMF/PPRC include: Central point of control - full screen Global PPRC configuration awareness Functional, tree-structured interface TSO commands not required Initialize and maintain Remote Copy configuration Single key stroke function invocation Initiate functions per pair, subsystem, or all Automatically establish target configuration at system startup Supports adding, moving, removing pairs, subsystems and links RCMF does not manage unplanned outage secondary data consistency Drive Peer-to-Peer/Dynamic Address Switching (P/DAS) User-initiated status and exception reporting Can run as a NetView application - System Automation not required