EMC GDDR for SRDF /SQAR with AutoSwap

Transcription

1 EMC GDDR for SRDF /SQAR with AutoSwap Version 4.2 Product Guide REV 01

2 Copyright 2015 EMC Corporation. All rights reserved. Published in the USA. Published February, 2015 EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. EMC 2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners. For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories section on the EMC online support website. 2 EMC GDDR Version 4.2 Product Guide

3 CONTENTS Preface Chapter 1 Chapter 2 Product Overview What is EMC GDDR? Major features Situational awareness Survivor recognition Leadership nomination Additional capabilities Types of environment Supported business continuity configurations SRDF/SQAR with AutoSwap configuration EMC GDDR fundamentals Control systems Workload location Managed workloads External workloads Excluded systems HMC-only systems HMC Bypass feature EMC GDDR processes EMC GDDR components Parameters User interface Events Monitors Message interception rules EMC GDDR supported scripts Planned event management Test event management Unplanned event management Resumption of replication after SRDF link outages Regional disaster operations Special actions Parameter Load wizard: Telling EMC GDDR what to manage Installing EMC GDDR Preinstallation tasks Mainframe environment requirements Minimum software requirements Minimum hardware requirements DASD support Installation procedure Before you begin Gather EMC GDDR installation information Install EMC GDDR Run the installation jobs Post-installation tasks EMC GDDR Version 4.2 Product Guide 3

4 Contents Chapter 3 Integrating EMC GDDR Overview of EMC GDDR-managed system types Production or test systems and their optional contingency systems Excluded systems HMC only systems External workload systems Coupling facility LPARs Integration tasks GDDR installation and user BPX authorization (optional) HFS file and directory customization Update system parameter files SYS1.PARMLIB( BPXPRMxx ) customization SYS1.PARMLIB(IKJTSOxx) customization TSO logon customization APF authorization LINKLIB and REXX parameter file installation Customize LINKLIST Customize REXX parameter files Create parameter members for SRDF Host Component on C-Systems Edit SCF initialization parameters Authorize the EMC Consistency Group started task to use the trip API Perform ConGroup configuration Perform ConGroup Started Task automated startup Perform MSC configuration Specify EMC GDDR security EMC GDDR RACF functional groups Summary of RACF permissions EMC GDDR user interface security RACF authorization for HMC LPAR actions Mainframe Enablers EMCSAFI security interface authorization Authorized module and RACF-protected resource authorization verification Define EMC GDDR datasets Define global variable datasets Allocate the parameter management datasets Install EMC GDDR started procedures Install EMC GDDR Licensed Feature Code Customize GDDRMAIN parameters Specify GDDR data in virtual dataset names Worker parameters COMM parameters CSYSSITE parameters CPC parameters SYMM parameters Customize member GDDRPROC Customize the GDDR ISPF user interface invocation REXX exec Configure EMC GDDR Step 1: Update your personal GDDR ISPF profile Step 2: Define initial site, system, storage, utility, and GDDR option parameters Step 3: Modify EMC GDDR user exits (optional) Optional configuration features SRDF Recovery Preference SRDF/SQAR High Availability (HA) operation CPC Recovery - LPAR Recovery features EMC GDDR Version 4.2 Product Guide

5 Contents Chapter 4 Chapter 5 Using EMC GDDR Online Facilities Primary Options Menu Option P: Profile Update Personal GDDR ISPF Profile Option M: Maintenance GDDR Setup and Maintenance Option P: Manage GDDR Parameters Option D: Message, Debug and Trace Options Option Q: Manage GDDR Internal Command Queue Option H: Perform HMC Discovery Option R: Refresh GDDR Message Table Option S: Manage GDDR System Variables Option T: Transfer Master C-System Option G: GDDR Config View GDDR Configuration Option C: Checkup Perform Pre-script Checkup Health Check monitoring GDDR Event monitoring exception notification Additional pre-script environment checks Option S: Scripts Run GDDR Scripts Option T: Timing View GDDR Script Statistics Option A: Actions Perform GDDR Actions Option H: Perform HMC Discovery Option L: Perform HMC LPAR Actions Option CBU: Perform HMC CBU actions Option S: Manage Couple Datasets Option CF: Manage CF Structures Option E: EzSM - Run EMC z/os Storage Manager Option ST: estem - Run EMC Started Task Execution Manager Adding a new procedure Adding tasks to the procedure Executing a procedure locally Executing a procedure remotely Executing a procedure within a procedure Performing Script Operations Running scripts Call overrides Recovering from script errors Rerunning a script WTOR messages Planned script operations Automated Configuration Check - DASD - GDDRPCCD Swap production from DC1 to DC2 - SRDF/S pref. -GDDRPA Swap DASD from DC1 to DC2 - SRDF/S pref. - GDDRPA AbandonRegion <n>(out-of Region site swap)- GDD2P17A Abandon Secondary site (DC2 ) - GDDRPA60 Abandon Tertiary site (DC3 ) - GDDRPA60 Abandon Quaternary site (DC4 ) - GDDRPA Restart production at DC3 or DC4 after site region swap - GDD2P18A Test operations Perform test IPL from BCVs at DC3 or DC4- GDD2P01A Resume after test IPL from BCVs at DC3 or DC4 - GDD2P02A Perform test IPL from R2s at DC2 - GDD2P03A Resume after Test IPL from R2s at DC2 - GDD2P16A Perform test IPL from R2s at DC3 or DC4 - GDDRPA Resume after test IPL at DC3 or DC4 - GDDRPA EMC GDDR Version 4.2 Product Guide 5

6 Contents Unplanned script operations Recover after unplanned swap -GDDRUP Recover after loss of DC1 (LDR) - GDD2U13A Resume replication after unplanned swap - GDDRPA0A Resume replication after loss of DC1 - GDDRPA0A Resumption operations Resume SRDF/S replication after ConGroup trip - GDDRPA Resume SRDF/A in MSC mode to DC3 or DC4 - GDDRPM Resume SRDF/A in SQAR mode to DC3 - GDDRPF Reclaim Secondary site (DC2 ) - GDDRPA65 Reclaim Tertiary site (DC3 ) - GDDRPA65 Reclaim Quaternary site (DC4 ) - GDDRPA Regional disaster operations Options for recovery after loss of primary region Recover at DC3 after RDR at DC1 and DC2 - GDDRPA05 Recover at DC4 after RDR at DC1 and DC2 - GDDRPA05 Recover at DC3 with SRDF/S to DC4 - GDDRPA05 Recover at DC4 with SRDF/S to DC3 - GDDRPA Restart Production LPARs at DC3 with Cascaded SRDF - GDDRPA06 Restart Production LPARs at DC4 with Cascaded SRDF - GDDRPA06 Restart Production LPARs at DC3 with Concurrent SRDF - GDDRPA06 Restart Production LPARs at DC4 with Concurrent SRDF - GDDRPA Recover at DC3 with Cascaded SRDF after LDR at DC1 - GDDRPA07 Recover at DC4 with Concurrent SRDF after LDR at DC1 - GDDRPA Special operations Planned STAR-HA Takeover - GDDRPA Unplanned STAR-HA Takeover - GDDRUP Restart Secondary MSC Server at <DCx> - GDDRPA Restart primary MSC server at <DCx> - GDDRMMSC Transfer AutoSwap Owner to <DCx> - GDDRPXAS Transfer Master C System to <DCx> - GDDRPXMC Global Variable Backup - GDDRPGVB Move systems to alternate CPC - GDDRMCPC Chapter 6 Chapter 7 Handling Unplanned Events Introduction Consistency group trips Unplanned swaps GDDR AutoSwap and restart of Enhanced Catalog Sharing Local and regional disaster operations DC4 or DC4Confirm loss of the primary region Confirm ready for recovery at the secondary region AutoSwap lost owner policy (LOP) Lost owner policy Lost owner policy operations System failure operations EMC GDDR C-System failure Production system failure EMC GDDR Master Function transfer Performing Maintenance Procedures Setting up a new EMC GDDR C-System Renaming an existing EMC GDDR C-System EMC GDDR Version 4.2 Product Guide

7 Contents Changing the GDDR C-System or GDDR managed system IP address Changing the GDDR C-System or GDDR managed system IP port Adding a new system or sysplex to EMC GDDR Changing the Consistency Group name Adding new RDF groups to EMC GDDR Adding new devices to EMC GDDR Removing an RDF group from EMC GDDR control Removing devices from EMC GDDR control Removing a system or a sysplex from EMC GDDR Changing the global variable DIV dataset or WORKER parameters AutoSwap special cases Page datasets Non-LOGR couple datasets Standalone dump considerations Chapter 8 Appendix A Appendix B Troubleshooting Detecting and resolving problems Using the GDDRXCMD batch utility To print the current queue To clear the current queue Troubleshooting EMC GDDR User Exits User exit programming considerations Sample procedure to use interpreted REXX user exits Sample procedure to use CA-OPS/MVS compiled REXX user exits Built-in routines available to exits Exit specifications GDDRUX GDDRUX GDDRUX GDDRUX Using GDDRMAIN Stopping GDDRMAIN Stop command (P) GDDRMAIN subtasks and dependent address spaces GDDRMAIN console commands START STOP RESTART CANCEL TASKS LOCK COMM DLM GVB MPARM RDFREFR WORKER MSGS BC and BR SCRIPT EMC GDDR Version 4.2 Product Guide 7

8 Contents GDDRMAIN EXEC parameters GDDRGVX utility DSPLIST DIVLIST DSPSAVE RELOAD EMC GDDR system variable integrity and access Index lock Update lock Dynamic LPA Dynamic exits Remote command processing GDDR script submission operator command Authorization Keywords for options Examples Appendix C Appendix D Automated Configuration Utilities Automated Configuration Discovery for DASD (GDDRACDD) Prerequisites Procedure Implementation Sample JCL Arguments Optional DD-cards Parameters (ACDDPARM DD statement) Output Exception reporting GDDR RDF Director Overview utility (GDDRDIRS) GDDR MSC Configuration Validation utility (GDDMSCFX) Sample JCL Example reports GDDR DLm Serial Number utility (GDDRDLSN) GDDR SDDF Session utility (GDDRSDDF) Requirements Optional DD cards Invoking the utility Sample reports SRDF device and BCV status reporting utilities BCPii Interface Introduction to the BCPii interface BCPii HMC Networking capabilities and requirements GDDMPARM CPC parameter entries CPC parameter requirements CPC parameter LAN network ID requirements CPC parameter SE/HMC control requirements Security changes required to use BCPii BCPii facility classes SYS1.PARMLIB changes required for BCPii GDDRBPCI BCPii test job for B-Systems EMC GDDR Version 4.2 Product Guide

9 Contents Appendix E SMP/E Post-Maintenance Procedure Introduction The GDDRPMNT job To access the updated panels Glossary EMC GDDR Version 4.2 Product Guide 9

10 Contents 10 EMC GDDR Version 4.2 Product Guide

11 FIGURES Title Page 1 SRDF/SQAR with AutoSwap environment Physical designations in SRDF/SQAR topology Logical designations in SRDF/SQAR topology Symmetrix and SRDF group asymmetries SRDF/SQAR operations and SDDF session management Initial state of SRDF/SQAR SRDF/SQAR inter-region swap (1 of 2) SRDF/SQAR inter-region swap (2 of 2) SRDF/SQAR intra-region swap SRDF/SQAR site A failure (1 of 2) SRDF/SQAR site A failure (2 of 2) SRDF/SQAR Primary Region failure (1 of 2) SRDF/SQAR Primary Region failure (2 of 2) EMC JCL customization utility EMC JCL customization utility completed panel MSC servers in SRDF/SQAR mode GDDECHK input parameters Validation of GDDR$ADM group access by facility Validation of specific calls from GDDR modules Primary Options Menu Change GDDR ISPF Profile Variable Values panel Setup and Maintenance Menu Parameter Management Options Menu GDDR parameter management Parameter Load wizard work flow step Parameter Load wizard work flow step Parameter Load wizard work flow step Parameter Load wizard work flow step Parameter Load wizard work flow step Parameter Load wizard work flow step Select Parameter Input Dataset for parameter review Reviewer's version of the Parameter Management Options Menu Manage GDDR Parameter Backups panel Select Dataset for GDDR Parameter Backup Select Parameter Input Dataset panel Prepare Work Dataset for Parameter Load confirmation panel Prepare Work Dataset status panel Parameter Management Options Menu with parameter load input selection Select Parameter Input Dataset panel with Edit-in-Progress serialization lock - User Select Parameter Input Dataset panel with Edit-in-Progress FORCE authorization - User GDDR Parameter Wizard panel after FORCE of Edit-in-Progress serialization lock - User Select Parameter Input Dataset panel after FORCE of Edit-in-Progress serialization lock -User Define Configuration Basics panel Define GDDR Configuration Features Define C-Systems panel Define GDDR Datasets panel Define Site Roles and Groups panel EMC GDDR Version 4.2 Product Guide 11

