version 2 release 4 z/os...contents figures xvii tables xxi about this document.....xxv

z/OS: z/OS DFSMS Advanced Copy ServicesDFSMS Advanced Copy Services
IBM
SC23-6847-40
Note
Before using this information and the product it supports, read the information in “Notices” on page 751.
This edition applies to Version 2 Release 4 of z/OS (5650-ZOS) and to all subsequent releases and modifications until otherwise indicated in new editions.
Last updated: 2020-02-24 © Copyright International Business Machines Corporation 1994, 2020. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Part 1. Advanced Copy Services overview.............................................................. 1
Chapter 1. Introducing Advanced Copy Services........................................................................................3 In this topic.............................................................................................................................................3 Overview of the Advanced Copy Services functions............................................................................. 3
Including XRC TSO commands in automated procedures..................................................................47 Using the ANTRQST API to run XRC.................................................................................................... 47 Specifying XRC journal, control, and state data sets.......................................................................... 47
Accessing secondary volumes while XRC is active........................................................................... 173 Ending an XRC session.......................................................................................................................174 Applying XRC operational scenarios..................................................................................................174
Applying CXRC operational scenarios............................................................................................... 211 Example: recovering from a disaster using the XRECOVER command.......................................212 Example: applying software maintenance in a coupled environment........................................ 213
Chapter 9. Extended remote copy data recovery operations................................................................ 215 In this topic........................................................................................................................................ 215 Understanding the XRC volume synchronization process................................................................ 215
Comparing the ERRORLEVEL options.......................................................................................... 227 ERRORLEVEL(VOLUME)................................................................................................................228 ERRORLEVEL(SESSION)...............................................................................................................228 ERRORLEVEL(group_name)......................................................................................................... 229
Part 3. Peer-to-Peer Remote Copy......................................................................233
Managing volumes and paths............................................................................................................ 300 Adding a PPRC volume pair.......................................................................................................... 300 Querying PPRC volumes............................................................................................................... 301 Querying PPRC linkage................................................................................................................. 312 Querying PPRC paths....................................................................................................................313 Suspending PPRC volume pair operations...................................................................................318 Deleting a PPRC volume pair........................................................................................................318 Deleting PPRC paths.....................................................................................................................319
Failover/Failback in a PPRC environment..........................................................................................327 Failover process for synchronous PPRC in a planned outage..................................................... 327 Failback process for synchronous PPRC in a planned outage.................................................... 328 Failover/Failback for synchronous PPRC an unplanned outage..................................................329 Failover process for PPRC-XD in a planned outage.....................................................................329 Failback process for PPRC-XD in a planned outage.................................................................... 330 Failover/Failback process for PPRC-XD in an unplanned outage................................................331
Chapter 16. Peer-to-Peer Remote Copy data recovery operations....................................................... 333 In this topic........................................................................................................................................ 333 Examining disaster recovery from a system viewpoint.................................................................... 333 Resuming operations at the recovery site.........................................................................................334 PPRC failover/failback........................................................................................................................335 Managing errors during recovery.......................................................................................................336
Chapter 17. Moving and migrating data with Peer-to-Peer Remote Copy.............................................337 In this topic........................................................................................................................................ 337 Moving the work load with PPRC....................................................................................................... 337 Migrating data with PPRC...................................................................................................................338 Copying the secondary volumes with PPRC......................................................................................338 Migrating data on a secondary with Multi-Target Mirror...................................................................339 Migrating data on a primary with Multi-Target Mirror.......................................................................341
Chapter 24. Managing Global Mirror ...................................................................................................... 401 In this topic........................................................................................................................................ 401 How Global Mirror consistency groups are formed.......................................................................... 401
Restrictions...................................................................................................................................403 Changing the Global Mirror session performance parameters.........................................................403 Changing the Global Mirror session topology....................................................................................403 Adding volumes to the Global Mirror session................................................................................... 404 Terminating a Global Mirror session..................................................................................................404 Failover/failback for a Global Mirror session.....................................................................................404
Diagnosing Global Mirror session problems......................................................................................411
Incremental Resync for Metro/Global Mirror cascade......................................................................422 Introducing Incremental Resync for Metro/Global Mirror.......................................................... 422 Setting up incremental resync for Metro/Global Mirror.............................................................. 423 Recovery scenarios for Metro/Global Mirror with incremental resync....................................... 424
cache........................................................................................................................................497 CCSTOR - list the concurrent copy session status...................................................................... 498 LISTWS - report the WSDS status................................................................................................ 498
Appendix A. Advanced Copy Services diagnostic aids......................................... 501 Maintaining the system data mover........................................................................................................501 Restarting system data mover address spaces (SDM, XRC, CC, SnapShot).......................................... 501 Diagnosing system data mover functions with the MVS MODIFY command........................................ 501
CREFRESH operation (XRC)............................................................................................................... 502 DELBMAP operation (XRC).................................................................................................................503 DUMP operation (XRC, CC).................................................................................................................503 DVCDATA operation (XRC, CC).......................................................................................................... 503 IGNORE_INTERRUPTS operation (XRC)........................................................................................... 504 LISTDVCS operation (XRC)................................................................................................................ 504 LISTSESS Operation ..........................................................................................................................505 PATHS operation ............................................................................................................................... 507 REDISCOVER operation (XRC)...........................................................................................................508 RESTART operation (XRC)..................................................................................................................508 SCDATA operation (XRC, CC)............................................................................................................. 508 SCTRAP operation (XRC)....................................................................................................................509 SCTRAP2 operation (XRC)................................................................................................................. 510 STATESAVE operation (XRC)............................................................................................................. 510 SUSSESS operation (XRC)..................................................................................................................511 TERMDVC operation (XRC).................................................................................................................512 TERMSESS operation (XRC, CC).........................................................................................................513 XENDDUMP operation (XRC)............................................................................................................. 514 XRCTRAP/SUPRDUMP operation (XRC).............................................................................................515 Peer-to-peer remote copy diagnostic aids........................................................................................515
Concurrent copy SMF type 42 subtype 4 records.............................................................................519
Appendix C. ANTRQST and ANTRQSTL macros – call to the system data mover API................................................................................................................523 SDM API usability guide.......................................................................................................................... 525
Programming requirements...............................................................................................................525 SDM API usage................................................................................................................................... 526 SDM API macros.................................................................................................................................526 SDM API invocation............................................................................................................................527 Programming considerations.............................................................................................................529 Programming examples..................................................................................................................... 532
2. Disaster recovery scenario with remote copy............................................................................................ 12
6. CXRC configuration with system data mover at recovery site.................................................................188
7. CXRC configuration with system data mover at primary site.................................................................. 190
8. CXRC configuration with system data mover at primary site on remote host........................................ 191
9. Master data set......................................................................................................................................... 192
11. PPRC ESCON path options......................................................................................................................238
18. Internal Incremental Pairs in a Multi-Target Configuration.................................................................. 248
20. Metro/Global Copy (Cascaded Volumes)............................................................................................... 262
23. Establishing a PPRC path through an ESCD........................................................................................... 299
34. A typical PPRC configuration before a P/DAS operation........................................................................356
35. P/DAS swap operation complete............................................................................................................359
37. Setting Up Global Mirror for ESS............................................................................................................ 376
38. Forming Consistency Groups According to Specified Intervals............................................................ 402
39. Moving a Global Mirror Session to Recovery Site in a Planned Outage.................................................405
40. Returning Global Mirror to Primary Site in an Planned Outage............................................................. 407
41. Moving Global Mirror Session to Recovery Site in an Unplanned Outage.............................................408
42. Returning Global Mirror to Primary Site in an Unplanned Outage.........................................................410
43. Metro/Global Mirror volume configuration.............................................................................................414
44. A full-volume copy, only one FlashCopy relationship active on a volume............................................ 431
45. Multiple FlashCopy relationships active on a volume............................................................................432
46. How the NOCOPY relationship works.................................................................................................... 434
47. Inband FlashCopy Requests Are Transmitted from PPRC Primary to PPRC Secondary...................... 441
48. Example of Initial FlashCopy Results.....................................................................................................442
xviii
57. FlashCopy Target as PPRC primary with preserve mirroring.................................................................447
58. Remote Pair FlashCopy for XRC............................................................................................................. 448
59. The state of a target volume after a FCWITHDR command processes.................................................450
60. How the ESS processes the FCWITHDR with DDSW(YES) command .................................................. 452
61. FCESTABL Example 1............................................................................................................................. 467
68. FCQUERY Example 3: Query for a Remote Open Device....................................................................... 471
69. FCQUERY Example 4: Query for a Remote CKD Device.........................................................................471
70. FCWITHDR Command Example 1.......................................................................................................... 476
xx
Tables
2. Allowable combinations of copy operations on the same device................................................................7
3. Comparison of Remote Copy Functions..................................................................................................... 13
5. Address space descriptions........................................................................................................................25
10. System data mover locations in basic XRC configurations ..................................................................... 33
11. Considerations for determining XRC resource needs ............................................................................. 34
12. Steps for disk volume determination ...................................................................................................... 35
13. Data Set Allocation Command Examples.................................................................................................44
14. XRC FACILITY class profile names........................................................................................................... 46
16. Instructions for changing journal, control, and state data sets...............................................................48
17. Sample Journal Data Set Patterns for Two Stripes..................................................................................51
18. Sample Journal Data Set Patterns for Eight Stripes................................................................................ 51
19. Decision process for utility volume specification.....................................................................................55
20. Quick reference for XRC session limits.................................................................................................... 57
22. ANTXIN00 parmlib parameters..............................................................................................................114
xxi
24. DVCBLOCK and DONOTBLOCK Values and Workload-Based Write Pacing..........................................147
25. Specifying UTILITY(FIX) and the XADDPAIR command with a secondary volume serial number specified as XRCUTL ............................................................................................................................... 151
26. Specifying UTILITY(FLOAT) and the XADDPAIR command with a secondary volser of XRCUTL.........152
27. Specifying UTILITY(FIX or FLOAT) and the XADDPAIR command with a secondary volser that is not XRCUTL.............................................................................................................................................. 152
28. PRIORITY specification with the XADDPAIR command........................................................................ 154
31. Coupled session descriptions.................................................................................................................186
34. Clearing coupled HOLD status................................................................................................................206
35. Using the XADVANCE command.............................................................................................................222
36. XRC system failure volume pair suspensions, determined by ERRORLEVEL options.......................... 228
37. PPRC resource considerations............................................................................................................... 250
40. Quick reference for PPRC session limits................................................................................................ 261
47. General failure recovery procedures for PPRC...................................................................................... 348
xxii
50. Comparing P/DAS and dual copy............................................................................................................354
51. Reply options for IGF52xA messages....................................................................................................362
52. System actions for switch pair, and swap..............................................................................................363
53. Example of a P/DAS swap function in a sysplex environment.............................................................. 366
54. Global Mirror FACILITY class profile names.......................................................................................... 373
65. How the ANTRQST macro relates to major functions............................................................................523
66. Functions supported by ANTTREXX....................................................................................................... 685
68. Results of Calling ANTTREXX................................................................................................................. 688
About this document
The purpose of this publication is to help you understand and use IBM® Advanced Copy Services functions. It describes three "dynamic" copy functions and several "point-in-time" copy functions. These functions provide backup and recovery of data should a disaster occur to your data center. The dynamic functions are peer-to-peer remote copy, extended remote copy, and coupled extended remote copy, and are known collectively as remote copy. FlashCopy®, SnapShot, and Concurrent Copy are the point-in-time copy functions.
For information about the accessibility features of z/OS®, for users who have a physical disability, see Appendix E, “Accessibility,” on page 747.
Required product knowledge To use this document effectively, you should be familiar with the following information:
• Programming, especially programming with TSO commands • Current disaster recovery and workload migration procedures at your location
The person using this information must understand the effects of changing system parameters. For some cases, such as adjustments to the PARMLIB parameters, it is recommended that you contact an IBM representative before you make any adjustments.
© Copyright IBM Corp. 1994, 2020 xxv
xxvi z/OS: z/OS DFSMS Advanced Copy Services
How to send your comments to IBM
We invite you to submit comments about the z/OS product documentation. Your valuable feedback helps to ensure accurate and high-quality information.
Important: If your comment regards a technical question or problem, see instead “If you have a technical problem” on page xxvii.
Submit your feedback by using the appropriate method for your type of comment or question: Feedback on z/OS function
If your comment or question is about z/OS itself, submit a request through the IBM RFE Community (www.ibm.com/developerworks/rfe/).
Feedback on IBM Knowledge Center function If your comment or question is about the IBM Knowledge Center functionality, for example search capabilities or how to arrange the browser view, send a detailed email to IBM Knowledge Center Support at [email protected].
Feedback on the z/OS product documentation and content If your comment is about the information that is provided in the z/OS product documentation library, send a detailed email to [email protected]. We welcome any feedback that you have, including comments on the clarity, accuracy, or completeness of the information.
To help us better process your submission, include the following information:
• Your name, company/university/institution name, and email address • The following deliverable title and order number: z/OS DFSMS Advanced Copy Services,
SC23-6847-40 • The section title of the specific information to which your comment relates • The text of your comment.
When you send comments to IBM, you grant IBM a nonexclusive authority to use or distribute the comments in any way appropriate without incurring any obligation to you.
IBM or any other organizations use the personal information that you supply to contact you only about the issues that you submit.
If you have a technical problem If you have a technical problem or question, do not use the feedback methods that are provided for sending documentation comments. Instead, take one or more of the following actions:
• Go to the IBM Support Portal (support.ibm.com). • Contact your IBM service representative. • Call IBM technical support.
© Copyright IBM Corp. 1994, 2020 xxvii
Summary of changes
This information includes terminology, maintenance, and editorial changes. Technical changes or additions to the text and illustrations for the current edition are indicated by a vertical line to the left of the change.
Summary of changes for z/OS Version 2 Release 4 (V2R4)
New
The following content is new.
• The 136 (X'88') reason code was added to the table in “Preserve Mirror reason codes for volume capability” on page 676 and “Preserve Mirror reason codes for volume extent capability” on page 679. It was missing in previous versions of the documentation.
• APAR OA56518 provides a new query that returns safeguarded copy query information, which is mapped by DSECT ANTSGMAP. These sections were also updated:
– “Syntax for ILK=ESSRVCS” on page 537 – “Subparameters for REQUEST=SGCQUERY” on page 601 – Appendix D, “REXX support for the ANTRQST API,” on page 685 – “SGCQUERY (Safeguarded Copy Query)” on page 732
• With APAR OA57172, new volume capability and preserve mirror incapable reason codes were added. For more information, see “Volume capability and reason codes” on page 674 and “Preserve Mirror reason codes for volume capability” on page 676.
Changed
• Usage information was added to TracksPerRead and TracksPerWrite. For more information, see “ANTXIN00 parmlib parameters” on page 114.
Deleted
The following content was deleted.
• The 136-159 (X'80-9F') and 160-191 (X'A0-BF') reason codes were removed from the table in “Preserve Mirror reason codes for volume capability” on page 676 and “Preserve Mirror reason codes for volume extent capability” on page 679 because they were incorrect.
• With APAR OA58275, all references to PREF and PREFERRED were removed.
Summary of changes for z/OS Version 2 Release 3 (V2R3) The following changes are made for z/OS Version 2 Release 3 (V2R3). The most recent updates are listed at the top of each section.
New
Remote pair FlashCopy, which allows a FlashCopy relationship to be mirrored across a remote mirror, is now available for XRC. For more information, see “Remote Pair FlashCopy for XRC” on page 448. To provide that support:
© Copyright IBM Corp. 1994, 2020 xxix
• RemotePairFlashCopy, TraceTableBufferSize, and XstartQuery parameters are added to parmlib member ANTXIN00. For more information, see “ANTXIN00 parmlib parameters” on page 114,
• The XRECOVER command is enhanced. See “XRECOVER–Recovering data on the recovery system” on page 88.
• The default for the SuspendOnLongBusy is changed to YES. For more information, see “ANTXIN00 parmlib parameters” on page 114.
• A TGTXRCPRI keyword is added to ANTRQST REQUEST=FCESTABLISH. It specifies the handling of the request based on whether or not the specified target is an XRC primary device. For more information, see “Syntax for ILK=ESSRVCS” on page 537 and “Subparameters for REQUEST=FCESTABLISH” on page 571.
• New information for Remote Pair FlashCopy is shown in the XQUERY report and the XQUERY ENVIRONMENT(PARM) report. See “XQUERY storage control XFEATURES report” on page 169 and “XQUERY ENVIRONMENT(PARM) report” on page 140.
A new topic, “Channel extender considerations” on page 165, was added.
Cascading FlashCopy allows a track, set of tracks, or volume to be both a source and target of a FlashCopy relationship. In addition, Cascaded FlashCopy provides the ability to restore using Fast Reverse Restore to the original FlashCopy source from a FlashCopy target without having to withdraw other FlashCopy target relationships that the FlashCopy source may have. For more information, see “Cascading FlashCopy” on page 443.
Support for extent space efficient volumes has been added. See “Volume types” on page 8. In addition, changes have been made where necessary to differentiate track space efficient volumes from extent space efficient volumes.
A new REFRESHS keyword has been added for use with the ANTRQST macro and with ANTREXX. For more information, see “Subparameters for REQUEST=XSET” on page 661 and “XSET (XRC session parameters)” on page 741.
Changed
The default trace table size is increased to 120 MB for each ANTAS00x address space. If XRC trace options are on and require more storage then 120 MB, up to 3 times (360 MB) of auxiliary storage can be allocated. These topics were updated:
• “Paging space requirements” on page 31. The data space requirements for ANTCLnnn and ANTASnnn were increased.
• “ANTXIN00 parmlib parameters” on page 114. Parameter TraceTableBufferSize now has a range of 5-255, and the recommendation is to use a value of 120 or higher.
XRC support is enhanced to allow use of the multiple subchannel set configuration to specify the volumes in an XRC session. The enhancements include accepting 5-digit device numbers, and allowing primary volumes, secondary volumes, and swap volumes in alternate channel subsets.
For the XRC multiple subchannel set support, these topics were updated:
• “XRC operational considerations” on page 22 • “Choosing an XRC configuration” on page 32 • “XADDPAIR–Adding volume pairs or utility volumes” on page 63 and “Subparameters for
REQUEST=XADD” on page 641 • “XQUERY configuration report” on page 170 • “XQUERY SWAP report” on page 170 • “LISTDVCS operation (XRC)” on page 504 • “LISTSESS Operation ” on page 505 • “PATHS operation ” on page 507 • “SCDATA operation (XRC, CC)” on page 508
xxx z/OS: z/OS DFSMS Advanced Copy Services
• “SUSSESS operation (XRC)” on page 511 • “TERMDVC operation (XRC)” on page 512 • “TERMSESS operation (XRC, CC)” on page 513
XRC device-based management supports XRC primary and utility volumes that are offline and may never have been online to the data mover system. Updates include the following:
• Changes to “Controlling ICKDSF activity to XRC volumes” on page 45. • TSO commands for XRC and the associated ANTRQST and REXX interfaces now support adding devices
by device number rather than volume serial. See the addition of the PDEVNUM keyword, and SDEVNUM keyword for add requests, in:
– TSO commands “XADDPAIR–Adding volume pairs or utility volumes” on page 63, “XDELPAIR– Deleting volume pairs” on page 73, “XSET–Changing session parameters” on page 91, and “XSUSPEND command syntax” on page 102
– ANTRQST interfaces “Subparameters for REQUEST=XADD” on page 641, “Subparameters for REQUEST=XDEL” on page 649, “Subparameters for REQUEST=XSET” on page 661, and “Subparameters for REQUEST=XSUSPEND” on page 669
– ANTTREXX interfaces “XADD (XRC add volume pair)” on page 733, “XDEL (XRC delete volume pair)” on page 736, “XSET (XRC session parameters)” on page 741, and “XSUSPEND (XRC suspend)” on page 745.
• See also the addition of the DEVNUM keyword to these commands:
– “XQUERY–Querying a session” on page 80 – “Subparameters for REQUEST=XQUERY” on page 653 – “XQUERY (XRC query)” on page 738, which supports looking for multiple volumes with the same
volume serial. • A new MessageVolumeFormat parameter of parmlib member ANTXIN00 controls whether messages
that include volume information show the volume serial, the device number, or both. See “ANTXIN00 parmlib parameters” on page 114.
• For ANTTREXX, new examples have been added to “ANTIMAIM” on page 694, “Starting an XRC session” on page 694, and “PESTPAIR” on page 695.
The following topics have been updated in support of Cascading FlashCopy:
• Table 2 on page 7 • “Volume capability and reason codes” on page 674 • “Preserve Mirror reason codes for volume capability” on page 676
The following section is updated for APAR OA53670: “STATESAVE operation (XRC)” on page 510. A new option, F, is added.
“Recommended specifications” on page 50 in “Specifying the journal data sets” on page 49 has been updated.
Sample JCL for allocating a control data set has changed. See “Specifying the control data set” on page 51.
The upper limit for BuffersPerStorageControl, PermanentFixedPages, and TotalBuffers has increased to 999999. For more information, see “ANTXIN00 parmlib parameters” on page 114.
The upper limit for TracksPerRead and TracksPerWrite has increased to 64. For more information, see “ANTXIN00 parmlib parameters” on page 114.
A SUPMSG keyword has been added to ANTRQST REQUEST=XQUERY. It can be used to suppress the ANTU2515I message from being issued. For more information, see “Subparameters for REQUEST=XQUERY” on page 653.
Summary of changes xxxi
New reason codes have been added to the ANTQFRVL macro. See “Volume capability and reason codes” on page 674, “XRC Remote Pair FlashCopy reason codes” on page 681 and “Preserve Mirror reason codes for volume capability” on page 676.
With a few exceptions, mentions of "space efficient volumes" have been changed to "track space efficient volumes."
The description of the SPACEREL keyword on the FCWITHDRAW request of the ANTRQST macro is updated to reflect support for extent space-efficient volumes. See “Subparameters for REQUEST=FCWITHDRAW” on page 582
A new PPRC suspend state has been added to the CQUERY report. See “Fields in formatted output” on page 302.
ANTRQST REQUEST=LEVEL now uses a bit string to indicate that a function is installed. See Appendix C, “ANTRQST and ANTRQSTL macros – call to the system data mover API,” on page 523
Summary of changes for z/OS Version 2 Release 2 (V2R2) The following changes are made for z/OS Version 2 Release 2 (V2R2).
Changed
The XRECOVER command now accepts CHECK and FORCE parameters, to control XRECOVER enhanced checking. For more information, refer to “XRECOVER–Recovering data on the recovery system” on page 88.
The XRECOVER request of the ANTRQST macro and ANTTREXX program now accept CHECK and FORCE. For more information, refer to “Subparameters for REQUEST=XRECOVER” on page 656 and “XRECOVER (XRC recover)” on page 739.
The PQUERY request of the ANTRQST macro and ANTTREXX program now accept QUIESCEDIO. For more information, refer to “Subparameters for REQUEST=PQUERY” on page 621 and “PQUERY (PPRC query)” on page 718.
The GMPStatus field of GMPSTAT can have a new value. For more information, refer to Table 57 on page 396.
xxxii z/OS: z/OS DFSMS Advanced Copy Services
Part 1. Advanced Copy Services overview This topic provides overviews to help you understand Advanced Copy Services.
© Copyright IBM Corp. 1994, 2020 1
2 z/OS: z/OS DFSMS Advanced Copy Services
Chapter 1. Introducing Advanced Copy Services
As businesses become more dependent on information technology to conduct their operations, the requirements for protecting their data, backing it up, and making it available, 24 hours a day and seven days a week are forever increasing. In the event of disaster or system failures, without a plan for recovery, loss of data can lead to significant financial cost or maybe total failure for businesses.
IBM Advanced Copy Services provides a combined hardware and software solution to help address these issues. Advanced Copy Services is a collection of functions that provides solutions to the complex challenges of disaster recovery, data migration, data duplication, and business continuance. Many of these functions run on IBM TotalStorage™ Enterprise Storage Server® (ESS). The ESS, designed for mid- range and high-end environments, gives you a high performance, continuous availability, high capacity storage subsystem that can be configured according to your requirements.
This chapter provides overviews to help you understand the functions of Advanced Copy Services.
In this topic This topic introduces you to the functions of Advanced Copy Services. It includes the following sections:
Section . . .
“Overview of the Advanced Copy Services functions” on page 3
“Using the ESS Copy services Web interface” on page 6
“Combining copy services operations” on page 7
Overview of the Advanced Copy Services functions Advanced Copy Services comprises the following functions and enhancements. Mirror functions provide a consistent point-in-time copy of data at the recovery site, while the data at the recovery site for Copy functions is not necessarily consistent.
• Metro Mirror, also known as (synchronous) Peer-to-Peer Remote Copy (PPRC) • Global Mirror, also known as (asynchronous) Peer-to-Peer Remote Copy • Global Copy, also known as PPRC-Extended Distance (PPRC-XD) • Metro/Global Copy • IBM® TotalStorage® z/OS Global Mirror, also known as z/OS Global Mirror (zGM) and Extended Remote
Copy (XRC), which includes Coupled Extended Remote Copy (CXRC) • Metro/Global Mirror, also known as synchronous PPRC combined with Global Mirror • Multi-Target Mirror (MTPPRC) • FlashCopy • Failover/Failback • SnapShot • Concurrent Copy (CC)
Table 1 on page 4 shows how each of the Advanced Copy Services copy functions falls into one of two groups. Dynamic copy functions constantly update the secondary copy as applications make changes to the primary data source. Point-in-time copy functions provide an instantaneous copy, or view, of what the original data looked like at a specific point in time.
Table 1. Dynamic copy and point-in-time copy functions
Type of copy Copy function names
Dynamic copy of data XRC, CXRC, PPRC, Global Mirror
Point-in-time copy of data FlashCopy, SnapShot, and Concurrent Copy
Note: Advanced Copy Services largely relies on a data movement engine, the system data mover (SDM), to efficiently and reliably move large amounts of data between storage devices. For more information, see “System data mover” on page 24.
Extended remote copy (XRC) Remote copy offers two options for your disaster recovery and workload migration needs: extended remote copy (XRC) and peer-to-peer remote copy (PPRC). XRC addresses the problem of unrecoverable data that occurs between the last, safe backup of a primary system to a recovery system and the time when the primary system fails.
XRC provides an asynchronous copy operation, over distance, with minimal performance impact to primary system DASD I/O write operations.
XRC supports only IBM Z-attached (count key data, or CKD) devices. This includes data running on z/OS, z/VM® and Linux.
XRC functions can be dispatched on a zIIP processor if one is available. To enable XRC for operating on a zIIP processor, use the zIIPEnable parameter in the ANTXIN00 PARMLIB member, as shown in Table 22 on page 114. For more general information about zIIP processing, refer to the section about Using System z Integrated Information Processor (zIIP) in z/OS MVS Planning: Workload Management. See also z/OS RMF Report Analysis for information on how to monitor zIIP processing.
For additional information about:
• XRC, refer to Chapter 2, “What is remote copy? ,” on page 9. • Planning for XRC, refer to Chapter 3, “Planning for extended remote copy,” on page 21. • Setting up your XRC environment, refer to Chapter 4, “Setting up the extended remote copy
environment,” on page 43. • Issuing XRC commands, refer to Chapter 5, “Extended remote copy command descriptions,” on page
61. • Managing your XRC environment, refer to Chapter 7, “Managing extended remote copy operations,” on
page 143. • Managing Coupled XRC sessions, refer to Chapter 8, “Managing coupled extended remote copy
sessions,” on page 185. • Recovering your data with XRC, refer to Chapter 9, “Extended remote copy data recovery operations,”
on page 215. • Migrating data with XRC, refer to Chapter 10, “Migrating data with extended remote copy,” on page 223. • Recovering from error conditions using XRC, refer to Chapter 11, “Recovering from error conditions
using extended remote copy,” on page 227.
Peer-to-Peer Remote Copy (PPRC) Like XRC, Peer-to-Peer Remote Copy (PPRC) addresses the problem of unrecoverable data that occurs between the last, safe backup of a primary system to a recovery system and the time when the primary system fails.
PPRC offers several options supporting copy functions both synchronous and asynchronous with the primary volume’s I/O operation.
PPRC supports both IBM Z-attached (CKD) devices and Open System (fixed block, FB) devices.
• PPRC, refer to “Overview of remote copy ” on page 9. • Planning for PPRC, refer to Chapter 12, “Planning for Peer-to-Peer Remote Copy,” on page 235. • Setting up your PPRC environment, refer to Chapter 13, “Setting up the Peer-to-Peer Remote copy
environment,” on page 255. • Issuing PPRC commands, refer to Chapter 14, “Peer-to-Peer Remote copy command descriptions,” on
page 265. • Managing your PPRC environment, refer to Chapter 15, “Managing Peer-to-Peer Remote Copy
operations,” on page 293. • Recovering your data with PPRC, refer to Chapter 16, “Peer-to-Peer Remote Copy data recovery
operations,” on page 333.
FlashCopy The FlashCopy function provides a point-in-time copy of data for backup and recovery operations. FlashCopy creates a Time 0 (T0) copy of a volume or set of tracks. The T0 copy is current with the volume or set of tracks at the time that the action is initiated. Subsequent updates to the original volume or set of tracks are not reflected in the T0 copy.
In contrast to FlashCopy Version 1, FlashCopy Version 2 allows you to copy individual tracks and create multiple relationships. The target tracks for a FlashCopy V2 request can be on the same volume as the source, or any other volume within the same ESS subsystem. Also, multiple source copies can be made to different target locations. Restrictions on source and target volumes being in the same logical subsystem have been lifted. Target tracks do not need to be on a different volume and have the same track addresses as the source tracks. This allows you to copy only critical data instead of an entire volume, and it allows the copies from multiple source volumes to share the same target volume.
FlashCopy supports both IBM Z-attached (CKD) devices and Open System (FB) devices.
For additional information about FlashCopy, refer to Chapter 26, “What is FlashCopy?,” on page 429.
Global Mirror A Global Mirror environment also addresses the issue of unrecoverable data lost between backups. Global Mirror gives you the ability to establish PPRC-XD pairs over a long distance and maintain consistent FlashCopy versions at the disaster recovery site without suffering any significant performance degradation or requiring applications to be quiesced.
For additional information about Global Mirror, refer to Chapter 20, “Planning for Global Mirror,” on page 371.
Metro/Global Copy The Metro/Global Copy function allows you to cascade a PPRC pair with a PPRC-XD pair such that the PPRC secondary also serves as the PPRC-XD primary. In this configuration, a primary and secondary pair is established with the secondary located in a nearby site, protected from primary site disasters. The secondary volume for the PPRC-XD copy could be located thousands of miles away and would continue to be updated if the original primary location suffered a disaster.
For additional information about Metro/Global Copy, refer to “Metro/Global Copy” on page 242.
Metro/Global Mirror The Metro/Global Mirror function enables a three-site, high availability disaster recovery solution. It combines the capabilities of both Metro Mirror and Global Mirror functions for greater protection against planned and unplanned outages.
For additional information about Metro/Global Mirror, refer to Chapter 25, “Metro/Global Mirror,” on page 413.
Chapter 1. Introducing Advanced Copy Services 5
Multi-Target Mirror A Multi-Target Mirror environment allows a device to be the primary of more than one PPRC pair. It simplifies recovery scenarios for cascaded configurations, when swapping from the local site to the intermediate site. With Multi-Target support, during a failover to the intermediate site, the intermediate device can become a primary to both the local and the remote, eliminating the need to suspend the intermediate to remote site pair when swapping back to the local site. It provides for the capability of an incremental resynchronization between the two secondary volumes in both planned and unplanned swap scenarios.
Failover/Failback Metro Mirror and Global Mirror for ESS support the capability to initiate failover to the secondary site in the case of a disaster or planned outage at the primary site. Once the primary site is recovered, you can initiate failback to the primary site from the secondary site, restoring your original primary-secondary volume relationships. See “PPRC failover/failback” on page 335 for details.
Although failover/failback is supported by the ESS, it is intended for use with Global Copy only in a planned outage scenario.
SnapShot SnapShot is a function of RAMAC Virtual Array (RVA) storage subsystems that allows you to make a very quick copy of a set of tracks (an entire volume, a data set, or just a random set of tracks). The copy operation is completed with only a few I/Os to the device.
SnapShot supports only IBM Z-attached (CKD) devices.
• SnapShot, refer to Chapter 27, “What is SnapShot copy?,” on page 481. • SnapShot requirements, refer to “SnapShot copy requirements” on page 481. • Using Snapshot, PPRC, and RVA together, refer to “Using SnapShot copy, PPRC, and RVA together” on
page 484.
Concurrent copy Concurrent copy is an extended function that enables data center operations staff to generate a copy or a dump of data while applications are updating that data. Concurrent copy delivers a copy of the data, in a consistent form, as it existed before the updates took place.
Concurrent copy supports only IBM Z-attached (CKD) devices.
For additional information about concurrent copy, refer to Chapter 28, “What is concurrent copy?,” on page 489.
Using the ESS Copy services Web interface IBM includes a Web-browser interface called TotalStorage Enterprise Storage Server (ESS) Copy Services. The interface is part of the ESS subsystem and can be used to perform FlashCopy and PPRC functions.
The default support for the Web Copy Services is for open-systems environments. If you plan to use Copy Services functions using the TotalStorage ESS Copy Services interface, ensure that your IBM service representative enables the proper support to use System/390® volumes. The IBM TotalStorage Enterprise Storage Server Introduction and Planning Guide contains a worksheet for ESS Copy Services that helps the service representative determine which option to enable.
For additional information about using the Web-browser interface, refer to the IBM TotalStorage Enterprise Storage Server Introduction and Planning Guide.
Combining copy services operations Copy services include Concurrent Copy, SnapShot, FlashCopy, XRC, and PPRC. Various hardware platforms support different combinations of these capabilities as shown in Table 2 on page 7. In the table, FlashCopy refers to either FlashCopy V1 or FlashCopy V2, FlashCopy V1 refers to volume FlashCopy, and FlashCopy V2 refers to data set FlashCopy as documented in Chapter 26, “What is FlashCopy?,” on page 429.
Table 2 on page 7 represents:
• Copy services capabilities supported by TSO commands described in this document, and not the support for the copy services API macro ANTRQST, the program ANTTREXX and the IBM TotalStorage ESS Web-browser interface. .
• What copy services combinations are allowed on the same device. In some cases, the indication of NO for a combination might be allowed. However, this combination is not recommended by IBM because undesirable results might occur. Some of these undesirable results include suspension of XRC volumes and or sessions, and the unexpected withdrawal of tracks from FlashCopy relationships.
To determine whether a combination works, select one volume type from the top row and one from the leftmost column. The top row represents the copy service function in which a device is currently active, and the leftmost column represents the copy service function in which a device may become active.
Table 2. Allowable combinations of copy operations on the same device
If device is → can it also become ↓?
XRC source
XRC target
PPRC source
PPRC target
FlashCopy source
FlashCopy target
SnapShot copy source
SnapShot copy target
XRC source No Yes Yes No Yes Yes Yes No No
XRC target Yes No (2) Yes No Yes No Yes Yes No
PPRC source Yes Yes Yes(4) Yes Yes Yes(3) Yes Yes No
PPRC target No No Yes No Yes Yes(5) No Yes No
FlashCopy source Yes Yes Yes Yes Yes(1) Yes(4) Yes No No
FlashCopy target No No Yes(3) No No No Yes(4) No No
Concurrent copy source (2) Yes Yes Yes No Yes Yes Yes No No
SnapShot copy source No Yes Yes Yes No No No No Yes
SnapShot copy target No No No No No No No Yes No
Note:
1. With FlashCopy V2, a volume can contain both source and target tracks. However, a track or extent cannot be:
• Both a source and a target • The target from more than one source.
2. Host software disallows this combination within a logical XRC session. There is no protection across logical XRC sessions. Unpredictable results will occur, as data is written to the same track from two different source volumes.
3. This is allowed unless:
• The PPRC primary / FlashCopy target is Global Mirror. (FlashCopy to a Global Mirror primary is not supported.)
Chapter 1. Introducing Advanced Copy Services 7
• The PPRC primary / FlashCopy target is in a cascaded PPRC environment (regardless of whether the device is Metro Mirror, Global Copy, or Global Mirror). If FlashCopy to PPRC primary is specified without Preserve Mirror Required, the command is allowed by changing the first leg of the cascade to a duplex pending state while the copy is in progress, potentially disrupting high availability.
4. With appropriate microcode levels. 5. Occurs only with remote pair FlashCopy / Preserve Mirror, and is done by the microcode. It cannot be
done by software. 6. An XRC target that is also used as a FlashCopy target will produce unpredictable results. However this
configuration is not prevented.
• Using the Web-browser interface, refer to IBM TotalStorage Enterprise Storage Server Introduction and Planning Guide.
• The ANTRQST macro, refer to Appendix C, “ANTRQST and ANTRQSTL macros – call to the system data mover API,” on page 523.
• The ANTTREXX program, refer to Appendix D, “REXX support for the ANTRQST API,” on page 685.
Volume types The types of volumes include standard volumes as well as two types of space efficient volumes. The types of space efficient volumes differ in how they can be used.
• Standard volumes have all physical storage allocated to them at the time that the volume is defined. Standard volumes are also known as fully provisioned volumes.
• Track space efficient volumes have no physical space allocated to them until the first write is done to the volume. The physical space is allocated to the volume in tracks from the space efficient repository, which is a separate volume, defined in each extent pool, used only for track space efficient volume physical space, and not accessible directly from any host. Track space efficient volumes will be phased out with the introduction of extent space efficient volumes. Track space efficient volumes:
– Are limited to being FlashCopy targets – Their FlashCopy relationships are limited to NOCOPY.
• Extent space efficient volumes, also commonly called thin provisioned volumes, have no physical space allocated to them until the first write is done to the volume. Physical space is allocated on demand to the volume in extents, 21 cylinders at a time, directly from the extent pool where the volume is defined, rather than on a track by track basis from a space efficient repository. This improves the performance of space efficient volumes. Extent space efficient volumes:
– Are not limited to being FlashCopy targets – Their FlashCopy relationships are not limited to NOCOPY.
No special keywords are required to create FlashCopy or PPRC relationships with extent space efficient volumes.
Chapter 2. What is remote copy?
Remote copy is a storage-based disaster recovery, business continuance, and workload migration solution that allows you to copy data to a remote location in real time. "Remote copy" refers to these main Advanced Copy Services functions:
1. Metro Mirror (Peer-to-Peer Remote Copy, or PPRC) 2. Global Copy (PPRC-Extended Distance, or PPRC-XD) 3. Global Mirror, or asynchronous PPRC 4. z/OS Global Mirror (Extended Remote Copy, or XRC)
and these additional functions which combine elements of those listed above with other Advanced Copy functions:
1. Metro/Global Copy (PPRC and PPRC-XD) 2. Metro/Global Mirror (PPRC and Global Mirror) 3. Multi-Target Mirror (MTPPRC) 4. Metro/zGlobal Mirror (XRC-IR) 5. Failover (Reverse PPRC relationship during an outage) 6. Failback (Copy changed tracks following an outage)
Note: Remote copy is an extended function on most IBM storage controls, along with the appropriate levels of DFSMSdfp and z/OS. The Coupled Extended Remote Copy (CXRC) function of XRC supports very large customer configurations. The PPRC function provides both synchronous and asynchronous support.
• Coupled XRC, refer to Chapter 8, “Managing coupled extended remote copy sessions,” on page 185. • PPRC, refer to “Choosing Peer-to-Peer Remote copy” on page 15 and “Managing PPRC extended
distance mode” on page 319.
In this topic This topic provides overviews on these remote copy (XRC and PPRC) solutions, and how to choose which one to use in your environment. It includes the following sections:
Section...
“Using remote copy for disaster recovery” on page 10
“Using remote copy for workload migration” on page 12
“Deciding which remote copy option to use” on page 13
“Using channel extenders ” on page 18
“XRC, PPRC and GDPS combination incremental resynchronization” on page 18
Overview of remote copy For many years the perception of data protection has centered around recovery from local events such as fire or weather. This was often addressed by having backup tapes at a remote site, which would ensure recovery in a 24 to 48 hour window. Today, when businesses are often required to be operational
24x7x365, and potential disasters due to weather, power outages, fire, water, or even terrorism pose numerous threats, the importance of real time disaster recovery and business continuance have become absolutely necessary for many businesses. The remote copy functions described herein provide the framework for solutions that address this critical business requirement.
Remote copy operates with two systems: A primary system at one location and a recovery system at another location. You can locate both systems in the same building or at remote locations. The recovery system only needs to be in place for the time when a recovery is required, and can be a stand-alone system. Each system has specific DASD that processes data that you have identified as remote copy- managed. In case of a disaster at your primary location, your recovery system accesses data from the recovery system DASD.
Once established, remote copy provides the following benefits:
• Provides a real-time copy of all SMS-managed and non-SMS-managed data. • Copies changes of your primary system data to your recovery system as you make those changes to
your primary system data. • Is application independent. You do not need separate copy functions for multiple applications or
databases. • Supports all DASD data needed for application recovery. • Provides an improved recovery time on the recovery system, especially in the case of a disaster.
Note: To help switch applications from the primary site to the recovery location, you may want to automate operations, with a program such as NetView® or Geographically Dispersed Parallel Sysplex®
(GDPS®). Your installation can make this switch with a minimal impact on users.
Using remote copy for disaster recovery Disasters occur in many forms. Some disasters happen suddenly, when they do, they stop all processing at a single point in time. A more likely scenario happens when a disaster interrupts operations in stages that occur over several seconds or even minutes. This is often referred to as a rolling disaster. You must, therefore, plan for recovery from a potential disaster that causes system failures that are immediate, intermittent, or gradual. IBM’s remote copy functions address this real-world situation.
Recovering from a disaster without remote copy
Figure 1 on page 11 shows how a data processing facility attempts disaster recovery without remote copy. The existing system cannot keep data at the recovery site current; therefore, any updates made since the last periodic backup may be lost. Without remote copy, you must determine what updates have occurred since the last backup, and then try to manually recreate the missing data.
Figure 1. Current disaster recovery scenario (without remote copy)
Recovering with remote copy
Figure 2 on page 12 shows how disaster recovery proceeds with remote copy solutions.
Comparing Figure 1 on page 11 with Figure 2 on page 12, you find that remote copy improves the current disaster recovery process by allowing a much shorter recovery time with little or no data loss. Remote copy promotes faster recovery because it constantly updates the records at the recovery site to match the primary application records. In the event of a disaster, remote copy minimizes or even eliminates data loss.
Chapter 2. What is remote copy? 11
Figure 2. Disaster recovery scenario with remote copy
The remote copy XRC and PPRC options maintain current copies of your vital data as follows:
• With synchronous PPRC, a minimal amount of data might be lost between the last update at the primary system and the recovery at the recovery system site.
• With PPRC extended distance, data updates might be lost since the last complete copy cycle; because updates are not copied in order, the contents of the secondary volume are unpredictable.
• With XRC, the only data that is lost is data that is in transit between the time that the primary system fails and the recovery at the recovery system site occurs.
For additional information about PPRC, refer to Chapter 15, “Managing Peer-to-Peer Remote Copy operations,” on page 293.
Using remote copy for workload migration In addition to disaster recovery, you can use remote copy for migrating the workload from one location to another or for moving (or migrating) data from one set of volumes to another, with minimal effect on continuous availability applications. For example, reasons for migrating data from one volume to another might include the following:
• Removing volumes from use • Performing maintenance on a storage control • Moving applications to a new data center in another location
• Migrating a remote-copy DASD volume to any other DASD type, refer to Chapter 10, “Migrating data with extended remote copy,” on page 223.
• Migrating work from the primary site to a secondary site, refer to Chapter 17, “Moving and migrating data with Peer-to-Peer Remote Copy,” on page 337.
• Redirecting application I/O from one set of DASD volumes to another set of the same type, refer to Chapter 19, “Peer-to-Peer Remote Copy dynamic address switching (P/DAS),” on page 353.
Restrictions for migrating data
Remote copy can copy data from one volume to another if the number of bytes per track and the number of tracks per cylinder are the same between the two devices, and the target device has an equal or greater number of cylinders. The only way to copy data between unlike devices or from larger devices to smaller capacity devices is by using DFSMSdss (or DFDSS, or a comparable product) logical dump, restore, or copy functions. Although the 3380 volumes do not have the same number of bytes per track as the 3390 volumes, you can use DFSMSdss to copy data between the two unlike devices.
For additional information about DFSMSdss copy functions, refer to the z/OS DFSMSdss Storage Administration.
Advantages of using remote copy to migrate data
Using remote copy over other data migration methods provide the following advantages:
• Minimal application down time — Remote copy updates the remote migration copy at the same time that you update the application. When the migration copy is complete, you simply quiesce application programs, ensure that all updates are on the migration volumes, and start up the application using the new volumes.
• Minimal application impact — Application performance is not affected during the migration. You can continue to update data normally, with a pause to switch to the new volumes.
• Migration automation — There is less operator intervention that is required to perform the migration because there is no need for a dump and restore process.
Deciding which remote copy option to use Based on your specific needs, you can choose from several remote copy disaster recovery options: Extended remote copy (XRC), peer-to-peer remote copy (PPRC), or PPRC-Extended Distance.
Both primary and recover site storage control must be on cached storage subsystems.
Table 3 on page 13 compares both the extended remote copy and peer-to-peer remote copy options.
Table 3. Comparison of Remote Copy Functions
Topic . . . XRC PPRC PPRC-XD Global Mirror Cascaded PPRC Multi-Target PPRC
Application independent?
Type of solution
HW and SW HW and SW HW and SW HW and SW HW and SW HW and SW
Design priority Minimize impact on application performance
Maintain current data at recovery site
Minimize impact on application performance
Minimize impact on application performance
Cascade Multi-Target
Recovery Entire session Vol-by-vol basis Vol-by-vol basis Vol-by-vol basis for entire session
Vol-by-vol basis for entire session
Vol-by-vol basis for entire session
Recovery site data is current
Except the bytes in transit
Secondary site kept fully current
Except the bytes in transit
As of last FlashCopy consistency group completed (6)
Depends on the technology used (6).
Depends on the technology used (6).
Support software for system with system data mover
All supported z/OS releases
Primary system support software
Must support timestamping function
Table 3. Comparison of Remote Copy Functions (continued)
Topic . . . XRC PPRC PPRC-XD Global Mirror Cascaded PPRC Multi-Target PPRC
Channel type ESCON, fiber, or parallel
ESCON and FCP for PPRC link (ESCON, fiber, or parallel for host links)
ESCON and FCP for PPRC link (ESCON, fiber, or parallel for host links)
FCP for PPRC link (FCP for host links)
FCP for PPRC link (ESCON, fiber, or parallel for host links)
FCP for PPRC link (ESCON, fiber, or parallel for host links)
Supported copy distance
Unlimited (3) Unlimited Unlimited (7) Unlimited (7)
Copy operation
Asynchronous (5); for Metro/Global Mirror, synchronous for the secondary site.
Multi-vendor support
Notes:
1. When PPRC extended distance is enabled, data at the secondary site is not consistent with the primary site. For more information, see “Managing PPRC extended distance mode” on page 319.
2. Adding channel extenders can extend the distance by sending the data across telecommunication lines. See “Using channel extenders ” on page 18 for more information.
3. For PPRC extended distance, the distance between storage controls can be greater than that supported with ESCON. For information, see “Managing PPRC extended distance mode” on page 319.
4. The initial volume copy to the secondary device is asynchronous. Primary updates are transmitted asynchronously to secondary volumes when PPRC extended distance is enabled. For more information, see “Managing PPRC extended distance mode” on page 319.
5. For Metro/Global Copy, the initial volume copy to the local PPRC secondary is synchronous. Updates are transmitted asynchronously to the PPRC-XD secondary volumes. For more information, see “Metro/Global Copy” on page 242.
6. The secondary site kept fully current for both Metro/Global Copy and Metro/ Global Mirror. For Metro/Global Mirror, the remote site is current up to the last FlashCopy consistency group created. The Global Mirror master will form FlashCopy Consistency Groups at a user-specified interval. The data at the recovery site is consistent to the last successful consistency group formed by the master. With Incremental Resync, the remote site can be made current in the case of an intermediate site outage.
7. For the Metro Mirror relationship, the distance should be < 100 km for performance reasons, and the Global Mirror relationship may be at unlimited distance.
Choosing extended remote copy Extended remote copy is a combined hardware and software solution to the problem of accurate and rapid disaster recovery. XRC also provides a DASD and workload migration solution.
XRC is designed for sites that match the following criteria:
• Must maintain the highest levels of performance on their primary system. • Support extended distances between volume copies. • Can support a recovery point objective time of a few seconds. • Provides support for a mixed vendor environment. You are allowed to mix and match primary and
secondary volumes for any vendor supporting XRC architecture. Primary volumes must have XRC architecture support, but secondary volumes need not have XRC architecture support.
Protecting your enterprise’s data requires that related updates are applied to the secondary volumes in the same order as they were applied on the primary volumes. Maintaining data integrity becomes especially critical when a volume is updated by multiple applications, or when a data set exists on multiple volumes spread across multiple storage controls. XRC’s design strategy ensures that secondary updates are applied on a consistent basis across multiple storage controls. This update sequencing is necessary in order to avoid data integrity problems and potential data loss.
XRC supports channel extenders, ESCON, FICON®, and parallel channel operation. With ESCON and FICON channels, the XRC function provides for the recovery system to reside at an extended distance from the primary system.
Figure 3 on page 15 presents an overview of the XRC option of remote copy. The workload (or DASD) migration configuration is basically the same, except that the "recovery site" would be considered the "migration target".
Figure 3. Extended remote copy overview
For additional information about CXRC , refer to Chapter 8, “Managing coupled extended remote copy sessions,” on page 185.
How extended remote copy (XRC) works
XRC is implemented in a cooperative way between cached storage subsystems and DFSMS/MVS host system software. With XRC, copies of updated data are automatically sent to the recovery system. This is done asynchronously to data updates on the primary system, and with a minimal increase to DASD write response time at the application.
Choosing Peer-to-Peer Remote copy PPRC, available on all supported z/OS releases, is a hardware solution to the problem of accurate and rapid disaster recovery, and also provides a workload migration solution. It is designed to provide data transfer synchronously and asynchronously.
Synchronous PPRC is designed to provide real-time mirroring of logical volumes within an ESS or between two ESSs. The sites using synchronous PPRC must conform to the following conditions:
• Need the recovery system to always be fully current with the primary system • Can accept some performance impact to application write I/O operations at the primary location • Can accept typical write overhead plus 1ms per km impact.
PPRC extended distance is designed for those sites that conform to the following conditions:
• Need a disaster recovery solution with a recovery point object (RPO) of many hours, or even several days.
• Have the primary and recovery storage control sites separated by very long distances beyond those supported for synchronous PPRC.
• Need the flexibility to use both synchronous and asynchronous data transfers, especially when bandwidth restrictions are a consideration.
Figure 4 on page 16 presents an overview of the PPRC option of remote copy, based on a disaster recovery need. The workload (or DASD) migration configuration is basically the same, except that the "recovery site" would be considered the "migration target."
Figure 4. PPRC overview
How Synchronous PPRC works
The following describes the PPRC synchronous copy functions:
• A PPRC data copy to the recovery storage subsystem is synchronous with the primary volume’s I/O operation. This means that the primary system writes data to a primary volume’s storage subsystem, the data is transferred to cache and nonvolatile storage (NVS), and the storage control sends channel end status to the host.
• The primary site storage control then initiates an I/O channel program to the recovery site storage control to transfer the updated data.
• The primary site storage control returns device end status to the primary system when the transfer to the recovery site storage control cache and NVS is complete.
• The primary system notifies the application program that the operation is complete.
Note: The PPRC copy function does not consider the primary system DASD write operation complete until the data that is sent to the recovery storage subsystem has received channel end and device end status from the secondary volume storage control. Each primary system write to the recovery subsystem causes an increase to the primary system response time.
How PPRC extended distance works
When PPRC extended distance is active, the ESS captures information about updates to the primary and periodically sends those updates to the secondary. As a result, there is no guarantee that application dependent writes are transferred in the same sequence as they were applied to the primary volume.
For additional information about PPRC extended distance, refer to “Understanding how PPRC extended distance works” on page 320.
How Metro/Global Copy works
Metro/Global Copy is a cascaded PPRC solution that enables you to combine two PPRC pairs, synchronous PPRC and PPRC-XD, which operates asynchronously, to create a low-cost, long-distance, tier four data loss disaster recovery configuration. In a cascading PPRC configuration, a single volume is defined as both a primary and a secondary, combining three volumes into two PPRC pairs.
For additional information about Metro/Global Copy, refer to “Metro/Global Copy” on page 242.
Choosing Global Mirror A Global Mirror environment also addresses the issue of unrecoverable data lost between backups. Global Mirror gives you the ability to establish PPRC-XD pairs over a long distance and maintain consistent FlashCopy versions at the disaster recovery site without suffering any significant performance degradation or requiring applications to be quiesced.
How Global Mirror works
Global Mirror for ESS combines PPRC-Extended Distance pairs (PPRC-XD) with FlashCopy consistency groups to provide true backup at a secondary site. This is accomplished through the addition of a master session in the hardware configuration. This master session controls all updates to the secondaries of the PPRC-XD pairs and, at the secondary site, the creation of consistent copies (using FlashCopy), at user specified intervals. Global Mirror for ESS requires FCP connection.
For additional information about Global Mirror, refer to Chapter 20, “Planning for Global Mirror,” on page 371.
How Metro/Global Mirror works
Metro/Global Mirror is a three-site solution, which uses synchronous replication to mirror data between a local site and an intermediate site, and asynchronous replication to mirror data from an intermediate site to a remote site. In this configuration, a Metro Mirror pair is established between two nearby sites (local and intermediate) to protect from local site disasters. The Global Mirror volumes can be located thousands of miles away and would continue to be updated if the original local site has suffered a disaster and I/O has to be failed over to the intermediate site. In the case of a local-site-only disaster, Metro/ Global Mirror can provide a zero-data-loss recovery at the remote site as well as at the intermediate site.
For additional information about Metro/Global Mirror, refer to Chapter 25, “Metro/Global Mirror,” on page 413.
Choosing Multi-Target Mirror A Multi-Target Mirror environment allows a device to be the primary of more than one PPRC pair. It simplifies recovery scenarios for cascaded configurations, when swapping from the local site to the intermediate site. With Multi-Target support, during a failover to the intermediate site, the intermediate device can become a primary to both the local and the remote, eliminating the need to suspend the intermediate to remote site pair when swapping back to the local site. It provides for the capability of an incremental resynchronization between the two secondary volumes in both planned and unplanned swap scenarios.
Multi-Target Mirror allows for
• Synchronous replication within a data center combined with another metro distance synchronous relationship
• Adding another synchronous replication for migration without interrupting an existing replication • Combining synchronous mirroring at metro distances with asynchronous mirroring at global distances
from the same primary • Improved support for three and four-site configurations
For more information, refer to “Multi-target PPRC solutions” on page 243.
Using channel extenders Remote copy supports channel extenders for instances where a direct ESCON or Fiber connection is not possible, or where the performance overhead is too severe. Channel extenders perform the following functions:
• Allow you to configure remote copy between locations that are either beyond the maximum ESCON channel distance, or where ESCON fiber optic cables cannot physically be placed.
• Operate as a pair of devices. One device attaches to a host system channel and the second unit connects to the storage control, which considers the attached extender to be a system channel. Both devices are connected through a network of fiber-optic cables or telecommunication lines.
An advantage of XRC is that it minimizes the effect on applications when data moves across long distances. Channel extenders provide an important part of this solution. There may be a small delay between the time that the application makes the update and when the system data mover receives the update. This potential delay is a result of the time that is required for signals to travel greater distances and the channel-to-network protocol translation necessary to achieve transmission at the extended distance.
For PPRC extended distance operations, channel extenders are used when the primary and secondary storage control sites are separated by very long distances. For information, see “Managing PPRC extended distance mode” on page 319.
XRC, PPRC and GDPS combination incremental resynchronization XRC, PPRC and GDPS combination incremental resynchronization (IR) offers both high availability and disaster recovery capability. It consists of a three-site solution that combines XRC and PPRC in a GDPS environment, where two sites are geographically close and a third site is geographically remote. The two close sites are connected through PPRC. The remote site is mirrored by XRC. High availability is provided by HyperSwap® function between the two close sites. Disaster recovery capability is provided for the remote site. For more information, see the licensed publication GDPS Metro/zGlobal Mirror: Planning and Implementation Guide, ZG24-1757.
Metro/zGlobal Mirror (XRC-IR) is not supported with multi-target PPRC on the primary.
Part 2. Extended Remote Copy This provides the information to help you use extended remote copy.
Chapter 3. Planning for extended remote copy
Before installing and using XRC, you need to plan for it. Understanding the system requirements helps you prepare for a successful installation of XRC.
For additional information about a coupled XRC environment, refer to Chapter 8, “Managing coupled extended remote copy sessions,” on page 185.
In this topic This topic is intended to help you plan for extended remote copy. It includes the following sections:
Section . . .
“XRC operational considerations” on page 22
“Introducing the XRC components” on page 23
“Establishing XRC secondary volumes” on page 29
“Evaluating remote copy with DFSMShsm” on page 29
“Defining storage requirements” on page 30
“Configuring extended remote copy” on page 32
“Determining XRC resource needs” on page 34
“Protecting access to XRC commands” on page 37
“XRC enhanced multiple reader function” on page 38
XRC requirements You must meet the software and hardware requirements below in order to plan for and successfully install XRC. Table 3 on page 13 includes information about XRC hardware and software requirements.
XRC software requirements The system data mover (SDM) function works with any supported z/OS releases.
XRC hardware requirements The following topics describe hardware requirements for XRC:
• ESA/390 hardware. • Your ES/9000 environment must be compatible. The XRC primary system builds on the existing sysplex
concept to ensure sequence consistency. You must have a sysplex timer if multiple processing units update XRC primary volumes. The system clock is sufficient in a single processor or virtual server environment.
• The system data mover must have access to the control, state, and journal data sets, and to the primary and secondary copy volumes. If you are going to configure a coupled environment, all SDM hosts must have access to a shared volume that contains the master data set.
• All host primary systems must have a common time reference. This is necessary so that XRC can provide data consistency for all volume updates across all attached host systems. Host system
MVS/DFP software performs timestamping of all application I/O write operations to active XRC volumes. Therefore, all channel programs issued to XRC-managed volumes are timestamped with a common time reference.
Examples: The following are examples of common time references:
– The system time-of-day clock provides the common time reference for environments with either a single processor, or with multiple virtual servers defined.
– In an environment with multiple processing units, the sysplex timer, or equivalent, provides the common time reference for application programs. XRC and application programs both require a common time reference.
• Although the primary application systems require a common timer reference so XRC can properly order dependent application I/Os, the XRC system itself does not need to be attached a sysplex timer.
• A compatible secondary volume must be available for each primary volume you wish to copy. The secondary volume must have the identical track capacity and number of tracks per cylinder and either the same or larger volume capacity.
XRC supported devices
For the primary subsystem, XRC supports all storage controls that have XRC-capable licensed internal code (LIC).
Recommendation: The secondary subsystem should be equivalent to the primary system storage control, with similar cache and NVS sizes, for the best XRC system performance and recoverability.
XRC operational considerations This section addresses physical and operational limitations for XRC, including limits on the number of active volumes and sessions, and volume format restrictions.
The following limitations apply to XRC operations:
• Each volume may be an XRC primary in only one session. Each secondary volume can belong to only one XRC volume pair. However, a secondary volume in one XRC session may be a primary volume in another session. A volume cannot be both primary and secondary within the same session.
• Each logical storage subsystem (LSS) in an Enterprise Storage Server (ESS) storage subsystem can support up to 64 XRC sessions. This session limit is a combination of XRC and concurrent copy sessions. The 3990 Storage Control supports up to four XRC sessions per SSID. Each connected MVS system can manage a unique set of volumes behind the storage subsystem.
• You can define a maximum of 256 volumes for each LSS in an ESS storage subsystem. The 3990 Storage Control supports up to 128 volumes.
• Each XRC session can support a maximum of 80 storage control sessions. However, the practical limit, for a session with a full complement of buffers, is 40 storage control sessions. This limit is further re

version 2 release 4 z/os...contents figures xvii tables xxi about this document.....xxv

Documents