12 Figures Title Page 48 Define Data Storage Objects panel Define SRDF Device Ranges panel Define TimeFinder Device Ranges panel, 1 of Define TimeFinder Device Ranges panel, 2 of Define TimeFinder Device Ranges panel, 3 of Define SDDF Clean Utility Gatekeepers panel Define DLm Devices panel Define DLm Devices - ACP Details panel Define Host Objects panel Define Managed Systems panel Define System IPL Priorities panel Define Managed LPARs panel Define System Recovery Attributes panel Define Managed CPCs panel Define IPL Parameters panel Define HMC Load Activation Profiles Define Managed HMCs panel Define HMC Community Names panel Define Managed Couple Datasets panel 1 of Define Managed Couple Datasets panel 2 of Define Managed CF Structures panel 1 of Define Managed CF Structures panel 2 of Define External Workloads panel Define EMC Mainframe Enablers STCs panel Specify GDDR Options panel Specify Default Script Call Overrides panel (1 of 2) Specify Default Script Call Overrides panel (2 of 2) Script Sysplex Options panel Script JCL Parameters panel Utility Parameters panel Messaging Options panel Specify GDDR Tuning Values panels Define GDDR User Labels panel Validate GDDR Parameter Set panel Activate GDDR Parameter Set panel Parameter Load Activation status panel 1 of Parameter Load Activation status panel 2 of Set Output Message Levels by Program panel Add Program to MsgLevel/Debug/Trace List panel Manage GDDR Internal Command Queue panel HMC object discovery panel HMC Discovery Results panel Message table refresh indicator Manage GDDR System Variables panel 1 of Manage GDDR System Variables panel 2 of Manage GDDR System Variables panel 3 of Transfer Master C-System panel View GDDR Configuration panel Perform Health Check panel GDDRMAIN System Details panel Select Script to Run panels Script to Run panel (Master C-System at Secondary Region) 1 of Script to Run panel (Master C-System at Secondary Region) 2 of EMC GDDR Version 4.2 Product Guide

13 Figures 101 Script to Run panel (Master C-System at Secondary Region) 3 of Select Script to Run panel unavailable scripts displayed Select Script to Run panel unavailable scripts hidden Script Selection for Status panel GDDR Actions Menu HMC object discovery panel HMC Discovery Results panel Perform HMC LPAR Actions panel Perform CBU Actions panel Manage Couple Datasets panel Manage CF Structures panel EMC z/os Storage Manager Product Home menu EMC Started Task Execution Manager Procedure Member List panel Specify Parameters for Initial Script Run panel Specify Call Overrides panel (screen 1 of 2) Specify Call Overrides panel (screen 2 of 2) Confirm Job Submission panel Display of module maintenance data SRDF/SQAR ACDD parameter example GDDR SRDF directors overview for ALL RDF groups, 1 of GDDR SRDF directors overview for ALL RDF groups, 2 of RDF groups by director by Symmetrix by site, Site: DC RDF groups by director by Symmetrix by site, Site: DC RDF groups by director by Symmetrix by site, Site: DC3 and Site UNK Primary Options Menu Help panel with "M" Command Line entry GDDR Applied PTF Maintenance One of multiple panels showing SMP/E details EMC GDDR Version 4.2 Product Guide 13

14 Figures 14 EMC GDDR Version 4.2 Product Guide

15 TABLES Title Page 1 Mainframe environment requirements Minimum hardware requirements Installation tasks RIMLIB library contents SRDF Host Component parameter members RACF functional groups RACF permissions RACF permissions, OPERCMDS class Summary of GDDR ISPF RACF permissions SAMPLIB inventory Defining Managed Couple Datasets Script management options Monitored events Software state analysis messages Script generation status messages EMC GDDR call overrides Resiliency Expert global variables GDDRMAIN subtasks Dependent address spaces GDDRMAIN console command summary Possible lock states Script keywords Control keywords EMC GDDR Version 4.2 Product Guide 15

16 Tableses 16 EMC GDDR Version 4.2 Product Guide

17 PREFACE As part of an effort to improve its product lines, EMC periodically releases revisions of its software and hardware. Therefore, some functions described in this document might not be supported by all versions of the software or hardware currently in use. The product release notes provide the most up-to-date information on product features. Contact your EMC representative if a product does not function properly or does not function as described in this document. Note: This document was accurate at publication time. New versions of this document might be released in EMC Online Support. Check EMC Online Support to ensure that you are using the latest version of this document. Purpose Audience This guide describes the basic concepts of EMC Geographically Dispersed Disaster Restart (EMC GDDR), how to install it, and how to implement its major features and facilities. This document is part of the EMC Geographically Dispersed Disaster Restart (EMC GDDR) documentation set, and is intended for use by EMC GDDR systems administrators and computer operators. Readers of this document are expected to be familiar with the following topics: IBM z/os operating environments IBM parallel sysplex EMC software: SRDF, ResourcePak Base, Consistency Group, and AutoSwap Related documentation The following publications provide additional information: EMC GDDR Release Notes EMC GDDR Message Guide EMC Mainframe Enablers Installation and Customization Guide EMC ResourcePak Base for z/os Product Guide EMC Symmetrix SRDF Host Component for z/os Product Guide EMC AutoSwap for z/os Product Guide EMC Consistency Group for z/os Product Guide EMC TimeFinder/Mirror for z/os Product Guide EMC TimeFinder/Clone Mainframe Snap Facility Product Guide EMC REXX Interface Programmer s Reference Guide EMC GDDR Version 4.2 Product Guide 17

18 Preface Conventions used in this document EMC uses the following conventions for special notices: A caution contains information essential to avoid data loss or damage to the system or equipment. The caution may apply to hardware or software. IMPORTANT An important notice contains information essential to software or hardware operation. Note: A note presents information that is important, but not hazard-related. Typographical conventions EMC uses the following type style conventions in this document: Normal Used in running (nonprocedural) text for: Names of interface elements, such as names of windows, dialog boxes, buttons, fields, and menus Names of resources, attributes, pools, Boolean expressions, buttons, DQL statements, keywords, clauses, environment variables, functions, and utilities URLs, pathnames, filenames, directory names, computer names, links, groups, service keys, file systems, and notifications Bold Used in running (nonprocedural) text for names of commands, daemons, options, programs, processes, services, applications, utilities, kernels, notifications, system calls, and man pages Used in procedures for: Names of interface elements, such as names of windows, dialog boxes, buttons, fields, and menus What the user specifically selects, clicks, presses, or types Italic Used in all text (including procedures) for: Full titles of publications referenced in text Emphasis, for example, a new term Variables Courier Used for: System output, such as an error message or script URLs, complete paths, filenames, prompts, and syntax when shown outside of running text Courier bold Used for specific user input, such as commands Courier italic Used in procedures for: Variables on the command line User input variables < > Angle brackets enclose parameter or variable values supplied by the user [ ] Square brackets enclose optional values Vertical bar indicates alternate selections the bar means or { } Braces enclose content that the user must specify, such as x or y or z... Ellipses indicate nonessential information omitted from the example 18 EMC GDDR Version 4.2 Product Guide

19 Preface Where to get help EMC support, product, and licensing information can be obtained though EMC Online Support as described next. Note: To open a service request through EMC Online Support, you must have a valid support agreement. Contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account. Product information For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to EMC Online Support (registration required) at: Technical support EMC offers a variety of support options. Support by Product EMC offers consolidated, product-specific information on the Web at: The Support by Product web pages offer quick links to Documentation, White Papers, Advisories (such as frequently used Knowledgebase articles), and Downloads, as well as more dynamic content, such as presentations, discussions, relevant Customer Support Forum entries, and a link to EMC Live Chat. EMC Live Chat Open a Chat or instant message session with an EMC Support Engineer. elicensing support To activate your entitlements and obtain your Symmetrix license files, visit the Service Center on as directed on your License Authorization Code (LAC) letter ed to you. For help with missing or incorrect entitlements after activation (that is, expected functionality remains unavailable because it is not licensed), contact your EMC Account Representative or Authorized Reseller. For help with any errors applying license files through Solutions Enabler, contact the EMC Customer Support Center. If you are missing a LAC letter, or require further instructions on activating your licenses through EMC Online Support, contact EMC's worldwide Licensing team at licensing@emc.com or call: North America, Latin America, APJK, Australia, New Zealand: SVC4EMC ( ) and follow the voice prompts. EMEA: +353 (0) and follow the voice prompts. Your comments Your suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Send your opinions of this document to: VMAXContentFeedback@emc.com EMC GDDR Version 4.2 Product Guide 19

20 Preface 20 EMC GDDR Version 4.2 Product Guide

21 CHAPTER 1 Product Overview This chapter presents an overview of EMC GDDR and its capabilities. What is EMC GDDR? Major features Supported business continuity configurations EMC GDDR fundamentals EMC GDDR components EMC GDDR supported scripts Parameter Load wizard: Telling EMC GDDR what to manage Product Overview 21

22 Product Overview What is EMC GDDR? EMC Geographically Dispersed Disaster Restart (EMC GDDR) is a mainframe software product that automates business recovery following both planned outages and disaster situations, including the total loss of a data center. EMC GDDR achieves this goal by providing monitoring, automation, and quality controls to many EMC and third-party hardware and software products required for business restart. Because EMC GDDR restarts managed systems following disasters, it does not reside on the same z/os systems that it is seeking to protect. EMC GDDR resides in separate logical partitions (LPARs) from the host z/os systems that run your application workloads. You install EMC GDDR on a control z/os system at each site. Each EMC GDDR node is aware of the other EMC GDDR nodes through network connections between each site. This awareness allows EMC GDDR to: Detect disasters Identify survivors To achieve the task of business restart, EMC GDDR automation extends well beyond the disk level and into the host operating system level. It is at this level that sufficient controls and access to third party software and hardware products exist to enable EMC to provide automated recovery capabilities. EMC GDDR s main activities include: Managing planned site swaps (workload and DASD) between the primary and secondary sites and recovering the SRDF /SQAR with AutoSwap environment. Managing planned site swaps (DASD only) between the primary and secondary sites and recovering the SRDF/SQAR with AutoSwap environment. Managing recovery from a single or dual planned or unplanned site outage in one region, with local SRDF/S protection established differentially between the recovery sites in another region. Out of region recovery is supported with cascaded or concurrent SRDF to an available out of region site. Managing the recovery of the SRDF environment and restarting SRDF /A (asynchronous remote replication) in the event of an unplanned site swap. Active monitoring of the managed environment and responding to exception conditions. Reset/IPL of z/os systems at remote site. Testing disaster recovery from BCVs at remote site. Testing disaster recovery from R2 at remote site. 22 EMC GDDR Version 4.2 Product Guide

23 Product Overview Major features EMC GDDR successfully undertakes these activities by exploiting the following major features: Situational awareness Survivor recognition Situational awareness Survivor recognition Leadership nomination EMC GDDR can distinguish normal operational disruptions from disasters and respond accordingly. For example, EMC GDDR is able to distinguish between network outages (SRDF link drop) and real disasters. This awareness is achieved by periodic exchange of dual-direction heartbeats between the EMC GDDR Control Systems (C-Systems). EMC GDDR can determine which sites and systems have survived a disaster. Unlike the foundation technologies (such as TimeFinder /Mirror or TimeFinder/Clone Mainframe Snap Facility), EMC GDDR has built-in intelligence to monitor other EMC GDDR systems. EMC GDDR constantly checks for disaster situations and constantly ensures that other GDDR systems are healthy. This checking allows EMC GDDR to recognize and act on potential disaster situations, even if only one EMC GDDR system survives. Split brain problems associated with cluster technologies are avoided through operator prompts. Upon the initial recognition stage, EMC GDDR issues messages to the operator console seeking confirmation of the event and confirmation of restart actions required. If a local or regional disaster occurs, EMC GDDR can determine which of the surviving sites will execute the recovery. The EMC GDDR Master Control System (C-System) operates in a Master Owner/ No-Owner role for other EMC GDDR C-Systems. In a four-site topology, the EMC GDDR Master C-System would normally reside at the DC2 (Data Center) location. However, if the DC2 location is destroyed or the EMC GDDR C-System itself fails, one of the surviving GDDR C-Systems assumes the role of the EMC GDDR Master. Changes to EMC GDDR configuration information can only be made on the EMC GDDR Master Control System (C-System). EMC GDDR propagates these changes to the GDDR-managed systems using the GDDR inter-system communications feature. Restart procedures following disasters are coordinated from the EMC GDDR Master C-System. EMC GDDR coordinates and executes predetermined processes to: Restart the enterprise at the desired surviving site in the event of a disaster Automate a planned site swap Major features 23

24 Product Overview Additional capabilities As part of the planned site swap process and as part of the recovery process after an unplanned site swap, EMC GDDR can optionally perform the following tasks: Trigger stopping or starting distributed workloads Trigger stopping or starting z/os workloads in multiple sysplexes in parallel Types of environment EMC GDDR can manage environments that are comprised of the following elements: Multiple z/os systems Multiple sysplexes Multiple Symmetrix controllers Intermix of CKD and FBA/FBAM DASD and BCVs Supported business continuity configurations An EMC GDDR site is a physical location, housing CPU or DASD or both, where: Data Center DC1 is part of all supported EMC GDDR configurations DC2 is a site connected to DC1 with SRDF/S DC3 is a site connected to DC1 with SRDF/A, either actively or as a recovery connection DC4 is a site connected to DC2 with SRDF/A, either actively or as a recovery connection EMC GDDR is available in the following configurations: SRDF/S with ConGroup The 2-site SRDF/S with ConGroup configuration provides disaster restart capabilities at site DC2. SRDF/S with AutoSwap The 2-site SRDF/S with AutoSwap configuration provides for near-continuous availability through device failover between DC1 and DC2. SRDF/A The 2-site SRDF/A configuration provides disaster restart capabilities at site DC3. SRDF/Star The 3-site SRDF/Star configuration provides disaster restart capabilities at either DC2 or DC3. Concurrent and cascaded SRDF support further minimize the DC3 recovery time objective. SRDF/Star with AutoSwap The 3-site SRDF/Star with AutoSwap configuration provides for near-continuous availability through device failover between DC1 and DC2 as well as disaster restart capabilities at DC3. Concurrent and cascaded SRDF support further minimize the DC3 recovery time objective. Note: Cascaded SRDF/ Star configurations, with or without AutoSwap, can be dynamically reconfigured back and forth between concurrent and cascaded data flow, and can have R22 devices at DC3. 24 EMC GDDR Version 4.2 Product Guide

25 Product Overview SRDF/SQAR with AutoSwap The 4-site SRDF/SQAR with AutoSwap configuration provides for near-continuous availability through device failover between DC1 and DC2, within Region 1; as well as disaster restart capabilities at Region 2 with DC3 and DC4 located an extended geographical distance away from Region 1. SRDF concurrent or cascaded replication protects data originating from the recovery site following a primary region outage. EMC GDDR has been designed to be customized to operate in any of these configurations. EMC GDDR functionality is controlled by a parameter library. During EMC GDDR implementation, this parameter library is customized to reflect: The prerequisite software stack The desired data center topology (two, three, or four sites, synchronous or asynchronous). The data centers in Region 1 are referred to as sites DC1 and DC2; data centers in Region 2 are referred to as sites DC3 and DC4. SRDF/SQAR with AutoSwap configuration EMC GDDR is able to control multiple sysplexes from a single GDDR Control System. This document discusses the EMC GDDR SRDF/SQAR with AutoSwap configuration. Documentation for other EMC GDDR configurations is available on the EMC Online Support site. SRDF/SQAR (Symmetrix Quadrilateral Asynchronous Replication) is a four-site implementation of SRDF/S and SRDF/A that enables differential resynchronization between sites along the perimeter of a 'square' multi-site SRDF topology. Its principle objective is to meet the requirement for a multi-region high availability and disaster restart solution. EMC GDDR support for the SRDF/SQAR configuration provides the ability to recover from a single or dual unplanned site outage in one region, with local SRDF/S protection established differentially between the recovery sites in another region. This enables you to meet the requirement of quickly resuming a workload with SRDF/S and AutoSwap protection in another region. In certain failure scenarios it also provides zero data loss disaster recovery across regions. Supported business continuity configurations 25

26 Product Overview Primary Site, Site A Secondary Site, Site B DC1 AutoSwap AutoSwap DC2 Region 1 Primary Region EMC GDDR EMC GDDR DC1 DASD R11 SRDF/S R21 DC2 DASD DC3 DC4 R21 SRDF/S R22 Region 2 EMC GDDR EMC GDDR Secondary Region DC3 DASD AutoSwap AutoSwap DC4 DASD Tertiary Site, Site C FICON channel (Active) FICON channel (Inactive) MSC Groups Host IP Link (Active) Host IP Link (Inactive) SRDF Link (Active) SRDF Link (Inactive) Quaternary Site, Site D Figure 1 SRDF/SQAR with AutoSwap environment Figure 1 shows the four EMC GDDR C-Systems with their independent heartbeat communication paths, separate from the production disk and computer facilities. Each of the managed z/os systems has EMC AutoSwap and EMC Consistency Group (ConGroup) installed. As Figure 1 shows, each GDDR SRDF/SQAR environment manages two consistency groups and two Multi-Session Consistency (MSC) groups. A consistency group is a named group of source (R1) volumes managed by the EMC Consistency Group (ConGroup) application as a unit. An MSC group is a named group, consisting of multiple RDF groups operating in SRDF/A mode, managed by the EMC MSC control software feature as a single unit. The relationship between the Site A, DC1 and Site B, DC2 is maintained through SRDF/Synchronous replication of primary disk images at DC1 to DC2, while SRDF/Asynchronous replication maintains out of region mirrored data at Site C, DC3 and Site D, DC4. 26 EMC GDDR Version 4.2 Product Guide

27 Product Overview Minimum software requirements The following EMC software components are needed to run GDDR SRDF/SQAR. The following Mainframe Enablers functionality is required: SRDF/Host Component ResourcePak Base with SRDF/A multi-session consistency (MSC) Consistency Group AutoSwap SRDF/SQAR design features and restrictions Enginuity level 5876 or higher is required in all Symmetrix systems. SRDF/SQAR is required to be configured with the MSC High Availability feature with a second SCF instance and MSC configured using weight factor =2. Host Component actions which change the devices defined to SQAR MSC groups require the MSC tasks to be down at the time of the change. Connectivity is provided only along the perimeter of the SQAR topology. Cross-site connectivity (A>D, B>C) is not supported. Differential resynchronization is only allowed along the perimeter of the SQAR topology. A>D and B>C connectivity is not supported. Therefore, traditional 3-site SRDF/Star as a recovery configuration is not supported. In the case of a single site failure it is important to know which SRDF/A site is more current. The existing SRDF/A secondary time of day value is used to determine which site is ahead. Terminology: physical and logical Figure 2 illustrates the designations used to describe the physical configuration of an SRDF/SQAR topology. These designations do not change as a result of planned or unplanned events. The concept of a region is introduced in the SRDF/SQAR configuration. The SRDF/SQAR configuration features two regions which are interconnected using SRDF/A and are typically separated by a large distance. Within each region there are two sites that are connected via SRDF/S intra-region. Region 1 DC1 R11 SRDF/S R21 DC2 SRDF/A SRDF/A DC3 R21 SRDF/S R22 DC4 Region 2 Figure 2 Physical designations in SRDF/SQAR topology Supported business continuity configurations 27

28 Product Overview Figure 3 illustrates the designations that are used to describe the SRDF/SQAR logical environment. Sites can change roles during planned or unplanned site and /or region swaps. The role of a site is described as Primary, Secondary, Tertiary, or Quaternary, referenced using the corresponding letters A, B, C, and D respectively. Primary Region Site A Primary R11 SRDF/S Secondary R21 Site B SRDF/A SRDF/A Secondary Region Site C R21 SRDF/S R22 Site D Tertiary Quaternary Figure 3 Logical designations in SRDF/SQAR topology For example, if Site A experienced an outage, recovery can occur at Site B within the primary region or at either Site C or Site D in the secondary region, using data current to the point of disaster from Site B. If a regional outage occurred, recovery can occur at Site C or D. In this case the primary site will move to one of the Region 2 sites and become Site A. This is described in detail in the planned and unplanned operational scenarios section. Configuration rules Symmetrix systems and SRDF groups As shown in Figure 4, it is permissible to have varying numbers of Symmetrix systems connecting the sites. However, the number of asynchronous (SRDF/A) groups configured for the two SQAR groups must be equal. Further, the number of SYNC and recovery groups cannot be more than the number of asynchronous groups. Only one SQAR configuration (two related MSC SQAR groups) are allowed in a single MSC environment. Figure 4 Symmetrix and SRDF group asymmetries 28 EMC GDDR Version 4.2 Product Guide

29 Product Overview Devices All devices protected in SQAR mode must be replicated DC1-> DC2, DC1-> DC3, DC2 -> DC4, and DC3-> DC4. It is not allowed to have more devices replicated with SRDF/S then with SRDF/A, or more devices replicated in SRDF/A than with SRDF/S. Operational scenarios Figure 5 SRDF/SQAR operations and SDDF session management Normal operation The behavior of SRDF/SQAR is similar to that of SRDF/Star during normal operation. The algorithm for establishing and sustaining normal SQAR operations with consistency requires (as a starting point) an active synchronous SRDF relationship between sites A and B with zero invalid tracks, and two active SRDF/A relationships, A>C and B>D, each with zero invalid tracks and each exporting a positive SRDF/A consistency indication. The SRDF/S mirror (A -> B) of the R11 devices for the MSC GroupA will be Consistency Group protected. If a Consistency Group trip occurs, MSC Group B will be dropped. Cycle switching will continue for MSC Group A, but SDDF management will be suspended (due to the dropping of B>D). SQAR processing will return to normal if MSC Group B is restarted and ConGroup is resumed. Two SDDF sessions each at Sites C and D are used to track changes that are owed to other sites to ensure the minimally necessary amount of data is transferred during resync operations. These bitmaps are periodically rotated and cleared after two cycle switches have occurred in each SRDF/A leg. SDDF session management The objective of SDDF session management is to maintain the knowledge in each site of the data which that site has locally that the opposite site may not have. The periodic clearing and rotating of SDDF sessions at both sites optimizes the amount of data moved Supported business continuity configurations 29

30 Product Overview during a differential resynchronization by only moving tracks that may have changed at one site and not the other. This allows for a differential resynchronization that moves the least amount of data. There are two MSC host subtasks (one per MSC Group), as shown in Figure 5, independently monitoring and driving the cycle switch processing of the A>C and B>D MSC groups. These tasks run in the same SCF address space. Each MSC subtask has two main functions: Perform SRDF/A cycle switching on one leg of the SQAR Manage the SDDF sessions on the opposite leg's SRDF/A R2 volumes There are two SDDF sessions each at Sites C and D. Each session will be in one of two states (active or inactive) and will toggle between these states under the control of one MSC subtask. In short, the SDDF sessions serve as SQAR's 'memory' of what data a site has received that may not be at the opposite site. The specific meaning of the SDDF session's bits is as follows: Site C: Data that Site C has that may not be at D Site D: Data that Site D has that may not be at C A given MSC subtask, MSCGA for example, is responsible for performing SRDF/A cycle switching for one leg of the SQAR (MSCGA), and for ensuring that SDDF sessions on the SRDF/A R2 of other leg (cycle switched by the MSCGB subtask) reflect the fact that data has successfully arrived at the SRDF/A R2 under control of the MSCGA subtask. MSCGA does this by clearing bits in the inactive session on MSCGB's SRDF/A R2 once MSCGA has completed at least two cycle switches on its own leg. Following the clearing of the inactive session, the SDDF sessions are rotated making the active session 'inactive' and the inactive session 'active'. The MSCGA subtask knows after executing at least two cycle switches what data has reached Site C and based on this definitive knowledge has the right to clear the inactive SDDF session in D because it knows whatever data is in the inactive SDDF session at Site D has already arrived at Site C. As part of the session rotations, the inactive SDDF session is now cleared and made active and, in the event of a subsequent disaster, any data tracked in both of Site D's SDDF sessions must be data that Site D has which may not be at Site C. These bits represent tracks that must therefore become part of a differential resynchronization to make devices at Sites C and D equivalent. Conversely, the MSCGB subtask will rotate and clear the inactive SDDF session in Site C once it has completed at least two cycle switches because it knows the data is in Site D. As in SRDF/Star, the SRDF/A cycle switching is only loosely coupled with the SDDF session management in that SDDF session management only occurs after at least two cycle switches, but need not occur every two cycle switches When SDDF processing is fully enabled for both SQAR groups, message SCF1630I (SQAR Recovery is now available) is issued. SQAR mode is indicated by the x'02' flag in the first byte of the Cycle Tag, which will be set when SQAR Recovery becomes available. The x'80' and x'40' bits indicating R2 Consistency are common to MSC and are a prerequisite to Recovery. Therefore, the first byte of the Cycle Tag will be x'c2' when SQAR Recovery is available. 30 EMC GDDR Version 4.2 Product Guide

31 Product Overview Recovery and resynchronization In the event of an unplanned outage requiring the restart of the production workload at another region, you must make two independent determinations: 1) which site is to be the new primary site and 2) which site has the most current data. Data currency is determined by the SRDF/A secondary time of day value. GDDR will interrogate this time and present you with this information to guide the decision on resynchronization direction. The data to be resynchronized is determined by performing an inclusive OR of all the SDDF bitmaps among the arrays and instructing the array with the most current data to mark the resulting set of tracks remotely invalid and all other sites to mark them locally invalid. Normal SRDF differential resynchronization follows. High availability support EMC GDDR support of SRDF/SQAR provides the high availability takeover feature for the MSC task with the MSC TAKEOVER command initiating a takeover operation for both SQAR groups. In the event of the loss of the Primary MSC task a Secondary MSC task will take over the cycle switch and SDDF session management of the SQAR configuration, becoming the Primary MSC task in the same manner as was done with SRDF/Star. Supported scenarios This section describes some of the planned and unplanned scenarios that are supported in SRDF/SQAR. The link states are shown for each link and the 'LB' indicates a link block state on one mirror of an R22 device. Note that only a subset of scenarios in planned and unplanned outage cases are presented here to give you a sense of the capabilities included in SRDF/SQAR. The starting point for normal operation is as follows: Supported business continuity configurations 31

32 Product Overview Figure 6 Initial state of SRDF/SQAR Planned scenarios Examples of planned scenarios follow. The term 'primary site' refers to the one site in a SQAR configuration that contains only R1 mirrors (refer to Figure 3 on page 28). Note how the logical site and region roles change in the scenarios but the physical site and region names remain constant: 1: Inter-region swap Primary/secondary and tertiary/quaternary sites swap regions (configuration rotates on horizontal axis). Two cases are shown with the primary site at DC3 or DC4. Refer to Figure 6 for the initial state. Figure 7 SRDF/SQAR inter-region swap (1 of 2) Figure 8 SRDF/SQAR inter-region swap (2 of 2) 32 EMC GDDR Version 4.2 Product Guide

33 Product Overview 2: Intra-region swap Primary/secondary and tertiary/quaternary sites swap (config rotates on vertical axis) Figure 9 SRDF/SQAR intra-region swap Unplanned scenarios Examples of several unplanned scenarios follow. Refer to Figure 6 on page 32 for the initial state and note that the logical site roles change in the scenarios but the physical site names remain constant. 3a: Site A failure Recover at Site C. Protect to C>D(sync) and D>B(async). GDDR blocks this recovery scenario if site C does not have the most recent data. Region 1 A XR11 R2 B SRDF/A C R1 SRDF/S R21 D Region 2 Figure 10 SRDF/SQAR site A failure (1 of 2) Supported business continuity configurations 33

34 Product Overview 3b:Site A failure Recover at Site D (using B data drained to D). Protect to C(sync) and B(async) Region 1 A XR11 R2 B SRDF/A C R2 SRDF/S R11 D Region 2 Figure 11 SRDF/SQAR site A failure (2 of 2) Case 4a: Primary Region failure Recover at C, protect to D using latest copy of data Region 1 A R11 R2 B C R1 SRDF/S R2 D Region 2 Figure 12 SRDF/SQAR Primary Region failure (1 of 2) 34 EMC GDDR Version 4.2 Product Guide

35 Product Overview Case 4b: Region 1 Workload failure Recover at D, protect to C using latest copy of data Region 1 A R11 R2 B C R2 SRDF/S R1 D Region 2 Figure 13 SRDF/SQAR Primary Region failure (2 of 2) Supported business continuity configurations 35

36 Product Overview EMC GDDR fundamentals This section discusses: Control systems Workload location Managed workloads EMC GDDR processes Control systems The EMC GDDR control systems are more commonly referred to as EMC GDDR C-Systems. One EMC GDDR C-System is located at each site (DC1, DC2, DC3, and DC4). C-Systems must be configured as standalone systems by specifying either XCFLOCAL or MONOPLEX in PARMLIB's IEASYS PLEXCFG parameter (XCFLOCAL is recommended). This enables the C systems to avoid SFM sysplex timer failure recovery operations and allows the C systems to continue operations during sysplex timer recovery operations. Each EMC GDDR C-System runs as a standalone z/os system from local DASD. EMC suggests that you locate the C-System DASD on separate controllers from the production DASD. Because the EMC software applications run from local C-System volumes, this separation ensures that the C-Systems are not affected by any events that may impact the availability of the managed systems. The main functions of a EMC GDDR C-System are to: Control the recovery after an outage Control a planned site swap EMC GDDR C-Systems do not run any production workload. One of the C-Systems is the Master C-System. During normal operations, the Master C-System is the central control point for all EMC GDDR activities. The Master C-System is located at the secondary DASD site. This ensures that, in the event of losing the primary DASD site, the Master C-System survives to coordinate recovery. If the Master C-System becomes unavailable for some reason, a C-System at another location/site assumes the EMC GDDR master function ownership. When the original Master C-System becomes available, the master function ownership automatically transfers back to the correct location. Some EMC GDDR functions can only be carried out by the Master C-System, for example: Running planned processes Updating EMC GDDR parameters All EMC GDDR C-Systems are potential candidates to takeover as the Master C-System. 36 EMC GDDR Version 4.2 Product Guide

37 Product Overview Workload location In an EMC GDDR Complex, the business or production workload can run as either: A single site workload All production workload runs at a single site only; that is, one side of the sysplex. This is normally the same location as the primary DASD site. A multi-site workload Production workload runs at both the primary and secondary sites. Production system A production system is a managed system that normally runs the site s workload and updates the primary DASD. Production systems are typically located at the same location as the primary DASD. Contingency or standby system A contingency or standby system is a managed system that normally provides a hot backup to a production system.a contingency system: May be in a geographically distanced region equipped with processor capacity reserved for support of business workload restarts. Multiple locations containing contingency or standby systems may be used to increase availability and provide disaster restart options. Regional contingency systems are typically located in the same location as the secondary DASD, while out-of-region standby systems provide protection from geographic and infrastructure exposures that may negatively impact the primary and secondary sites. Recovery LPAR Managed systems As previously described, contingency systems provide a way to move a workload from one system to a different system. Recovery LPARs provide a way to run the same system in two different locations at different times. A recovery LPAR is located on the same CPC, or on a different CPC, at the same site or at a different site. If a system is defined with a recovery LPAR then an additional recovery option is presented to the operators when such a system is lost. Managed systems can have a contingency system as well as a recovery LPAR. Any production or contingency/standby system defined to EMC GDDR is known as an EMC GDDR managed system. Managed workloads EMC GDDR can trigger the stop and restart of production workloads on: z/os systems Distributed systems EMC GDDR fundamentals 37

38 Product Overview External workloads External workloads run in mainframe systems which do not have their DASD in the managed Symmetrix units. EMC GDDR can coordinate Stop and Start of the workload on these "non-managed" mainframe systems with the workload Stop and Start for managed systems. Excluded systems EMC GDDR can be configured to exclude certain systems from workload management, although these systems have their DASD in the managed Symmetrix units. HMC-only systems EMC GDDR can be configured to limit IPL and CBU actions for certain systems to the online interface. No other actions or automation are performed for these systems. Note: Overview of EMC GDDR-managed system types on page 62 provides more information about how systems are specified. HMC Bypass feature EMC GDDR processes If the site where GDDR is running is under management of a third-party facility provider, GDDR offers the HMC Bypass feature, by site and by LPAR to prevent GDDR HMC interaction with all or selected LPARs at that site. An EMC GDDR process is a predetermined sequence of function calls. Generally one function call corresponds to one action. An EMC GDDR process is started by calling EMC GDDR provided routines, either from a batch job or as a result of specific messages being issued. There are two types of EMC GDDR processes: Planned process An EMC GDDR planned process is initiated through the EMC GDDR interface to perform a planned task. The planned process encompasses planned swap, reconfiguration, resumption, and test processes. Unplanned process/takeover process The EMC GDDR unplanned process or takeover process can only be initiated following an error that results in a possible takeover situation. Takeover processes are initiated as a result of certain messages being issued or specific events occurring. The messages or events that trigger an unplanned or takeover process can originate on any system, either a C-System or a production system. They only take place on the current Master C-System. 38 EMC GDDR Version 4.2 Product Guide

39 Product Overview They are invoked automatically after any of the following types of failure or loss are detected: Sites DASD Systems Loss of SRDF link Loss of host channels Process restart The return codes from the function calls that make up an EMC GDDR process are saved in GDDR global variables. For functions that issue EMC SRDF Host Component commands, the return code of the commands is also saved. If multiple commands are issued from one function, the return codes from each command are saved in GDDR global variables. EMC GDDR components After the cause of the original failure has been identified and resolved, the EMC GDDR process can be rerun. EMC GDDR uses the saved return codes to establish the point of restart; that is, the point of the previous failure. This ensures that no modifications to the supplied EMC GDDR process jobs are required in order to rerun after a failure. EMC GDDR is comprised of a number of components: Parameters User interface Events Monitors Message rules Parameters EMC GDDR parameters define the environment and configuration that it manages. The parameters can modify the sequence of function calls that is an EMC GDDR process. User interface The EMC GDDR user interface is an ISPF application. It is available only on EMC GDDR C-Systems. Events An EMC GDDR event is a change in state of a component part of the environment that EMC GDDR is actively monitoring. Examples of EMC GDDR events include: CGT ConGroup trip has occurred/state change CGD ConGroup group is disabled/state change EMC GDDR components 39

40 Product Overview SRA SRDF/A link is down MHB missing C-System heartbeat The event can have a state of either TRUE or FALSE. If the event has a state of TRUE, it has occurred or is currently occurring. If the event has a state of FALSE, it is no longer occurring. An event that is TRUE is considered an exception. EMC GDDR events are used by the GDDR event monitor and GDDR processes to determine environment state. A change in state can then: Trigger unplanned/takeover processes Prevent a planned process from running Monitors There are two monitors on each EMC GDDR C-System: The EMC GDDR event monitor The EMC GDDR heartbeat monitor Event monitor The EMC GDDR event monitor runs on each C-System and is used to analyze event state changes in which EMC GDDR is interested. On detecting the occurrence of selected events, the event monitor determines what action to take and prompts operators with the appropriate choices. The Event Monitor verifies the status of SRDF, ConGroup, and MSC operation on a user-defined interval. GDDR produces messages for integration with user automation that indicate when a GDDR event changes state. (OFF to ON, or ON to OFF). Table 13, Monitored events, on page 206 provides a detailed description of GDDR-monitored events. Certain software operating states are monitored and communicated solely through messages. Message rules enable certain messages of interest to be forwarded to managed systems where user automation can then react to the problem. Table 14, Software state analysis messages, on page 208 provides detailed descriptions of state analysis messages. Examples of the usage of messages for the monitored operating states are: MSC and ConGroup Analysis SDDF Analysis SRDF/A Analysis RDF Group and Link analysis Loss of DASD access Loss of Site Heartbeat monitor The EMC GDDR heartbeat monitor aids the event monitor in determining the status of the EMC GDDR managed environment. The lack of a heartbeat from a particular C-System is used to determine the state of a C-System and the site. 40 EMC GDDR Version 4.2 Product Guide

41 Product Overview Message interception rules EMC GDDR is supplied with message interception rules to be installed on the GDDR C-Systems and GDDR-managed systems. The message interception rules have two primary functions: To detect events that EMC GDDR is interested in and set the appropriate EMC GDDR event TRUE or FALSE. To detect events that EMC GDDR processes have to wait for (WTOR), and reply as to the success or failure of the waited for event. This will determine if an EMC GDDR process proceeds or terminates. EMC GDDR uses the z/os MCSOPER facility to monitor the GDDR-managed systems for messages of interest. The GDDRMAIN tasks which are installed on the EMC GDDR C-Systems and the GDDR-managed systems perform the communication function to route message traffic to or from production systems. You or EMC service personnel can use the arrival of a message at the target production system to trigger an automation rule (for example using Computer Associates OPS/MVS Event Management and Automation, IBM Tivoli NetView, or BMC Control-M ). Such rules can be used to start or shut down workloads on the appropriate systems. DYNAPI interface The EMC GDDR interface to EMC DYNAPI allows EMC GDDR to run dynamic SRDF commands in parallel. EMC GDDR supported scripts EMC GDDR provides a number of scripts that allow you to perform any of the following actions: Planned event management Test event management Unplanned event management Resumption of replication after SRDF link outages Regional disaster operations Special actions Planned event management Operations personnel can handle planned event management scenarios by running any of the following scripts. Note: DC1 and DC2 represent the current primary DASD site or current secondary DASD site and DC3 and DC4 represent the tertiary and quaternary DASD sites. When these representations are shown in italic type in script titles, this indicates the values are interchangeable. The descriptions assume that DC1 is the Primary DASD site and Primary site at the beginning of the script. EMC GDDR supported scripts 41

42 Product Overview Automated Configuration Check - DASD - GDDRPCCD Use this script as part of the pre-script checkup before any GDDR script is run. Review the GDDRPCCD script joblog for GDDP4** 'E' level messages, and resolve reported discrepancies before starting a planned, test or resumption script. This script performs the following actions: Discovers Symmetrix devices in a set of defined Symmetrix units and RDF groups Validates existing RDF.DEVICES and DLM.DEVICES parameters and other configuration global variables against the discovered DASD configuration and against GDDMPARM information Abandon Region RG1 (site swap) - GDD2P17A Abandon Secondary Site (DC2 ) - GDDRPA60 (Site maintenance) Abandon Tertiary Site (DC3 ) - GDDRPA60 (Site Maintenance) Abandon Quaternary Site (DC4 ) - GDDRPA60 (Site Maintenance) The GDDRPA60 scripts allow operations personnel to take down any site in the configuration for maintenance purposes. For configurations with AutoSwap, note the following considerations when using GDDRPA60 to abandon the secondary DASD site: The Master C-System and the AutoSwap owner are co-located on the Secondary DASD site. If the configuration has MSC, then the Primary MSC Server is also located on the Secondary DASD site. For the Abandon Secondary Site script GDDRPA60, you must take the required actions in advance to move all these roles to the Primary DASD site. Use the GDDR scripts (GDDRPXMC, GDDRPXAS, GDDRMMSC, GDDRPA36) to perform these moves. Swap production from DC1 to DC2 - GDDRPA42 This script swaps the single-site workload from the primary DASD site to the secondary DASD site. This script performs the following actions: Stops the business workload at the primary DASD site Swaps the DASD to the secondary DASD site (AutoSwap followed by SRDF/S personality swap) Swaps the Primary and Secondary MSC Server Roles when SQAR High Availability is implemented. Resumes SRDF/S Restarts the business workload Reestablishes the SRDF/SQAR with AutoSwap environment Swap DASD from DC1 to DC2 - GDDRPA21 This script swaps only the DASD from the primary DASD site to the secondary DASD site. 42 EMC GDDR Version 4.2 Product Guide

43 Product Overview Test event management Perform test IPL from BCVs at DC3/DC4 - GDD2P01A Splits BCVs, makes them R/W Activates test LPARs and IPLs test z/os systems using BCV volumes Starts test business workload, if applicable Resume after test IPL from BCVs at DC3DC4 - GDD2P02A Stops test business workload, if applicable Reset clears test system LPARs Reestablishes the BCVs Perform test IPL from R2s at DC3/DC4 - GDDRPA27 Perform test IPL from R2s at DC2 - GDD2P03A Confirms that SRDF/A has been stopped normally via an SRDF/A PENDDROP Activates LPARs and IPLs test z/os systems using R2 volumes Starts test business workload, if applicable Resume after test IPL from R2s at DC2 - GDD2P16A Stops test business workload, if applicable Reset clears test system LPARs Restarts SRDF/S to DC2 Restart SRDF/S with AutoSwap to DC2 Resume SRDF/A after test IPL at DC3/DC4 - GDDRPA28 This script restores the SRDF/A link to DC3 or DC4 (either from DC1 or DC2 depending upon where the production workload is currently running) after a test on DC3 or DC4. This script performs the following tasks: Reset clears all systems IPLed during the test Deactivates all LPARs previously activated for the test Restarts SRDF/SQAR with AutoSwap Unplanned event management Operations personnel can manage unplanned events in one of two ways: The EMC GDDR Event Monitor prompts the operator for management confirmation of trigger events which indicate a site or DASD outage. The operator replies affirmative to the prompt and the GDDR recovery script starts. The operator may start the appropriate unplanned script and respond to prompts. The script initiates and validates that the state of the current host and storage environments matches the script prerequisites before proceeding. EMC GDDR supported scripts 43

44 Product Overview Recover after unplanned swap - GDDRUP31 This script performs the following restart actions after an unplanned swap has completed successfully: SRDF/S preferred version (default) GDDR determines whether this recovery type is possible. Note: if not, then the SRDF/A preferred recovery is performed Performs the required HSWAP operations for an intra-region site swap Splits BCVs at DC1 Resumes synchronous replication from DC2 to DC1 Starts ConGroup Starts workload at DC2 (if applicable) Splits BCVs at DC3 Resumes SRDF/A from DC1 to DC3 Switches MSC definitions, preserving SQAR mode of operation Moves AutoSwap owner to DC1 Manages couple datasets and CF Structures (if applicable) Re-establishes BCVs at DC1 and DC3 Transfers Master C to DC1 SRDF/A preferred version This version requires you to run script GDDRPA0A at a later time, to resume synchronous replication from DC2 to DC1 Performs HSWAP operations at DC2, DC3, and DC4 Starts workload at DC2 (if applicable) Manages couple datasets and CF Structures (if applicable) Recover after loss of DC1 (LDR) - GDD2U13A Loss of DC1 can occur through a sequence of events which may occur in different order. From a data protection perspective, there are two important sequences: Type 1: loss of channel access occurs first, then replication is lost Type 2: remote replication is lost first, then channel access is lost GDD2U13A covers both scenarios. GDDR blocks this script if DC3 has more recent data. Warn user about potential data loss Stop workload at DC1 (if applicable) Perform HSWAP operations at DC2, DC3 and DC4 Split BCVs at DC4 (Type 2 only) Resume replication DC2 to DC4 (Type 2 only) Start SRDF/A in MSC mode, DC2 to DC4 Reestablishes BCVs at DC4 (Type 2 only) Start workload at DC2 (if applicable) Manages couple datasets and CF Structures (if applicable) 44 EMC GDDR Version 4.2 Product Guide

45 Product Overview Resume replication after unplanned swap - GDDRPA0A This script resumes the SRDF/S link to the secondary DASD site after an unplanned swap (due to the loss of the primary DASD). This script performs the following activities: HSWAP at DC1 Split BCVs at DC1 Resume SRDF/S from DC2 to DC1 Start ConGroup Split BCVs at DC3 Resume replication DC1 to DC3 Activate SRDF/A DC1 to DC3 Swap SQAR mode definitions Transfer AutoSwap owner to DC1 Reestablish the SQAR with AutoSwap environment Reestablish BCVs at DC1 and DC3 Move Master C to DC1 Resume replication after loss of DC1 - GDDRPA0A HSWAP at DC1 Split BCVs at DC1 Resume SRDF/S from DC2 to DC1 Start ConGroup Split BCVs at DC3 Resume replication DC1 to DC3 Activate SRDF/A DC1 to DC3 Deactivate old MSC environment Transfer AutoSwap owner to DC1 Reestablish the SQAR with AutoSwap environment Reestablish BCVs at DC1 and DC3 Move Master C to DC1 Resumption of replication after SRDF link outages Operations personnel can resume operations after planned or unplanned outages by running any of the following scripts. Resume SRDF/S replication after ConGroup trip - GDDRPA23 This script resumes SRDF/S replication and reestablishes the BCVs at the secondary DASD site if applicable. EMC GDDR supported scripts 45

46 Product Overview Resume SRDF/A in SQAR mode - GDDRPF29 This script restores the SRDF/A links after a planned or unplanned stop of SRDF/A. Resume SRDF/A in MSC mode to DC3/DC4 - GDDRPM29 This script restores the SRDF/A link to DC3 in MSC mode (from either DC1 or DC2 depending upon where the production workload is currently running) after a planned or unplanned swap. Reclaim Secondary site (DC2) - GDDRPA65 Reclaim Tertiary site (DC3) - GDDRPA65 Reclaim Quaternary site (DC4) - GDDRPA65 The GDDRPA65 scripts allow operations personnel to restore normal operations after a site has been abandoned for maintenance. For configurations with AutoSwap, note the following considerations when using GDDRPA65 to reclaim the secondary DASD site: Before running this script, the Master C-system must be moved to the Secondary DASD site. After the script completes, the AutoSwap owner must be moved to the Secondary DASD site. If the configuration has MSC, then the Primary MSC Server must also be moved to the Secondary DASD site. GDDR offers scripts (GDDRPXMC, GDDRPXAS, GDDRMMSC) to perform these moves. Regional disaster operations Operations personnel can initiate secondary region operations by running any of the following scripts. Recover at DC3/DC4 after RDR at DC1 and DC2 - GDDRPA05 This script should only be run if there is a regional disaster which causes outages at both DC1 and DC2 or if DC1 and DC2 have been abandoned using the GDD2P17A script. It activates LPARs and restarts the production z/os systems at the chosen site. The script can be run using either DC3 or DC4 for single site recovery, or using DC3 or DC4 as SRDF/S source site, using DC4 or DC3 as SRDF/S target site. If SRDF/S is desired, you are presented with an option to drain data from the site with the most recent data, limited to DC3 and DC4. This script performs the following actions: Activates all needed LPARs Activates CBU (if required) Creates a consistency point at DC3 or DC4 Prepares SRDF environment IPLs all needed production systems Restart production at DC3/DC4 SRDF/A to DC1/DC2 - GDDRPA06 This script should only be run if there is a major failure that prevents the production workload from being run from either DC1 or DC2. It restarts the production z/os systems at the chosen site and reestablishes SRDF/A to the primary region. 46 EMC GDDR Version 4.2 Product Guide

47 Product Overview GDDRPA06 is available in four variations in SRDF/SQAR configurations: DC3 source site, with cascaded replication DC3 -> DC4 and DC4 -> DC2 DC3 source site, with concurrent replication, DC3 -> DC4 and DC3 -> DC1 DC4 source site, with cascaded replication DC4 -> DC3 and DC3 -> DC1 DC4 source site, with concurrent replication DC4 - > DC3 and DC4 -> DC2 This script performs the following actions: Activates all needed LPARs Activates CBU (if required) Creates a consistency point at DC3 or DC4 Prepares SRDF environment IPLs all needed production systems Starts SRDF/A in MSC mode Recover at DC3 with Cascaded replication DC3 -> DC4, DC4 -> DC2 - GDDRPA07 Recover at DC4 with Concurrent replication DC4 -> DC3, DC4 -> DC2 - GDDRPA07 Choose one of these scripts to run if there is a local disaster that prevents the production workload from being run from DC1. These scripts restart the production LPARs at the chosen site and reestablishes SRDF/A to the DC2 site. Note that GDDRPA07 with cascaded replication is not allowed unless DC3 (site C) has the most recent data. These scripts perform the following actions: Activates all needed LPARs including CFs Activates CBU (if required) Creates a consistency point Prepares SRDF environment IPLs all needed production systems Starts SRDF/A in MSC mode EMC GDDR supported scripts 47

48 Product Overview Special actions Planned STAR-HA Takeover - GDDRPA36 Unplanned STAR-HA Takeover - GDDRUP35 Restart Secondary MSC Server at <DCx> - GDDRPA36 Restart primary MSC server at <DCx> - GDDRMMSC Transfer AutoSwap Owner to <DCx> - GDDRPXAS Transfer Master C System to <DCx> - GDDRPXMC Global Variable Backup - GDDRPGVB Move systems to alternate CPC - GDDRMCPC Parameter Load wizard: Telling EMC GDDR what to manage The environment that EMC GDDR manages is described to EMC GDDR through a collection of common variables. The EMC GDDR Parameter Load wizard groups these variables in a series of ISPF panels, each backed by a member in a PDS. For the initial setup of EMC GDDR, it is strongly recommended that you go through the entire series of panels at least once to become familiar with all the required and optional features of EMC GDDR, and to ensure that all defined elements are in agreement with the desired behavior of the product. The variable groups include the following: Configuration-defining variables These variables define the type of managed configuration, the C-systems, the initial role for each site, the consistency group names and the MSC group names. Storage object variables These variables define the actual SRDF and TimeFinder devices, SRDF groups, and gatekeeper devices that form the configuration that EMC GDDR will manage. Host object variables These variables define the managed, external and HMC-only systems, and their LPARs, system recovery attributes, IPL-parameters and CPCs. Host object variables also define HMC consoles, sysplex objects and EMC Mainframe Enablers started tasks. GDDR option variables These variables define user-selectable values for a variety of actions taken in the course of GDDR automation sequences. GDDR option variables also define site defaults for JCL and utilities used by GDDR, messaging options, and tuning values. 48 EMC GDDR Version 4.2 Product Guide

49 CHAPTER 2 Installing EMC GDDR Invisible Body Tag This chapter describes the EMC GDDR installation procedure. Preinstallation tasks Installation procedure Post-installation tasks Installing EMC GDDR 49

50 Installing EMC GDDR Preinstallation tasks Mainframe environment requirements Before you begin installing EMC GDDR, review the hardware and software requirements listed next. The basic infrastructure must support SRDF/SQAR with AutoSwap. In addition to this, EMC GDDR has the following specific infrastructure requirements: There must be network connectivity between all C-Systems. An HMC (Hardware Management Console) must be available at each site that can be accessed from each C-System (access to these HMCs can be protected by means of a private VLAN). EMC GDDR has the mainframe environment requirements listed in Table 1. Before you install EMC GDDR, make sure your environment meets these requirements. Table 1 Mainframe environment requirements Item Processor hardware configuration DASD hardware configuration Software Requirements Any system that supports current IBM mainframe operating systems Any supported Symmetrix DASD model at an Enginuity level specified in the EMC GDDR Release Notes Any currently supported IBM operating system Minimum software requirements The minimum software prerequisites needed to run EMC GDDR 4.2 are as follows: z/os SRDF/Host Component ResourcePak Base with SRDF/A multi-session consistency (MSC) Consistency Group AutoSwap BCPii The IBM Base Control Program internal interface (BCPii) is supported if the GDDR C-Systems are using z/os 1.10 or a later release. In addition, the CPC must be a z9 or higher (BC or EC). Appendix E, BCPii Interface, provides additional information. The z/os level of the managed systems is not a consideration for the use of BCPii for HMC operations. BCPii operations are conducted on the CPC named in GDDRMAIN control statements. That CPC may or may not host a C-system, but it must host some system running GDDRMAIN (C-System or production system). Note: The MCL levels that must be met are explained in the BCPii chapter of the MVS Programming Callable Services for High Level Languages document (SA ). 50 EMC GDDR Version 4.2 Product Guide

51 Installing EMC GDDR Additional configuration requirements Note: The EMC GDDR Release Notes provide information regarding supported software release levels for the previous items. You can find installation procedures for the EMC software products in the EMC Mainframe Enablers Installation and Customization Guide. SRDF/SQAR with AutoSwap has the following additional requirements: CAX protection must be added to the SRDF/SQAR-defined ConGroups. LOSTOWNERPOLICY ONSWAP=OPERATOR must be specified. The EMC Consistency Group for z/os Product Guide and EMC AutoSwap for z/os Product Guide provide information on these items. In addition, there must be one or more gatekeeper devices for each MSC-controlled RDF group. These gatekeeper devices must be: Not SRDF/S-protected Not ConGroup and CAX-protected Not SRDF/A-protected For CKD, in OS configuration as OFFLINE at IPL SRDF/SQAR configurations do not support external devices on the SRDF/S leg. External devices are managed by GDDR but are outside of the SQAR-protected devices. Restrictions Minimum hardware requirements This initial release of SRDF/SQAR with AutoSwap does not support SRDF dynamic device reconfiguration. Further, SRDF Host Component actions which change the devices defined to SQAR MSC groups require the MSC tasks to be down at the time of the change. Table 2 describes the recommended minimum processor and I/O configuration for an EMC GDDR C-System. Table 2 Minimum hardware requirements Item Logical processors MSU Storage Requirements 1 (2 are recommended) 15 on a IBM (or equivalent) 512 MB Logical paths to own local DASD devices 4 Logical paths to managed DASD devices 4 Note: EMC recommends separate channels for EMC GDDR-managed storage gatekeepers and production gatekeeper functions. Preinstallation tasks 51

52 Installing EMC GDDR DASD support EMC GDDR supports and can manage the following combinations of DASD: Single EMC Symmetrix controllers configured with any of the following: All CKD devices All FBA and FBA-META devices Any combination of CKD, FBA and FBA-META devices Multiple EMC Symmetrix controllers configured with any of the following: Installation procedure Before you begin All CKD devices All FBA and FBA-META devices Any combination of CKD, FBA and FBA-META devices Management and monitoring of both CKD and FBA/FBA-META devices is performed from the z/os platform where the EMC GDDR application resides. From the EMC GDDR point of view, CKD and FBA/FBA-META Symmetrix devices are the same; that is, each is treated no differently than the other. They are all command targets of SRDF Host Component configuration commands using local, remote or GNS syntax. EMC GDDR requires that if even only one device in an RDF group is defined to GDDR, then all devices in that group must be defined to GDDR. Most GDDR actions are directed at the RDF group level (although in some cases, GDDR will act on device ranges if that is appropriate). EMC GDDR has no limitations on the number of EMC Symmetrix controllers/devices that can be managed. Any limitations are subject to restrictions in EMC hardware and software. This section describes how to install EMC GDDR. The EMC GDDR installation kit is provided as an electronic download from EMC Online Support. The procedure for the EMC GDDR installation is as follows for each EMC GDDR C-System: Table 3 Installation tasks Task 1. Review pre-installation information Reference Preinstallation tasks on page 50 and Gather EMC GDDR installation information on page Install EMC GDDR Install EMC GDDR on page EMC GDDR Version 4.2 Product Guide

53 Installing EMC GDDR Gather EMC GDDR installation information Before beginning the EMC GDDR installation, you need to gather information in preparation for the installation. Identify or decide upon the following items: CLIST library and EDIT macro Determine a name for the edit macro created by the installation dialog. You also need to determine the name of a CLIST library where you can store the edit macro. Product dataset name prefix Choose the dataset prefix you will use to install EMC GDDR. Names for the product datasets consist of a final qualifier, such as LINKLIB, and a dataset prefix. For example, if you choose a dataset prefix of EMC.GDDRvrm, the LINKLIB dataset will be named EMC.GDDRvrm.LINKLIB. Ensure that you have RACF ALTER authority (or the equivalent from another security manager) for the datasets created with this dataset prefix. Note: Throughout this guide, datasets created using this dataset prefix are referred to as if they had been created with the suggested value. The actual fmid for your installation may be different. ResourcePak Base dataset name prefix Specify the dataset name prefix you used when you install ResourcePak Base. EMC recommends that you use EMC.fmid if it agrees with your site standards. SMP/E dataset name prefix Choose the name prefix for the SMP/E datasets into which you installed EMC GDDR. If you have installed another EMC product using SMP/E, you should install EMC GDDR into the same CSI. If you are installing an EMC SMP/E maintained product for the first time, EMC recommends using EMC.SMPE. SMP/E datasets volser Choose the disk volume onto which you will install the distribution libraries required by SMP/E. This may be the same volume you use for the product libraries. However, many customer sites prefer to keep SMP/E-related datasets on separate volumes from product libraries. An amount of space similar to that needed for the product libraries is required. Install-to-disk volser Determine the disk volume onto which you will install the target (that is, runtime) datasets. The space required is nominal. EMC suggests that you use EMC.fmid if it agrees with your site standards. Disk unit name Decide upon a disk unit name for the above volumes. For many users, SYSDA will suffice. However, use whatever generic or esoteric name your local standards require. Installation procedure 53

54 Installing EMC GDDR Install EMC GDDR Load GDDRvrm.XMITFILE to disk The EMC GDDR kit consists of a PDS containing TSO TRANSMIT images of files needed to perform an SMP/E indirect-library installation. This PDS is packaged on CD or as an electronic download from EMC Online Support. To install EMC GDDR on an EMC GDDR control system, take the following steps: 1. Load the TSO TRANSMIT file, GDDRvrm.XMITLIB, to the mainframe disk. 2. Run GDDRvrm.XMITLIB(#EXTRACT) to extract ds-prefix.rimlib and the SMP/E indirect libraries. 3. Customize the RIMLIB JCL. 4. Run the installation jobs. 5. Perform cleanup. 6. Apply maintenance updates. The following sections describe these steps in more detail. 1. Take one of the following steps: If you are installing EMC GDDR from a CD, complete the following steps: a. Mount the CD on an open system host. b. Allocate a working directory on the open system for the installation. c. Copy the contents of the CD to the working directory. If you are installing EMC GDDR from an EMC Online Support download, complete the following steps: a. Log in to a privileged account on an open systems host (root on UNIX or administrator on Windows). b. Allocate a working directory on the open system for the installation. c. Log on to EMC Online Support. d. Navigate to Downloads > Geographically Dispersed Disaster Restart (GDDR). Note: If you are not able to access this location, you may not have registered your software or registered it incorrectly. Follow the prompts to register your software, correct your registration, or contact EMC in the event of a problem. e. Click the product version you want to download. The product version consists of a zip file that contains the installation kit and the installation instructions. f. Download the installation kit into the working directory. 2. If your current host is a Windows system, unzip the file in the working directory. If your current host is a UNIX system, unzip and untar the file into the working directory. 54 EMC GDDR Version 4.2 Product Guide

55 Installing EMC GDDR 3. Locate GDDRvrm.XMITFILE. This file is in TSO TRANSMIT format and contains a flattened copy of GDDRvrm.XMITLIB, a PDS that holds other TRANSMIT images, the JCL to extract them, and necessary SMP/E installation files. 4. On the target mainframe, allocate a file to which you can FTP GDDRvrm.XMITFILE. Use the dataset name prefix you intend to use for product installation. The final qualifier must be XMITFILE. For example, if you intend to install the product with a dataset name prefix of EMC.GDDRvrm, name the file EMC.GDDRvrm.XMITFILE. Allocate the dataset with the following characteristics: LRECL=80 BLKSIZE=3120 DSORG=PS SPACE=(CYL,(44,2)) Note: The SPACE parameter assumes that you are allocating the dataset on a 3390 device. 5. FTP the file to the mainframe in binary format. Your FTP session may look something like the following: ftp hostname (username and password prompts) cd.. 25 is working directory name prefix binary 200 Representation type is image put GDDRvrm.XMITFILE EMC.GDDRvrm.XMITFILE 6. Use TSO RECEIVE to receive the file into a PDS. The PDS is created by the RECEIVE command and does not have to be pre allocated. However, you must specify a dataset name using the DA[taset] parameter or the file will be allocated using your TSO prefix (usually your logonid). The dataset name specified must have the final qualifier of XMITLIB. For example: receive indataset( EMC.GDDRvrm.XMITFILE ) INMR901I Dataset EMC.GDDRvrm.XMITLIB from userid on nodename INMR906A Enter restore parameters or DELETE or END + da( EMC.GDDRvrm.XMITFILE ) If you did not specify DA( ) as above, the dataset would be allocated as userid.xmitlib. Installation procedure 55

56 Installing EMC GDDR Run GDDRvrm.XMITLIB(#EXTRACT) Customize the RIMLIB JCL Now run GDDRvrm.XMITLIB(#EXTRACT) to extract ds-preface.rimlib and the SMP/E indirect libraries. Take the following steps: 1. Edit the #EXTRACT member of the newly RECEIVED library. You can edit the #EXTRACT job by running the SETUP REXX program you can find in the XMITLIB dataset. The SETUP REXX program prompts you for all of the information needed to edit the job. If you wish to edit the job manually, make the following changes: Change the JOB card to one that conforms to your standards. Globally change ds-prefix to the dataset prefix of this library (which will be the dataset prefix for the product libraries). Globally change DVOL to the disk volser onto which you want to place the extracted libraries. Globally change DISK-UNIT to an esoteric unit name such as SYSDA that is appropriate for your site. 2. Submit #EXTRACT. Step completion codes should be 0, except for the DELETE step, which will have a step completion code of 8 unless the job is a rerun. The RIMLIB library (<ds-prefix>.rimlib) is a PDS containing JCL to install the product. After you extract the RIMLIB PDS, you find that RIMLIB has the contents shown in Table 4. Table 4 RIMLIB library contents File #01ALLOC #02DDDEF #03RECEV #04APPLY #05ACCPT #06CLEAN #91HFS #92CMHFS #93HWMCA #99MAINT GDRJCL GDRWIN1 SETUP Contents Allocate target and distribution libraries Add or replace product library DDDEFS to SMP/E CSI SMP/E RECEIVE function into global zone SMP/E APPLY function into target zone SMP/E ACCEPT product sysmods into distribution zone Deletes indirect libraries and DDDEFs used for them Allocate and MOUNT the HFS dataset Copy the USSEXEC modules to the HFS dataset and set the proper attributes of each module Copy the HWMCAAPI file downloaded from IBM to the GDDR HFS dataset SMP/E RECEIVE and APPLY service REXX to customize the install process ISPF panel used in REXX install process REXX to simplify the customization process Complete the following steps to customize the installation JCL using the automated dialog: 56 EMC GDDR Version 4.2 Product Guide

57 Installing EMC GDDR 1. Edit the RIMLIB library (ds-prefix.rimlib). 2. Locate the member named SETUP on the member selection list and type EX in the selection column next to it and press Enter. Menu Functions Confirm Utilities Help EDIT EMC.GDDRvrm.RIMLIB Row of Command ===> Scroll ===> CSR Name Prompt Size Created Changed ID #01ALLOC 45 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #02DDDEF 51 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #03RECEV 22 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #04APPLY 22 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #05ACCPT 22 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #06CLEAN 53 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #91HFS 33 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #92CMHFS 48 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #93HWMCA 45 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring #99MAINT 27 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring GDRJCL 206 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring GDRWIN1 51 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring ex SETUP 13 yyyy/mm/dd yyyy/mm/dd hh:mm:ss idstring **End** Result: The panel shown in Figure 14 appears EMC JCL Customization Utility COMMAND ==> Type EXEC on the command line and press ENTER to proceed, or PF3 to exit. CLIST library ==> 'hlq.gddrvrm.rimlib' Edit macro name ==> GDR Product dsname prefix ==> hlq.gddrvrm Mainframe Enablers dsname prefix ==> hlq.mfevrm SMP/E dsname prefix ==> EMC.SMPE SMP/E datasets volser ==> Install-to disk volser==> Disk unit name ==> SYSDA Enter your job card below ('%MEMBER%' will be replaced by member name): => //%MEMBER% JOB MSGCLASS=A,CLASS=A,MSGLEVEL=(1,1) Figure 14 EMC JCL customization utility 3. Enter or change the following information on the panel shown in Figure 14 to customize your installation: a. The CLIST library field is set by default to the name of the RIMLIB library. This field should contain the name of a library in which you want the edit macro created by this dialog to be stored. The default value is fine for most users and need not be changed. b. In the Edit macro name field, either: Accept the default name displayed. or If necessary, change the name of the edit macro. Installation procedure 57

58 Installing EMC GDDR Note: Normally, you should not have to change the name. Result: The edit macro is created in the CLIST library from the data entered on this panel and applied to all members of RIMLIB that start with a # character. c. In the Product dsname prefix field, enter the dataset name prefix you want to use for the target datasets. EMC suggests hlq.gddrvrm. d. In the SMP/E dsname prefix field, enter the dataset name prefix of the SMP/E datasets into which you installed EMC GDDR. For example, if you called the SMPSCDS dataset EMC.SMPE.SMPSCDS, enter EMC.SMPE. e. In the SMP/E datasets volser field, enter the six-character volume serial number of the disk volume on which you want to allocate the SMP/E distribution libraries for EMC GDDR. This volume may be the same as the volume you specify in the next step, or you may elect to keep these datasets on a separate volume. f. In the Install-to disk volser field, enter the six-character volume serial number of the disk volume to which you want to install the EMC GDDR libraries. g. In the Disk unit name field, you can specify an esoteric disk name that is appropriate to your site. SYSDA is the default, but you can overtype it with another esoteric disk name. h. Enter a site-appropriate job card. The job card is initially set to a value which may be suitable to many users. The first seven characters of the job name is set to your TSO userid, plus X. You can set the job name to %MEMBER%. This causes the edit macro to set each job name equal to the JCL member name (that is, #01ALLOC, #02DDDEF, and so forth). Do not use any parameter that contains an ampersand (&), such as NOTIFY=&SYSUID. An ampersand in the job card can cause edit macro errors. Figure 15 shows an example of a completed panel as the user is about to press Enter and complete the dialog EMC JCL Customization Utility COMMAND ==> Type EXEC on the command line and press ENTER to proceed, or PF3 to exit. CLIST library ==> 'EMC.GDDR420.RIMLIB' Edit macro name ==> GDR Product dsname prefix ==> EMC.GDDR420 Mainframe Enablers dsname prefix ==> EMC.MFE760 SMP/E dsname prefix ==> EMC.SMPE SMP/E datasets volser ==> Install-to disk volser==> AAP005 Disk unit name ==> SYSDA Enter your job card below ('%MEMBER%' will be replaced by member name): => //%MEMBER% JOB MSGCLASS=A,CLASS=A,MSGLEVEL=(1,1) Figure 15 EMC JCL customization utility completed panel 58 EMC GDDR Version 4.2 Product Guide

59 Installing EMC GDDR Run the installation jobs 4. When you are satisfied with your entries, type exec on the command line and press Enter. Result: If the dialog completes successfully, you see something similar to the following: BUILDING AN EDIT MACRO(GD) IN 'EMC.GDDRvrm.RIMLIB' PROCESSING MEMBER: #01ALLOC PROCESSING MEMBER: #02DDDEF PROCESSING MEMBER: #03RECEV PROCESSING MEMBER: #04APPLY PROCESSING MEMBER: #05ACCPT PROCESSING MEMBER: #06CLEAN PROCESSING MEMBER: #91HFS PROCESSING MEMBER: #92CMHFS PROCESSING MEMBER: #93HWMCA PROCESSING MEMBER: #99MAINT *** Carefully examine each job before you submit it to make sure that it was customized the way you intended. Submit the customized jobs in the following order, making sure that each job completes successfully before submitting the next one: 1. #01ALLOC 2. #02DDDEF 3. #03RECEV 4. #04APPLY You should expect completion codes of 0 (zero) for all jobs except for #02DDDEF, where 04 is acceptable if this is a new installation rather than an upgrade. If your testing results are positive, run #05ACCPT to update the distribution libraries and zone. The #05ACCPT job completes with an RC=04. This is normal for the SMP/E ACCEPT process. You can ignore it. SMP/E installation is now complete. Cleanup After you are satisfied that EMC GDDR is correctly installed and functioning properly, run the #06CLEAN job to delete datasets and DDDEFs used during the installation process that are no longer needed. Apply maintenance updates If you have received maintenance cover letters from EMC or have instructions to apply maintenance from EMC support personnel, use the supplied job #99MAINT. This job receives and applies APARs and PTFs. This job may require further customization before you run it, depending on the nature of the maintenance. Note: Do not attempt to apply maintenance until the EMC GDDR ACCEPT job has completed successfully and then only if instructed to do so by EMC Customer Service. Installation procedure 59

60 Installing EMC GDDR Post-installation tasks Complete the maintenance update by running the GDDR SMP/E post-maintenance job. The post-maintenance job interrogates the SMP/E CSI dataset, extracts the PTF name, and builds a replacement GDDR Primary Options Menu panel containing the PTF number in the maintenance level of the GDDR Release.Version.Maintenance variable. A replacement GDDR Primary Options Menu Help panel provides the means to display detailed information about the contents of the maintenance release. Refer to Appendix F, SMP/E Post-Maintenance Procedure, for assistance. Having completed the SMP/E installation steps, several more tasks remain to complete the installation of EMC GDDR. These tasks are described in detail in Chapter 3, Integrating EMC GDDR. 60 EMC GDDR Version 4.2 Product Guide

61 CHAPTER 3 Integrating EMC GDDR This chapter describes customization procedures for EMC GDDR. Overview of EMC GDDR-managed system types Integration tasks GDDR installation and user BPX authorization (optional) HFS file and directory customization Update system parameter files Create parameter members for SRDF Host Component on C-Systems Edit SCF initialization parameters Authorize the EMC Consistency Group started task to use the trip API Perform ConGroup configuration Perform ConGroup Started Task automated startup Perform MSC configuration Specify EMC GDDR security Define EMC GDDR datasets Install EMC GDDR started procedures Configure EMC GDDR Optional configuration features Integrating EMC GDDR 61

62 Integrating EMC GDDR Overview of EMC GDDR-managed system types In addition to C-Systems, there are four different types of systems defined to EMC GDDR: Production or test systems and their optional contingency systems Excluded systems HMC only systems External workload systems These systems are referred to as EMC GDDR-managed systems within this document. Production or test systems and their optional contingency systems These systems benefit from the full set of EMC GDDR systems management features, and require that GDDRMAIN be running on these systems at all times: These systems run from the EMC GDDR-managed DASD. EMC GDDR triggers the start and stop of the business workload during GDDR scripts. EMC GDDR performs Stop/Start ConGroup operations on these systems if Call_Override bytes 08/09 are true. These systems can be IPLed, reset, activated, or deactivated during certain scripts. These systems can be protected using the LPAR Recovery feature and can participate in CPC (Central Processor Complex) swaps. These systems can be managed from the Perform HMC LPAR Actions panel. EMC GDDR can perform CBU actions, in scripts or in panels, for the CPCs on which these systems run. EMC GDDR manages or simulates the management of couple datasets and CF Structures for these systems, if they are in a sysplex. Note the following requirements: These systems must be specified in GDDMPARM COMM parameters. The Define Managed Systems panel must have an entry for each system. These systems must have CPC and LPAR defined for them. These systems must have IPL parameters defined for them. These systems must have Mainframe Enabler STCs defined for them. Excluded systems These are mainframe systems running from the EMC GDDR-managed DASD. EMC GDDR performs Stop/Start ConGroup on these systems if Call_Override bytes 08/09 are true. EMC GDDR does not trigger Start/Stop of workload for these systems. EMC GDDR does not perform HMC LPAR actions for these systems during scripts, but they are listed on the GDDR HMC LPAR Actions panel. 62 EMC GDDR Version 4.2 Product Guide

63 Integrating EMC GDDR The excluded systems appear on the Define Managed Systems panel as "Manage Workload=NO". These systems can be specified in GDDMPARM COMM parameters. These systems can have CPC and LPAR defined for them. These systems can have Mainframe Enabler STCs defined for them. Note: The above three items are required if you intend to use the ConGroup Stop/Start method (Call_Override bytes 08/09 = 1). You can add or delete these systems from the Define Managed Systems panel, unless they are specified in GDDMPARM COMM parameters. HMC only systems The only functionality for these systems is ACT/DEACT/LOAD/RESET actions performed from within the GDDR HMC LPAR Actions panel. To facilitate auto-discovery, EMC recommends that these systems be defined in GDDMPARM. These systems must have CPC and LPAR defined. These systems must have IPL parameters defined. You can add or delete these systems from the Define Managed Systems panel, unless they are specified in GDDMPARM COMM parameters. External workload systems Coupling facility LPARs This category of systems appears on the Define External Workloads panel. These systems have very limited support. These are mainframe systems; they are not running from the EMC GDDR-managed DASD. However, when EMC GDDR triggers stop/start workload for managed systems, these systems will be included as well. The only functionality for these systems is ACT/DEACT actions performed from within scripts and the GDDR HMC LPAR Actions panel. For activation, coupling facility (CF) LPARs come first. During deactivation, CF LPARs are processed following all others. Exactly one CF LPAR is included on the Define Managed LPARs panel associated with the system flagged CF LPAR 'YES' on the Define Managed Systems panel, for the Home site of the system. CF LPARs cannot have a Recovery LPAR defined at another site. There are no IPL parameters associated with CF LPARs. There is no COMM statement defined for CF LPARs in GDDMPARM. Overview of EMC GDDR-managed system types 63

64 Integrating EMC GDDR Integration tasks Once you have completed the SMP/E installation steps, complete the tasks described in the following sections before using EMC GDDR: GDDR installation and user BPX authorization (optional) on page 64 HFS file and directory customization on page 65 Update system parameter files on page 66 Create parameter members for SRDF Host Component on C-Systems on page 69 Edit SCF initialization parameters on page 71 Authorize the EMC Consistency Group started task to use the trip API on page 71 Perform ConGroup Started Task automated startup on page 72 Perform MSC configuration on page 74 Specify EMC GDDR security on page 77 Define EMC GDDR datasets on page 88 Install EMC GDDR started procedures on page 89 Configure EMC GDDR on page 102 These changes, with the exception of the GDDR-managed system security definitions and started task installation, are made on the EMC GDDR C-Systems only. GDDR installation and user BPX authorization (optional) If your site has previously secured BPX for OMVS usage, the following authorizations are required to complete the steps shown in HFS file and directory customization and to allow EMC GDDR users to perform operations that use OMVS facilities. Use of the OMVS extended attribute command (extattr) requires authorization as described by the following RACF commands: RDEFINE FACILITY BPX.FILEATTR.PROGCTL UACC(NONE) PERMIT BPX.FILEATTR.PROGCTL CLASS(FACILITY) ID(your-user-ID) ACCESS(READ) Where your-user-id is the ID of the installer. Access to this facility is needed to set the extended attributes on the gddrc* OMVS programs. This is completed at installation by the job in the #91HFS RIMLIB member. This command is included in the SAMPLIB(GDDCRACF) member. 64 EMC GDDR Version 4.2 Product Guide

65 Integrating EMC GDDR HFS file and directory customization 1. Customize and submit #91HFS RIMLIB job. This job allocates the Hierarchical File System (HFS) and creates the GDDR USS directories. 2. Customize and submit the #92CMHFS RIMLIB job. In #92CMHFS, the variable name USS-PATH is the USS module installation path which is also supplied on the GDDR Utility Parameters panel, USS module installation path field. If not supplied during the parameter load process, the default is /usr/gddr. This job copies the USS executables from the installation USSEXEC data set to the directory created by step 1 above. On completion of the job, check that the p attribute (program-controlled) has been added to the USS executables by listing the directory file contents - ls -l. Note: RIMLIB jobs #91HFS, #92CMHFS, and #93HWMCA require appropriate user authorization to create root-level OMVS directories and to modify USS executable attributes. 3. From select Support & Downloads > Support by product >Systems and servers, url = a. Select System z. b. Sign on with a valid IBM Resource Link userid and password. c. Select "Services". d. Under the heading "Servers; Mainframe", select API. e. Under the heading "API Code Library by Platform", select z/os. f. Select and download IBM Hardware Management Console (HMC) API. 4. Customize and submit the #93HWMCA RIMLIB job. This job copies the HMCWAAPI DLL from the download target dataset to the GDDR HFS directory specified by 'USS-PATH'. 5. After #93HWMCA completes successfully, log on to the OMVS environment and issue the following commands: su <===== sets super user authority chmod 755 /USS-PATH/g* <===== sets access permissions for the HMC API programs 6. Repeat these commands on each C-System. USS and pre-requisite HFS setup is required for the HMC Message Scanner. The purpose of the message scanner is to automate, during GDDR scripts, the IPL process of GDDR-managed systems until customer automation takes control. HFS file and directory customization 65

66 Integrating EMC GDDR Update system parameter files Perform the following system parameter file updates. SYS1.PARMLIB( BPXPRMxx ) customization Add the following mount to the BPXPRMxx member of SYS1.PARMLIB: SYS1.PARMLIB(IKJTSOxx) customization MOUNT FILESYSTEM(' gddr_hfs_dataset_name ') MOUNTPOINT('/USS-PATH') TYPE(HFS) MODE(RDWR) Where gddr_hfs_dataset_name is the name of the EMC GDDR HFS dataset allocated and filled during the installation process. 1. Confirm that the following entries exist in AUTHCMD, AUTHPGM, and AUTHTSF lists. Add any missing entries to the IKJTSOxx member of SYS1.PARMLIB of each C-System. 66 EMC GDDR Version 4.2 Product Guide

67 Integrating EMC GDDR To AUTHCMD add entries: SCFRDFME SCFRDFM6 EHCMSCM9 SCFRDFM9 EHCMSCME EHCMSCM6 To AUTHPGM add entries: GDDFLIST GDDRDAP1 GDDRDAP3 GDDRXCMD GDDRSTAT GDDRSSVI GDDRQFCN GDDRCGTP GDDRSTOK GDDRQRY5 GDDRQRY6 SCFRDFME SCFRDFM6 EHCMSCM9 EMCTF ECGCLEAN EHCMSCM6 EHCMSCME SCFRDFM9 ECGUTIL To AUTHTSF add entries: GDDBCPC2 GDDBCPC3 GDDBCPD2 GDDBCPE2 GDDBCPL2 GDDBCPQ2 GDDBCPS2 GDDRXMPS GDDRAWTZ GDDRFC1X GDDRINF2 GDDRMCS1 GDDRXYZ2 GDDRQDE2 GDDRQDE3 GDDRQDE4 GDDRQDE5 GDDRQDE6 GDDRQDE7 GDDRQDE8 GDDRQDE9 GDDRQDEA GDDRQDEB GDDRQDEC GDDRQDED GDDRQDEE GDDRQDEF GDDRQDEG /* EMC ME utility /* EMC M6 utility /* EMC M9 utility /* EMC M9 utility /* EMC ME utility /* EMC M6 utility /* SDDF list utility /* GDDR /* GDDR /* GDDR /* GDDR check for presence of an active task /* Initialize GDDR command queue /* Manipulate GDDR command queue /* GDDR - ConGroup communication /* GDDR /* GDDR /* GDDR /* EMC ME utility /* EMC M6 utility /* EMC M9 utility /* EMC TimeFinder Mirror /* EMC ConGroup cleanup utility /* EMC M6 MSC cleanup utility /* EMC ME MSC cleanup utility /* EMC M9 utility /* EMC ConGroup 6.4 cleanup utility /* BCPII AUTH CONNECT /* BCPII AUTH COMMAND /* BCPII AUTH DISCONNECT /* BCPII AUTH EVENT /* BCPII AUTH LIST /* BCPII AUTH QUERY /* BCPII AUTH SET /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR /* GDDR */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ + */ 2. Activate this change using an IPL or dynamically change by using the TSO PARMLIB UPDATE(xx) command. Update system parameter files 67

68 Integrating EMC GDDR TSO logon customization APF authorization 1. You may need to increase the region size of TSO logon procedures that use the GDDR user interface and batch jobs that run GDDR scripts. EMC recommends allocating a TSO logon proc region of 2,100,000, as a starting point. 2. Ensure that TSO logon procs of all TSO users who wish to run the GDDR ISPF user interface contain a SYSEXEC DD which points to hlq.gddrvrm.rcxfe. This library is allocated during installation. APF-authorize the hlq.mfevrm.linklib and hlq.gddrvrm.linklib libraries. LINKLIB and REXX parameter file installation Note: If your site prefers to reference hlq.gddrvrm.linklib and hlq.mfevrm.linklib by using STEPLIB DD statements, then you can skip the LINKLIST and REXX parameter file customization procedures. Customize LINKLIST EMC GDDR version 4.2 uses a REXX function package named GDDFUSER with an alias of IRXFUSER.4.2 IRXFUSER is a placeholder in SYS1.LINKLIB, providing flexibility for customization of REXX function packages. You have several choices for installation, depending on whether you have applications using previously customized REXX function packages on GDDR C-Systems and GDDR-managed systems. These instructions apply to each C-System and each GDDR-managed system on which GDDRMAIN is to be installed. If no applications use previously customized REXX function packages, or there are applications which use STEPLIB DD statements to reference a customized REXX function package module, then only follow the directions provided with Customize LINKLIST below. If customized REXX function packages named IRXFUSER accessed via the LINKLIST exist on one or more GDDR-managed systems or C-Systems, perform the steps listed in Customize LINKLIST below and Customize REXX parameter files on page Delete the placeholder IRXFUSER module from SYS1.LINKLIB. 2. Add hlq.mfevrm.linklib and hlq.gddrvrm.linklib to the LINKLIST using one of the following methods: Add the following LNKLST entries in a PROGxx member: LNKLST ADD NAME(LNKLST) DSN(hlq.MFEvrm.LINKLIB) LNKLST ADD NAME(LNKLST) DSN(hlq.GDDRvrm.LINKLIB) or Add the following entries in a LNKLSTxx member: hlq.mfevrm.linklib(vvvvvv) hlq.gddrvrm.linklib(vvvvvv) 68 EMC GDDR Version 4.2 Product Guide

69 Integrating EMC GDDR In these entries, vrm is the current EMC GDDR version, release, modification identifier and vvvvvv is the volser where the hlq.gddrvrm.linklib dataset resides. The volser specification is only required if the dataset is not cataloged in the master catalog. 3. Replace hlq.gddrvrm.linklib with the dsname of the EMC GDDR LINKLIB SMP/E target library allocated and filled during the installation process. Activate this change using one of the following methods: IPL Customize REXX parameter files Issue the SET PROG=xx command Issue the SETPROG LINKLIST,ADD command This procedure is used when there is an application using previously customized REXX function packages not accessed by a STEPLIB DD statement. The application has already taken advantage of the placeholder aspect of IRXFUSER in SYS1.LINKLIB, so additional steps are required to ensure the EMC GDDR uses the proper function package named GDDFUSER, without the alias IRXFUSER. 1. Add GDDFUSER to the three REXX parameter files used in establishing the REXX processing environment. Before you begin, create a backup copy of the files. The REXX parameter files to be edited are: IRXPARMS for REXX under MVS IRSTSPRM for REXX under TSO IRXISPRM for REXX under ISPF 2. Place the newly assembled versions of IRXPARMS, IRXISPRM, and IRXTSPRM into SYS1.LPALIB overlaying the default members. For more information, refer to the TSO/E REXX Reference SA , chapter Language Processing Environments, subtopic Changing the default values for initializing an environment. Create parameter members for SRDF Host Component on C-Systems During planned and unplanned Swap scripts, EMC GDDR uses a utility named in the Utility.IEBGENER GDDR parameter to copy the appropriate parameter member over the currently used SRDF Host Component RDFPARM member. The hlq.gddr.vrm.samplib members with the names listed below must be created in the PDS pointed to by the RDF entries within the Define EMC Mainframe Enablers STCs panel, Option E: Define EMC MF Enablers STCs on page 171. These members contain complete and identical SRDF Host Component initialization parameters, but are different with respect to MSC group definition, as described in Table 5. Create parameter members for SRDF Host Component on C-Systems 69

70 Integrating EMC GDDR Note: Many of these members define MSC gatekeeper devices. Avoid using these gatekeepers elsewhere in the GDDR-managed configuration. Table 5 SRDF Host Component parameter members Member SITEQR1 SITHQR1 SITEQR2 SITHQR2 Description Defines SRDF/SQAR mode, Current Primary Region = 1, WF=0 Defines SRDF/SQAR-mode, Current Primary Region = 1, WF=2 Defines SRDF/SQAR-mode, Current Primary Region = 2, WF=0 Defines SRDF/SQAR-mode, Current Primary Region = 2, WF=2 The following are needed for the out-of-region recovery scripts with SRDF/A and in cases where SRDF/A cannot be resumed in SQAR mode, for example, after LDR at DC1 or when the links required for the RCVRY groups are unavailable: SITEUQC1 Defines an MSC group in MSC-Only mode, Current Primary Region = 1, DC1-DC3 leg, WF=0 SITHUQC1 Defines an MSC group in MSC-Only mode, Current Primary Region = 1, DC1-DC3 leg, WF=2 SITEUQC2 Defines an MSC group in MSC-Only mode, Current Primary Region = 1, DC2-DC4 leg, WF=0 SITHUQC2 Defines an MSC group in MSC-Only mode, Current Primary Region = 1, DC2-DC4 leg, WF=2 SITEUQC3 Defines an MSC group in MSC-Only mode, Current Primary Region = 2, DC3-DC1 leg, WF=0 SITHUQC3 Defines an MSC group in MSC-Only mode, Current Primary Region = 2, DC3-DC1 leg, WF=2 SITEUQC4 Defines an MSC group in MSC-Only mode, Current Primary Region = 2, DC4-DC2 leg, WF=0 SITHUQC4 Defines an MSC group in MSC-Only mode, Current Primary Region = 2, DC4-DC2 leg, WF=2 Note: The members listed above must be created on each C-system, in a PDS pointed to on the Define Mainframe Enablers STCs GDDR Parameter Load wizard panel. This panel defines one additional member (default: SRDFSTAR) which is actively used by the Host Component instance on the specified C-system. 70 EMC GDDR Version 4.2 Product Guide

71 Integrating EMC GDDR Edit SCF initialization parameters On each EMC GDDR-managed host and C-System, make sure the following SCF parameters are set correctly: Ensure that SCF.MSC.ADCOPY.ONDROP is set to NO. (This is the default setting for this parameter.) Setting this parameter to NO eliminates a potential conflict between EMC GDDR processing and SRDF Host Component actions following EMC GDDR actions to stop SRDF/A during planned or unplanned operations. Ensure that SCF.MSC.ENABLE is set to NO. Setting this parameter to NO prevents accidental MSC activation when software is recycled outside the control of EMC GDDR. The EMC Mainframe Enablers software, SCF in particular, is never stopped on the Master C-System. For a planned shutdown of the Master C-System, use option T, Transfer Master C-System on the GDDR Setup and Maintenance menu to move the Master-C function. Use the GDDRPXAS Transfer AutoSwap Owner script and the GDDRPA36, Planned Star-HA Takeover script, found on the Select Script Run panel under the Special scripts heading to move the AutoSwap owner and the MSC control function to the non-master C-System at the primary or secondary site. When the original Master C-System is restarted, move the applicable control functions back to it. If these guidelines are followed, EMC GDDR will ensure MSC is enabled when and where needed for its automation purposes. Ensure that SCF.MSC.OVERWRITE is set to YES to allow EMC GDDR to overwrite an existing MSC environment when required during an EMC GDDR automation sequence. Ensure that SCF.CSC.VERBOSE is set to YES. This setting enables additional messaging required for the proper detection of the loss of an EMC GDDR-managed system. Authorize the EMC Consistency Group started task to use the trip API Ensure that the user authorized to the ConGroup started tasks on the EMC GDDR C-Systems is also authorized with READ access to the EMC.CG.API.TRIP facility class. The authorization commands are: RDEFINE FACILITY EMC.CG.API.TRIP UACC(NONE) PERMIT EMC.CG.API.TRIP CLASS(FACILITY) ID(uuuuuuu) ACCESS(READ) Where uuuuuuu is the Userid assigned to the ConGroup STC on the C-systems at DC1 and DC2. Note: Appendix A of the EMC Consistency Groups for z/os Product Guide provides detailed instructions. Edit SCF initialization parameters 71

72 Integrating EMC GDDR Perform ConGroup configuration The following configuration parameters apply to EMC GDDR installation in SRDF/SQAR with AutoSwap environments. ConGroup parameter members for C-Systems as well as managed systems at DC1 and DC2 must be identical, and specify as owner, the SMFID for the C-System at DC2. ConGroup parameter members for C-Systems as well as managed systems at DC3 and DC4 must be identical, and specify as owner, the SMFID for the C-System at DC4. Specify the MODE ConGroup parameter with the MULTI keyword. Use of the MULTI keyword enables the use of an internal lock, ALL-CONGROUPS to serialize many global operations to ensure the integrity of ConGroup's functionality. Refer to the EMC Consistency Group for z/os Product Guide for more information about these configuration parameters. Perform ConGroup Started Task automated startup By default, EMC GDDR does not perform ConGroup Stop/Start commands to refresh ConGroup parameters. There are two exceptions: You can use the call override described below to force GDDR to perform stop/start instead of using the REFRESH command. In out-of-region recovery scenarios the ConGroup STC will usually not be running at the time GDDR would do a ConGroup REFRESH command. GDDR detects this and automatically performs a start of ConGroup, regardless of call override settings. If the ConGroup STC is found to be running at the time GDDR needs to issue a ConGroup REFRESH command, the use of ConGroup Stop/Start commands is controlled by the Perform EMCCGRP Shutdown and Perform EMCCGRP Startup call overrides, which are available for certain scripts. When invoked, these call overrides stop or start the ConGroup started tasks running on all z/os systems under EMC GDDR management; this includes C-Systems, production systems, and contingency systems. Note: Table 16, EMC GDDR call overrides, on page 255 contains descriptions of the call overrides. EMC GDDR allows some flexibility in the way you specify the location of the software parameters for the ConGroup STCs on each z/os system. The //CONFIG member included in the ConGroup STC startup proc contains the ConGroup startup parameters which define the consistency group. The name for the //CONFIG member can be specified in two ways: 1. Hard-code the name within the startup JCL. If the //CONFIG member name is hard-coded within the startup JCL, then any EMC GDDR script that starts ConGroup creates a ConGroup startup command string similar to the following: S cgstcname where: cgstcname is the ConGroup proc name. 72 EMC GDDR Version 4.2 Product Guide

73 Integrating EMC GDDR 2. Use a procedure substitution variable called MBR to reference a PDS member name. If the JCL procedure substitution variable MBR is used, then any EMC GDDR script that starts ConGroup creates a ConGroup startup command string similar to: S cgstcname,mbr=cgrp_mbr where: cgstcname is the ConGroup proc name. MBR is a JCL procedure substitution variable name required by EMC GDDR which must be defined in your JCL procedure. hlq.gddrvrm.samplib(gddrcgrp) shows the usage of this variable. cgrp_mbr is the member name assigned to variable MBR to be substituted in the //CONFIG DD. Determining which command string to use In the Define Mainframe Enablers STCs panel shown in Figure 71 on page 171, the you can define the following parameters: System The MVS system name of the system to which the statement applies. STC name The started task name associated with Type = CG. GDDRCGRP is recommended, but you may select a name that matches your actual ConGroup procedure name cgstcname. Parameter dataset and member names X(CGRPCAX6) are recommended, but you may specify a member name of your choosing that matches your actual cgrp_mbr member name. X is used as a DUMMY dataset name for Consistency Group parameters, as the actual dataset name is not relevant to constructing a ConGroup start command. The EMC GDDR scripts will use the variables to determine which of the command strings to use. If System, CG, STC Name, and Parameter Dataset name are supplied in the Define EMC Mainframe Enablers STCs panel, then EMC GDDR uses this value and builds command string: S cgstcname,mbr=cgrp_mbr where: cgrp_mbr is the value assigned to procedure variable MBR. If a parameter member name is not supplied for type=cg in the Define EMC Mainframe Enablers STCs panel, then the value of cgstcname is derived from the STC Name field associated with Type=CG, in the Define Mainframe Enablers STCs panel. EMC GDDR assumes that the // CONFIG DD member name value is hardcoded in the JCL procedure and builds the following command string: S cgstcname Perform ConGroup Started Task automated startup 73

74 Integrating EMC GDDR Note: The Define Mainframe Enablers STCs panel field descriptions following Figure 71 on page 171 provide detailed information regarding these parameters. Perform MSC configuration This section describes how to define the MSC environment required by SRDF/SQAR. Figure 16 MSC servers in SRDF/SQAR mode SRDF/SQAR MSC statement definitions A SQAR MSC group is designated with the keyword,sqar after the MSC group name, on the MSC_GROUP_NAME statement. Two MSC_GROUP_NAME statements with accompanying dependent statements MSC_SQAR, MSC_INCLUDE_SESSION, and MSC_GROUP_END are required to form a SQAR configuration. The MSC_SQAR statement contains the ConGroup name of the primary site followed by the MSC group name of the secondary SQAR group. The ConGroup name must be different on each of the primary and secondary MSC SQAR group definitions. The MSC_INCLUDE _SESSION statement is coded similar to a Star MSC_INCLUDE_SESSION statement; the second RDF group is the recovery group from Site C to Site D or Site D to Site C. SRDF/SQAR MSC_INCLUDE_SESSION statement conditions The number of asynchronous (SRDF/A) groups configured for the two SQAR groups must be equal. 74 EMC GDDR Version 4.2 Product Guide