EMC Consistency Group for z/OS Version 7.6 Product Guide

EMC Confidential

EMC® Mainframe EnablersConsistency Groups for z/OSVersion 7.6

Product GuideREV 02

Consistency Groups for z/OS Version 7.6 Product Guide2

Copyright © 2001- 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.

EMC2, 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.

Document Coverage

The EMC Consistency Groups for z/OS Product Guide is for use with the following products:

◆ EMC SRDF/Consistency Groups for z/OS

◆ EMC AutoSwap for z/OS

3

4 Consistency Groups for z/OS Version 7.6 Product Guide

CONTENTS

Document Coverage ...................................................................................... 3

Preface

Chapter 1 Overview

The EMC Mainframe Enablers and Consistency Groups ................................ 20Licensing .............................................................................................. 20

Introduction to Consistency Groups............................................................. 21Dependent writes.................................................................................. 21Device or link failures............................................................................ 21

ConGroup’s role .......................................................................................... 23Consistency groups............................................................................... 23ConGroup monitoring............................................................................ 23

ConGroup APIs and utilities......................................................................... 24Gatekeeper server ................................................................................. 24Trip API ................................................................................................. 25ECGUTIL utility....................................................................................... 25CGRPQDEV Callable Service................................................................... 25

Security ...................................................................................................... 26 Information about Swap Service Messaging ................................................ 26

Chapter 2 Operations

Using ConGroup .......................................................................................... 28 Making sure ResourcePak Base is running................................................... 29

Running multiple copies of EMCSCF ...................................................... 29 Enabling ConGroup ..................................................................................... 30 Starting ConGroup ...................................................................................... 30

Start up syntax ...................................................................................... 30Command syntax .................................................................................. 31ConGroup tasks and LPARs ................................................................... 31Bypassing consistency groups at startup............................................... 32Stopping ConGroup............................................................................... 32

Creating the configuration file ..................................................................... 33Defining the consistency groups............................................................ 33Group definition process....................................................................... 33Consistency group states ...................................................................... 35ConGroup device recommendations...................................................... 36

Coordinating consistency groups................................................................. 36ConGroup modes .................................................................................. 36Coordination parameters....................................................................... 37Coordination operation ......................................................................... 37Reserve penetration .............................................................................. 38ConGroup and TDMF or FDRPAS............................................................. 38The gatekeeper server ........................................................................... 39

Monitoring consistency groups.................................................................... 41Monitoring mode................................................................................... 41RDF-ECA, Domino mode, and UNPLANNEDCONDITIONS ......................... 41Monitoring process ............................................................................... 42

Consistency Groups for z/OS Version 7.6 Product Guide 5

Contents

Suspending operations ......................................................................... 42R1 device sharing by mirror ................................................................... 44Resuming protection ............................................................................. 44

ConGroup AutoSwap Extension ................................................................... 45Swap types ........................................................................................... 45Device swap groups .............................................................................. 45Using the ConGroup AutoSwap Extension.............................................. 46Resuming operation .............................................................................. 47Ownership takeover .............................................................................. 47Autoswap “Swap On Link Failure” Swap Trigger..................................... 48More information .................................................................................. 48

IODF considerations.................................................................................... 48Support for IODF configuration changes ................................................ 48Addition and Deletion of Controllers and Gatekeepers........................... 49

Chapter 3 Resuming Operations after a ConGroup AutoSwap

Introduction................................................................................................ 52 Handling page datasets .............................................................................. 52 Defining complement device groups............................................................ 53

Using the AutoSwap DEFINE GROUP command ...................................... 53Using CONFIGCA.................................................................................... 54Using Group Name Services .................................................................. 54

Executing command initiated swaps ........................................................... 54 Resynchronizing SRDF................................................................................. 55 Enabling the consistency group................................................................... 55

Enabling in single-LPAR mode ............................................................... 55Enabling in multi-LPAR mode................................................................. 57

Chapter 4 Database Considerations

Introduction................................................................................................ 60ConGroup and database I/O.................................................................. 60Database consistency group suspensions............................................. 60DEVICE_LIST definitions ........................................................................ 60Expanding to new devices ..................................................................... 61Other configuration parameters............................................................. 61Recovery site startup............................................................................. 61

DB2 considerations..................................................................................... 62DEVICE_LIST definitions ........................................................................ 62DB2 consistency group configuration example ...................................... 63Recovery site startup............................................................................. 63

IMS considerations ..................................................................................... 64DEVICE_LIST definitions ........................................................................ 64IMS consistency group configuration example....................................... 64Recovery site startup............................................................................. 64

Mixed database considerations................................................................... 65DEVICE_LIST definitions ........................................................................ 65Hybrid consistency group configuration example .................................. 65Recovery site startup............................................................................. 66

Chapter 5 Configuration

Introduction to configuration parameters .................................................... 68Syntax conventions............................................................................... 68


Contents

Defaults ................................................................................................ 69 Global configuration parameters ................................................................. 69

ALLOW_SHARED_R1S............................................................................ 70AUTO_REFRESH ..................................................................................... 71CAXOPTS............................................................................................... 73CLOCKE ................................................................................................. 80CLOCKN................................................................................................. 81COUPLEDS_ALLOWED............................................................................ 81DISABLE_AT_SHUTDOWN ...................................................................... 83DISABLE_ON_VERIFY_ERROR ................................................................. 83DISPLAY_CONGROUP_LISTOPT .............................................................. 84GLOBAL................................................................................................. 85MODE.................................................................................................... 85MSGLEVEL............................................................................................. 88PAGEDEV_ALLOWED.............................................................................. 88REMSPLIT_INTERVAL.............................................................................. 89REMSPLIT_OPTION ................................................................................ 90RESUME_INTERVAL................................................................................ 91RESUME_OPTION .................................................................................. 91SAF_CLASS............................................................................................ 92SAF_PROFILE ......................................................................................... 93SEMISYNC_ALLOWED ............................................................................ 93USE_FBA_NR_ON_TO ............................................................................ 95USE_RDF_ECA ....................................................................................... 96VERIFY_INTERVAL .................................................................................. 96

Consistency group-specific configuration parameters .................................. 97ALLOW_SHARED_R1S............................................................................ 97ALLOWABLE_MSS................................................................................ 100CAX ..................................................................................................... 101CONGROUP and SRDF_CONGROUP ...................................................... 101DEVICE_LIST........................................................................................ 103DEVICE_LIST_STD ................................................................................ 105EXCLUDE ............................................................................................. 106SCFG ................................................................................................... 107SMS_GROUP ....................................................................................... 108SUSPEND_FAILURE .............................................................................. 108SUSPEND[_RETRY]_TIMEOUT ............................................................... 109SYMM_DEV# ....................................................................................... 110SYMGROUP ......................................................................................... 111

Examples .................................................................................................. 114

Chapter 6 Command Reference

Customer Task Guide ................................................................................ 119 ConGroup operator commands.................................................................. 120

Command overview............................................................................. 120Syntax conventions............................................................................. 120Multiple subchannel device sets ......................................................... 121

HELP ......................................................................................................... 122 ADD .......................................................................................................... 122 #ADD ........................................................................................................ 124 CANCEL..................................................................................................... 125 DAS .......................................................................................................... 128 DELETE...................................................................................................... 128 #DELETE.................................................................................................... 129


Contents

DISABLE.................................................................................................... 130 DISPLAY .................................................................................................... 131 #DISPLAY .................................................................................................. 136 ENABLE .................................................................................................... 137 LA ............................................................................................................. 138 MOVEOWNER ............................................................................................ 138 #PIN.......................................................................................................... 140 QUERY CON............................................................................................... 140 REFRESH ................................................................................................... 141 REMSPLIT.................................................................................................. 142 RESET ....................................................................................................... 143 RESUME ................................................................................................... 144 SET VERIFY_INTERVAL................................................................................ 145 TAKEOVER ................................................................................................. 146 TRIP .......................................................................................................... 147 #UNPIN ..................................................................................................... 148 VERIFY....................................................................................................... 148

Appendix A Trip API

Introduction.............................................................................................. 152 Trip program ECGTRIP ................................................................................ 152 Prerequisites............................................................................................. 153 Sample Rexx Exec ..................................................................................... 154

Appendix B Problem Diagnosis

ConGroup diagnostic facilities................................................................... 156

Appendix C Cleanup Utility

Introduction.............................................................................................. 158Using ECGUTIL..................................................................................... 158Security............................................................................................... 159Gatekeepers........................................................................................ 159Trace messages .................................................................................. 159Commands.......................................................................................... 160

ADD DEVICES ............................................................................................ 160 AG (ARM GROUP) ...................................................................................... 162 DG (DEFINE GROUP) .................................................................................. 162 CG (CLEAN GROUP).................................................................................... 163 SET GROUP ............................................................................................... 163 SET MSGLEVEL .......................................................................................... 164 STOP......................................................................................................... 164 Messages ................................................................................................. 165 Limitations................................................................................................ 165 Example.................................................................................................... 166

Appendix D Swap Services Message Formatting

Swap services conventions ....................................................................... 168Verbose levels..................................................................................... 169Typographical conventions.................................................................. 169Message substitution fields ................................................................ 170


Contents

Appendix E Enhancements

Enhancements by release ......................................................................... 172


Contents


Title Page

FIGURES

1 Dependent write logic ................................................................................................. 212 Single source and target sites ..................................................................................... 223 Communications loss in a multiple Symmetrix configuration ....................................... 224 SRDF consistency group .............................................................................................. 235 ConGroup operational steps........................................................................................ 286 Concurrent RDF ........................................................................................................... 43


Figures


Title Page

TABLES

1 Task Guide ................................................................................................................ 1192 DISPLAY CONGROUP report: Detailed section ............................................................ 1333 DISPLAY CONGROUP report: Group summary section................................................. 1354 DISPLAY ENVIRONMENT report................................................................................... 1365 Swap services messages by application.................................................................... 1686 Consistency Groups for z/OS enhancements ............................................................. 172


Tableses


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 on the EMC online support website. Check the EMC online support website to ensure that you are using the latest version of this document.

PurposeThis document describes how to configure and use EMC Consistency Group (ConGroup).

Related documentationThe following EMC publications provide additional information:

◆ Mainframe Enablers Release Notes

◆ Mainframe Enablers Installation and Customization Guide

◆ Mainframe Enablers Message Guide

◆ SRDF Host Component for z/OS Product Guide

◆ TimeFinder/Clone Mainframe Snap Facility Product Guide

◆ Symmetrix Remote Data Facility (SRDF) for VMAX 40K, VMAX 20K/VMAX, DMX Series Product Guide

◆ Symmetrix TimeFinder for VMAX 40K, VMAX 20K/VMAX Series Product Guide

If you have obtained an eLicense or license keys for AutoSwap, refer to the AutoSwap for z/OS Version 7.5 Product Guide.

Conventions used in this documentEMC uses the following conventions for special notices:

CAUTION, used with the safety alert symbol, indicates a hazardous situation which, if not avoided, could result in minor or moderate injury.

Note: A note presents information that is important, but not hazard-related.

IMPORTANT

An important notice contains information essential to software or hardware operation.

Typographical conventions


Preface

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

{ } Braces enclose content that the user must specify, such as x or y or z

| Vertical bar indicates alternate selections — the bar means “or”

... Ellipses indicate nonessential information omitted from the example


Preface

Where to get helpEMC support, product, and licensing information can be obtained on 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:

https://support.EMC.com

Technical support

EMC offers a variety of support options.

Support by Product — EMC offers consolidated, product-specific information on the Web at:

https://support.EMC.com/products

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, discussion, 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 https://support.EMC.com, as directed on your License Authorization Code (LAC) letter emailed 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 the Online Support site, contact EMC's worldwide Licensing team at [email protected] or call:

◆ North America, Latin America, APJK, Australia, New Zealand: SVC4EMC (800-782-4362) and follow the voice prompts.

◆ EMEA: +353 (0) 21 4879862 and follow the voice prompts.


http://support.EMC.com

https://support.EMC.com/products


Preface

Your commentsYour suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Send your opinions of this document to:

[email protected]


CHAPTER 1Overview

This chapter presents an overview of EMC Consistency Groups for z/OS (ConGroup).

◆ The EMC Mainframe Enablers and Consistency Groups ............................................ 20◆ Introduction to Consistency Groups......................................................................... 21◆ ConGroup’s role ...................................................................................................... 23◆ ConGroup APIs and utilities..................................................................................... 24◆ Security .................................................................................................................. 26◆ Information about Swap Service Messaging ............................................................ 26

Overview 19

Overview

The EMC Mainframe Enablers and Consistency GroupsEMC® Consistency Groups is one of the EMC Mainframe Enablers. The EMC Mainframe Enablers include the following components that you can use to monitor and manage your storage:

◆ ResourcePak® Base for z/OS

◆ EMC Consistency Groups for z/OS

◆ SRDF ® Host Component for z/OS

◆ TimeFinder ®/Clone Mainframe Snap Facility

◆ TimeFinder/Mirror for z/OS

◆ TimeFinder Utility

Mainframe Enablers includes the software for all of these components. When you install the Mainframe Enablers, you install the software for all the components.

Licensing

As of Enginuity™ level 5875 or higher, Mainframe Enablers introduces support for Electronic Licensing (eLicensing). With the introduction of eLicensing, Symmetrix licensing is moving from a host-based model to a Symmetrix-based model, with the majority of licenses now being stored in a feature registration database on the Symmetrix system.

However, there are still a number of Symmetrix licenses that remain host-based and use License Feature Codes (LFCs).

For these remaining host-based licenses and for Symmetrix systems running Enginuity level 5874 or lower, ResourcePak Base (EMCSCF) requires LFCs to enable separately chargeable features in EMC software. These features require an LFC to be provided during the installation and customization of EMCSCF. The Mainframe Enablers Installation and Customization Guide lists the LFCs for the Mainframe Enablers components.

Enabling component licensingTo enable any of the Mainframe Enablers’ components, except ResourcePak Base (which is a persistent address space running on any z/OS processor on which it is installed), you need one of the following:

◆ For Enginuity level 5875 or higher, you need the eLicense for that component.

or

◆ For Enginuity level 5874 or lower, you need to install the License Feature Code (LFC) for that component into the ResourcePak Base initialization parameters file.

Follow the steps outlined in the Mainframe Enablers Installation and Customization Guide and the ResourcePak Base for z/OS Product Guide to install the Mainframe Enablers and enable Consistency Groups.


Overview

Introduction to Consistency GroupsEMC Consistency Groups for z/OS (ConGroup) is designed to protect the consistency of remotely mirrored data in an SRDF/S configuration.

The following sections provide an introduction to EMC Consistency Groups for z/OS.

Dependent writes

Many applications (especially transaction oriented systems or database management systems) use dependent write logic for data consistency. Dependent write logic means that an application’s attempt to issue a given I/O depends on the prior successful completion of another I/O operation. Figure 1 shows this process:

Figure 1 Dependent write logic

As Figure 1 shows, the application takes the following steps:

1. Writes a record of what it’s planning to do in the transaction log.

2. Writes the data to the actual database.

3. Writes another record to the transaction log to indicate that the data update was successfully made.

These three writes (log, database, and log again) are related. Each write is not issued until the previous related write has completed.

Device or link failures

When an application using dependent write logic is under SRDF, that application is protected by the transparent link outage feature in normal circumstances. When an SRDF link not running with the domino attribute fails or is intentionally disabled, the application writing to the R1 is not aware of the failure of writes to the R2. When the link is restored, the invalid R2 tracks are automatically filled in by the more up-to-date R1 tracks.

This solution works well if both the source and target site have only one Symmetrix system, as shown in Figure 2.

Write to transaction

log

Write to database

Write to transaction

log

Introduction to Consistency Groups 21

Overview

Figure 2 Single source and target sites

However, if the configuration includes multiple Symmetrix systems at the source or target site (and therefore, multiple links), something more is needed. Consider the situation shown in Figure 3.

Figure 3 Communications loss in a multiple Symmetrix configuration

In Figure 3, data at the primary site is remotely mirrored across more than one link. If one or more of these links break, and the remaining links continue to operate, the result is a mixture of “stale” and “fresh” data at the remote restart site. Restarting operations on this remote data could result in integrity problems, such as:

◆ Indexes pointing to the wrong data◆ Records being linked incorrectly◆ Corrupted database structures

Symmetrix system B

Symmetrix system A

SRDF link

z/OSSource site Target site

R1 R2

Broken link

Active link

Data frozen at time of link failure

Data continues to be updated

Primary site Restart site


Overview

ConGroup’s roleTo solve possible data consistency problems, something more is needed. That something more is ConGroup. ConGroup’s role is to:

◆ Prevent loss or corruption of data when there is a communications failure or device failure in configurations of multiple Symmetrix systems at the source or target site.

◆ Ensure logically consistent, restartable data copies on the remote side of an SRDF relationship.

Consistency groups

The key to maintaining data consistency through ConGroup are consistency groups. Each consistency group is a named group of source (R1) devices or Standard (STD) devices that ConGroup treats as a unit. The devices can be on multiple Symmetrix systems (as shown in Figure 4); however, all of the devices in a consistency group must be at the same site.

Figure 4 SRDF consistency group

A consistency group can include both mainframe and open systems devices; but, should not include R2 devices. ConGroup ignores any consistency groups that contain R2s.

ConGroup monitoring

During daily operation, ConGroup monitors the SRDF links for signs that a write is unable to propagate to the remote (target) R2 side; that is, that the ending status for the write has not yet been presented to the application.

To perform the monitoring, ConGroup V7.0 and later uses Enginuity Consistency Assist (ECA) monitoring mode. ECA is an Enginuity feature that signals to the host software when to open an ECA window for the group. It can be used for TimeFinder or SRDF/S.

While host software makes sure that all members have the ECA window open, Enginuity blocks host I/Os when the ECA window is open and, in case of SRDF/S, sets R1 SRDF mirrors not ready

Symmetrixsystem A'

Symmetrix system A

Symmetrix system B

Symmetrix system B'

Consistencygroup

SRDF link

SRDF link

z/OS

Source site

R1

R1 R2

R2

ConGroup’s role 23

Overview

ECA is an EMC technology that ConGroup can use to provide enterprise-level consistency protection for synchronous devices by performing suspend operations across all SRDF/S devices in a consistency group. This technology and other EMC technologies are grouped together as RDF Consistency.

Note: Starting with V 7.0, ConGroup no longer supports the IOSLEVEL monitoring mode that was available in earlier versions.

Allowing RDF-ECA to monitor CG protections provides distinct advantages over the previously supported IOSLEVEL mode:

◆ The I/O stalling is done near the data via the Symmetrix system instead of in the host operating system.

◆ Only one instance of ConGroup is necessary (or two for redundancy) versus an instance running on all LPARs with IOSLEVEL mode. Please note the AutoSwap restriction requiring one instance per LPAR.

◆ There is only one mechanism to maintain.

ConGroup dispatches batches of service tasks from an internal worker pool (on a schedule determined by ConGroup) to determine the ECA Window state in all the Symmetrix systems defined in a consistency group.

When a Symmetrix system determines that a write is not able to propagate to the R2 side, it defers completion of the current write operation, and enters a special state for a pre-determined time period. This state is the ECA Window Open state.

If a ConGroup service task finds a Symmetrix system in the ECA Window Open state, ConGroup alerts all other Symmetrix systems defined in the consistency group to enter the ECA Window Open state. All devices defined in this consistency group enter deferred write completion until the ECA Window is closed.

ConGroup then suspends SRDF/S protection for all members of the consistency group. When the SRDF/S suspends are complete, ConGroup closes the ECA Windows, which allows write I/O operations to resume. All devices on the target (R2) side of SRDF/S relationships in this consistency group definition are dependent write consistent.

ConGroup APIs and utilitiesConGroup also includes the following utilities:

◆ Gatekeeper server

◆ Trip API

◆ ECGUTIL utility

◆ CGRPQDEV Callable Service

Gatekeeper server

The gatekeeper server uses the ResourcePak Base Gatekeeper API to acquire a list of SCF gatekeepers. It dynamically allocates them to internal requestors for all syscalls and API calls within ConGroup.


Overview

Note: “The gatekeeper server” on page 39 provides more information about the gatekeeper server and how to use it.

Trip API

When invoked, the Trip API causes a trip of a specified consistency group. The Trip API consists of a macro (ECGAPI) and a program call (PC) routine and related code that runs in the ConGroup address space.

The Trip API is principally intended for use by 3rd party developers, but is available to all ConGroup users.

Note: “Trip API” on page 151 describes the TRIP API and how to use it.

ECGUTIL utility

ECGUTIL, the Cleanup utility, allows you to clear specified devices on one or more Symmetrix controllers.1 You would use ECGUTIL to clean up (correct) situations that have left devices in an incorrect state.

Suppose you have a channel failure that forces a swap. The swap leaves ConGroup-enabled R1 devices that ConGroup is not able to disable. You can use ECGUTIL (from a different host that can still reach the devices) to clean them up.

Note: “Cleanup Utility” on page 157 describes the Cleanup utility and how to use it.

CGRPQDEV Callable Service

CGRPQDEV is one of the routines in the Symmetrix Application Programming Interface (SymmAPI™). SymmAPI is a set of routines that can interface with Symmetrix® units attached to hosts that are running in an z/OS environment.

CGRPQDEV is a callable service used to query the EMC Consistency Group Address Space. Queries can be made to determine the names of all currently-defined consistency groups to determine which devices are part of a named consistency group, and to determine the state of a device in a consistency group.

CGRPQDEV is principally intended for use by EMC and 3rd party developers.

Note: A description of CGRPQDEV and usage instructions are found in the SymmAPI-Control (MF) Programmers Reference Guide.

1. Only locally-attached controllers are supported.

ConGroup APIs and utilities 25

Overview

SecurityConGroup provides for security by allowing you to validate authorization to access ConGroup resources through the mainframe EMCSAFI interface. As a result, any of the following SAF compliant security products can be used to ensure proper user authorization:

◆ RACF

◆ CA-ACF2

◆ CA-Top Secret

The security product you select must be compatible with RACF release 1.9 or higher.

Note: The Mainframe Enablers Installation and Customization Guide describes how to use EMCSAFI.

Information about Swap Service MessagingConGroup can generate swap services messages. For more information regarding ConGroup and swap services messages, refer to Appendix D, “Swap Services Message Formatting,”


CHAPTER 2Operations

This chapter describes ConGroup operations.

◆ Using ConGroup ...................................................................................................... 28◆ Making sure ResourcePak Base is running............................................................... 29◆ Enabling ConGroup ................................................................................................. 30◆ Starting ConGroup .................................................................................................. 30◆ Creating the configuration file ................................................................................. 33◆ Coordinating consistency groups............................................................................. 36◆ Monitoring consistency groups................................................................................ 41◆ ConGroup AutoSwap Extension ............................................................................... 45◆ IODF considerations................................................................................................ 48

Operations 27

Operations

Using ConGroupAfter installation, you are ready to set up and use ConGroup. Figure 5 provides an overview of ConGroup operations.

Figure 5 ConGroup operational steps

Create consistency

group

Verify consistency

group

Enable consistency

group

Monitor consistency

group

Write failure?

No

SRDF link failure orR2 device failure?

Trip consistency

group

Swap I/Oto R2s

Yes

Resume operations

Host I/O failure or R1 device failure?

With CAX enabled


Operations

Making sure ResourcePak Base is running ConGroup requires that SCF in ResourcePak Base (SCF) be fully active before ConGroup performs initialization. If EMCSCF is not running while ConGroup is running, any ConGroup commands issued receive the following message:

EMC SCF IS NOT AVAILABLE - reason

Where:

reason

Is one of the following:

• SERVICE EMCSAI FAILED• SERVICE SAICALL FAILED

If SCF is not running when you start ConGroup, you receive the message:

CGRP513E ****CONGROUP ENDED. SCF NOT ACTIVE

If SCF has been started, but not fully initialized, when you start ConGroup then tests at one-minute intervals for 30 minutes. If SCF becomes active during the 30 minutes, ConGroup continues normal initialization. If it has not detected an active SCF after 30 minutes have passed, ConGroup shuts down.

This behavior may provide the misleading impression that ConGroup protection is in force simply because ConGroup is running, when in fact ConGroup is waiting for SCF to become active in order to proceed with its own initialization. A fully initialized ConGroup is evidenced by CGRP149I messages for each specified group of devices being protected; for example:

CGRP149I CONGROUP cgrpname SUCCESSFULLY ENABLED

Running multiple copies of EMCSCF

You can run multiple instances of EMCSCF as separate subsystems. You may want to do this when you are testing new versions of EMCSCF or EMCSCF-enabled products.

To run multiple instances of EMCSCF as separate subsystems, add the following DD statement to the EMCSCF test procedure.

//SCF$nnnn DD DUMMY

Where:

nnnn

Defines this instance of EMCSCF as a unique z/OS subsystem. The DD statement would then be used in any task where you want to use this copy of EMCSCF.

For example:

Test version of EMCSCF (with nnnn set to 0100)

//EMCSCF EXEC PGM=SCFMAIN,TIME=1440,REGION=0M//STEPLIB DD DISP=SHR,DSN=test.load_library//SCFINI DD DISP=SHR,DSN=init_dataset //SYSABEND DD SYSOUT=*//SCF$0100 DD DUMMY

Making sure ResourcePak Base is running 29

Operations

Any task needing to use this instance of EMCSCF would add the SCF$0100 DD statement. For example, the JCL for ConGroup would add the DD statement:

//TEST EXEC PGM=EMCCGRP//SYSOUT DD SYSOUT=A//SYSIN DD *//SCF$0100 DD DUMMY

Enabling ConGroupAs a first step in using ConGroup, you install EMC Mainframe Enablers and enable the ConGroup software. The installation and enabling process is described in the Mainframe Enablers Installation and Configuration Guide.

ConGroup can run on one LPAR or on multiple LPARs. If you install ConGroup on multiple LPARs, you can have ConGroup instances on several LPARs protect the same consistency groups or have several ConGroup instances on different LPARs protecting different consistency groups.

As of Version 7.2, ConGroup also supports multiple (up to seven) independent ConGroup address spaces. These are not intended for full production but may be useful for testing new releases or other non-production tasks.

Note: “Coordinating consistency groups” on page 36 discusses modes. “MODE” on page 85 describes the MODE global configuration parameter.

Starting ConGroupGenerally, you should start ConGroup as soon after IPL as possible and keep it running at all times. EMC recommends that you include the activation of ConGroup in the IPL procedures on all your systems.

While you can run ConGroup as a batch job, EMC recommends that you run ConGroup as a started task, with SUB=MSTR to avoid any potential deadlock conditions with JES during consistency group suspend operations. (SUSPEND_FAILURE=WTOR is valid only if ConGroup is running SUB=MSTR.) You should also run the EMCCGRP started task at the same priority as VTAM or JES or at a higher priority.

Start up syntax

To start ConGroup after installation, issue:

S EMCCGRP[,REUSASID=YES]

Where: EMCCGRP

The ConGroup started task

Note: EMCCGRP is used as the name of the ConGroup started task throughout this manual.


Operations

The product-specific CGP SAMPLIB contains the sample started task procedure to run ConGroup, EMCCGRP. Customize this member for your installation, and install it in the appropriate PROCLIB.

REUSASID=YES

This is an optional parameter on the z/OS Start command. To avoid permanent loss of ASIDs during the life of an IPL, you should use REUSASID=YES on your start commands for ConGroup.

Note: The z/OS level on your system must be 1.9 or higher and running on a z/990 or higher. DIAG must include REUSASID(YES) (use D DIAG to check, and SET DIAG=R1 to set to YES). You should contact your Systems Programmer to discuss whether this is available for use.

Command syntax

A ConGroup task contains a number of display and control commands that are issued with the MODIFY command in the following format:

F EMCCGRP,command [parameter[parameter[...]]]

Where: EMCCGRP


command and parameter

A ConGroup statement, a command followed by its parameter or parameters

In addition, EMC commands and parameters also follow these syntax conventions:

◆ CAPITALIZATION = must be typed

◆ [ ] = optional entry

◆ Italics = argument

◆ | = alternative argument values

◆ Default values are indicated by an underline. For example, if the parameter has the following option, (YES|NO), the underlined NO indicates the default value.

Note: Chapter 6 describes ConGroup commands and parameters.

ConGroup tasks and LPARs

You can execute up to seven ConGroup started tasks if they are all at the 7.2 level or higher, plus one additional ConGroup started task at the 7.0 level – all in the same LPAR. Each ConGroup started task may manage multiple consistency groups within the LPAR.

The CONFIG DD statement points to the dataset that contains the ConGroup configuration file. The ConGroup configuration file contains parameter statements that define the devices in consistency groups.

EMC recommends that all ConGroup instances use the same configuration file by having the CONFIG DD statements point to the same dataset.

Starting ConGroup 31

Operations

This prevents the intolerable situation of a new node joining the "set" with a different set of parameters. ConGroup checks for this and, if the configuration files are not identical in content, forces the new node to shutdown immediately.

Note: In a multiple LPAR, shared DASD environment, a ConGroup address space (task) only needs to be on every LPAR if AutoSwap is being used (if the groups are "CAX" groups).

Bypassing consistency groups at startup

ConGroup has two types of “group bypass” at startup or refresh:

◆ Complete consistency group bypass

◆ GNS group bypass 1

Complete consistency group bypassAt startup, ConGroup ignores consistency groups that have a local R2 defined, but continues to start. (In previous versions, ConGroup would consider a local R2 definition for a consistency group an error and not start.)

ConGroup recognizes R21 and R22 devices, but treats them as R2 devices. The SRDF Host Component for z/OS Product Guide provides more information.

GNS group bypassIf ConGroup does not find a GNS group name when it attempts to include the devices of that group into a consistency group, ConGroup ignores that GNS group when starting. The rest of the devices in the consistency group are ConGroup protected.

Stopping ConGroup

The normal and preferred way to stop ConGroup is to issue the STOP command with the jobname. For example, to stop the ConGroup task whose jobname is EMCCGRP, issue the following commands.

P EMCCGRP

If there is an active global activity currently running, message CGRP801I is issued and the stop command is retried internally for up to five minutes. If not stopped at the end of five minutes, the system will be shutdown as if the ‘F cg,STOP’ command was entered (see below).

If you cannot get ConGroup to stop, or if there is an emergency where there is no time to wait for an orderly shutdown, then issue the following modify command:

F EMCCGRP,STOP

Note: This form of stopping ConGroup ignores any global activities that are protected by the ALL-CONGROUPS lock, and brings the application down rapidly. This could leave devices in an unpredictable state.

1. GNS stands for Group Name Services “Defining consistency groups through Group Name Services” on page 34 provides more information about GNS -defined consistency groups.


Operations

Creating the configuration fileYour first step is to create the ConGroup configuration file.The configuration file consists of a series of statements that define

◆ Global configuration parameters that apply to general ConGroup operation

◆ Group-specific configuration parameters that describe a particular consistency group

Each statement can have a maximum length of 70 bytes and may not span lines. Columns 71 to 80 are ignored.

Note: You can find a sample configuration file in the CGRPCFG0 member in the Mainframe Enablers SAMPLIB.

Defining the consistency groups

As part of the configuration definition procedure, you must define your consistency groups. Consistency groups maintain consistency for an SRDF configuration. Each consistency group consists of a list of the devices to monitor.

Consistency groups are defined through the SRDF_CONGROUP or CONGROUP configuration parameters. ConGroup supports the following:

◆ All valid SRDF topologies, including concurrent and switched SRDF

◆ Standard (STD) devices with established BCVs

Each SRDF consistency group consists of a group name (up to eight characters) and a list of devices. The devices can be:

◆ Mainframe device numbers

◆ Ranges of mainframe device numbers

◆ Mainframe volsers

◆ Symmetrix device numbers

◆ Ranges of Symmetrix device numbers

◆ Group Name Services groups

Symmetrix device numbers and ranges of Symmetrix device numbers can include, FBA devices. Group Name Services groups can also include FBA devices.

The devices in a consistency group can be on different Symmetrix systems, but all devices must be at the same physical site. You cannot include devices from different physical sites in the same consistency group.

Group definition process

You can define a consistency group:

◆ Through the ConGroup configuration parameters

◆ Through the Group Name Services (GNS) facility of ResourcePak Base

Creating the configuration file 33

Operations

Defining consistency groups through ConGroup configuration parametersConsistency group definitions come after the global configuration parameters and with the group-specific parameters. To define a group, first define the name of the group with the SRDF_CONGROUP or CONGROUP parameter.

Then, define the devices that make up the group with the DEVICE_LIST, DEVICE_LIST_STD, and SYMM_DEV# parameters. Position is important. Make sure you include the device definitions immediately after the name definition.

You can find more information about these configuration parameters and examples of their use in Chapter 5.

Defining consistency groups through Group Name ServicesYou can also use the Group Name Services (GNS) component of ResourcePak Base, to do the following:

◆ Define consistency groups

◆ Dynamically add devices to or subtracting devices from groups

Take the following steps to use GNS groups in consistency group definitions:

1. Build a GNS group through TSO, Batch, or ISPF. Assign a name to the group, and specify the devices that make it up.

2. Edit the ConGroup configuration file to define the GNS group. Use the SCFG parameter with the name of that group as an argument. (“SCFG” on page 107 describes the SCFG parameter.)

Note: The definition of any consistency group can be composed of one or more device specifications entered with a DEVICE_LIST parameter, one or more Symmetrix device numbers entered with the SYMM_DEV# parameter, or one or more GNS groups. Because consistency groups are composed of R1 devices, you should define only Enterprise RDF1 groups as consistency groups.

Keep in mind that using GNS groups to define the contents of consistency groups has several advantages:

◆ You can define consistency groups that span multiple LPARs.

◆ You can add devices in other LPARS and devices currently offline to an LPAR running ConGroup.

◆ You can update consistency group definitions “on the fly” without having to update the ConGroup configuration file. (“Dynamically changing groups” explains this process. You can also refer to “ADD” on page 122 and “DELETE” on page 128 for more information.)

◆ Although you can use the ConGroup configuration parameters (SYMM DEV#) to define open systems devices, EMC suggests that you use GNS instead. If SYMM DEV# is used, you must ensure that the meta heads are specified. Members may be specified, but they are ignored. ConGroup determines the correct members based on the specified heads.


Operations

You can also use the GNS EXCLUDE parameter to exclude certain devices when defining a consistency group. For a given consistency group, there can be one or more EXCLUDE parameter statements.

Note: The ResourcePak Base for z/OS Product Guide describes Group Name Services.

GNS names and ConGroupConGroup supports GNS naming conventions. As GNS also supports open systems, some of the GNS names may include characters, such as blank spaces. If a GNS name you use in ConGroup includes blank spaces, enclose that name in double quotes; for example:

SCFG(“West Coast Stores”)

Dynamically changing groupsGroup definition simplifies the process of changing the contents of a group. To change the contents of a group:

1. Use GNS to change the definition of the group.

Note: The ResourcePak Base for z/OS Product Guide describes the GNS commands.

2. In ConGroup, execute a ConGroup REFRESH command to cause the changes to the group(s) to be incorporated into the consistency groups.

Note: “REFRESH” on page 141 describes the REFRESH command. As far as ConGroup is concerned, the definition of the GNS group remains unchanged because the GNS name is the same. No changes are required to the ConGroup configuration file.

Optionally, the new dynamic add and delete functions can be used to create changes for the group(s). For descriptions of these commands, refer to “ADD” on page 122 and “DELETE” on page 128.

Consistency group states

A consistency group can be either ENABLED or DISABLED. ENABLED/DISABLED are the on/off switches for ConGroup protection.

ENABLED When a consistency group is ENABLED, ConGroup protection is turned on, and that consistency group is eligible to be suspended should the circumstances arise.

An ENABLED consistency group can be in one of the following sub states:

◆ Active

This is the normal state for a consistency group. Data is flowing to the remote devices and the consistency group is eligible to be suspended.

◆ Suspend pending

An error has occurred, causing ConGroup to suspend the consistency group; that is, to stop the data flow to the remote devices. While in this state, I/O to the devices is held until the suspend completes.

Creating the configuration file 35

Operations

◆ Suspended

The suspend has completed. Data has stopped flowing to the remote devices, and I/O has resumed to the local devices. The remote devices are in a consistent state.

◆ Remote split in process

This state implies that the consistency group is suspended. ConGroup is in the process of splitting all the remote (R2) devices from their Business Continuance Volume (BCV) devices, if present.

◆ Resume in process

ConGroup is in the process of resuming the data flow to the remote devices, or has completed the process and is now waiting for all the devices in the consistency group to synchronize with their respective remote devices.

DISABLEDThere is no ConGroup protection active. The consistency group is essentially a defined group of devices with nothing to do.

ConGroup device recommendations

Follow these recommendations when defining consistency groups.

◆ When configuring JES checkpoint and spool volumes in a consistency group, the EMCCGRP and EMCSCF started tasks must be started SUB=MSTR.

◆ ConGroup does not support active XCF couple datasets, with the exception of LOGR couple datasets.

◆ EMC does not recommend configuring page datasets in a consistency group that is not an AutoSwap (CAX) consistency group.

Note: The AutoSwap Product Guide has more information about page datasets in a AutoSwap consistency group.

Coordinating consistency groupsThe following sections discuss various aspects of consistency group coordination.

ConGroup modes

In previous versions, ConGroup ran in single LPAR mode and single LPAR mode continues to be the default. In single LPAR mode, there is no information sharing among ConGroup instances that are monitoring the same consistency groups.

However, ConGroup offers multi-LPAR mode, an optional coordination mechanism based on distributed locking, message exchange, and the Cross System Communication (CSC) facility of EMCSCF.

To set ConGroup in multi-LPAR mode, you set the MODE=MULTI global configuration parameter. Multi-LPAR mode provides shared information across all ConGroup instances monitoring the same consistency group(s) about the state of those consistency groups. Multi-LPAR mode allows some ConGroup commands, ENABLE, RESUME, and REFRESH, to


Operations

be global commands. This means that a ENABLE, RESUME, or REFRESH command issued for a consistency group on one LPAR is automatically issued on each LPAR monitoring that group. You do not have to issue the command manually on each LPAR.

Note: “ENABLE” on page 137, “REFRESH” on page 141, and “RESUME” on page 144 describe these commands.

In addition, when you run in multi-LPAR mode and specify the ConGroup AutoSwap extension, you can use the MOVEOWNER and TAKEOVER commands. (The MOVEOWNER and TAKEOVER commands are not available in single LPAR mode or for non-CAX consistency groups.)

Note: “MOVEOWNER” on page 138 and “TAKEOVER” on page 146 describe these commands.

To use multi-LPAR mode across systems and/or sysplexes, the system time must come from the same source. This could be the sysplex timer or a single CEC system clock.

Coordination parameters

The coordination parameters that you previously entered into CONFIG2 you now enter as global configuration parameters into CONFIG.

These coordination parameters include:

CLOCKE(n) — CLOCKE specifies the multiple of the clock tick interval used by ConGroup for heartbeat coordination and other purposes.

Note: “CLOCKE” on page 80 provides further information about the CLOCKE parameter.

CLOCKN(n) — CLOCKN specifies the time, in hundredths of a second, between coordination activities.

The number of seconds represented by CLOCKN must be equal to or greater than twice (after dividing by 100) the idle poll value of CSC. The idle poll value is optionally specified in ResourcePak Base with the SCF.CSC.IDLEPOLL parameter. If the number of seconds represented by CLOCKN is less than double the CSC idle poll value, reliable coordination is not possible, an error message is issued, and initialization fails.

For normal operation the default value should be used for both CLOCKN and SCF.CSC.IDLEPOLL.

Note: “CLOCKN” on page 81 provides further information about CLOCKN. The ResourcePak Base Product Guide discusses SCF.CSC.IDLEPOLL.

Coordination operation

As described in “Coordinating consistency groups” on page 36, ConGroup uses the CSC facility of EMCSCF to identify other active instances of ConGroup. ConGroup instances using the same CSC port exchange information that is used to coordinate actions and sequence command execution.

Coordinating consistency groups 37

Operations

As each ConGroup instance starts, it begins exchanging messages with existing members of the group. If a consistency group is using the ConGroup AutoSwap Extension (CAX) option, part of the information exchanged is the SMF ID of the owner LPAR.

The owning LPAR is determined by the value of the GLOBAL parameter. (GLOBAL (owner=owning LPAR)). This argument must be the same in ConGroup parameter files for all instances of ConGroup that use the defined consistency group.

Note: “ConGroup AutoSwap Extension” on page 45 presents more information about CAX. “GLOBAL” on page 85 presents more information about the GLOBAL parameter.

The group of consistency groups has only one owner LPAR and all ConGroup instances are aware of the current owner as a result of the message exchanges. The remainder of the ConGroup LPARs in the group are referred to as non-owners.

If, at some point, ownership needs to be transferred from one LPAR to another, you can use either the MOVEOWNER or TAKEOVER commands. The MOVEOWNER and TAKEOVER commands use synchronized message passing to coordinate the ConGroup activities on all LPARs in a manner that result in the passing of the ownership attribute from one LPAR to another.

Use MOVEOWNER if both the current owner LPAR and the prospective new owner LPAR are running. Use TAKEOVER if the current owner is not running.

Use MOVEOWNER as your first choice. MOVEOWNER lets you verify the identity of the existing owner before you use TAKEOVER.

Note: “MOVEOWNER” on page 138 and “TAKEOVER” on page 146 describe these commands.

Reserve penetration

Reserve penetration allows ConGroup commands to penetrate host-initiated hardware reserves. Previously, any ConGroup command would fail if it encountered a host-initiated hardware reserve. With Enginuity operating environment for Symmetrix Version 5x71 and later, ConGroup commands run to conclusion when they encounter a hardware reserve.

Your primary use of this feature is during ConGroup startup and when you issue QUERY commands. Reserve penetration also includes a retry on reserved devices that is helpful with older Enginuity release levels that do not support reserved penetration.

ConGroup and TDMF or FDRPAS

If you are using ConGroup with IBM (Softek) Transparent Data Migration Facility, (TDMF) or Innovation Data Processing’s FDRPAS, you need to keep the following points in mind.

Using ConGroup and TDMF or FDRPAS — Ensure that TDMF or FDRPAS does not migrate/swap into or out of a consistency group. In addition, you need to define the TDMF or FDRPAS source and target devices to be in the same consistency group. Define the sources and targets using the DEVICE_LIST parameter and not volser masking.

Note: “DEVICE_LIST” on page 103 provides more information about the DEVICE_LIST parameter.


Operations

Using ConGroup with AutoSwap and TDMF or FDRPAS — You must not allow a TDMF or FDRPAS source or target to be in an AutoSwap consistency group.

The gatekeeper server

As an internal performance aid, ConGroup uses the ResourcePak Base (SCF) Gatekeeper API to assist in managing the internal polling processes.

Note: The ResourcePak Base for z/OS Product Guide describes how to specify gatekeeper devices in SCF.

When started, ConGroup requests the list of available SCF gatekeepers. That list is then managed for other internal ConGroup processes by a dedicated gatekeeper server process.

After a worker process receives a poll request, it sends a request for a gatekeeper device.

ConGroup receives the request and finds an unused gatekeeper on the list and responds to the worker process with that gatekeeper’s information.

Managing the gatekeeper poolNormally, you can let the gatekeeper pool function automatically. However, there may be occasions when the gatekeeper pool is backed up with queuing and you have to change the gatekeeper pool.

Determining whether there is gatekeeper queuingTo see if there is queuing for gatekeepers, you can use the DISPLAY ENVIRONMENT report. The DISPLAY ENVIRONMENT report has lines that show the gatekeeper pool:

Work Pool Size: 10 Free: 10 Busy: 0 5 Second Request History: 0 0 2 0 0 Gatekeeper Queue HWM: 2

Note: “DISPLAY” on page 131 provides more information about the DISPLAY ENVIRONMENT report.

Busy shows the current number of busy worker processes. Because worker processes are overwhelmingly involved in issuing poll requests which require gatekeepers, a sustained non-zero value for “busy” indicates sustained congestion.

5 Second Request History shows the number of busy worker processes in each of the last five seconds. The leftmost value represents the most recent five seconds, and so on. Because most requests are very quick, even high values in this rolling history do not generally translate into a sustained non-zero busy value. “Catching” a non-zero busy value should be fairly rare in a normally functioning system. Of course, the busier the system, the more likely you are to find a non-zero busy value.

HWM stands for “high water mark.” The value shown indicates the number of gatekeeper requests have had to wait for a free gatekeeper since startup or since the last issuance of CE GKREFR.

Coordinating consistency groups 39

Operations

When started, ConGroup requests the list of available SCF gatekeepers. That list is then managed for other internal ConGroup processes by a dedicated gatekeeper server process.

If the value is zero (0), no gatekeeper request ever has to wait for a free gatekeeper. However, the value is almost always non-zero.

EMC recommends that you specify at least two (2) gatekeepers in ResourcePak Base (SCF) for each controller that ConGroup is protecting. The reason for this is simply to allow ConGroup to split the polling workload into parallel sub-workloads. The most parallelism ConGroup can achieve is 10 sub-workloads because ConGroup runs with 10 worker subtasks.

Note: Each additional gatekeeper provides progressively smaller marginal advantage. More than five achieves little advantage.

If you specify only one user gatekeeper per controller through SCF, potentially dozens of poll operations are single threaded (with a corresponding high HWM) even though there are 10 workers. Note that currently, each group definition generates independent polling, so four groups generate at least four times the amount of polling as one group. But the gatekeepers are shared (and are correspondingly busier) when you define multiple groups.

Changing the gatekeeper poolYou can change the gatekeeper pool while ConGroup is running. To do this, change the SCF INI file to specify the desired gatekeepers, and then issue commands to refresh the list.

Take the following steps:

1. Change the SCF INI file to specify the desired gatekeepers with the SCF.GATEKEEPER.LIST statement.

2. Enter the following commands to SCF to refresh the list:

F SCF,INI,REFRESHF SCF,DEV,REFRESH GATEKEEPER

Result: The SCF message, SCF0417I REFRESH COMPLETE, is displayed.

Note: The Mainframe Enablers Message Guide describes message SCF0417I.

3. Enter the following command to ConGroup:

F CONGROUP,CE GKREFR

Result: ConGroup begins using the new gatekeepers.

CE is a special command that stands for Command Entry. CE routes the command tokens that follow it to a general-service command processor in the ConGroup address space. This command processor is distinct from the command processor that handles most traditional ConGroup commands (such as ENABLE or REFRESH). The use of CE is not tied to GKREF or any other specific command.


Operations

Note: The ResourcePak Base for z/OS Product Guide provides more information about SCF INI.

Monitoring consistency groupsThe following sections describe how ConGroup monitors consistency groups.

Monitoring mode

As noted in “ConGroup monitoring” on page 23, ConGroup 7.0 or higher uses only RDF-ECA mode to monitor consistency groups. RDF-ECA monitoring mode provides enterprise-level consistency protection for synchronous devices by performing suspend operations across all SRDF/S devices in a consistency group.

Note: Starting with V7.0, ConGroup no longer supports IOSLEVEL monitoring.

RDF Enginuity Consistency Assist. RDF-ECA is an EMC technology that ConGroup can use to provide enterprise-level consistency protection for synchronous devices by performing suspend operations across all SRDF/S devices in a consistency group. This technology and other EMC technologies are grouped together as RDF Consistency.

RDF-ECA mode for consistency groups operates within the Symmetrix system and is supported by Enginuity 5x71.45 or higher. RDF-ECA mode can detect remote mirroring failures for both CKD (count key data) and FBA (fixed block architecture) devices. Therefore, consistency groups can include both mainframe and open systems devices.

In addition, RDF-ECA mode removes the requirement that a ConGroup instance be operational on all attached servers. This is because with RDF-ECA mode, the Symmetrix system, rather than the host processor, suspends writes during a ConGroup incident.

ConGroup can be in one LPAR and be visible to all other LPARs. This means only one ConGroup instance that consumes just one z/OS address space. This simplifies operation in multi-LPAR systems.

However, if EMC AutoSwap™ is operational on devices in any consistency group, ConGroup must be operational in all LPARs.

RDF-ECA, Domino mode, and UNPLANNEDCONDITIONS

The original consistency mechanism for SRDF is Domino mode (discussed in “domino mode” on page 228). While its behavior provides data integrity protection during rolling disasters, Domino mode is not often used because it stops all host I/O if data cannot be delivered to a target volume. This usually results in host application failures.

RDF-ECA has been extended to provide similar Domino mode behavior with a new Autoswap condition option, UNPLANNEDCONDITIONS=SYNCLINKFAILURE. The SYNCLINKFAILURE keyword allows work to continue if a successful swap occurs when configured with channel access to the target volumes. This provides a solution for sites needing to ensure that no additional work is processed unless the I/O is represented on the target volume.

Monitoring consistency groups 41

Operations

If a SRDF failure occurs, a swap is attempted. If the swap is successful, host application I/O continues on the target volumes. If the swap is not successful, then the host applications halt because the source devices are Not Ready to the host.

Note: “Autoswap “Swap On Link Failure” Swap Trigger” on page 48 and “CAXOPTS” on page 73 describe UNPLANNEDCONDITIONS and the various triggers you can use.

Monitoring process

ConGroup monitoring of consistency groups operates within the Symmetrix system and is supported by Enginuity 5x71.45 or later. ConGroup monitoring can detect remote mirroring failures for both CKD (count key data) and FBA (fixed block architecture) devices.

Therefore, consistency groups can include both mainframe and open systems devices. However, all devices should be defined to the mainframe host. Only groups with mainframe-defined devices trip successfully.

During daily operation, ConGroup monitors the SRDF links for signs that a write is unable to propagate to the remote target R2 side; that is, that the ending status for the write has not yet been presented to the application. When the Symmetrix system finds such a problem, it sets the ECA Window state to Open.

Note: “The gatekeeper server” on page 39 provides more information about the service tasks and their use.

Suspending operations

When a Symmetrix system determines that a write is not able to propagate to the R2 side, it defers completion of the current write operation, and enters a special state for a pre-determined time period. This state is the ECA Window Open state.

If ConGroup finds a Symmetrix system in the ECA Window Open state, ConGroup alerts all other Symmetrix systems defined in the consistency group to enter the ECA Window Open state.

Knowledge of the ECA Window Open state propagates to any other ConGroup host instance, protecting this consistency group when those instances poll. The result is all devices defined in this consistency group enter deferred write completion until the ECA Window is closed.

ConGroup then suspends, SRDF/S protection for all members of the consistency group. When the SRDF/S suspends are complete, ConGroup closes the ECA Window on all Symmetrix systems. Closing the ECA Window allows write I/O operations to resume.

This ensures that all devices on the target (R2) side of SRDF/S relationships in this consistency group definition are dependent write consistent.

Concurrent RDFEnginuity supports remotely mirroring a single primary volume to two secondary volumes concurrently. This feature is called Concurrent RDF and is available in both ESCON and Fibre Channel RDF configurations. ConGroup supports this RDF configuration with the SYMGROUP parameter.


Operations

Concurrent RDF requires that each secondary volume operate in the same primary mode, either both synchronous or both semi-synchronous, but allows either (or both) volumes to be placed into adaptive copy mode.

ConGroup needs you to define which of the RDF groups in the Concurrent RDF configuration are to be protected.

Figure 6 shows a concurrent RDF configuration in which one secondary volume is in synchronous mode and ConGroup protected, while the other is in adaptive copy and not ConGroup protected.

Figure 6 Concurrent RDF

Normal operating rules for SRDF also apply to concurrent configurations:

◆ When operating in synchronous mode, ending status for an I/O is not presented until the remote Symmetrix system acknowledges receipt of the I/O to the primary Symmetrix system.

◆ If both secondary volumes are operating in synchronous mode, ending status is not presented until both volumes acknowledge receipt of the I/O.

◆ If one volume is in synchronous mode and one volume is in adaptive copy mode, ending status is presented to the host when the synchronous volume acknowledges receipt of the I/O.

In Figure 6 on page 43, RDF Group 2 in Symmetrix system 00344 and RDF Group 4 in Symmetrix system 00345 are the RDF groups in synchronous mode to be protected by ConGroup. RDF Group 6 and RDF Group 7 are RDF groups in modes other than semi-synchronous and not monitored by ConGroup.

In this case, the SYMGROUP parameter would specify RDF Groups 2 and 4 are to be protected. If a ConGroup trip occurs, then all devices in the involved Symmetrix system are suspended.

Consistencygroup

R1a

R1b

R2b

R2a

R2a

R2b

SRDF group 4

SRDF group 2

SRDF group 6

SRDF group 7

0032200345

0035600344

z/OS

Monitoring consistency groups 43

Operations

Concurrent R2 (R22)Starting with Version 7.0, and available with Enginuity 5874 and higher, ConGroup recognizes concurrent R2 devices. Concurrent R2 are termed R22 devices. Concurrent R2 (R22) is an Enginuity feature that allows an R2 device to have two RDF mirrors. Each R2 mirror is paired with a different R1 mirror and only one of the R2 mirrors can be RW on the link at a time.

ConGroup can tolerate R22 devices; however, it treats R22 devices as R2 devices. Note that if the R22 is diskless, no operations can be performed.

R1 device sharing by mirror

Enginuity now allows independent mirror RDF-ECA, This allows for independent ConGroup protection in a Concurrent SRDF/Synchronous configuration. This means that if you decide to disarm the protection on one leg, the other synchronous leg can remain active and continue protecting the primary production site. (Previously, if one leg was disarmed, the other leg must also have been disarmed.)

This feature means that RDF ECA groups can be defined by R1 mirror instead of R1 device. To enable this feature, set the configuration parameter ALLOW_SHARED_R1S for a specific group or set the ALLOW_SHARED_R1S global configuration parameter. This causes duplicate checking of R1 devices to be replaced with duplicate checking at the mirror level. Then, any explicit or implicit SYMGROUP parameter statements you specify for the group used to assign mirrors to the group.

To summarize, R1 device sharing means that two groups can share an R1 device. This is done by issuing explicit or implicit SYMGROUP statements in separate group definitions to assign specific mirrors to each respective group.

Eligibility for sharing is determined by the order in which groups are specified in the configuration file. After an R1 mirror in an RDF ECA group is assigned to a consistency group, that mirror is no longer eligible for assignment to any subsequently defined consistency group.

Therefore, an R1 device can only be shared if it is concurrent. One of the mirrors is assigned to one group and the other mirror is assigned to another group. This means that each of the sharing groups must restrict their assignment of R1 mirrors to those mirrors not assigned by another group.

Note: If you attempt to use group sharing of an R1 with an Enginuity level not supporting R1 device sharing, ConGroup also returns an error.

Resuming protection

If a ConGroup trip occurs, you must follow a specific, planned procedure to return your site to normal operation. Chapter 3 provides an overview of the steps you need to follow to return your site to normal operation.


Operations

ConGroup AutoSwap ExtensionConGroup can optionally include the ConGroup AutoSwap Extension (CAX). CAX can move (swap) workloads from volumes in one set of Symmetrix systems to volumes in other Symmetrix systems without operational interruption.

Note: ConGroup AutoSwap was originally called Symmetrix Dynamic Address Switching (S/DAS). Messages you receive from ConGroup AutoSwap may still refer to S/DAS.

CAX is a licensed feature. To use the ConGroup AutoSwap extension, you must ensure you have an active license. Consult the Mainframe Enablers Installation and Customization Guide for information on licensing MFE components.

CAX performs swaps while application workloads continue in conjunction with ConGroup.

CAX uses the Cross System Communication Component (CSC) of ResourcePak Base for communication. The CSC component uses the Symmetrix system to communicate changes in consistency groups between ConGroup instances on different LPARs.

Swap types

When your site configures independent channel paths to connected Symmetrix systems with the secondary (R2) volumes and when SRDF is operating in synchronous mode, you can perform a non-disruptive swap from the primary (source) to secondary (target) volumes.

Swaps can be manually initiated as planned events or automatically as unplanned events upon failure detection.

Planned swaps support activities such as building maintenance, power reconfiguration, DASD relocation, or channel connectivity reorganization.

Unplanned swaps protect systems against various interruptions that are the result of total channel loss, an intervention required on one or more devices, or outages. Outages can include power supply failures, building issues, air conditioning problems, channel connectivity, or entire DASD subsystems failures, operator error, or the consequences of intended or unintended sprinkler discharge.

Device swap groups

The bases of swaps are consistency groups. To accomplish a non-disruptive switch from the primary (local) to the secondary (remote) volumes, you extend the defined consistency group so that it is part of a device swap group.

In certain circumstances, swapping back to the original configuration can be easily achieved using a complement group. A complement group is a named set of devices to which normal operations for the devices in an associated consistency group are restored after an outage. You associate a CAX consistency group with a complement group by defining a complement group through AutoSwap or through GNS.

Note: “Defining complement device groups” on page 53 describes the various methods you can use to define complement groups.

ConGroup AutoSwap Extension 45

Operations

Using the ConGroup AutoSwap Extension

To use ConGroup AutoSwap Extension, you set two configuration parameters:

◆ CAXOPTS

◆ CAX

The CAXOPTS configuration parameter allows you to create an options set. Each options set is a collected series of parameter statements that specify how ConGroup handles a set of devices for AutoSwap processing. You identify each options set with a name of from one to eight characters.

The CAX configuration parameter allows you to activate ConGroup AutoSwap on a consistency group by consistency group basis. Each consistency group needing Autoswap protection must include one CAX statement.

Note: “CAXOPTS” on page 73 and “CAX” on page 101 provide descriptions of these parameters.

Each consistency group definition that includes CAX needs to have a single identified owner. The owner is the LPAR responsible for AutoSwap activity coordination. You specify the owner through the OWNER= subparameter.

Note: “GLOBAL” on page 85 describes the OWNER= subparameter.

At startup, ConGroup validates the device swap group. During operation, ConGroup monitors the consistency group devices. If a failure event occurs or if you initiate a planned swap, ConGroup determines whether to:

◆ Trip the consistency group and preserve a consistent image of the data on the R2 devices.

◆ Invoke a swap of the ConGroup primary devices in the device swap group to the secondary devices in the device swap group on the secondary Symmetrix system.

◆ Enter a system halt state while the reconfiguration takes place and hold I/O to the ConGroup protected devices. After the reconfiguration, operations are automatically restored to the R2 devices specified in the AutoSwap COMPLEMENT argument.

Note: CAX coordinates these actions with any other LPARs that have access to the ConGroup protected devices.

After the halt, operations are automatically restored to the devices specified by the AutoSwap COMPLEMENT argument.

Note: ConGroup AutoSwap supports only one mirror in a concurrent RDF environment. “SYMGROUP” on page 111 provides information about how to narrow your protected mirror list to one mirror.


Operations

Resuming operation

After an AutoSwap event occurs, you can resume ConGroup protection by taking the following steps:

1. Define a complement group to the original protected group.

2. Swap the data from the original protected group (now on R2 devices) to the complement group.

3. Return the data from the complement group to the original R1 group.

4. Resynchronize SRDF so the I/O can begin on the restored primary R1 devices.

5. Reenable the consistency group.

If the consistency group contains dynamic SRDF devices, then you perform SRDF personality swaps. Personality swaps are the fastest and safest way of resuming ConGroup protection. In a personality swap, R1s become R2s, and R2s become R1s.

Note: Chapter 3 in this guide provides a description of how to return your site to normal operation.

Ownership takeover

All consistency groups defined with the CAX capability must have a single owning LPAR. This is where the single ConGroup instance that is responsible for AutoSwap activity coordination is running.

However, there may be times when you need to change the ownership to a different LPAR; for example:

◆ When you need to perform maintenance on the current owning LPAR

◆ When the owning LPAR goes down

In earlier versions of ConGroup, if you needed to change the ownership of consistency groups from the current owning LPAR to another LPAR, you had to make that change manually by changing the ownership specification in the configuration file and reinitializing the consistency group in a different LPAR.

ConGroup CAX allows the movement of the ownership attribute from one LPAR to another LPAR in the consistency group. As discussed earlier, the ConGroup MOVEOWNER and TAKEOVER operator commands reassign ownership without having to reinitialize all participating ConGroup instances.

In normal operations, when both the current owning LPAR and the LPAR you want to make owner are running, you use the MOVEOWNER command to transfer consistency group ownership.

In a situation where the owner LPAR is not running, you use the TAKEOVER command to transfer ownership to another LPAR that is currently running.

Keep in mind that both the MOVEOWNER and TAKEOVER command use the SMF IDs assigned to the LPARs - as does the OWNER= subparameter of the GLOBAL parameter where the owning LPAR is first specified. Each SMF ID is a unique name of up to four characters.

ConGroup AutoSwap Extension 47

Operations

After a timeout period, ConGroup cleans up hung locks left behind on other nodes when a ConGroup node fails.

The new ownership you assign lasts as long as any single participating ConGroup is active. If all ConGroup instances are shutdown and then restarted, ownership reverts to the GLOBAL parameter OWNER= subparameter specification in the configuration file.

Note: “MOVEOWNER” on page 138 and “TAKEOVER” on page 146 describe how to change ownership.

Autoswap “Swap On Link Failure” Swap Trigger

The UNPLANNEDCONDITIONS CAX option of the CAXOPTS configuration parameter allows you to specify AutoSWAP swap triggers. There were three AutoSwap triggers:

◆ INTERVENTIONREQUIRED

◆ NOPATHS

◆ SYNCLINKFAILURE

Use of SYNCLINKFAILURE requires RDF-ECA. This trigger causes a swap by programmatically setting devices to Not Ready whenever an SRDF link failure occurs.

From an AutoSwap point of view, this is identical to INTERVENTIONREQUIRED. The difference is that the Not Ready condition is set by ConGroup in response to a synchronous link failure.

Note: “CAXOPTS” on page 73 describes the UNPLANNEDCONDITIONS CAX options. The SRDF Host Component for z/OS Product Guide describes the SRDF Domino mode.

More information

You can find more information about using AutoSwap in the AutoSwap for z/OS Product Guide.

IODF considerations

Support for IODF configuration changes

To protect actively managed groups from accidental disruption due to IODF ACTIVATEs of configurations to remove access devices (in other words, gatekeepers) from z/OS, ConGroup now pins its access devices using the IBM UCBPIN service. The new #DISPLAY GATEKEEPERS command shows which devices are pinned. ConGroup automatically pins and unpins gatekeepers based on which controllers include R1 devices that ConGroup has defined in any protected groups.

In concert with this change, ConGroup has been modified to no longer require UCB access to any protected devices, no matter how they are defined in the ConGroup configuration file. Previously, for example, SCFG (GNS) specification of devices causes ConGroup to attempt to access the protected R1s through their UCBs (if available). This access occurred


Operations

at startup, refresh, AutoVerify, and other processing. With routine access to local UCBs eliminated, and with the advent of pinned gatekeepers, ConGroup’s manageability is enhanced.

Addition and Deletion of Controllers and Gatekeepers

When ConGroup starts, it queries its connected SCF to determine which controllers are available. The returned list of controllers includes the identity of gatekeeper devices defined or defaulted in the SCF configuration file. ConGroup creates a subtask for each controller and a single subtask to manage the list of gatekeepers for all of the controllers. Other processes in ConGroup then request gatekeepers from the gatekeeper subtask whenever they wish to access a particular controller.

As described above, all gatekeepers are kept pinned by ConGroup as long any devices on those controllers are defined in any congroup. If multiple gatekeepers are defined, ConGroup may use more than one concurrently. If a user needs to remove a gatekeeper from ConGroup (for example, so that it can be removed from the IODF configuration), it must first be unpinned. This can be done in one of two ways. First, the group or groups that “touch” the controller in question can be removed from ConGroup’s configuration. This can be done by dynamic deletion (using the ConGroup DELETE command) of all relevant devices, or by Refreshing the group out of existence, or by shutting down ConGroup. The other method is to unpin the target gatekeepers. This is done with the ConGroup #UNPIN command. The #UNPIN command only works against pinned gatekeepers if there remains (after the unpin) at least one gatekeeper to that controller. In other words, you can’t unpin all the gatekeepers to a controller.

When new controllers are introduced to SCF (via INI file change or by IODF configuration change), SCF notifies ConGroup. ConGroup then automatically incorporates any new controllers by building new subtasks and by updating its gatekeeper list. Since new controllers do not (initially) have any ConGroup protected devices, they will not have any pinned gatekeepers. However, as soon as any device on one of the new controllers is added to a group, all the gatekeepers on that controller are pinned. Deletions from the INI file do not cause a commensurate deletion of controller subtasks and gatekeeper structures from ConGroup.

IODF considerations 49

Operations


CHAPTER 3Resuming Operations after a ConGroup AutoSwap

Invisible Body Tag

This chapter describes the steps you must take to resume ConGroup, SRDF, and AutoSwap-protected host operations after a ConGroup AutoSwap event.

◆ Introduction............................................................................................................ 52◆ Handling page datasets .......................................................................................... 52◆ Defining complement device groups........................................................................ 53◆ Executing command initiated swaps ....................................................................... 54◆ Resynchronizing SRDF............................................................................................. 55◆ Enabling the consistency group............................................................................... 55

Note: This chapter describes procedures that involve other EMC products: EMC AutoSwap and SRDF Host Component. You can find more information about these products in the AutoSwap for z/OS Product Guide and the SRDF Host Component for z/OS Product Guide.

Resuming Operations after a ConGroup AutoSwap 51

Resuming Operations after a ConGroup AutoSwap

IntroductionThe resumption of ConGroup, SRDF, or AutoSwap protected host operations after an AutoSwap event requires careful planning. At your site after the swap, the applications are still running (if the swap was caused by an unplanned outage) and the target (R2) devices have become the new primary devices.

The swap back, returning to the original source (R1) devices, may be accomplished in the following steps using ConGroup or AutoSwap:

1. If page dataset devices are in a consistency group, perform a dynamic SRDF personality swap on the page dataset devices before the swap back is initiated. ConGroup AutoSwap operates upon page datasets only when they are on SRDF R1 devices.

This dynamic SRDF personality swap must be done prior to initiating the swap back. After the swap to the original R1 group is complete, another SRDF personality swap must be performed on the page dataset devices.

Note: The devices must be dynamic for the SRDF personality swap to take place successfully. If the devices are not dynamic, the SRDF personality swap will not work.

2. Define a complement device group.

3. Swap the data from the original protected group (now on the R2 devices) to a complement group and return the data from the complement group to the original R1 group.

Note: If the original event was an unplanned swap that involved FBA devices, you need to specify the CAX option UNPLANNEDOPTIONS(FBAUSRNRDY) to make the R2 devices Not Ready on the channel. “CAXOPTS” on page 73 describes UNPLANNEDOPTIONS(FBAUSRNRDY).

4. Resynchronize SRDF so that I/O can begin on the restored primary R1 devices.

5. Re-enable the consistency group.

Handling page datasetsIf page datasets are included in the consistency group, you must perform a dynamic SRDF personality swap on these devices. Consistency groups that contain devices with page datasets must also include at least one non-page dataset device.

Unlike other devices in the original protected group (now on the R2 devices), ConGroup AutoSwap only swaps consistency groups containing page datasets from R1 to R2 devices.

Use SRDF Host Component to perform the dynamic SRDF personality swap. You can find information about this process in the SRDF Host Component for z/OS Product Guide.



Defining complement device groups To use complement groups, you must create a group defined as the complement of the consistency group that was involved in the AutoSwap event that swapped to the secondary R2 devices. You can define complement groups in three ways:

◆ With the DAS DEFINE COMPLEMENT operator command issued through the still-running ConGroup.

◆ With a complement group definition in the CONFIGCA DD file.

◆ Through the DEFINE COMPLEMENT command in Group Name Services of ResourcePak Base.

Note: A complement group definition created through the DAS DEFINE COMPLEMENT operator can be used only if the task that executed the AutoSwap event is still running. Therefore, EMC recommends that you create your own complement definition to be used as an alternative when the ConGroup task is not running. “Using CONFIGCA” on page 54 describes the CONFIGCA DD file.

Using the AutoSwap DEFINE GROUP command

If the ConGroup task that executed the AutoSwap event is still running, the swap back procedure needs to use a device group defined as a complement to the group that was part of the event to the secondary R2 devices.

You create the complement group using the COMPLEMENT option of the AutoSwap DEFINE GROUP operator command as follows:

DAS DEFINE GROUP complementgroup COMPLEMENT originalgroup [options]

Where:

complementgroup

The name for the complement group. This name has the same requirements as that of any consistency group: no more than eight characters.

originalgroup

The name for the original group that was part of the autoswap event. This name also has the same requirements as that of any consistency group: no more than eight characters.

options

The optional parameters defined for the complement group. The options specified in this statement apply to the complement group, not the original group.

The parameters for the original group and its complement do not have to be the same. For example:

DAS DEFINE GROUP returngroup COMPLEMENT prodgroup RETAIN SWAPCONTROL=BYDEVICE

prodgroup

The monitored group

Defining complement device groups 53


returngroup

The complement of the monitored group.

As a ConGroup AutoSwap group, prodgroup is defined with SWAPCONTROL=BYGROUP. In the example above, the returngroup is defined with SWAPCONTROL=BYDEVICE.

Note: The AutoSwap Product Guide describes the options you can select.

You can define the complement group at any time after you have defined the original consistency group. When defined before a ConGroup AutoSwap event, the complement group is created, but is not populated with devices.

The “swap-back” device definition for the complement group occurs automatically during the ConGroup AutoSwap event, so that the swap back definition defines only the devices that were auto swapped.

Using CONFIGCA

If the task that executed the swap event has been stopped and then restarted, you cannot use a COMPLEMENT definition. Instead, you must have externalized the definition of the complement group (the “swap back” group) in a user-defined file. Then, specify this file in the ConGroup JCL as the CONFIGCA DD statement.

The following example shows such a definition for ConGroup:

//EMCCGRP PROC PRFX='EMC.CONGROUP',CONFIG=CGRPCFG0, // SCFPRFX='EMC.SCF' //* //CONGROUP EXEC PGM=CGRPMAIN,REGION=0M //STEPLIB DD DSN=&PRFX..LINKLIB,DISP=SHR // DD DSN=&SCFPRFX..LINKLIB,DISP=SHR //CONFIG DD DSN=&SCFPRFX..SAMPLIB(&CONFIG.),DISP=SHR //CONFIGCA DD DSN=complementgroup,DISP=SHR

Using Group Name Services

You can also use DEFINE COMPLEMENT command of the Group Name Services in ResourcePak Base to create a complement group. The ResourcePak Base for z/OS Product Guide describes the DEFINE COMPLEMENT command.

Executing command initiated swapsWhen you have consistency groups defined, you can perform swaps of the complement group (the swap-back group) through ConGroup.

To execute a command-initiated manual swap through ConGroup, you use the DAS command, as follows:

F EMCCGRP,DAS SWAP GROUP returngroup

Where:

returngroup

The complement group



Resynchronizing SRDFThe swap back operation using DAS SWAP performs the necessary steps of SRDF resynchronization, so that I/O may begin on the primary R1 devices. This operation is documented in the SRDF Host Component for z/OS Product Guide.

Enabling the consistency groupIf you are running in multi-mode, (the default) the commands are globally communicated, and don't need to be issued on all LPARS. The exception to this is the DISABLE command. The purpose of the DISABLE is to turn off the consistency group setting on the devices defined in the consistency group. If you are running without a CAX group, a disable on one LPAR disables on all LPARS. However, if you are running with a CAX group, you should issue the DISABLE command (or, a DAS DEL GRP grpname command issued) on the owner LPAR to remove the AutoSwap group.

Following the procedures outlined below, using commands in to enable the consistency group.

In the following procedures:

emccgrp

The ConGroup task

cgpgname

The consistency group name

backgrp

The swap back group

Enabling in single-LPAR mode

The following instructions explain how to enable a consistency group in single-LPAR mode, where the ConGroups instances are not communicating with one another.

Note: In single-LPAR mode, if you do not issue the following commands in the owner LPAR, it may look like the ConGroup is in an Enabled/Active state, but the AutoSwap group may not be ready for a swap event. Both the ConGroup and AutoSwap displays should be issued at the end of the procedures to verify that the group(s) are in a desired state.

Delete the AutoSwap group from the owner LPAR to do a REFRESH Issue the following commands:

1. Delete the AutoSwap group from the owner LPAR:

F emccgrp,DAS DEL GRP cgpgpname

2. Refresh on the non-owner LPAR(s):

F emccgrp,REFRESH FORCE

3. Refresh on the owner LPAR:

F emccgrp,REFRESH FORCE

Resynchronizing SRDF 55


Verify that the ConGroup is Enabled/Active, the AutoSwap group is defined, and the devices are in an auto-swappable state. Issue the following commands:

F emccgrp,DIS CON cgpgpname

F emccgrp,DAS DIS GRP cgpgpname DET

After a ConGroup trip but before starting the resume process, you must delete the AutoSwap group. Issue the following commands:

1. Delete the AutoSwap group from the owner LPAR:

F emccgrp,DAS DEL GRP cgpgpname

2. Resume ConGroup on the non-owner LPAR(s):

F emccgrp,RESUME cgpgpname

3. Resume ConGroup on the owner LPAR:

F emccgrp,RESUME cgpgpname

Verify that the ConGroup is Enabled/Active, the AutoSwap group is defined, and the devices are in an auto-swappable state.

F emccgrp,DIS CON cgpgpname

F emccgrp,DAS DIS GRP cgpgpname DET

Swap back the device UCBs. Issue the following command(s):

1. Create the group to swap back and optionally swap immediately following the group definition, on the owner LPAR:

F emccgrp,DAS DEF GRP backgrp COMPLEMENT

Optionally use the SWAPIMMED option to swap immediately following the group definition.

2. Verify all of the devices have swapped back.

3. Enable the consistency group on the non-owner LPAR(s):

F emccgrp,ENABLE cgpgpname FORCE

4. Enable the consistency group on the owner LPAR:

F emccgrp,ENABLE cgpgpname FORCE

Ensure that step 3 completes successfully. Otherwise the consistency group may appear to be in an acceptable state but the AutoSwap group has not been defined.



Enabling in multi-LPAR mode

If you are running in multi-mode, (MODE=MULTI) the commands are globally communicated, and don't need to be issued on all LPARS. Bring up the consistency group on any LPAR, by issuing the following:

/s emccgrp

The exception to this is the DISABLE command. The purpose of the DISABLE is to turn off the consistency group setting on the devices defined in the consistency group. If you are running without a CAX group, a disable on one LPAR disables on all LPARS. However, if you are running with a CAX group, you should issue the DISABLE command (or a DAS DEL GRP grpname command) on the owner LPAR to remove the AutoSwap group.

Enabling the consistency group 57

CHAPTER 4Database Considerations

I

This chapter provides considerations for using ConGroup with DB2, IMS and multiple database management systems.

◆ Introduction............................................................................................................ 60◆ DB2 considerations................................................................................................. 62◆ IMS considerations ................................................................................................. 64◆ Mixed database considerations............................................................................... 65

Database Considerations 59

Database Considerations

IntroductionWhen in RDF remote mirroring in campus mode across two or more control units, a database management system can have its logs or data on different control units. When failures occur, they do not occur consistently. On one secondary (remote) device, a write failure or an RDF link failure can occur while on another secondary (remote) device, the data flow continues from the primary (local) devices.

Then, the various elements in a dependent data stream are out of synchronization.

ConGroup and database I/O

ConGroup keeps dependent I/O synchronized when its data is spread across multiple Symmetrix systems. Typical database management, system-generated, dependent I/O consists of:

◆ Logs

◆ Application data

◆ Metadata

◆ System data

The dependent I/O occurs only after its predecessor I/O successfully completes. When such I/O spans multiple Symmetrix systems, ConGroup’s purpose is to freeze dependent I/O when predecessor I/O is unsuccessful because of a device or link failure.

Note: In all cases, the devices potentially related by I/O dependency must be defined in the consistency group’s device list. “DEVICE_LIST definitions” on page 60 describes device lists.

Database consistency group suspensions

The effect of a consistency group suspension on a database management system is similar to that of a z/OS power-loss outage. The database management system does not have an opportunity to properly flush buffers or close logs and database files. Under such circumstances, a warm or emergency startup of the database management system resolves any data inconsistencies caused by the outage, as long as the DBMS has the necessary log records to perform backout to a prior point of consistency.

DEVICE_LIST definitions

As discussed previously, all devices used for related dependent I/O must be defined in one consistency group. If you are a database administrator, make sure that you include the following types of volumes in the consistency group device list:

◆ Volumes where log and system data resides.

◆ Volumes where application data resides.

Note: You should group application data with the logs because application data I/O is dependent on the logs. Failure to do so negates the purpose of ConGroup protection.



◆ Volumes that contain the system data of any transaction processor, such as CICS, that you use to coordinate synchpoints, commits, or checkpoints -- between either IMS, DB2, or both.

If your site does not use SMS, you, as database administrator, must constantly monitor the migration of database data to ensure that the secondary devices remain within an active consistency group’s device list.

Expanding to new devices

When you expand I/O to devices outside an existing active consistency group, you need to:

◆ Perform a device list update

◆ Issue the ConGroup REFRESH command, for example:

F EMCCGRP,REFRESH

Note: “REFRESH” on page 141 describes the REFRESH command.

Specifying an SMS group in the group’s devicelist, greatly simplifies this task by keeping the contents of the consistency group’s device list static.

Note: “SMS_GROUP” on page 108 provides information about SMS groups.

Other configuration parameters

EMC recommends that you use SUSPEND_FAILURE=RETRY or WTOR if remote data integrity must take precedence over local database availability.

Note: “SUSPEND_FAILURE” on page 108 describes this parameter and its possible values.

If a SUSPEND I/O fails because of an unavailable path after you use SUSPEND_FAILURE=RETRY, ConGroup suspends local I/O and retries the SUSPEND until the SUSPEND_TIMEOUT value is exceeded.

If you want local database availability to take precedence over remote data integrity, choose SUSPEND_FAILURE=FAIL. This parameter allows local I/O to resume immediately upon experiencing a SUSPEND I/O failure because of an unavailable Symmetrix link.

Recovery site startup

The devicelist configuration ensures that I/O to devices containing log data is never superseded by I/O to devices containing application or system data. Conversely, if a recovery site log has signaled that a unit-of-work (UOW) has completed, while I/O had not reached its remote target database, the incomplete UOW on the database would not be detected because the recovery would be driven by end-UOW records present on the log.

Introduction 61


ConGroup ensures that both data and logs remain synchronized so that database management system startup can resolve such transient data inconsistencies. Database management system startup rolls back database updates to a prior checkpoint or commit point. Avoid any type of restart that suppresses this process, such as a cold start, if you want consistent data.

DB2 considerationsThe following sections describe considerations you should keep in mind if you use DB2.


Volumes in the ConGroup devicelist for a DB2 group must include all volumes where DB2 system data and all other application tablespaces reside. DB2 system data whose devices must be included are:

◆ ICF CATALOGS◆ ARCHIVE LOGS◆ BSDS01◆ BSDS02◆ LOGCOPY1.DS01 - LOGCOPY1.DSnn◆ LOGCOPY2.DS01 - LOGCOPY2.DSnn◆ DSNDB01◆ DSNDB04◆ DSNDB06◆ DSNRLST ◆ DSNDDF (V4 or lower)◆ DSNRGFDB (if used)

You should include devices containing linear datasets comprising all DB2 application data, vendor applications, and the Query Management Facility (QMF). To make this devicelist comprehensive, include all potentially usable devices found in SYSIBM.SYSVOLUMES that are pointed to by DB2 storgroups during the devicelist definition.

Stogroups can span to such volumes when currently used volumes no longer contain room for tablespaces defined after the devicelist has been defined. Such tablespaces would be unintentionally excluded from the consistency group if the currently unused devices in SYSIBM.SYSVOLUMES were not included. Of course, an ALTER STOGROUP sgname ADD VOLUMES (volser list) should also be reflected in an updated devicelist followed by a REFRESH command.

You may exclude DSNDB07 because it is not required for DB2 recovery site restart. You can exclude DSNDB07 with the EXCLUDE parameter.

Note: “EXCLUDE” on page 106 provides more information about the exclude process.

If you exclude DSNDB07, no other DB2 data can share its devices. Sharing those devices may cause this data to be unintentionally unprotected. For the same reason, you must also remove this database’s devices from any SMS storage groups to prevent SMS from moving needed files to devices shared with this database. You can allocate DSNDB07 at the recovery site just before DB2 restart.



DB2 consistency group configuration example

The following is an example of a configuration file entry for DB2 consistency group:


When a consistency group is tripped and DB2 startup commences at the recovery site, you need to permit a warm start to resolve in-progress, in-commit, in-abort or in-doubt Units-of Recovery (URs) so that they are either committed or rolled-back. This is the only way that ConGroup can guarantee data consistency. The DB2 log contains the data it needs to perform DB2 roll-forward and backward recovery of incomplete Unit-of-Recovery-IDs (URIDs) during the warm start process.

EMC does not recommend that you use a cold start, or conditional restart, which suppresses the UR recovery. Use cold starts with extreme caution, and only after you examine the DB2 active logs to determine if incomplete URIDs do not exist.

Whether or not you use ConGroup protection, avoid long-running update tasks with low commit-to-update ratios. Such tasks cause extended restart times.

RESUME_INTERVAL=60SRDF_CONGROUP=DB2PROD* The following device list ranges represent devices where * all DB2 system and application data resides.DEVICE_LIST=2F0-2FB,DB2001,DB201FSMS_GROUP=DB2GRP* The following excludes DB2005, DB2007 * for DSNDB07. No other critical data may share these devices. EXCLUDE=DB2005,DB2007SUSPEND_FAILURE=RETRYSUSPEND_TIMEOUT=30

DB2 considerations 63


IMS considerationsThe following sections describe considerations you should keep in mind if you use IMS.


Depending on the IMS configuration, include devices containing only IMS system datasets in the consistency group definition, in addition to those containing application databases, as follows:

◆ DFSOLP00 - DFSOLPnn◆ DFSOLS00 - DFSOLSnn◆ DFSWADS0 - DFSWADSn◆ RECON1◆ RECON2◆ RECON3◆ MODSTAT◆ MODBLKS◆ MATRIX◆ ACBLIB◆ FORMAT◆ RDS◆ QBLKS◆ SHMSG◆ LGMSG

IMS consistency group configuration example

The following is an example of a configuration file entry for an IMS consistency group:


When a consistency group is suspended and IMS startup begins at the recovery site, you need to allow IMS to undergo an emergency restart. The emergency restart permits IMS to close the previously active log and backout databases to a prior checkpoint encountered on the WADS and OLDS.

To permit an emergency restart, issue the command:

/ERE OVERRIDE

Then, wait for message DFS3257I, followed by message DFS994I.

RESUME_INTERVAL=60SRDF_CONGROUP=IMSPROD* The following device list ranges represent devices where * all IMS system and application data resides.DEVICE_LIST=2E0-2EB,IMS001,IMS01FSMS_GROUP=IMSAPPSSMS_GROUP=IMSWADSSMS_GROUP=IMSOLDS* The following excludes IMS005, IMS007.* No other critical data may share these devices. EXCLUDE=IMS005,IMS007SUSPEND_FAILURE=FAIL



EMC does not recommend an IMS cold start. A cold start does not perform all log closes and database backouts. Use a cold start with extreme caution only after:

◆ Examining the OLDS by running DFSULTR0 in PSB mode

◆ Obtaining a list of active PSBs

◆ Performing batch backout against WADs and OLDs

Mixed database considerationsIn the case of hybrid applications which use multiple database management systems (for example, IMS and DB2) within the same unit of work, use one common consistency group definition.


If there is no logical relationship between data in multiple database management systems, you can use separate consistency group definitions. However, if these separate consistency group definitions contain common devices, they do, in effect, behave as a single consistency group.1 This is because the RDF suspension of the intersecting devices caused by one group triggering also causes the other group to trigger.

Hybrid consistency group configuration example

The following is an example of a configuration file entry for a hybrid consistency group:

1. Different consistency groups containing common devices are called intersecting consistency groups.

RESUME_INTERVAL=60 SRDF_CONGROUP=COMMON * The following device list ranges represent devices where * all IMS system and application data resides. DEVICE_LIST=2E0-2EB,IMS001-IMS01F SMS_GROUP=IMSAPPS SMS_GROUP=IMSWADS SMS_GROUP=IMSOLDS * The following excludes IMS005, IMS007. * No other critical data may share these devices. EXCLUDE=IMS005,IMS007 * The following device list ranges represent devices where * all CICS system data and journals resides. DEVICE_LIST=2D0-2DB,CIC001-CIC01F SMS_GROUP=CICJRL * The following device list ranges represent devices where * all DB2 system and application data resides. DEVICE_LIST=2F0-2FB,DB2001,DB201F SMS_GROUP=DB2GRP SMS_GROUP=DB2LOGS * The following excludes a subset of range DB2005,DB2007 * for DSNDB07. No other critical data may share these devices. EXCLUDE=DB2005,DB2007 SUSPEND_FAILURE=RETRY SUSPEND_TIMEOUT=45

Mixed database considerations 65



In addition to database management system specific restart issues, you should consider the following recovery site operational issues.

◆ DB2 restart may produce indoubt threads that must be resolved with the DB2 command:

-RECOVER INDOUBT connection name ACTION (ABORT)

You can identify indoubt threads by issuing the command:

-DISPLAY THREAD (*) TYPE (INDOUBT)

◆ IMS restart may also produce indoubt threads that you can identify by issuing either of the following commands:

/DIS CCTL ALL INDOUBT

or

/DIS OASN SUBSYS ALL

Following recovery site restart, such scenarios result when both the transaction manager and the database management system logs have not recorded completion of a two-phased commit on the target (R2) devices at the recovery site. Use of separate database management system-specific consistency groups are more likely to cause this problem.


CHAPTER 5Configuration

This chapter describes the Congroup configuration file and configuration parameters.

◆ Introduction to configuration parameters ................................................................ 68◆ Global configuration parameters ............................................................................. 69◆ Consistency group-specific configuration parameters .............................................. 97

Configuration 67

Configuration

Introduction to configuration parametersConGroup requires a configuration file. The configuration file includes two types of configuration parameters:

◆ Global configuration parameters that specify general ConGroup operation

◆ Consistency-group specific configuration parameters that define a particular consistency group

You specify ConGroup configuration parameters as a series of statements in the following format:

keyword = value

The following rules apply:

◆ keyword must begin in column one.

◆ You can include a comment on a parameter line as follows:

keyword=value /* comment text */

◆ A consistency group name is defined first, immediately followed by the devices in the consistency group.

◆ The parameter statements should be saved as a member of a parameter library which is pointed to by the CONFIG DD statement of the ConGroup started task JCL.

Note: You can find a sample configuration file in the CGRPCFG0 member in the CGP SAMPLIB (SMP/E DDNAME: CGPSAMP).

Syntax conventions

EMC command and parameter syntax conventions include the following:

◆ Keywords appear in uppercase (for example, DISABLE). They must be spelled exactly as shown.

◆ Variables appear in lowercase and italics (for example, column-name). They represent user-supplied names or values in the syntax.

◆ Default values are indicated by underlining the value. For example, (YES|NO) indicates that NO is the default value.

◆ If punctuation marks, parentheses, arithmetic operators, or other such symbols are shown, you must enter them as part of the syntax.



◆ | = alternative argument values

◆ cuu = Specifies the z/OS device number on the Symmetrix control unit.

◆ cuu-cuu = Specifies a range of z/OS device numbers, where the first cuu is the starting z/OS device number of the range and the second cuu is the ending z/OS device number of the range. The ending device number must not be less than the starting device number.


Configuration

◆ symdev# (or device) = This parameter specifies a Symmetrix device number, specified in hex. To specify a range of Symmetrix device numbers, use the form of dev1-dev2 where dev1 is the starting Symmetrix device number and dev2 is the ending Symmetrix device number.

Note: If ALL is specified, all devices on the Symmetrix system that are eligible for the specified action are affected.

In addition, refer to “Conventions used in this document” on page 15 for additional information regarding conventions used in this manual.

Defaults

As of release 7.6, commands with YES|NO responses now default to NO instead of YES.

Global configuration parametersGlobal configuration parameters affect all consistency groups used with the current instance of ConGroup. Place global configuration parameters first in the configuration file, followed by consistency-group specific configuration parameters that define one or more consistency groups.

Note: “Consistency group-specific configuration parameters” on page 97 provides descriptions of those configuration parameters you use to define a particular consistency group.

The global configuration parameters include the following:

◆ AUTO_REFRESH

◆ CLOCKE

◆ CLOCKN

◆ COUPLEDS_ALLOWED

◆ DISABLE_AT_SHUTDOWN

◆ DISABLE_ON_VERIFY_ERROR

◆ DISPLAY_CONGROUP_LISTOPT

◆ GLOBAL

◆ MODE

◆ MSGLEVEL

◆ PAGEDEV_ALLOWED

◆ REMSPLIT_INTERVAL

◆ REMSPLIT_OPTION

◆ RESUME_INTERVAL

◆ RESUME_OPTION

◆ SAF_CLASS

Global configuration parameters 69

Configuration

◆ SAF_PROFILE

◆ SEMISYNC_ALLOWED

◆ USE_FBA_NR_ON_TO

◆ USE_RDF_ECA

◆ VERIFY_INTERVAL

ALLOW_SHARED_R1S

PurposeALLOW_SHARED_R1S allows you to either allow or disallow the definition of RDF ECA groups by mirror for all consistency groups you define.

If you allow definition of RDF ECA groups by mirror for all consistency groups, duplicate device checking is replaced by duplicate checking at the mirror level. Any explicit or implicit SYMGROUP statements defined for all consistency groups are used to assign mirrors to those group.

If you disallow the definition of consistency groups by mirror (the default), ConGroup does not use duplicate checking at the mirror level. SYMGROUP statements defined for consistency groups do not assign mirrors to those groups.

Note: “Consistency group states” on page 35 provides more information.

Parameter typeConsistency-group specific

Syntax

ALLOW_SHARED_R1S={YES|NO}

Argument

YES

Allow the definition of consistency groups by mirror.

NO

(Default) Do not allow the definition of consistency groups by mirror.

Comments◆ ALLOW_SHARED_R1S=YES permits concurrent SRDF devices (though use of mirrors) to

be in two consistency groups. This allows you to retain protection in one leg if the Mainframe Enablers other leg trips.

Consider the following example using consistency groups 04 and 05 in controller MEDREC:


Configuration

◆ When you set ALLOW_SHARED_R1S to YES, you can use the SYMGROUP parameter to indicate which group is protected using ECA.

• If the SYMGROUP configuration parameter is applied to both consistency groups, ConGroup protects both legs.

• If the SYMGROUP configuration parameter is omitted, ConGroup also protects both legs.

• If the SYMGROUP configuration parameter was applied to only one of the groups, then only that group would be protected.

Note: “SYMGROUP” on page 111 provides more information.

Only protected groups can trip. However, when any protected group trips, all protected groups are suspended.

◆ Trying to specify definition by mirror to R1 devices whose Enginuity level not supporting R1 device sharing generates an error.

Example ALLOW_SHARED_R1S=YES

AUTO_REFRESH

PurposeAUTO_REFRESH controls the ConGroup mechanism that detects when a device becomes varied online. ConGroup checks to see if that device should belong to a consistency group, and automatically generates a REFRESH command statement if needed. AUTO_REFRESH is ignored if the consistency group is a CAX group.

Note: “REFRESH” on page 141 provides more information.

Parameter typeGlobal

Syntax

AUTO_REFRESH={NO|YES}

SRDF_CONGROUP=MEDRECSUSPEND_FAILURE=FAILSUSPEND_RETRY_TIMEOUT=45SYMGROUP=(DLR1,04)DEVICE_LIST=8A00-8A0F

Group 04 is ECA protected. An ECA event onthe 04 leg suspends 04, but not 05.

ECA protection is not enabled on the consistencygroup 05 leg. For consistency purposes, 04 or 05 leg events have no effect on 05.


Configuration

Arguments

NO

(Default) REFRESH command statements are not automatically generated.

YES

REFRESH command statements are automatically generated.

Comments When you define a consistency group, you can include devices in the consistency group by specifying an SMS group or a volser mask. If a device becomes varied online, and that device belongs to a specified SMS group or fits a specified volser mask, ConGroup generates a REFRESH command statement so that the new device is included into the consistency group.

For example, suppose the definition of a consistency group contains the following statement:

DEVICE_LIST=EMC*

When ConGroup starts, all the devices that are online whose volsers begin with the characters EMC are included into the consistency group.

Suppose after startup, a DISPLAY command statement gave these results:

CONGROUP=DB2PROD ENABLED ACTIVEUSE_RDF_ECA=YESUSE_FBA_NR_ON_TO=YESSUSPEND_FAILURE=WTOR SUSPEND_RETRY_TIMEOUT=120CTLR SER#=000190300647 uCode: 58740239 GroupId: 0003

If volume EMC005 is varied online, ConGroup recognizes this event, and determines that the volume EMC005 fits the volser mask EMC*. ConGroup generates a REFRESH command so that EMC005 is included as part of consistency group DB2PROD.

Auto-Refresh is used when you specify volser masks for either the DEVICE_LIST or the EXCLUDE parameters, or when you specify SMS groups. If you specify devices by z/OS device number (cuu), the devices become part of the consistency group, regardless of whether they are online or offline. A REFRESH command statement is initiated when devices that you included by CUU are varied online or offline.

Offline devices excluded only by volser are not excluded as the volser does not exist during the time the device is offline. Clipping a device that you defined by cuu as part of the consistency group does not initiate a REFRESH as the device is already part of the group.

The REFRESH command statement is issued only if the state of the consistency groups allow it to be issued. If the REFRESH command cannot be issued immediately, ConGroup monitors the consistency groups and issues the REFRESH at an appropriate time.

Note: “REFRESH” on page 141 describes the REFRESH command.

Note that AUTO_REFRESH does not issue a REFRESH command if CAX is defined. In such a situation, the following message is returned:

CGRP610W CONGROUP - Auto_Refresh is bypassed. Issue manually if desired.


Configuration

Note: “CAX” on page 101 describes how to define CAX.

ExampleAUTO_REFRESH=YES

CAXOPTS

PurposeThe CAXOPTS parameter defines a set of ConGroup AutoSwap options under an options set name. You can then associate that options set for a consistency group through the CAX consistency-group specific parameter.

Note: “CAX” on page 101 describes the CAX consistency-group specific parameter.


Syntax

CAXOPTS options_set=(cax_option[,cax_option[,...]])

Arguments

options_set

The name to be given to a set of CAXOPTS statements that you want to apply to this consistency group.

The option set name can be one through eight characters in length.

cax_option

The options that make up the option set. If you use multiple cax_option arguments, enclose them in parentheses and separate them with commas or intervening spaces.

CAX optionsYou can use the following as CAX options. These are the only CAX options supported by ConGroup or appropriate for ConGroup usage.

Parameter and range of valid valuesPage link

[NO]AllowSystemsCountMismatch|[NO]ASCM 74

CFW={OFFVAL|NO|ALLOW} 74

CROSSSYSTEMTIMEOUT={300|time_interval} 75

LOSTOwnerpolicy ONSWAP={OPERATOR|HOLDIO|BACKOUT| SYSRESET[(wait_code)]}

75

[No]ROUTEMESSAGEtoowner [ALL|Warn|Error] 76

QUIESCETimeout={MIH|time_interval} 76


Configuration

Descriptions

[NO]AllowSystemsCountMismatch|[NO]ASCM

During validation processing, the number of participating LPARs and path groups is determined. Then at swap time, the number of participating LPARs and path groups is determined again.

If you use the default, AllowSystemsCountMismatch (ASCM), the LPAR count at swap time does not have to match the number of participating systems for the device established at validation time.1 The swap can continue.

If you specify NOAllowSystemsCountMismatch (NOASCM), the LPAR counts at swap time must be equal to or greater than the number of path groups for the device established at validation time. If the LPAR count is less than the number of established path groups for the device, the swap cannot proceed.

EMC recommends using the ASCM default for both planned and unplanned swaps (especially where you have specified SWAPCONTROL=BYRANGE or BYGROUP) and validate the group before performing swap processing.

If you specify NOASCM, the devices must be individually validated across all hosts. A message is output for each device mismatch with an associated CGRS19I message.

Note: The Mainframe Enablers Message Guide provides details about messages you can receive.

The [NO]ALLOWSYSTEMSCOUNTMISMATCH option replaces and performs the same function as the [NO]BYPASSSYSTEMSCOUNT option used in previous releases of ConGroup. For backward compatibility, however, ConGroup still recognizes [NO]BYPASSSYSTEMSCOUNT and its alias, [NO]BSC.

CFW={OFFVAL|NO|ALLOW}

Controls cache fast writer (CFW).2 The argument values can be:

OFFVAL

UNPLANNEDCONDitions=INTERVENTIONREQUIRED|NOPATHS| SYNCLINKFAILURE

77

UNPLANNEDOPTIONS=FBAUSRNRDY 78

CSD={NRDY|USRNRDY} 78

[NO]AllowOnlineToDevice|[NO]AllOnTo 78

[NO]AllowOnlineUndefinedDevice|[NO]ALLONUNDEFDEV 79

1. If LPARs and path groups for LPARs cannot be found at validation time, the message CGRP195E is issued. The Mainframe Enablers Messages and Code Guide describes CGRP195E.

2. When you use CFW, additional integrity checks may be involved. In some cases, the subsystem ID is checked. If the device has been swapped, the SSID is different and the job is terminated. For this reason, EMC recommends against the use of CFW on devices that may be swapped.

Parameter and range of valid valuesPage link


Configuration

(Default) CFW is disabled during ConGroup validation processing. No CFW processing is attempted during a ConGroup AutoSwap swap event. If you subsequently reactivate CFW, and a ConGroup AutoSwap swap event occurs, jobs using the ability of CFW fail. You must rerun these jobs after the swap.

EMC recommends you use CFW=OFFVAL, followed by the VALIDATE command. CFW=OFFVAL turns off CFW for the devices in the group. VALIDATE detects and warns you about any pre-existing CFW usage.

NO

If CFW is active on any devices in the consistency group, validation of the consistency group fails and ConGroup AutoSwap processing is disabled.

ALLOW

CFW is checked during ConGroup validation processing. However, no change in a device’s CFW state is made. If a ConGroup AutoSwap swap event occurs, jobs using CFW fail. You must rerun these jobs.

CROSSSYSTEMTIMEOUT={300|time_interval}

Specifies the cross-host timeout value. This is the time ConGroup AutoSwap waits for acknowledgement from other ConGroup AutoSwap instances on other hosts. The time_interval value may be in the range of 60 seconds through 9999 seconds. The default value is 300.

LOSTOwnerpolicy ONSWAP={OPERATOR|BACKOUT|SYSRESET[(wait_code)]}

Specifies the action for ConGroup AutoSwap to take if all communication with the owner or controlling system is lost during the swap process. Lost communication occurs when SRDF and channel paths to the consistency group devices become disconnected. LOSTOwnershipolicy affects system behavior only during the swap process.

Note: The GLOBAL configuration parameter (page 85) controls which smfid is the owner.

In such a situation, ensure that the owner host is really dead and not just isolated before you take any action, such as issuing a ConGroup TAKEOVER command. In some circumstances, the owner could back out of the swap without being able to contact the non-owners or the nonowners being able to contact the owner.

You can abbreviate LOSTOwnerpolicy as LOP.

The argument values can be:

OPERATOR

(Default) Specifies that the operator should be asked what LOSTOwnerpolicy to execute. ConGroup issues the WTOR message:

ESWP485A (rrrrr) Reply HOLDIO, BACKOUT, SYSRESET, TAKEOVERASOWNER

HOLDIO, BACKOUT, SYSRESET are values documented in this section. TAKEOVERASOWNER requests that this LPAR assume ownership.

Be careful to ensure that the owner is really dead and not just isolated before using this option.


Configuration

Note: The Mainframe Enablers Message Guide provides details about error messages.

HOLDIO

Specifies that I/O is to be halted on the system that has lost connectivity with the owner system.

BACKOUT

Specifies that the swap operation is undone on the system that has lost connectivity with the owner system.

SYSRESET[(wait_code)]

Specifies that a non-restartable wait state of wait_code occurs on the system that has lost connectivity with the owner system. Valid values for wait_code can range from X’FF0’ to X’FFE’. The default wait_code is 0FF0.

[No]ROUTEMESSAGEtoowner [ALL|Warn|Error]

Allows AutoSwap messages to be consolidated in a single place (the owner system SYSLOG). This enables you to better locate issues in Autoswap processing. (The alias is ROUTEMSG)

The keywords are:

If you use [No]ROUTEMESSAGEtoowner with no keywords, ConGroup uses the ERROR keyword as the default. That is, only E (error) messages are routed to the owner system SYSLOG.

The messages have the system name contained in them where the request sequence number would normally be displayed. For example, the following message is routed from the nonowner system X06 to the owner system. The source system is indicated by the >X06.

CGRS274E (>X06)(PID 00001) 'TO' device C4B9 has an invalid state, RS 00000003

QUIESCETimeout={MIH|time_interval}

Specifies the quiesce time out. During IO halt processing this is the time that AutoSwap waits for any outstanding IO to complete on a device. If IO is still active on the device following this timeout then a swap backout occurs.

The time interval can be between 0 and 300 seconds.

If the resolved timeout value is less than 15 seconds, then 15 seconds is used.

MIH, the default and recommended value, tells AutoSwap to use the z/OS Missing Interrupt Handler timeout interval. A value of zero (0) is equivalent to specifying MIH.

ALL All nonowner AutoSwap messages are routed to the owner system SYSLOG.

Warn Only W and E (warning and error) messages are routed to the owner system SYSLOG.

ERROR Only E (error) messages are routed to the owner system SYSLOG.


Configuration

UNPLANNEDCONDitions=INTERVENTIONREQUIRED|NOPATHS|SYNCLINKFAILURE

Details ConGroup AutoSwap action to be taken when the specified condition occurs for a device in the ConGroup. This is a required argument. There is no default value. Note that you can specify all UNPLANNEDCONDITIONS values or no UNPLANNEDCONDITIONS value:

UNPLANCOND=INTERVENTIONREQUIREDUNPLANCOND=NOPATHSUNPLANCOND=SYNCLINKFAILUREUNPLANCOND=INTERVENTIONREQUIRED NOPATHS SYNCLINKFAILURE

You can also disable unplanned swaps by setting UNPLANCOND to null:

UNPLANCOND=

In this case, all possible autoswap conditions are disabled. There are no unplanned swaps if a link failure occurs.

The other values can be:

INTERVENTIONREQUIRED

Specify INTERVENTIONREQUIRED (INTREQ) if you want a swap to occur if any device in the group “drops Ready.” The device signals this by Unit Check status with INTERVENTIONREQUIRED. This status indicates that the device is still addressable, but is unable to perform normal functions. INTERVENTIONREQUIRED is recommended if you want the protection offered by unplanned swaps.

NOPATHS

Specify NOPATHS if you want a swap to occur when a loss of access to a device occurs. This includes loss of all channel paths to a device, a device being BOXed, or an intervention (intreq) condition generated by a paging device. Intreq on a paging device is included in a nopaths trigger, as such a condition would normally result in a disabled WTOR and likely loss of an LPAR. If any of these conditions occurs to a device in the group, NOPATHS tells AutoSwap to swap the group. EMC recommends this CAX option if you want the protection offered by unplanned swaps.

NOPATHS affects operations only when all paths are lost. If many paths fail, performance may be severely degraded; but, an unplanned AutoSwap is not triggered. You may choose to use AutoSwap’s SWAP command to transfer the workload to the alternate Symmetrix systems.

SYNCLINKFAILURE

Specify SYNCLINKFAILURE when you want ConGroup with AutoSwap to cause a swap by programmatically setting devices to Not Ready whenever an SRDF link failure occurs. From an AutoSwap point of view, SYNCLINKFAILURE is identical to INTERVENTIONREQUIRED and implies INTREQ internally.

The difference between INTERVENTIONREQUIRED and SYNCLINKFAILURE is that, with SYNCLINKFAILURE, the Not Ready condition is set by ConGroup in response to a synchronous link failure.

SYNCLINKFAILURE works as follows:

1. An I/O triggers an RDF-ECA Window open condition.


Configuration

2. The I/O is stalled.

3. ConGroup eventually detects the open window as a result of periodic polling.

4. ConGroup opens the windows on all other devices in the consistency group.

5. When all the windows are open, ConGroup immediately closes all the windows with a special flag for Enginuity. This flag tells the Symmetrix system to set the devices Not Ready (NR) and to close the windows.

6. Upon seeing the NR condition, AutoSwap initiates a swap.

7. AutoSwap redirects the initial IO to the channel attached R2.

Use of SYNCLINKFAILURE requires Enginuity patch 36705.

IMPORTANT

Use SYNCLINKFAILURE with caution. SYNCLINKFAILURE is not sensitive to Concurrent SRDF or SRDF/Star configurations.

The UNPLANNEDCONDITIONS option replaces and performs the same function as the AUTOSWAPCONDITIONS option used in previous releases of ConGroup. For backward compatibility, however, ConGroup still recognizes AUTOSWAPCONDITIONS.

UNPLANNEDOPTIONS=FBAUSRNRDY

This parameter is for unplanned swaps involving FBA devices only. It specifies that FBA R2 devices should be made Not Ready on the channel.

CSD={NRDY|USRNRDY}

Used to specify or override the default of RNR (RDF-Not-Ready) state at completion of an AutoSwap event.

The CSD parameter option has been added to allow users the ability to specify the post-swap state of the R1 devices that were swapped.

CSD option argument values can be:

NRDY (Default) This is optional and is the CAX default. Specifying NRDY sets R1 devices to RNR state at completion of an AutoSwap event.

USRNRDYSets the R1 devices that were swapped to User-Not-Ready state at completion of an AutoSwap event.

[NO]AllowOnlineToDevice|[NO]AllOnTo

This option facilitates the Host Read Only (HRO) support on a TO device by allowing ONLINE target (TO) devices in a AutoSwap or CAX group to be acceptable or unacceptable to AutoSwap.

The default value of NoAllowOnlineToDevice results in the AutoSwap validation process failing the group activation if there are any ONLINE target (TO) devices.

AllowOnlineToDevice is used in conjunction with the HRO Only attribute provided by the ResourcePak Base SCF.DEV.ATTR.HRO.INCLUDE keyword specified in the ResourcePak Base SCFINI parameter file. HRO is a local to the host where the parameter is specified and prevents any write processing occurring to the TO device.


Configuration

AllowOnlineToDevice allows ONLINE target (TO) devices to be present in the AutoSwap group, but only where a corresponding SCF.DEV.ATTR.HRO.INCLUDE.LIST also includes the target (TO) device. Where the R2 is ONLINE prior to an AutoSwap SWAP the Read Only (R/O) state is ensured by Symmetrix.

However, following an AutoSwap SWAP the R2 becomes Read Write (R/W). Specifying the target (TO) device in the SCF.DEV.ATTR.HRO.INCLUDE.LIST ensures that the Read Only state is preserved following the swap.

For an ONLINE target (TO) device where there is no corresponding ResourcePak Base SCF.DEV.ATTR.HRO.INCLUDE.LIST AutoSwap group validation fails and message CGRS274E is displayed.

CGRS274E (00009)(PID 00002) 'TO' device 06712 has an invalid state, RS 00000013 (online not Host R/O).

For an ONLINE target (TO) device where there is a corresponding SCF.DEV.ATTR.HRO.INCLUDE.LIST specified the informational message CGRS617I is displayed indicating that the ONLINE target (TO) is acceptable.

CGRS617I (00009)(PID 00002) 'TO' device 06712 is ONLINE. Allowed by Host Read Only attribute.

There are special considerations on the AutoSwap SWAP back where HRO is specified. When the target (TO) device is not swapped and remains ONLINE, the device is set to NRDY due to the ChangeSourceDevice (CSD) specification and becomes unavailable. Additional processing is required following such a SWAP back to make the device available again for access.

For further information on Host Read Only support refer to the ResourcePak Base Product Guide.

[NO]AllowOnlineUndefinedDevice | [NO] ALLONUNDEFDEV

This option allows FROM devices, which are online but excluded or not discovered by MFE ResourcePak base, to be acceptable (AllowOnlineUndefinedDevice) or unacceptable (NOAllowOnlineUndefinedDevice) to AutoSwap during group validation processing. This can occur when SCF.DEV.EXCLUDE is specified in the SCFINI file or MFE ResourcePak base was unable to discover the device due to IO timeouts or some other access issue.

If NOAllowOnlineUndefinedDevice is specified, or defaulted, then message CGRS587 is displayed as an E level message and validation processing fails for this group, for example:

CGRS587E (00001)(PID 01305) UCB not found for ONLINE 'FROM' device: 'FROM'/'TO' 05803,0C5E/05255,0C5E.

AllowOnlineUndefinedDevice must be specified to allow validation to be accepted in this instance. Careful use of this keyword specification is required as it could result in loss of access to a device following an AutoSwap SWAP.


Configuration

ExampleIn this example the ConGroup AutoSwap Extension are required. If ConGroup AutoSwap is not operating or the consistency group device group fails validation, ConGroup does not enable the consistency group.

CAX=(CAXOPTS=CAXOPT1)CAXOPTS CAXOPT1=(AUTOCOND=NOPATHS,CFW=OFFVAL,LOSTO ONSWAP=SYSRESET(OFF0),ASCM)

The CAX statement declared that CAXOPT1 specifies the following ConGroup AutoSwap options for this consistency group:

◆ AUTOCOND=NOPATHS specifies that if an I/O failure with a “no paths available” condition for any of the devices in the consistency group occurs, that failure event actions begin.

◆ CFW=OFFVAL turns off the cachefastwrite at the time of group validation. No CFW processing is attempted during the swap event.

◆ LOSTOwnerpolicy ONSWAP=SYSRESET(0FF0) specifies that if all communication (both channels and SRDF) is lost, processing continues, if possible, on the primary side and the secondary side enters a non-restartable wait state 0FF0.

◆ ASCM specifies that failure response actions do not occur even if the system count at the time of the event does not match the system count at validation time.

If the failure event is the inability to communicate from the R1 to the R2, a normal ConGroup trip occurs and the ConGroup AutoSwap Extension is disabled. This is because the R2 data is no longer current. A swap should never occur to “stale” data.

CLOCKE

PurposeCLOCKE specifies the multiplier of the clock tick interval after which unreleased coordination locks are expired. The default value for CLOCKE is 20. That means that if the clock tick is five seconds and you use the default value for CLOCKE, the unreleased coordination locks expire in 5 x 20=100 seconds.


Syntax

CLOCKE({20|n})

Argument

20|n

The multiplier value. Values between four (4) and 9999 are valid. The default is 20. For normal operation, use the default value of 20.

ExampleThe following example sets the multiplier to 25. This means that if the clock tick is five seconds, the unreleased locks expire in 5 x 25=125 seconds.

CLOCKE(25)


Configuration

CLOCKN

PurposeCLOCKN specifies the time, in hundredths of a second, between coordination activities.


Syntax

CLOCKN({1000|n})

Argument

n

The interval (in hundredths of a second) between ConGroup coordination activities. The range of allowable values is from 100 to 30000 (hundredths of a second). The default value is 1000 (10 seconds).

Comments◆ The number of seconds represented by CLOCKN must be at least twice (after dividing

by 100) the idle poll value of the Cross System Communication (CSC) component of ResourcePak Base.1 The idle poll value is optionally specified in the ResourcePak Base SCF.CSC.IDLEPOLL parameter. If the number of seconds represented by CLOCKN is less than twice the CSC idle poll value, reliable coordination is not possible, an error message is issued, and initialization fails.

Note: The ResourcePak Base for z/OS Product Guide discusses SCF.CSC.IDLEPOLL.

◆ Because ConGroup functions often take multiple clock intervals, large values for CLOCKN can unnecessarily lengthen the amount of time ConGroup functions can take.

ExampleNone.

COUPLEDS_ALLOWED

PurposeCOUPLEDS_ALLOWED allows you to add volumes with couple datasets to a consistency group, or explicitly prevent addition of volumes with couple datasets to a consistency group.

Note: With current maintenance applied, you can set the COUPLEDS_ALLOWED global configuration parameter if you are have an AutoSwap consistency group and are using the ConGroup AutoSwap extension.

1. The CLOCKN value can be greater than twice SCF.CSC.IDLEPOLL.


Configuration


Syntax

COUPLEDS_ALLOWED={NO|YES}

Arguments

NO

(Default) Prohibits volumes with couple datasets to be explicitly added to the consistency group.

YES

Allows volumes with couple datasets to be explicitly added to the consistency group. If you include DEVICE_LIST=ALL and also specify COUPLEDS_ALLOWED=YES, then volumes with couple datasets are not added to the consistency group.

CommentsThere are seven types of couple datasets:

◆ SYSPLEX◆ CFRM◆ WLM◆ OMVS◆ ARM◆ SFM◆ LOGR

When a consistency group trips, ConGroup sets volumes with couple datasets to high IOS levels. This could cause problems if the wrong couple datasets are added to the consistency group.

If you are using CICS journaling/logging through the System Logger, consider including only the primary LOGR couple dataset in a consistency group. If a LOGR couple dataset is to be included in a consistency group, there must be no other couple datasets on the volume with the primary LOGR couple dataset.

COUPLEDS_ALLOWED allows you to add the primary couple dataset used by the System Logger to the consistency group. No determination as to which couple dataset is added is made so you should isolate the logger datasets on volume(s) separate from the SYSPLEX couple datasets.

If the primary LOGR couple dataset is to be used as part of a consistency group, you should set up the LOGR structure in the Coupling Facility for duplexing to staging datasets. After the consistency group has tripped, the contents of the primary LOGR couple dataset, the LOGR staging datasets, and the LOGR logstream datasets contains the information necessary to restart CICS.

ExampleCOUPLEDS_ALLOWED=YES


Configuration

DISABLE_AT_SHUTDOWN

PurposeThe DISABLE_AT_SHUTDOWN parameter specifies to ConGroup whether congroup protection for all consistency groups should be disabled when ConGroup is shutdown.


Syntax

DISABLE_AT_SHUTDOWN={NO|YES}

Arguments

NO

(Default) Consistency group protection remains enabled when ConGroup shuts down.

YES

When ConGroup is shut down, all consistency groups are disabled. If you are running in multi mode, the last ConGroup instance to be shut down disables the groups. You must shut down the owner system last.

CommentsDISABLE_AT_SHUTDOWN is particularly important when ConGroup is active on multiple z/OS images. Disabling a consistency group turns off ConGroup protection for all the devices in that consistency group, regardless of which hosts are connected to the devices.

ExampleDISABLE_AT_SHUTDOWN=YES

DISABLE_ON_VERIFY_ERROR

PurposeThe DISABLE_ON_VERIFY_ERROR parameter specifies whether ConGroup should disable an ENABLED/ACTIVE consistency group if the auto-verify logic finds that the devices in the consistency group are not in the expected state.


IMPORTANT

The auto-verify logic is disabled for swapped or swapping consistency groups.

Syntax

DISABLE_ON_VERIFY_ERROR={YES|NO}


Configuration

Arguments

YES

The consistency group is put into a DISABLED state.

Note: If you do not include the DISABLE_ON_VERIFY_ERROR parameter, a DISPLAY ENVIRONMENT command shows that DISABLE_ON_VERIFY_ERROR is set to NO.

If the default is overridden to YES, a successful RDFECA TRIP cannot be guaranteed because sometimes AUTO_VERIFY may DISABLE the group first.

NO

(Default) CONGROUP does not put the group in a DISABLED state because a verify fails.

Note: If an E level message is generated, the situation should be investigated.

Note: DISABLE_ON_VERIFY_ERROR is always NO for consistency groups that also have an AutoSwap group associated with them. If you make an R1 Not Ready in such cases, Auto-Verify still functions, but does not disable the consistency group. Disabling the consistency group would delete the AutoSwap group.

ExampleThe following example specifies that ConGroup should disable an ENABLED/ACTIVE consistency group.

DISABLE_ON_VERIFY_ERROR=YES

DISPLAY_CONGROUP_LISTOPT

PurposeThe DISPLAY_CONGROUP_LISTOPT parameter sets the default behavior for the DISPLAY CONGROUP operator command.


Syntax

DISPLAY_CONGROUP_LISTOPT={LIST|NOLIST}

Arguments

LIST

(Default) Information about all the devices in the consistency group are displayed by the DISPLAY CONGROUP processing.


Configuration

NOLIST

Information about all the devices in a consistency group is suppressed.

ExampleDISPLAY_CONGROUP_LISTOPT=NOLIST

GLOBAL

PurposeGLOBAL has one argument, OWNER. OWNER specifies the SMF ID of the LPAR that controls the consistency group during CAX operations. If a failure occurs that results in all communication being lost between the primary and secondary sites, the system specified in OWNER proceeds.

IMPORTANT

OWNER must be specified if you set MODE=MULTI in the GLOBAL configuration file. When MODE=MULTI is specified, GLOBAL OWNER specification is mandatory because RDF-ECA management functions are only carried out on a designated owner LPAR.

If OWNER is not specified, ConGroup initialization is terminated and message CGRP085E is issued. You must then specify the OWNERID and restart ConGroup.

The OWNER parameter is effectively ignored by Refresh. This is crucial in order to properly support the MOVEOWNER or TAKEOVER commands.

Note: You can use the MOVEOWNER or TAKEOVER operator commands to transfer ownership to a different LPAR without the need to reinitialize ConGroup manually. “MOVEOWNER” on page 138 and “TAKEOVER” on page 146 provide more information.


Syntax

GLOBAL=(OWNER=SMFid)

Arguments

SMFid

The SMF ID of the owner LPAR. This argument must be the same in ConGroup parameter files for all instances of ConGroup that use the defined consistency group.

MODE

PurposeThe MODE parameter prevents or allows two or more ConGroup instances running in different LPARs to communicate with each other.


Configuration

IMPORTANT

If you set MODE=MULTI, you should always specify a "GLOBAL=(OWNER=SMFid)" in the configuration file. “GLOBAL” on page 85 provides more information.


Syntax

MODE={SINGLE|MULTI}[,{CGSET00|CGSETnn}]

Arguments

SINGLE

(Default) Prevents two or more ConGroups from communicating with each other. All ConGroup instances that come up do not attempt to talk to ConGroups already running.

MULTI

Allows two or more ConGroups running the same release to communicate with each other. All ConGroup instances that come up can talk to ConGroups already running.

Note: The multiple ConGroups must be running at the same release level (for example, 7.6).

CGSETnn

The CGSETnn subparameter is optional and ensures ConGroup and Autoswap cross-address space and/or LPAR isolation.

Valid values for nn: 00 through 06. CGSET00 is the default value.

ConGroups with the same CGSET value belong to the same ConGroup 'set' and coordination of ADD processing is conducted through CSC communications within the participating ConGroup address spaces. A given ConGroup address space can belong to one and only one CGSET.

Note: All ConGroup address spaces in a multi-mode configuration that wish to communicate must have same CGSET number.

Using CGSET allows ConGroup to modify a configuration without the disable/enable processing involved in a ConGroup REFRESH command, which had the negative effect of temporarily stopping protection of all ConGroups (star and non-star) in a ConGroup address space.

For multiple ConGroups running in the SAME LPAR, the CGSET parameter must be unique for each instance of ConGroup running in the same LPAR. For example, with the CGSET parameter defaulted to the value “00”, any additional instance must specify a value between “01” and 06”.


Configuration

Note: Even though you can now run up to seven independent ConGroup address spaces in one LPAR, only one ConGroup address space may be associated with a given SCF.

For running ConGroups in different or separate LPARs, the CGSET parameter takes on an additional meaning where the value assigned in one LPAR has ConGroup ‘pair-up’ with an instance of ConGroup in a different LPAR that has the same CGSET value assigned to it. This provides redundancy support for a production ConGroup.

For example, if an instance of Congroup running in LPAR 1 uses a CGSET value of “01”, and another instance of ConGroup running in LPAR 2 uses the same CGSET value of “01”, the two instances of ConGroup in the two LPARs both monitor and protect their defined ConGroups. Of course, the two instances of ConGroup must use the same configuration file. So, if LPAR 1 malfunctions, the ConGroup processing in LPAR 2 still provides its intended function for both defined ConGroups.

Note: Regarding cross-LPAR CGSET "conflicts:" these are automatically resolved/prevented by independent CRC checks on the configuration file at each node with subsequent comparison based on the CRC as embedded in inter-node message traffic.

Comments◆ Regardless of whether you use the default SINGLE mode or set MODE=MULTI,

whenever any R1-R2 pair defined in a configuration file is protected by more than one ConGroup instance, you need to ensure that all such ConGroup instances use the same configuration file.

◆ With MODE=MULTI, you should not start new ConGroups during the execution of the MOVEOWNER or TAKEOVER command statements. Starting a new ConGroup during MOVEOWNER or TAKEOVER is not currently supported and produces unpredictable results.

◆ If you set MODE=MULTI, ConGroup uses an internal lock, ALL-CONGROUPS to serialize many global operations to ensure the integrity of ConGroup’s functionality. If you use the default, MODE=SINGLE, ConGroup has no reason to use (and does not use) ALL-CONGROUPS.

ExampleThe following instructs ConGroup to run in MULTI mode and defines CGSET06 as the global storage name token anchor.

MODE=MULTI,CGSET06


Configuration

MSGLEVEL

PurposeMSGLEVEL specifies the minimum level of verbosity (detail) that a message must have to be sent to SYSLOG. When a message is issued, the verbosity level associated with it is compared with the address-space-wide MSGLEVEL. If the message’s verbosity level is equal or lower than the specified MSGLEVEL, the message is queued for display.


Syntax

MSGLEVEL({5|n})

Argument

n

The level of detail (verbosity) for SYSLOG messages. The value can range from one (1) to 9, where 9 is the most verbose. The default is five (5), which should be sufficient for most purposes.

Note: Do not change from the default unless directed to do so by EMC representatives.

ExampleThe following example sets the MSGLEVEL at seven (7). Any message with a verbosity level from 1 to 7 is sent to SYSLOG.

MSGLEVEL(7)

PAGEDEV_ALLOWED

PurposeThe PAGEDEV_ALLOWED parameter specifies whether devices that contain page datasets can be defined as part of a consistency group. PAGEDEV_ALLOWED is global in scope and applies to all defined consistency groups.


Syntax

PAGEDEV_ALLOWED={NO|YES}

Arguments

NO

(Default) Devices with page datasets cannot be defined as part of a consistency group.

YES

Devices with page datasets can be defined as part of a consistency group.


Configuration

Note: Page datasets support is provided with Enginuity 5x71 and later only.

CommentsI/O to devices with page datasets cannot be halted during the suspend processing. This means that during the ConGroup trip process, I/O may complete to the remote mirror of a paging volume prior to the SRDF SUSPEND command completing against that volume.

You must ensure that devices containing page datasets do not also contain data which has dependencies with data on other devices in the consistency group. Failure to do so may result in inconsistent data on the remote side.

If you specify DEVICE_LIST=ALL, then volumes with page datasets are NOT added to the consistency group unless you take the following actions. You should identify the page devices for specific inclusion in the group by using DEVICE_LIST=device, and specify PAGEDEV_ALLOWED=YES.

ExampleThe following example allows the definition of consistency groups that include page devices.

PAGEDEV_ALLOWED=YES

REMSPLIT_INTERVAL

PurposeThe REMSPLIT_INTERVAL parameter specifies the number of seconds a REMSPLIT command1 waits before retrying the request after receiving temporary errors. The request is not retried if any of the following happens:

◆ The request succeeds.

◆ ConGroup encounters an R2 device without a BCV when you have specified NOESTERR as a REMSPLIT_OPTION.

Note: “REMSPLIT_OPTION” on page 90 describes the REMSPLIT_OPTION parameter.

◆ The request is canceled by the CANCEL operator command.


Syntax

REMSPLIT_INTERVAL=seconds

1. The REMSPLIT command remotely splits all the target (R2) standard Symmetrix devices from their BCV devices (if they are attached to one). “REMSPLIT” on page 142 describes the REMSPLIT command.


Configuration

Argument

seconds

The number of seconds a REMSPLIT process waits. If you do not specify a value for REMSPLIT_INTERVAL, then REMSPLIT_INTERVAL defaults to 10 seconds.

CommentsMessage CGRP206I is issued each time the REMSPLIT process retries the remote split.

Note: The MainFrame Enablers Message Guide describes CGRP206I and other messages you can receive.

ExampleThe following example specifies that the REMSPLIT command wait 15 seconds before retrying the request.

REMSPLIT_INTERVAL=15

REMSPLIT_OPTION

PurposeThe REMSPLIT_OPTION parameter, when set to NOESTERR, instructs ConGroup to generate message CGRP314E during remote split processing. CGRP314E notifies the operator about all R2 devices without an attached BCV.


Syntax

REMSPLIT_OPTION=NOESTERR

Argument

NOESTERR

When you specify NOESTERR, remote split processing fails when an R2 device is found without an attached BCV. When you do not specify NOESTERR (that is, do not include REMSPLIT_OPTION in the configuration file), R2 devices without attached BCVs are ignored and no error message is generated.

Example The following example instructs CONGROUP to generate CGRP314E during remote split processing.

REMSPLIT_OPTION=NOESTERR


Configuration

RESUME_INTERVAL

PurposeThe RESUME_INTERVAL parameter specifies the number of seconds a RESUME command waits before checking whether all the devices in the consistency group are synchronized. Message CGRP022I is issued, followed by another message describing the state of the RESUME command. ConGroup continues to retry the request until either of the following occurs:

◆ The request succeeds.

◆ The request is canceled by the CANCEL operator command.


Syntax

RESUME_INTERVAL=seconds

Argument

seconds

The number of seconds a RESUME command waits. If you do not specify a value for RESUME_INTERVAL, RESUME_INTERVAL defaults to 10 seconds.

ExampleThe following example specifies that the RESUME command wait 15 seconds before checking whether all the devices in the consistency group are synchronized.

RESUME_INTERVAL=15

RESUME_OPTION

PurposeThe RESUME_OPTION parameter, when set to NOTRNMSG, suppresses messages about processing verification that are resolved by resuming processing. The default generates the transient state message during processing resumption.

In addition, you can specify the RSMALLIT option, which displays the invalid tracks for all devices in the consistency group during each RESUME_INTERVAL.


Syntax

RESUME_OPTION={NOTRNMSG|RSMALLIT|NOTRNMSG+RSMALLIT}


Configuration

Arguments

NOTRNMSG

Messages about processing verification that are resolved by resuming processing are suppressed.

Note: If you do not specify NOTRNMSG then TRNMSG is the default. You cannot explicitly specify TRNMSG.

RSMALLIT

Invalid tracks for all devices in the consistency group are displayed during each RESUME_INTERVAL. If you do not specify RSMALLIT, only messages for the first device found with invalid tracks are issued on each interval.

NOTRNMSG+RSMALLIT

Options can be combined for both suppression of resolved process verification messages and display of invalid tracks. See full descriptions immediately above.

ExampleTo specify both the NOTRNMSG and the RSMALLIT values:

RESUME_OPTION=NOTRNMSG+RSMALLIT

or

RESUME_OPTION=RSMALLIT+NOTRNMSG

SAF_CLASS

PurposeThe SAF_CLASS parameter defines the QNAME that is used to perform security checks for the operator commands.


Syntax

SAF_CLASS=qname

Argument

qname

Any valid queue name that is defined to the security subsystem. The default value is DATASET.

ExampleNone.


Configuration

SAF_PROFILE

PurposeThe SAF_PROFILE parameter defines the base RNAME that is used to perform security access checks for the operator commands. Before making a security access check, ConGroup appends a command-specific suffix to the value of this parameter.


Syntax

SAF_PROFILE=resource_name

Argument

resource_name

Any valid resource name for the security subsystem. The resource name can be up to 35 characters long.

Note: The Mainframe Enablers Installation and Customization Guide provides a list of the values you can use.

The default value is EMC.VALIDATE.ACCESS.

ExampleNone.

SEMISYNC_ALLOWED

PurposeThe SEMISYNC_ALLOWED parameter specifies whether semi-synchronous devices (J1) can be used in a consistency group definition.


Syntax

SEMISYNC_ALLOWED={NO|YES}

Arguments

NO

(Default) Only synchronous devices can be defined as part of a consistency group.

IMPORTANT

You must use this default if you have any CAX groups defined in your configuration file.


Configuration

YES

Devices operating in a semi-synchronous copy state can be defined as part of a consistency group.

Because CAX groups cannot use semi-sync devices, ConGroup ignores any specification of SEMISYNC_ALLOWED=YES when CAX groups are in the ConGroup configuration file. Instead, it uses the “default” value of not allowing semi-sync devices.

If a semi-sync device appears in a CAX group, ConGroup issues message CGRP273E, indicating that SEMISYNC_ALLOWED=NO is in effect.

Note: The Mainframe Enablers Message Guide provides a description of CGRP273E and other messages you can receive.

Comments To use semi-synchronous devices with consistency groups requires special consideration and knowledge of the nature of the applications being protected by SRDF in semi-synchronous mode.

Semi-synchronous mode is designed to improve the performance of SRDF in configurations where the overhead introduced by propagation delay in synchronous mode adversely impacts application performance. Semi-synchronous mode reduces this performance impact by acknowledging the completion of a write I/O to the application by the local (primary) Symmetrix system before propagating the data to the remote (secondary) Symmetrix system. In essence, this eliminates propagation delay.

Propagation delay elimination results in a performance benefit if the interarrival time of write I/Os to the primary Symmetrix system is greater than the service time for the I/O across the SRDF link. If this interarrival time is less than the link service time, then semi-synchronous mode provides no performance benefit over SRDF’s synchronous mode of operation. Therefore, the benefit of semi-synchronous mode is very application and workload dependent.

Semi-synchronous mode limits out of sync conditions to, at most, one I/O per logical volume. However, this does allow two logically dependent I/Os to be in flight in the SRDF communications infrastructure at the same time. Such a condition is likely only in applications that do not exhibit deferred write characteristics or are not highly buffered in the CPU. Modern relational databases, such as DB2, defer dependent writes and are not likely to issue logically dependent I/Os in close time proximity. However older DBMS systems, such as IMS, often do not defer dependent writes and are likely to have dependent I/Os in progress at the same time in SRDF semi-synchronous mode.

EMC does not recommend that you use semi-synchronous mode in multiple control unit SRDF implementations, (or in a single control unit employing multiple SRDF groups) with applications that do not defer writes. Such usage may result in inconsistent data at the remote site in the event of an unplanned outage at the primary site.


Configuration

IMPORTANT

ConGroup AutoSwap (CAX) groups cannot use semi-synchronous devices. Therefore, ConGroup ignores this parameter if there are CAX groups in the ConGroup configuration file. That is, ConGroup ignores a YES value if there are any CAX groups in the configuration file.

ExampleSEMISYNC_ALLOWED=YES

USE_FBA_NR_ON_TO

PurposeThe USE_FBA_NR_ON_TO configuration parameter has significance only in mixed CKD device and FBA device situations.

USE_FBA_NR_ON_TO=YES ensures that, if the ECA Window times out on the FBA devices, these FBA devices become Not Ready. This is useful in situations where you do not want a open system application to continue to run on the R1 side while an AutoSwap application on a mainframe system swaps to the R2 side.


Syntax

USE_FBA_NR_ON_TO={NO|YES}

Arguments

NO

(Default) Specifies that ConGroup disable the feature that FBA devices become Not Ready if the ECA Window times out on the FBA devices.

YES

Specifies that ConGroup enables the feature that FBA devices become Not Ready if the ECA Window times out on the FBA devices.

ExampleThe following example specifies that FBA devices become Not Ready if the ECA Window times out on the FBA devices.

USE_FBA_NR_ON_TO=YES


Configuration

USE_RDF_ECA

PurposeUSE_RDF_ECA is defaulted to YES because RDF_ECA is the only monitoring mode available in ConGroup, and is maintained for compatibility purposes only. If you should set USE_RDF_ECA to NO, ConGroup flags it with an error.

Note: “Monitoring mode” on page 41 provides more information.


VERIFY_INTERVAL

PurposeThe VERIFY_INTERVAL parameter specifies the time interval (in seconds) before the auto-verification subtask attempts to verify the state of all ENABLED/ACTIVE consistency groups. This is to ensure that all consistency group devices are still in the expected state.


Syntax

VERIFY_INTERVAL=seconds

Argument

seconds

The time interval in seconds. The maximum value you can specify is 99,999,999 (seconds).

If you do not specify a value for VERIFY_INTERVAL, ConGroup uses a default of 300 seconds. If you enter a value of 0 (zero), the auto-verify logic is disabled.

IMPORTANT

The auto-verify logic is disabled for swapped or swapping consistency groups.

ExampleThe following example specifies that the auto-verification subtask wait 250 seconds (4 minutes and 10 seconds) before attempting to verify the state of all ENABLED/ACTIVE consistency groups.

VERIFY_INTERVAL=250


Configuration

Consistency group-specific configuration parametersIn the ConGroup configuration file, you place consistency-group specific configuration parameters after the global configuration statements. You use consistency group-specific configuration parameters to declare a consistency group and define its characteristics.

The consistency-group-specific configuration parameters are described in the following sections:

◆ ALLOW_SHARED_R1S

◆ ALLOWABLE_MSS

◆ CAX

◆ CONGROUP and SRDF_CONGROUP

◆ DEVICE_LIST

◆ DEVICE_LIST_STD

◆ EXCLUDE

◆ SCFG

◆ SMS_GROUP

◆ SUSPEND_FAILURE

◆ SUSPEND[_RETRY]_TIMEOUT

◆ SYMM_DEV#

◆ SYMGROUP

ALLOW_SHARED_R1S

PurposeALLOW_SHARED_R1S enables you to allow or disallow the definition of RDF ECA groups by mirror for the consistency group you are currently defining. This lets you to use ECA protection for two different consistency groups for each device.

If you allow definition of RDF ECA groups by mirror for a consistency group, duplicate device checking is replaced by duplicate checking at the mirror level. Any explicit or implicit SYMGROUP statements defined for the consistency group are used to assign mirrors to the group.

If you disallow the definition of consistency groups by mirror (the default), ConGroup does not use duplicate checking at the mirror level. SYMGROUP statements defined for the consistency group do not assign mirrors to the group.

Note: “Consistency group states” on page 35 provides more information.


Consistency group-specific configuration parameters 97

Configuration

Syntax

ALLOW_SHARED_R1S={YES|NO}

Argument

NO

(Default) Do not allow both RDF R1 mirrors to be protected by separate consistency group definitions.

YES

Allow both RDF R1 mirrors to be protected by separate consistency group definitions.

Comments◆ ALLOW_SHARED_R1S=YES permits a concurrent SRDF device (though use of mirrors)

to be in two consistency groups. This allows you to retain protection in one leg if the other leg trips.

Consider the following example using consistency groups 04 and 05 in controller MEDREC:

◆ The value set for the consistency-group specific ALLOW_SHARED_R1S overrides the value of the global ALLOW_SHARED_R1S for the definition of the current consistency group.

◆ When you set ALLOW_SHARED_R1S to YES, you can use the SYMGROUP parameter to indicate which group is protected using ECA.

• If the SYMGROUP configuration parameter is applied to both consistency groups, ConGroup protects both legs.

• If the SYMGROUP configuration parameter is omitted, ConGroup also protects both legs.

• If the SYMGROUP configuration parameter was applied to only one of the groups, then only that group would be protected.

Note: “SYMGROUP” on page 111 provides more information.

Only protected groups can trip. However, when any protected group trips, all protected groups are suspended.

◆ Trying to specify definition by mirror to R1 devices whose Enginuity level not supporting R1 device sharing generates an error.

SRDF_CONGROUP=MEDRECSUSPEND_FAILURE=FAILSUSPEND_RETRY_TIMEOUT=45SYMGROUP=(DLR1,04)DEVICE_LIST=8A00-8A0F

Group 04 is ECA protected. An ECA event onthe 04 leg suspends 04, but not 05.

ECA protection is not enabled on the consistencygroup 05 leg. For consistency purposes, 04 or 05 leg events have no effect on 05.


Configuration

Example In the following example, two consistency groups, MSFTIGO1 and MSFTIGO2, are established for the same device list, 8702-870A. The example sets ALLOW_SHARED_R1S and sets SYMGROUP to protect RDF Groups in both consistency groups:

CONGROUP=MSFTIGO1ALLOW_SHARED_R1S=YESSUSPEND_FAILURE-FAILSUSPEND_RETRY_TIMEOUT=50SYMGROUP=(000192600304,80)DEVICE_LIST=8702-870ACONGROUP=MSFTIGO2ALLOW_SHARED_R1S=YESSUSPEND_FAILURE-FAILSUSPEND_RETRY_TIMEOUT=50SYMGROUP=(000192600304,C0)DEVICE_LIST=8702-870A

In the following example, the two consistency groups, MSFTIGO1 and MSFTIGO2, are established for the same device list, 8702-870A. The example sets ALLOW_SHARED_R1S, but does not issue SYMGROUP. Therefore, RDF Groups in both consistency groups are protected:

CONGROUP=MSFTIGO1ALLOW_SHARED_R1S=YESSUSPEND_FAILURE-FAILSUSPEND_RETRY_TIMEOUT=50DEVICE_LIST=8702-870ACONGROUP=MSFTIGO2ALLOW_SHARED_R1S=YESSUSPEND_FAILURE-FAILSUSPEND_RETRY_TIMEOUT=50DEVICE_LIST=8702-870A

In the following example, the two consistency groups, MSFTIGO1 and MSFTIGO2, are established for the same device list, 8702-870A. The example sets the ALLOW_SHARED_R1S value, but does issue SYMGROUP only for MSFTIGO1. Therefore, only in MSFTIGO2 are both RDF Groups protected:

CONGROUP=MSFTIGO1ALLOW_SHARED_R1S=YESSUSPEND_FAILURE-FAILSUSPEND_RETRY_TIMEOUT=50SYMGROUP=(000192600304,80)DEVICE_LIST=8702-870ACONGROUP=MSFTIGO2ALLOW_SHARED_R1S=YESSUSPEND_FAILURE-FAILSUSPEND_RETRY_TIMEOUT=50DEVICE_LIST=8702-870A


Configuration

ALLOWABLE_MSS

PurposeThe ALLOWABLE_MSS parameter (and related PAIR subparameter of the CONGROUP statement) is required if using CAX and if any of the device pairs "straddle" two subchannel sets. The subparameters define what subchannel sets on the R1 devices are allowed. They may also be specified whether or not the device pairs straddle subchannel sets.

Note: As always, R2s seen in a group always cause the group to be bypassed. But with R2s on an alternate subchannel, ConGroup doesn't see them as R2s because they are the same channel address as the R1s.

The "helper" parameters of PAIR and ALLOWABLE_MSS are necessary to force a bypass when an R1's subchannel set does not match the "allowable" sets. Also, if the first group of a pair is not bypassed then the 2nd group in the pair is always bypassed.

“CONGROUP and SRDF_CONGROUP” on page 101" provides more information about usage of the PAIR subparameter.


SyntaxALLOWABLE_MSS(n[,n])

Argument(n[,n])

Defines the allowable subchannel sets.

CommentsThe combination of this parameter and the PAIR subparameter is the only way to always correctly bypass one of the two groups, regardless of statement ordering, when using an alternate subchannel set.

Examples

Note: If this parameter is specified, it must at least always specify subchannel set 0 (e.g. ALLOWABLE_MSS(0)).

ALLOWABLE_MSS(0)Only allow R1s from subchannel set 0.

ALLOWABLE_MSS(0,1)Allow R1s from subchannel set 0 or 1.


Configuration

CAX

PurposeThe CAX parameter specifies whether you want to activate the ConGroup AutoSwap Extension for a device swap group and sets the CAX options set you want to use for that group.

The CAX parameter requires the ConGroup AutoSwap Extension feature be available for ConGroup to enable.

Note: “CAXOPTS” on page 73 provides more information about the CAX parameter and ConGroup AutoSwap.


Syntax

CAX=(CAXOPTS=options_set)

Argument

options_set

The name of an options set created with CAXOPTS. Multiple CAX statements may refer to the same CAXOPTS statement.

Note: “CAXOPTS” on page 73 describes options sets.

CommentsConGroup AutoSwap Extension is a licensed feature of the Symmetrix system.

Note: The ResourcePak Base for z/OS Product Guide provides details about licensing.

Example CAX=(CAXOPTS=CASOPT1)

CONGROUP and SRDF_CONGROUP

PurposeThe CONGROUP parameter defines the name (from 1 through 8 characters) of a consistency group that contains either of the following:

◆ SRDF devices◆ SRDF devices and standard devices

The SRDF_CONGROUP parameter and the CONGROUP parameter have the same meaning. You can substitute one for the other.


Configuration


Syntax

[SRDF_]CONGROUP=groupname[,PAIR(pairname)]

Argument

groupname

Any string of from one (1) to eight (8) characters.

PAIR(pairname)

The PAIR parameter assigns a name to a pair of R1s and R2s. It is only required if any of the device pairs are located on different subchannel sets.

CommentsIn releases earlier than 7.3, R2s on an alternate subchannel were seen as R1s because support for alternate subchannels was not available and the channel address was interpreted as the same channel address as the R1s.

The "helper" subparameters of PAIR and ALLOWABLE_MSS parameter provide an "allowable" view of which alternate subchannels should be viewed as part of this ConGroup pair.

The PAIR subparameters can be specified at any time, but is only required if the device pairs are on alternate subchannel sets. For example, one device is on subchannel 0 and the other is on subchannel 1.

ExamplesCONGROUP=GROUPA

This example specifies the groupname as GROUPA.

CONGROUP=GROUPA,PAIR(MYPAIR)ALLOWABLE_MSS(0)...device definitions...

Only allow R1s from subchannel set 0


Configuration

CONGROUP=GROUPB,PAIR(MYPAIR)ALLOWABLE_MSS(0,1)...device definitions...

Allow R1s from subchannel set 0 or 1

This example specifies the group names of GROUPA and GROUPB, and the pair name that associates them is MYPAIR.

SRDF_CONGROUP=SALESDB2This example specifies the groupname as SALESDB2.

DEVICE_LIST

PurposeThe DEVICE_LIST parameter defines the devices that belong to the consistency group most recently defined with the CONGROUP or SRDF_CONGROUP. For a given CONGROUP or SRDF_CONGROUP parameter, there can be one or more DEVICE_LIST arguments.


Syntax

DEVICE_LIST={device[,device[,...]]|ALL}

Arguments

device

Can be:

• A mainframe device number

• A range of mainframe device numbers

• A mainframe volser

Separate each device by commas. Specify ranges with a hyphen, for example 280-28F. You can mix mainframe device numbers and volsers in the same statement.

When using volsers, ensure that all the devices meant to be defined in a consistency group are online to all LPARs participating in the consistency group. This guarantees that a trip effects all of the devices on every LPAR.

In addition to ranges of device numbers and volsers, you can use ALL to signify all devices. ALL can be useful with the EXCLUDE statement when a large number of devices are part of a consistency group.

DEVICE_LIST=ALL makes sure the devices meet the following criteria before selection:

• A device is not on the exclude list.

• A device is able to communicate with ConGroup.

• A device is in a Symmetrix system that meets the requirements listed for Symmetrix systems in the Mainframe Enablers Installation and Customization Guide.


Configuration

• A device is a R1 device or an STD device. The STD device must be established with its BCV partner. The consistency group cannot include R2 devices.

Note: “DEVICE_LIST_STD” on page 105 provides more information about STD devices in consistency groups.

• A device can be an open system or a mainframe device.

• A device can be on a different Symmetrix system than the other devices in the consistency group, but must be at the same physical site as the other devices. You cannot include devices from different physical sites in the same consistency group.

• A device is not a meta device.

• A device does not contain a Couple dataset. (LOGR Couple Facility datasets can be swapped.)

• A device does not contain a page dataset. (You can force the inclusion of devices containing page datasets by using DEVICE_LIST=device.)

ConGroup also supports the use of a volser mask for specifying devices to be included in a consistency group. Volser names for devices to be included in a consistency group are not required to contain hyphens.

Comments ConGroup monitors the SRDF devices on device list for failures to complete a successful write to their partner R2 device.

A failure to successfully write to a partner R2 device results in all the devices in the consistency group being suspended. This is a ConGroup trip.

ExamplesThe following example mixes devices and ranges of devices in the same statements:

DEVICE_LIST=200-27F,290,B000-B007DEVICE_LIST=900,901,90A,DB2001,DB2002

The following example, specifies that ConGroup include in the consistency group all the devices defined to the z/OS system:

DEVICE_LIST=ALL

Note: You may find ALL useful if you use it with the EXCLUDE parameter when a large number of devices are part of a consistency group. “EXCLUDE” on page 106 describes the parameter.

The following example uses a volser mask to add all the devices whose first three characters begin with IMS, regardless of what follows:

DEVICE_LIST=IMS*

You can use the mask character (*) after any number of characters, for example:

DEVICE_LIST=X*,QW*,EMC*,ABCO*,CDE01*


Configuration

Like the other DEVICE_LIST arguments, you can mix volser wildcards with the other device specifiers, for example:

DEVICE_LIST=200,300-310,ABC0*,SYM001,EMC*

DEVICE_LIST_STD

PurposeThe DEVICE_LIST_STD parameter defines the standard devices that belong to the consistency group most recently defined with the CONGROUP or SRDF_CONGROUP parameters. For any given consistency group, there can be one or more DEVICE_LIST_STD arguments.


Syntax

DEVICE_LIST_STD=device[,device[,...]]

Argument

device

Can be:




Separate values with commas. Specify ranges using a hyphen (for example 280-28F). You can intersperse mainframe device numbers and volsers in the same statement.

ConGroup also supports the use of a volser mask when specifying devices to be included in a consistency group. You can use the mask character (*) after any number of characters.

CommentsThe standard devices in this argument list are protected by BCVs rather than R2 devices. The consistency group is enabled only if the standard devices you specify in this parameter are established with their partner BCV devices.

Devices defined with the DEVICE_LIST_STD parameter are not monitored for the inability to write to their established BCV device. DEVICE_LIST_STD devices cannot cause a ConGroup trip, but they are split when a ConGroup trip occurs.

The STD device cannot be any type of RDF device (R1, R2, etc,) or else at start up, Congroup receives the following error message and the program does not start:

CGRP199E CUU ccuu IS NOT A STD DEVICE and congroup

Examples The following example mixes devices and ranges of devices in the same statements:

DEVICE_LIST_STD=200,300-303


Configuration

DEVICE_LIST_STD=STD001,STD002

The following example uses a volser mask to add all the devices whose first three characters begin with EMC, regardless of what follows:

DEVICE_LIST_STD=EMC*

As you can with the other DEVICE_LIST_STD parameters, you can mix volser wildcards with the other device specifiers, for example:

DEVICE_LIST_STD=X*,QW*,EMC*,ABCO*,CDE01*

or:

DEVICE_LIST_STD=200,300-310,ABC0*,SYM001,EMC*

EXCLUDE

PurposeThe EXCLUDE parameter allows you leave out certain devices when defining a consistency group. For a given consistency group, there can be one or more EXCLUDE statements.

Excluded devices have precedence over devices included by the DEVICE_LIST, DEVICE_LIST_STD, and SMS_GROUP parameters. That is, an excluded device is always left out, whereas an included device can be preempted by an EXCLUDE statement.


Syntax

EXCLUDE=device[,device[...,device]]

Argument

device

Can be:




Separate values with commas. Specify ranges using a hyphen (for example 280-28F). You can intersperse mainframe device numbers and volsers in the same statement.

CommentsThe EXCLUDE parameter does not apply to devices defined with the SYMM_DEV# parameter.

ExampleEXCLUDE=200-21F


Configuration

SCFG

PurposeThe parameter SCFG brings a device group defined through Group Name Services (GNS) into ConGroup.


Syntax

SCFG(gnsgroupname)

Argument

gnsgroupname

The name of a GNS group. Each group name can be from one to 65 alphanumeric characters long. Each apostrophe, if used, reduces the maximum possible length of the gnsgroupname by 1.

When specifying a GNS group name, you must enclose the name in apostrophes if it includes any character that is neither an uppercase letter nor a numeric digit. However, be aware that even if the GNS group name is enclosed in apostrophes, non-alphanumeric characters or lowercase alphabetic characters may be translated to blanks or converted to uppercase when presented as input to ConGroup, possibly causing the GNS group not to be found or possibly resulting in the processing of an unintended GNS group.

Comment

Although GNS can support all types of devices, only R1 devices are protected by ConGroup. Therefore, you should define only Enterprise RDF1 groups as consistency groups.

“Defining consistency groups through Group Name Services” on page 34 provides more information about using Group Name Services Applicable groups. The ResourcePak Base for z/OS Product Guide provides more information about Group Name Services.Example

The following example defines a consistency group name and a device list. The example also uses SCFG to associate a named list of devices defined through Group Name Services with the consistency group. Finally, the example uses CAX to associate a named set of CAX options with the group.

SRDF_CONGROUP=congroupname DEVICE_LIST=200-27F,290,B000-B007SCFG(gnsgroupname) CAX=(CASOPTS=optionsname)


Configuration

SMS_GROUP

PurposeThe SMS_GROUP parameter specifies that all the devices belonging to the specified SMS group also belong to the most recently defined consistency group.


Syntax

SMS_GROUP=SMS groupname

Argument

SMS groupname

Any valid SMS group name. Each SMS group name can be from one (1) through eight (8) characters in length.

ExampleSMS_GROUP=SMSTEST

SUSPEND_FAILURE

PurposeThe SUSPEND_FAILURE parameter specifies what ConGroup does when a failure occurs in the SUSPEND process.

IMPORTANT

SUSPEND_FAILURE is a required parameter. If you do not specify it for your consistency groups, you receive message CGRP336E and CGRP125E. ConGroup terminates without completing initialization or fails its refresh if it encounters CGRP336E during a refresh. Correct your config file to include a SUSPEND_FAILURE for each consistency group you define.


Syntax

SUSPEND_FAILURE={FAIL|WTOR|RETRY}

Arguments

FAIL

If the SUSPEND process fails, ConGroup does not retry and immediately resumes I/O to the devices in the consistency group. When a ConGroup SUSPEND fails, the remote devices are in an inconsistent state.


Configuration

WTOR

This value gives you, at run time, the option of retrying or failing the SUSPEND. WTOR is valid only if ConGroup is running SUB=MSTR. This is to avoid the possibility of encountering a deadlock with JES.

The following message is issued:

CGRP075W CONGROUP XXXXXXXX RECEIVED AN ERROR WHILE SUSPENDINGCGRP076I REPLY ’R’ TO RETRY OR ’C’ TO CANCEL

Respond to the message as follows:

• Enter R to retry the SUSPEND process. See the RETRY parameter below for more details.

• Enter C to cancel the SUSPEND process. See the FAIL parameter above for more details.

If the timeout value specified by SUSPEND_TIMEOUT is exceeded, the SUSPEND process is canceled.

RETRY

The SUSPEND process continues retrying until a successful completion, or until the timeout value specified in the SUSPEND_TIMEOUT value is exhausted.

CommentsWhen a consistency group is in the process of being suspended, I/O to the devices in the consistency group is halted until the SUSPEND process is complete. This includes the split of BCVs. This is a critical time, and if the error is severe, the SUSPEND process could take minutes to complete.

ExampleSUSPEND_FAILURE=RETRY

SUSPEND[_RETRY]_TIMEOUT

PurposeThe SUSPEND_TIMEOUT parameter specifies the number of seconds the SUSPEND process is allowed to retry. When the time period expires, the SUSPEND process is terminated, I/O to the devices is resumed, and the SUSPEND is deemed unsuccessful. ConGroup issues message CGRP070E followed by message CGRP073E.


Syntax

SUSPEND[_RETRY]_TIMEOUT=seconds


Configuration

Argument

seconds

The number of seconds allowed for a retry. If you do not specify a value, SUSPEND_TIMEOUT defaults to zero (0), meaning that the SUSPEND process does not timeout; that is, that the suspend operation is never automatically canceled.

CommentsYou can specify the SUSPEND_TIMEOUT parameter as either SUSPEND_TIMEOUT or SUSPEND_RETRY_TIMEOUT.

ExampleSUSPEND_TIMEOUT=60

SYMM_DEV#

PurposeThe SYMM_DEV# parameter is another way to include devices in a consistency group. The device numbers specified are the internal Symmetrix device numbers. (ConGroup can support 64k Symmetrix device addresses.)

Note: Do not use SYMM_DEV# for consistency groups that have AutoSwap options associated with them. ConGroup AutoSwap for z/OS is based on cuus, not Symmetrix device numbers, which cannot be used with AutoSwap for z/OS. This restriction does not apply to AutoSwap for z/VM.

Note: When FBA metas are specified with SYMM_DEV# statements, only the heads need to be specified. Members may be specified (mainly for compatibility and/or documentation) but are all ignored. (Starting with PTF SC72018 and SC73005.)


Syntax

SYMM_DEV#=device[,device[,...]],{CUU=cuu|NAME=ctlrname|SER=nnnnnnnnnnnn}

Arguments

device

Internal Symmetrix device numbers. As with values you use for the DEVICE_LIST parameter, you can specify the internal Symmetrix device numbers separately or in ranges. The Symmetrix devices specified must all be contained on the same physical controller.

CUU=cuu

The CUU keyword specifies the z/OS device used to identify the correct controller for the purpose of putting the device into the correct structure.


Configuration

The device specified by cuu does not need to be in a consistency group, nor is it implicitly included in a consistency group by this statement.

NAME=ctlrname

The NAME keyword may be used if a name has been assigned to the SYMM using the ESFCTLNM batch utility (see the ResourcePak Base Product Guide). If the name has embedded blanks it must be enclosed in quotes (e.g. 'Big Controller')

SER=serial

The SER keyword must specify the 12-digit serial number of the controller in which the SYMM_DEV#(s) reside.

Comments ◆ With SRDF consistency groups, the SYMM_DEV# parameter is used to define R1

primary SRDF devices to a consistency group. It is a way to allow the consistency group to manage devices that are not defined to the current LPAR.

◆ During device discovery, if a device specified is not found, ConGroup writes a entry for the device in a timeout queue. Then, periodically, ConGroup attempts to rediscover the device. The device remains on the timeout queue until it is rediscovered.

ExampleSYMM_DEV#=100-1FF,200,300,CUU=298

SYMM_DEV#=100-1FF,200,300,NAME='My Symmetrix'

SYMM_DEV#=100-1FF,200,300,SER=000123409754

SYMGROUP

PurposeThe SYMGROUP parameter defines the RDF ECA Groups that must have ECA protection maintained.

The SYMGROUP parameter does not include devices in an RDF ECA group. SYMGROUP specifies the R1 devices (or R1 mirrors if you have set ALLOW_SHARED_R1S) to be monitored.

If you set ALLOW_SHARED_R1S to specify R1 mirrors and do not specify SYMGROUP, ConGroup protects both legs. This is equivalent specifying SYMGROUP and listing both groups. (The example included in “ALLOW_SHARED_R1S” on page 97 gives an example of this.)

IMPORTANT

If you code any SYMGROUP parameters, then you must specify all consistent RDF Groups with the SYMGROUP parameters. The SYMGROUP parameter applies only to devices defined with the DEVICE_LIST, SMS_GROUP, and SYMM_DEV# parameters.


Configuration


Syntax

SYMGROUP=(group[,group[,...]])

Argument

group

An RDF ECA group that must have its consistency maintained.

group must have one of the following formats:

Note: In the following formats, RDFGroup, RDFGroup-RDFGroup, and ALL can be intermixed.

• ({symmdef|name},RDFGroup[,RDFGroup])

Specifies this parameter for individual R1 remote mirrors.

Note: [,RDFGroup] may be repeated as required.

• ({symdef|name},RDFGroupstart-RDFGroupend)

Specifies this parameter for a range of RDF ECA groups.

• ({symdef|name},ALL)

Specifies this parameter for all RDF ECA groups.

Where:

symdef

The 12 character serial number of the Symmetrix controller for the R1 remote mirrors.

name

The name/alias of the Symmetrix controller for the R1 remote mirrors. You may name the controller using the ResourcePak Base utility ESFCTLNM.

The logical controller name can be a string of up to 64 characters and must have been previously assigned through ResourcePak Base.

If the logical controller name has a simple format (single-word string of uppercase alphas), then you may enter the controller name without quotation marks. If the logical controller name is made up of mixed-case characters or contains spaces, then you need to enclose it in quotation marks.

RDFGroup

A 1 or 2 character string representing the hexadecimal RDF ECA Group number.


Configuration

Comments◆ ConGroup requires that at least one RDF ECA Group for each device (which is always

the case except when concurrent RDF is involved) be defined as requiring consistency to be maintained.

◆ Remote devices of RDF ECA Groups that do not require consistency to be maintained may be set to Adaptive Copy mode.

◆ A consistent RDF ECA Group is one where the R2 is in Sync or Semi-Sync mode.

◆ The SYMGROUP parameter applies to the most recently defined consistency group. It is not global in scope.

◆ The SYMGROUP parameter must come before the corresponding DEVICE_LIST statements.

◆ R1 mirror sharing is implemented through the ALLOW_SHARED_R1S and SYMGROUP configuration parameters. If you specify ALLOW_SHARED_R1S in a consistency group definition, you use a SYMGROUP statement to specify the ECA protection for the legs:

• If you apply SYMGROUP to both consistency groups, ConGroup protects both legs.

• If you omit SYMGROUP completely, ConGroup also protects both legs.

• If you apply SYMGROUP to only one of the groups, only that group is protected.

◆ In concurrent RDF configurations, only one of the RDF Group device relationships is required to be consistent and running in Sync or Semi-Sync mode. The other RDF Group device relationships may be in Adaptive Copy mode. SYMGROUP provides the mechanism for identifying this RDF Group.

When ConGroup trips, only the devices on the consistent link are suspended.

◆ Only protected groups can trip. Although all protected groups are suspended regardless of which protected group trips.

ExamplesConsider the following examples:

◆ SYMGROUP=(000184000345,2,4,6)

Specifies that RDF Groups 2, 4, and 6 on controller 000184000345 require protection.

◆ SYMGROUP=(BOSTON,02-04)

Specifies that RDF Groups 2, 3, and 4 on controller named BOSTON require protection.

◆ SYMGROUP=(000184000345,ALL)

Specifies that all RDF Groups on controller 000184000345 require protection.

◆ SYMGROUP=(WAREHSE4,ALL)

Specifies that all RDF Groups on controller WAREHSE4 require protection.


Configuration

ExamplesThe following examples illustrate how to use the configuration parameters to perform basic ConGroup operations:

1. Create one consistency group and define a number of devices for that group:

SRDF_CONGROUP=SALESDEVICE_LIST=900,C00-C2F,A200-A203

2. Create two consistency groups and define the devices using both z/OS device numbers and volsers:

CONGROUP=DB2TESTDEVICE_LIST=100-10F,STA001,STA002DEVICE_LIST=EC0-EC4DEVICE_LIST=B90-B9FCONGROUP=DB2PRODDEVICE_LIST=FIN001,FIN002,FIN003

3. Create a consistency group that includes an SMS group:

SRDF_CONGROUP=ENGNEERDEVICE_LIST=AC0-ACFSMS_GROUP=SMSENG

4. Create a consistency group that has concurrent RDF defined. RDF Group 2 is defined with AC0-ACF and is the RDF Group to be protected. The devices may also be defined to a second (concurrent) RDF Group that could be in SYNC or ADCOPY mode:

SRDF_CONGROUP=CONCURSYMGROUP=(000184000345,2)DEVICE_LIST=AC0-ACF

Note: The SYMGROUP statement must come before the corresponding DEVICE_LIST statements.

5. Create a consistency group that has STD and SRDF devices:

CONGROUP=MIXEDDEVICE_LIST=100-10F,STA001,STA002DEVICE_LIST_STD=STD000,STD001

6. Run a utility to name a controller:

//EMCJOB JOB (ACCT),'EMC',REGION=0M,CLASS=A /*JOBPARM SYSAFF=* //* MUST ISSUE DEV RESCAN TO SEE NAME //STEP1 EXEC PGM=ESFCTLNM //STEPLIB DD DISP=SHR,DSN=EMC.SSCF700.LINKLIB //SCF$MSF9 DD DUMMY //SYSPRINT DD SYSOUT=* //REPORT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * ASSIGN NAME 'USK1' TO CNTRL (000190300344)


Configuration

7. Use the controller name in a SYMGROUP statement:

SRDF_CONGROUP=MSFTEST SUSPEND_FAILURE=FAIL SUSPEND_RETRY_TIMEOUT=05 SYMGROUP=(USK1,04) DEVICE_LIST=9A00-9A0F

Examples 115

Configuration


CHAPTER 6Command Reference

I

This chapter describes ConGroup commands.

◆ Customer Task Guide ............................................................................................ 119◆ HELP ..................................................................................................................... 122◆ ADD ...................................................................................................................... 122◆ #ADD .................................................................................................................... 124◆ CANCEL................................................................................................................. 125◆ DAS ...................................................................................................................... 128◆ DELETE.................................................................................................................. 128◆ #DELETE................................................................................................................ 129◆ DISABLE................................................................................................................ 130◆ DISPLAY ................................................................................................................ 131◆ #DISPLAY .............................................................................................................. 136◆ ENABLE................................................................................................................. 137◆ LA ......................................................................................................................... 138◆ MOVEOWNER ........................................................................................................ 138◆ QUERY CON........................................................................................................... 140◆ #PIN...................................................................................................................... 140◆ REFRESH ............................................................................................................... 141◆ REMSPLIT.............................................................................................................. 142◆ RESET ................................................................................................................... 143◆ RESUME................................................................................................................ 144◆ SET VERIFY_INTERVAL............................................................................................ 145◆ TAKEOVER ............................................................................................................. 146◆ TRIP ...................................................................................................................... 147◆ #UNPIN ................................................................................................................. 148◆ VERIFY................................................................................................................... 148

Command Reference 117

Command Reference


Command Reference

Customer Task GuideThe customer task guide allows you to quickly find the corresponding command for any ConGroup task.

Table 1 Task Guide

Task Associated Command

Get help on any topic or area. “HELP” on page 122

Add a device to a controller. “ADD” on page 122

Terminate an ongoing ConGroup process. “CANCEL” on page 125

To pass AutoSwap statements to the AutoSwap Extension.

“DAS” on page 128

Remove a device from a controller. “DELETE” on page 128

Remove ConGroup protection from the specified consistency group.

“DISABLE” on page 130

Display the information requested onto the operator console. “DISPLAY” on page 131

Activate ConGroup protection for the specified consistency group, including the dynamic creation of a related CAX group.

“ENABLE” on page 137

Display the SMFIDs of the participating ConGroup address spaces.

“LA” on page 138

Transfer the ownership of a consistency group from the current owner LPAR to another LPAR.

“MOVEOWNER” on page 138

An alias for the DISPLAY command. “QUERY CON” on page 140

To update a consistency group configuration without terminating ConGroup.

“REFRESH” on page 141

To remotely split all the target (R2) standard Symmetrix devices from their BCV devices.

“REMSPLIT” on page 142

To update the state of a consistency group in ConGroup’s internal tables.

“RESET” on page 143

To start the flow of data from all the primary devices in the consistency group to their secondary devices.

“RESUME” on page 144

Specify the time interval (in seconds) before the new auto-verification subtask attempts to verify the state of all ENABLED/ACTIVE consistency groups.

“SET VERIFY_INTERVAL” on page 145

Transfer ownership of a consistency group from the current owner LPAR to the LPAR from which the TAKEOVER command is issued.

“TAKEOVER” on page 146

To trip a consistency group. “TRIP” on page 147

To go through all the verification tests normally done when a consistency group is being enabled.

“VERIFY” on page 148

Customer Task Guide 119

Command Reference

ConGroup operator commandsThe following sections describe the ConGroup operator commands.

Command overview

A ConGroup task contains a number of display and control commands that are issued with the MODIFY command in the following format:

F EMCCGRP,command [argument [argument [...]]]

Where:

EMCCGRP


Note: EMCCGRP is used as the name of ConGroup started task throughout this manual.

command [argument[argument[...]]]

A ConGroup statement, a command followed by its optional argument or arguments.

Command abbreviationsSome ConGroup commands can be abbreviated. For example, to enter a CANCEL command, you can type CAN. Where abbreviations are available, they will be noted using mixed case in the Syntax section; for example: CANcel. In this situation, typing the upper-case portion of the command is all that is required.

Syntax conventions

The commands in this chapter follow these syntax conventions:

◆ CAPITALIZATION = must be typed



◆ | = alternative argument values (|= “or”)

◆ Default values are indicated by an underline. For example, if the parameter has the following option, (YES|NO), the underlined NO indicates the default value.

◆ cuu = Specifies the z/OS device number on the Symmetrix control unit.

◆ cuu-cuu = Specifies a range of z/OS device numbers, where the first cuu is the starting z/OS device number of the range and the second cuu is the ending z/OS device number of the range. The ending device number must not be less than the starting device number.

◆ symdev# (or device) = This parameter specifies a Symmetrix device number, specified in hex. To specify a range of Symmetrix device numbers, use the form of dev1-dev2 where dev1 is the starting Symmetrix device number and dev2 is the ending Symmetrix device number.

In addition, refer to “Conventions used in this document” on page 15 for additional information regarding conventions in this manual.


Command Reference

Multiple subchannel device sets

Multiple subchannel set (MSS) is a z/Architecture and z/OS operating feature that allows applications to access devices in the traditional addressable 4-digit device number range from 0000 to FEFF and, at the same time, allows system addressable devices to be contained in additional subchannel sets. The range of the subchannel set numbers is 0-3, although presently only 0 to 2 are used.

Devices are addressed by z/OS in a particular subchannel set using a 5th digit on the device number. Where 5 digit device numbers are displayed or required for command input they are usually in the form sdddd, where:

s The subchannel set number

ddddThe 4 digit z/OS device number

For example, subchannel set 0 devices are 00000-0FEFF, subchannel set 1 devices are 10000-1FEFF, and so on.

The base, or active, subchannel set are those devices that are accessible to applications. These are the devices that are varied online and available.

The alternate subchannel set devices are those that are not varied online and are only available for system or "special" usage. Along with the current 3390A PAV alias devices, z/OS allows 3390S and 3390D devices to be defined in the alternate subchannel sets. 3390S and 3390D device types are knows as SPECIAL devices. When using ConGroup with AutoSwap, AutoSwap allows 3390D (secondary) devices to be defined as the target (TO) devices in an AutoSwap group. The source (FROM) devices are always in the base, or active, subchannel set.

The 4 digit device portion of the device number is identical for the same device pair. If the source (FROM) was device 01234 then the corresponding target (TO) device would be 11234. In an AutoSwap group all of the 3390D devices must be contained in the same subchannel set. Some system volumes, like the IPL device, cannot be contained within a subchannel set other than 0.

Once the swap is complete, the target (TO) devices are now the base devices even though it is still in a non-0 subchannel set. The source (FROM) devices are now the 3390D SPECIAL device type and are now inaccessible to any normal application usage.

When an IPL is required following a swap to devices in subchannel sets 1-3, the correct devices need to be selected by z/OS as the base devices during IPL processing. The IODF statement of the LOADxx member of SYSn.IPLPARM or SYS1.PARMLIB allows devices in a subchannel set other than 0 to be selected as the base, or active, devices. Refer to the IBM manual, z/OS 1.12 MVS Initialization And Tuning Reference for more information.

Note: To set the option to use multiple subchannel addressing, refer to the description of SCF.DEV.MULTSS in the Initialization chapter of the ResourcePak Base Product Guide.

ConGroup operator commands 121

Command Reference

HELP

PurposeThe HELP command displays all available ConGroup commands with a short explanation.

SyntaxHELP

ParametersNone.

CommentsNone.

ExampleNone.

ADD

PurposeDynamic addition of devices in ConGroup allows modification of a running configuration without the REFRESH command and without disruption to the affected group or to other groups. The goal is to achieve the capability of a 24x7 hour operation of ConGroup.

The ADD command allows users to add from one to ten ranges of devices to an existing consistency group within a single ADD command. The devices must be on a controller that is already part of the group specification. Add requests may only include devices on controllers that already have protected devices on them.

If a range includes non-existent devices (path offline), those devices are skipped and ignored. The remaining devices are then tested for qualification. If, after the path-offline addresses are excluded, any range includes any non-qualifying devices, the entire request fails and no devices are added.

Note: Devices can be added to controllers dynamically. It is not required that devices be added to controllers available to ConGroup at startup.

Note: When FBA metas are involved with the dynamic ADD or DELETE process, all meta members should be specified, unlike the SYMM_DEV# statements where only the heads need to be specified.

Syntax ADD {CUUs(range[,range]...)|DEVices(range[,range]...)}Group(congroup)CNTRL(serialnum)RAgroup(aa[,bb])[TIMeout(120|sss)]


Command Reference

Note: The CNTRL parameter is only used with DEVICES, and is not compatible with the CUU parameter.

Parameters

CUUs(range[,range]...)

Ranges of devices (or single device numbers). All devices are inserted into the running configuration using the RA groups specified with the required RAGROUPS parameter. Using this parameter does not require specifying a serial number via the CTRL/SER parameter.

Up to 10 ranges of CUUs (or single CUUs). A range of numbers is specified as nnnn-mmmm. Single numbers are specified as nnnn. Both range and single numbers are 1 to 4 hex digits representing the z/OS cuus.

DEVICES(range[,range]...)

Up to 10 ranges of devices (or single device numbers).

Both range and single numbers are 1 to 4 hex digits representing the symmetrix devices.

Note: If one or more devices are added using the DEVICE parameter that has a CUU assigned to it, the CUU is not displayed. It would be as if it were defined using the SYMM_DEV# parameter. This should be taken into consideration when updating your parameters after the ADD command is issued.

GROUP(congroup)

The name of consistency group to which the specified devices are added.

CNTRL(serialnum)The serial number of the controller where the devices exist. This is required if the DEVICES parameter is specified.

RAgroup(aa[,bb])

This parameter can consist of up to two (2) RDF group identifiers.

All the devices specified must have operational mirrors on the specified RA group or groups. Remote mirrors are assigned the same RDF-ECA Groupid as the rest of the group on that controller.

[TIMeout(120|sss)]

Optional parameter where sss is the maximum time to wait before giving up on the ADD and is between 1 and 3600 seconds. This would generally only be changed for especially busy systems to give the dynamic add time to complete.

Default value is 120 seconds.

Comments Devices are required to be in sync before executing the ADD function.

The ADD command must pass a SAF test to be executed. ConGroup does a RACF check against FACILITY class and a resource name EMC.CG.API.ADDDEL.

ADD 123

Command Reference

Refer to the “DELETE” on page 128 for a description of the corresponding function of this command.

Limitations include:

◆ ADD is not allowed if ALLOW_SHARED_R1S=YES is specified.

◆ Devices can only be added to existing consistency groups.

◆ Devices can only be added to controllers and RA groups which already include devices that ConGroup is protecting.

◆ If any devices fail validation, the entire request fails and no devices are added.

◆ If AutoSwap is specified, two RDF groups are not allowed. With AutoSwap, only the first RA group is used for all devices. The purpose of an RA group parameter is to validate the existence of pre-existing RA group(s) on the box for use by a device. If the device has one leg, only one RA group is needed. If the device is concurrent, then two RA groups are needed. Since concurrent make no sense in the context of AutoSwap, only the first RA group is used. There is no capability to match separate device ranges to different RA groups.

This command can be executed on a ConGroup participating in the same CGSET. The CGSET number is defined within each ConGroup address space using the new sub-parameter 'CGSETnn' on the MODE initialization parameter. Refer to “MODE” on page 85.

ConGroups with the same CGSET value belong to the same ConGroup 'set' and coordination of ADD processing is conducted through CSC communications amongst the participating ConGroup address spaces. A given ConGroup address space can belong to one and only one CGSET. All ConGroup address spaces in a multi-mode configuration that wish to communicate must have same Set number.

For Star configurations, execution of the ConGroup ADD command must follow the resume processing of devices that were moved into the production Star SRDF/S group, but precede the movement of devices into the SRDF/A group.

ExampleADD DEVICES(F9-FF) CNTRL(000192600399) RAGROUP(90) GROUP(MSFCASST)

#ADD

PurposeThe #ADD CONTROLLER command manually adds a controller to a particular ConGroup address space.

Syntax

#ADD CONTROLLER(serial)

ArgumentsCONTROLLER(serial) is the only valid argument


Command Reference

CommentsControllers are normally added automatically to every ConGroup address space in response to SCF configuration changes, so this command is not usually used or necessary. The only reason to ever add a controller manually is if you had previously deleted it manually from ConGroup on a given LPAR.

When adding a control unit to a ConGroup, use the following processes, based on your ConGroup scenario:

Adding a known control unit: If the controller on which the control unit is located is known to the ConGroup, add the control unit to the group using the DEVICE ADD command.

Adding an unknown control unit: If the controller is not known to the ConGroup, the controller must first be added. For a controller to be known to a ConGroup, it must first be known to SCF. You can display controllers in a ConGroup with the #DISPLAY GATEKEEPERS command. If it is not visible in the #DISPLAY GATEKEEPERS display, then check to see if it is known to SCF. If it is not known to SCF, it must be added to SCF. When added to SCF (either by INI file modification and an explicit DEV REFRESH, or by IODF change and an automatic DEV REFRESH), the ConGroup is made aware of the controller and implicitly adds it to its tables.

For more information, refer to the discussion in the Operations chapter under the section title IODF considerations, “Addition and Deletion of Controllers and Gatekeepers” on page 49.

ExampleThe following example manually adds a controller with a serial number of 000812004096 to ConGroup:

#ADD CONTROLLER(000812004096)

CANCEL

PurposeThe CANCEL command terminates an ongoing ConGroup process that may have been started by a ConGroup command or by external factors.

For example, a REMSPLIT (remote split) process started by a REMSPLIT command or a SUSPEND process started by an external ConGroup trip continues indefinitely until:

◆ The process ends normally.

◆ The process is terminated by a time limit mechanism (for example, SUSPEND_TIMEOUT).

◆ The process is terminated by the CANCEL command.

Valid operands for CANCEL are:

◆ SUSPEND

◆ RESUME

◆ REMSPLIT

CANCEL 125

Command Reference

These operands may optionally be followed by a consistency group name.

IMPORTANT

If you do not specify a consistency group name, all consistency groups are terminated.

Syntax

CANcel {SUSPEND|REMSPLIT|RESUME} [congroupname]

Parameters

SUSPEND

Specifies cancelling one or all SUSPEND processes.

REMSPLIT

Specifies cancelling one or all REMSPLIT processes.

RESUME

Specifies cancelling one or all RESUME processes.

congroupname

Specifies the consistency group name.

CommentsWhile a consistency group is being suspended, I/O to all the devices in the consistency group is queued until the SUSPEND process completes. While in this state, the applications using these devices are hung, waiting for the I/O to complete.

If a system problem is delaying the SUSPEND process, you may wish to forego having consistent data and allow the applications using the consistency group devices to continue.

CANCEL and SUSPEND

You can issue CANCEL SUSPEND with an argument. The argument specifies the consistency group whose SUSPEND process you want to cancel. If you do not supply an argument, all active SUSPEND processes are cancelled.

Note that this is a manual intervention to the SUSPEND process. You can automatically cancel a SUSPEND by supplying a SUSPEND_TIMEOUT statement in the configuration for the consistency group.

CANCEL and REMSPLIT

Depending on the number and state of the devices, a REMSPLIT process can take a long time to complete. When the REMSPLIT process receives temporary errors, it enters a retry loop. In each iteration of the loop, the REMSPLIT process takes the following steps:

◆ Waits the number of seconds specified in REMSPLIT_INTERVAL.

◆ Issues message CGRP206I.


Command Reference

◆ Retries the split request.

During this retry loop, you may wish to intervene manually and cancel the process.

You can issue CANCEL REMSPLIT with an argument. The argument specifies the consistency group whose REMSPLIT process should be cancelled. If you do not supply an argument, all active REMSPLIT processes are cancelled.

CANCEL and RESUME

A CANCEL RESUME cancels the resume processing wherever it is detected. This could be:

◆ Before any resumes are issued.

◆ During the resume processing.

◆ In the wait-for-synchronization process.

CANCEL RESUME does not stop the synchronization between the local and remote devices that have already had their data flow resumed. Any invalid tracks on the local devices continue to synchronize with their respective remote devices.

CANCEL RESUME merely terminates the monitoring process that informs you when all the devices in a consistency group are synchronized and that the remote data is consistent. Message CGRP007I is not issued when the devices are synchronized because the RESUME process has not been terminated.

You can issue CANCEL RESUME with an argument that specifies the consistency group whose RESUME process should be cancelled. If you do not supply an argument, all active RESUME processes are cancelled.

You should issue a CANCEL REMSPLIT and a CANCEL RESUME if you issue a RESUME SPLIT. If you just issue a CANCEL RESUME, ConGroup does not process the CANCEL RESUME until after SPLIT processing is complete.

Note: You can issue SRDF Host Component commands to suspend RDF or change the mode. After you issue CANCEL, you must issue DISABLE to disable ConGroup. Only after ConGroup is disabled can you issue SRDF Host Component commands.

ExamplesThe following example cancels the SUSPEND process for all active SUSPEND processes.

CANCEL SUSPEND

The following example cancels the REMSPLIT process for the consistency group named DB2PROD.

CANCEL REMSPLIT DB2PROD

CANCEL 127

Command Reference

DAS

PurposeThe DAS command passes AutoSwap statements to the AutoSwap Extension.

Applicable groupsConsistency groups with ConGroup AutoSwap enabled through CAX.

Syntax

DAS autoswapstatement

Parameter

autoswapstatement

Specifies the AutoSwap statement (command and arguments) to be executed.

Note: The AutoSwap Product Guide describes valid AutoSwap commands.

Examples The following example displays AutoSwap options in effect.

DAS DISPLAY OPT

The following example executes a SWAP of the devices in PATREC.

DAS SWAP GROUP PATREC

DELETE

PurposeDynamic deletion of devices in ConGroup allows modification of a running configuration without the REFRESH command and without disruption to the affected group or to other groups. The goal is to achieve the capability of a 24x7 hour operation of ConGroup.

The DELETE command allows users to delete from one to ten ranges of devices from an existing consistency group within a single DELETE command. If any specified ranges include unprotected devices, the entire request fails.

Note: When FBA metas are involved with the dynamic ADD or DELETE process, all meta members should be specified, unlike the SYMM_DEV# statements where only the heads need to be specified.

Syntax DELete {CUUs(range[,range]...)|DEVices(range[,range]...)}Group(congroup)CNTRL(serialnum)[TIMeout(120|sss)]

Note: The CNTRL parameter is only used with DEVICES, and is not compatible with the CUU parameter.


Command Reference

Parameters

CUUs(range[,range]...)

Up to 10 ranges of CUUs (or single CUUs).

A range of numbers is specified as nnnn-mmmm. Single numbers are specified as nnnn. Both range and single numbers are 1 to 4 hex digits representing the z/OS cuus.

DEVICES(range[,range]...)

Up to 10 ranges of devices (or single device numbers).

Both range and single numbers are 1 to 4 hex digits representing the symmetrix devices.

GROUP(congroup)

The name of consistency group to which the specified devices are deleted.

CNTRL(serialnum)

The serial number of the controller where the devices exist. This is required if the DEVICES parameter is specified.

[TIMeout(120|sss)]Optional parameter where sss is the maximum time to wait before giving up on the ADD and is between 1 and 3600 seconds. This would generally only be changed for especially busy systems to give the dynamic add time to complete.

Default value is 120 seconds.

Comments Refer to “ADD” on page 122 for the description of the corresponding function of this command.

The DELETE command must pass a SAF test to be executed. ConGroup does a RACF check against FACILITY class and a resource name EMC.CG.API.ADDDEL.


◆ DELETE is not allowed if ALLOW_SHARED_R1S=YES is specified.

◆ If any of the devices are not currently being protected by ConGroup, then entire request fails.

ExampleDELETE DEVICES(2B2-2B4) CNTRL(000192600399) GROUP(EMCGRP)

#DELETE

PurposeThe #DELETE manually deletes a controller from a particular ConGroup address space.

Syntax

#DELETE CONTROLLER(serial)

#DELETE 129

Command Reference

ArgumentsCONTROLLER(serial) is the only valid argument.

CommentsControllers do not normally need to be deleted, so this command is not usually used or necessary except as directed by EMC Support.

For more information, refer to the discussion in the Operations chapter under the section title IODF considerations, “Addition and Deletion of Controllers and Gatekeepers” on page 49.

Example#DELETE CONTROLLER(000812004096)

DISABLE

PurposeThe DISABLE command removes ConGroup protection from the specified consistency group.

Syntax

DISABLE congroupname [{NOWAIT | WAIT}]

Parameter

congroupname


NOWAIT

If used (or defaulted) NOWAIT specifies that the command is attempted immediately. If the ALL-CONGROUPS lock is already held when the DISABLE command is entered, the command fails and message CGRP387W is issued.

WAIT

Specifies allowing commands to be “stacked” by waiting until the ALL-CONGROUPS lock is available.

Comments◆ If a consistency group is DISABLED, there is no ConGroup protection active. The

consistency group is essentially a defined group of devices with nothing to do.

◆ The DISABLE command statement changes the status of the devices in the consistency group. It removes both ConGroup and the RDF-ECA protection and also deletes any related AutoSwap group.


Command Reference

Note: “ConGroup monitoring” on page 23 provides information about consistency group states.

ExamplesThe following example removes the consistency group named SALES from ConGroup protection.

DISABLE SALES

The following example removes ConGroup protection from the consistency group named PROFIT and waits for the ALL-CONGROUPS lock.

DISABLE PROFIT WAIT

DISPLAY

PurposeThe DISPLAY command displays the information requested onto the operator console.

Syntax

DISplay {CONgroup[group][{LIST|NOLIST}] | ENVIRONMENT}

Parameters

CONgroup

Displays all the devices and their respective volsers for a given consistency group.

Note: You can abbreviate CONGROUP as CON. You can also abbreviate DISPLAY CONGROUP as D C.

group

Specifies the consistency group name. If you do not specify a consistency group name with DISPLAY, all the consistency groups are displayed.

LIST|NOLIST

Controls the display of detail information. “DISPLAY_CONGROUP_LISTOPT” on page 84 discusses the default settings. You can override the default with DISPLAY.

ENVIRONMENT

DISPLAY ENVIRONMENT is primarily used for diagnostic purposes. It is primarily of use to experienced users and EMC support staff.

Displays configuration information about the consistency group environment rather than a specific consistency group definition. This includes information about AUTO_VERIFY, the state of AUTO_REFRESH, the RESUME and REMSPLIT options in effect, the SAF class and resource names, and the default DISPLAY CONGROUP list options.

DISPLAY 131

Command Reference

Comments◆ In previous versions of ConGroup, DISPLAY statements would fail if they encountered a

host-initiated device reserve. Starting with Version 6.2, DISPLAY statements can penetrate host-initiated hardware reserves and run to conclusion.

◆ If the consistency group you are displaying is defined as capable of being swapped, the display listing includes the line “This is an AutoSwap group.” For example, consider the following display resulting from a DISPLAY CONGROUP NOLIST:

GLOBAL SETTINGS: COUPLEDS_ALLOWED=NO DISABLE_AT_SHUTDOWN=ON PAGEDEV_ALLOWED=YES REMSPLIT_INTERVAL=5 RESUME_INTERVAL=30 SEMISYNC_ALLOWED=NO CONGROUP= CGRPX1B ENABLED ...ACTIVE USE_FBA_NR_ON_TO=YES SUSPEND_FAILURE=RETRY SUSPEND_RETRY_TIMEOUT=0 This is an AutoSwap group CTLR SER#=000190300344 uCode: 58740239 GroupId: 0001

◆ There are two instances that cause a consistency group to be set in a BLOCKED state.

• If an abend occurs within the address space, but does not cause the started task to end.

• A failed AutoSwap validate action.

A periodic health checker immediately detects a set flag in the global area and set the consistency group to BLOCKED. The flag is also checked whenever an MSC registration request is attempted. The BLOCKED status is then displayed when the DISPLAY command is issued.

The ‘BLOCKED’ flag can be cleared with the ConGroup RESET command. This can be done when and if the user determines that the prior abend has appropriately recovered or does not affect this particular group. Or, you can clear it when the BLOCKED state is due to an AutoSwap validation and the problem has been resolved.

The following is an example of a BLOCKED indicator on a group display:

GLOBAL SETTINGS: COUPLEDS_ALLOWED=YES DISABLE_AT_SHUTDOWN=ON PAGEDEV_ALLOWED=YES REMSPLIT_INTERVAL=9999 RESUME_INTERVAL=30 SEMISYNC_ALLOWED=YES CONGROUP= CGRPX1B DISABLED....ACTIVE....BLOCKED USE_FBA_NR_ON_TO=YES SUSPEND_FAILURE=FAIL SUSPEND_RETRY_TIMEOUT=0

This is an AutoSwap group CTLR SER#=000190300344 uCode: 58740239 GroupId: 0001+-----------------------------------------------------+ | R1 | R1 |Volser|Rdf-| CG |Sync|InvT|RA GRP/Mirr| NR | |Cuu |Dev#|or oth|1234|1234|1234|1234| 1 2 3 4|1234| +-----------------------------------------------------+ |82A0|00C8|UTN5E0|....|..D.|..S.|....|..|..|20|..|....| |82A1|00C9|UTN5E1|....|..D.|..S.|....|..|..|20|..|....| |82A2|00CA|UTN5E2|....|..D.|..S.|....|..|..|20|..|....| |82A3|00CB|UTN5E3|....|..D.|..S.|....|..|..|20|..|....| |82A4|00CC|UTN5E4|....|..D.|..S.|....|..|..|20|..|....|


Command Reference

|82A5|00CD|UTN5E5|....|..D.|..S.|....|..|..|20|..|....| |82A6|00CE|UTN5E6|....|..D.|..S.|....|..|..|20|..|....| |82A7|00CF|UTN5E7|....|..D.|..S.|....|..|..|20|..|....|

◆ The DISPLAY CONGROUPS output has been enhanced to show the Enginuity level of each Symmetrix controller in the group (when you specify or default to LIST) and the unique group ID number. For example:

CTLR SER#=000190300344 uCode: 57720042 GroupId: 0001

Example The detailed report consists of a detail section and group summary. (You produce a detailed report by specifying the LIST argument.) The following example of DISPLAY CONGROUP shows a detailed report.

The TRIPPABLE field is a computed value that indicates whether the group can be tripped.

CGRP282I D C LIST 204*** Begin Display from system X04 ***GLOBAL SETTINGS: COUPLEDS_ALLOWED=NODISABLE_AT_SHUTDOWN=OFFPAGEDEV_ALLOWED=NOREMSPLIT_INTERVAL=10RESUME_INTERVAL=10SEMISYNC_ALLOWED=YESCONGROUP= CGRPLR ENABLED ACTIVE ... USE_FBA_NR_ON_TO=NO SYNCLINKFAILURE=NO TRIPPABLE=YES SUSPEND_FAILURE=FAIL SUSPEND_RETRY_TIMEOUT=0CTLR SER#=000190300344 uCode: 57720042 GroupId: 0001USC1 - 2105 5772 +-----------------------------------------------------+ | R1 | R1 |Volser|Rdf-| CG |Sync|InvT|RA GRP/Mirr| NR | |Cuu |Dev#|or oth|1234|1234|1234|1234| 1 2 3 4|1234| +-----------------------------------------------------+ |4D3A|007A|......|A...|..E.|..S.|....|..|..|23|..|....| |4D3B|007B|......|A...|..E.|..S.|....|..|..|23|..|....||4D3C|007C|......|A...|..E.|..S.|....|..|..|23|..|....||4D3D|007D|......|A...|..E.|..S.|....|..|..|23|..|....|+-----------------------------------------------------+

If there is more than one control unit in the consistency group (and if you specify LIST), the report contains a series of detail sections followed by a single group summary section.

If ConGroup cannot determine the status of a consistency group, ConGroup displays the last known status followed by ’????’.

Note: All statuses in this display are polled results.

Table 2 lists the meanings of the items in the detailed section of the report.

Table 2 DISPLAY CONGROUP report: Detailed section (page 1 of 2)

Column Shows

R1 Cuu The z/OS device number.

R1 Dev# The Symmetrix device number.

Volser or other

The volser if the device is online or “..“if the device is offline.

DISPLAY 133

Command Reference

The summary report is as follows:

Group Summary:+-----------------------------------------------------+ | CG | CAX | RECA | TNR | Dev# | Invt |+-----------------------------------------------------+

ENABLED NO Y/ARMED NONE 11 0

Rdf- Device status:• “A” - Armed, the normal status.• “T” - Timeout, the window is closed by timeout.• “C” - Closed, the trip processing is complete. (That is,

shows when complete.)• “O” - OPEN, the ECA Window that is open as the result of a

ConGroup trip. Otherwise “....”

CG The consistency group status:• “E” for enabled. • “D” for Disabled. (This status is based on polling of the R1

only.)

Sync The SRDF status for each mirror:• “S” for Synchronized (Ready). • “U” for Unsynchronized (Not Ready).This is independent of whether ConGroup can protect the mirror.

InvT The invalid track status for each mirror:• “I” for mirrors that have invalid tracks. This status applies to any configured mirror.

RA GRP/Mirror Display

RDF group and mirror mask numbers; otherwise, “..“ if the corresponding mirror is not RDF protected.

NR The Not Ready status for each mirror. “N” for mirrors that are not ready. Only mirrors shown in the Prot column are tested. N in 1 is usr NR.

Table 2 DISPLAY CONGROUP report: Detailed section (page 2 of 2)

Column Shows


Command Reference

Table 3 lists the meanings of the items in the group summary section of the report.

The following example is a summary report. Because the NOLIST argument was specified, it has no detail section, only a summary section.

GLOBAL SETTINGS: COUPLEDS_ALLOWED=NO DISABLE_AT_SHUTDOWN=OFF PAGEDEV_ALLOWED=NO REMSPLIT_INTERVAL=10 RESUME_INTERVAL=10 SEMISYNC_ALLOWED=YES SRDFCGP= CGRPLR ENABLED ACTIVE USE_FBA_NR_ON_TO=NO

SUSPEND_FAILURE=FAIL SUSPEND_RETRY_TIMEOUT=0 Group Summary: +-----------------------------------------------------+ | CG | CAX | RECA | TNR | Dev# | Invt | +-----------------------------------------------------+ ENABLED NO Y/ARMED NONE 11 0

Table 3 DISPLAY CONGROUP report: Group summary section

Column Shows

CG Consistency group status - any of the following values:• ENABLED = All of the devices are ConGroup enabled.• DISABLED = All of the devices are ConGroup disabled.• MIXED = Some devices are enabled and some are

disabled.

CAX Any of the following values:• YES = The consistency group is defined as a CAX group.• NO = The consistency group is not defined as a CAX group.

/DFINED = The underlying AutoSwap group exists./UNDEFD = The underlying AutoSwap group does not exist.

RECA The RDF-ECA status for devices that are protected with RDF-ECA mode:• Y/CLEAR, no RDF-ECA is defined.• Y/ARMD, RDF-ECA is armed, the normal RDF-ECA status.• Y/OPEN, the ECA Window that is open as the result of a

ConGroup trip.• Y/CLOSED, the trip processing is complete. (shows when

tripped), the ECA Window is closed via SYSCALL or by timeout.

• Y/MIXED, the devices are not all in the same status.

TNR Target Not Ready - any of the following values:• ALL = All protected mirrors are TNR.• NONE = None of the protected mirrors are TNR.• MIXED = Some mirrors are TNR and others are not.

Dev# The total R1 device count for the group.

Invt The total number of invalid tracks in the group.

DISPLAY 135

Command Reference

The following is an example of the type of report that DISPLAY ENVIRONMENT can display. (The DISPLAY ENVIRONMENT report at your site may show slightly different fields.)

TIME/GHA: 14721462/50A3D53C AUTO_REFRESH=ON DISABLE_ON_VERIFY_ERROR=YES DISPLAY_CONGROUP_LISTOPT=NOLIST RESUME_OPTION=NOTNRMSG SAF_CLASS=DATASET SAF_PROFILE=EMC.VALIDATE.ACCESS VERIFY_INTERVAL=0 Work Pool Size: 10 Free: 10 Busy: 0 5 Second Request History: 0 4 0 0 0 Gatekeeper Queue HWM: 0 ConGroup is executing in SINGLE mode AutoSwap Ownerid=Z05 , LOCAL SYSTEM IS Z05 This is the owning system AutoSwap Listencode=128

Besides the display of the set global parameters, this report includes the items shown in Table 4:

#DISPLAY

PurposeThe #DISPLAY GATEKEEPERS command displays which CUUs are pinned.

Syntax#DISPLAY GATEKEEPERS

ArgumentsGATEKEEPERS is the only valid argument.

ExampleThe following example displays the current gatekeeper status for each controller ‘known’ by a ConGroup internal gatekeeper server:

Table 4 DISPLAY ENVIRONMENT report

Column Shows

TIME/GHA An internal debugging value used by EMC.

Work Pool Size The current work pool size. Indicates the number of active internal worker tasks -- for diagnostic use only. FREE indicates the number of worker tasks not currently working. BUSY indicates the number of worker tasks currently working.

5 Second Request History

The number of work pool requests (typically polls) in each of the last 5 seconds is displayed as series of five numerals. The most recent second is at the left of the list.

Gatekeeper Queue HWM

The maximum number of requests for a gatekeeper that could not be immediately satisfied. (HWM stands for high water mark.)


Command Reference

#DISPLAY GATEKEEPERS

Produces output similar to this (serial, uCode, channel address, location, type, pin status):

000195600140 5076 8003 LOCAL USR 000195700079 5076 3801 LOCAL USR PINNED000195700079 5076 3802 LOCAL USR PINNED000195700080 5076 3C00 LOCAL SCF

ENABLE

PurposeThe ENABLE command activates ConGroup protection for the specified consistency group, including the dynamic creation of a related CAX group if necessary. When ConGroup starts, the default is to start all consistency groups in an enabled state.

If ConGroup encounters a problem and cannot enable the consistency group, it puts the consistency group in a disabled state. When the problem is resolved, you can use the ENABLE command to activate ConGroup protection for the consistency group.

Syntax

ENable congroupname [FORCE] [{NOWAIT|WAIT}]

Parameters

congroupname


FORCE

Reenables the consistency group after a manual swap back of the devices. The FORCE parameter is intended to be used after a manual swap back so that operators are made aware that they must perform a swap back before enabling.

Note: An ENABLE congroupname FORCE fails if all of the devices in congroupname have not been swapped back.

NOWAIT

If used (or defaulted) NOWAIT specifies that the command is attempted immediately. If the ALL-CONGROUPS lock is already held when the ENABLE command is entered, the command is failed and message CGRP387W is issued.

WAIT

WAIT allows a command to be “stacked” by waiting until the ALL_CONGROUPS lock is available.

Comments◆ “ConGroup monitoring” on page 23 describes the possible states of consistency

groups.

ENABLE 137

Command Reference

◆ If you are operating in multi-LPAR mode, ConGroup automatically coordinates ENABLE requests on all LPARs. If you are operating in single-LPAR mode, you have to manually issue ENABLE requests on all relevant LPARs.

ExamplesThe following example starts ConGroup protection for the consistency group named PROD.

ENABLE PROD

The following example starts ConGroup protection for the consistency group named TEST and waits for the ALL_CONGROUPS lock.

ENABLE TEST WAIT

LA

PurposeThe LA command displays the SMFIDs of the participating ConGroup address spaces.

Syntax

LA

ParametersNone.

CommentsYou can see ConGroup nodes only by issuing the LA command and by examining connect and disconnect messages.

ExampleThe following example lists participating address spaces. The list includes a list of hosts running ConGroup. If there is an owning host (as there is in this case), the owner is marked.

F CG61A,LA EMCP001I LA Z06 <-- OWNER Z05 Z04

MOVEOWNER

PurposeThe MOVEOWNER command transfers the ownership of a consistency group from the current owner LPAR to another LPAR. You can issue MOVEOWNER from any LPAR running ConGroup. After MOVEOWNER is issued, but before ConGroup acts upon it, ConGroup validates the existence of the specified LPAR(s).


Command Reference

You can use the MOVEOWNER command only if you are using multi-LPAR mode.

Note: “GLOBAL” on page 85 describes the OWNER subparameter. “CAXOPTS” on page 73 discusses the lost owner policy, and “ConGroup AutoSwap Extension” on page 45 provides information about AutoSwap.

Syntax

MOVEOWNER [,] {LOCAL|to_smfid}

Parameters

LOCAL

If you specify LOCAL, ConGroup assigns ownership to the LPAR from which you issued MOVEOWNER.

to_smfid

The SMF ID of the new owner LPAR (up to four characters).

Note: Parameters are required for the MOVEOVER command.

CommentsIn normal operations (for example, if you need to transfer ownership because the owner LPAR is going to be IPLed) when the current prospective new owner is running, you use MOVEOWNER to transfer consistency group ownership.

As of ConGroup 7.2, MOVEOWNER/TAKEOVER was totally redesigned and rewritten to quickly modify the ownership as requested by the command entered. This replaces the slow previous process of actually recreating the groups again (and in the process re-enabling them).

When you recycle a new LPAR, it inherits the same status of the owner as at startup. The user has the choice of either ensuring the current owner is in a completely enabled state (both consistency group and AutoSwap groups) or of moving ownership back and doing a global ENABLE.

You may use MOVEOWNER LOCAL or TAKEOVER to transfer ownership to the LPAR that is issuing the command.


◆ Ownership is moved for every group that ConGroup protects.

◆ Moveowner not allowed with Shared R1s

Note: “TAKEOVER” on page 146 describes the TAKEOVER command.

Note: “MODE” on page 85 describes multi-LPAR mode.

ExampleThe following example moves the ownership from LPAR SYSA to SYSB.

MOVEOWNER 139

Command Reference

MOVEOWNER,SYSA,SYSB

ConGroup responds with the following message:

CGRP650I Ownership Moved To:SYSB(this system) From:SYSA

The following example moves the ownership from the current owner LPAR to the LPAR the command was run on.

MOVEOWNER,LOCAL

ConGroup responds with the following message:

CGRP650I Ownership Moved To:EMC7 (this system) From:EMC2

#PIN

PurposeThe #PIN command manually pins a ConGroup gatekeeper server managed CUU.

Note: For determining proper conditions for using this command, refer to the discussion on pinning gatekeepers in the Operations section of this manual.

Syntax#PIN CUU(nnnn)

ArgumentsCUU(nnnn)

A single channel address of the Gatekeeper to be pinned.

Example#PIN CUU(03C8)

QUERY CON

PurposeThe QUERY CON command is an alias for the DISPLAY command. You can use QUERY CON anywhere you would use the DISPLAY command.

Syntax

QUERY CONgroup [congroupname]


Command Reference

Parameter

congroupname

Specifies the consistency group name. To display all consistency groups, do not specify any consistency group name as a parameter.

CommentsIn previous versions of ConGroup, QUERY CON statements would fail if they encountered a host-initiated device reserve. Starting with Version 6.2, QUERY CON statements can penetrate host-initiated hardware reserves and run to conclusion.

ExampleThe following example displays all the consistency groups.

QUERY CON

The following example displays all the devices in consistency group named DB2PROD.

QUERY CON DB2PROD

REFRESH

PurposeThe REFRESH command dynamically updates a consistency group configuration without terminating ConGroup. When you define a consistency group through GNS or later update the definition, you can activate that definition by issuing a REFRESH statement. REFRESH implements the new configuration.

If any consistency group is suspended, disabled, or has a SUSPEND, a RESUME, or a REMSPLIT in process, an error message is produced.

The state of the consistency group configuration after the REFRESH completes is dependent on the number and type of errors (if any) encountered during the REFRESH. The REFRESH is processed in two phases:

1. A syntax and verification phase

2. An enabling phase

Any errors in the syntax and verification phase terminates the REFRESH and the old configuration is still active. Message CGRP201E is issued signifying this type of error.

After the new configuration has passed verification, the REFRESH statement disables all the old consistency groups or CAX groups and attempts to enable the new consistency groups or CAX groups. The new consistency or CAX groups may not be enabled if one or more devices are in an improper state for enablement.

For example, if a device has invalid tracks, the consistency group to which it belongs is not enabled. Although message CGRP200I is issued indicating that the new configuration is active, you should take special care to verify that the new consistency groups have been enabled successfully.

To enable the new consistency configuration, even if all the consistency groups are not in an enable-ready state, use the FORCE argument.

REFRESH 141

Command Reference

Syntax

REFresh [FORCE]

Parameter

FORCE

Enable the new consistency configuration even if all consistency groups are not in a proper state for enablement.

Comments◆ If you are operating in multi-LPAR mode, ConGroup automatically issues the REFRESH

statement on all LPARs using the same CSC listener port. If you are operating in single-LPAR mode, you have to manually issue the REFRESH on all relevant LPARs.

ExampleNone.

REMSPLIT

PurposeFor a specified consistency group, the REMSPLIT (REMoteSPLIT) command remotely splits all the target (R2) standard Symmetrix devices from their BCV devices (if they are attached to one). REMSPLIT applies only to the BCVs established to the target (R2) devices. It does not apply to BCVs established to standard devices in the consistency group (for example, the standards defined in DEVICE_LIST_STD).

You should issue REMSPLIT just before you issue a RESUME command for a specified consistency group so that you can save a separate copy of the consistent data. This step insures that there is a consistent copy of data in the event of a failure during the subsequent RESUME process.

Note: Remember that during the RESUME process, data consistency on the remote side is delayed until the RESUME is complete. By creating copies of the data with REMSPLIT, you ensure that there is always a copy of consistent data on which you can rely.

REMSPLIT starts an asynchronous process to split all the BCVs.

For a REMSPLIT operation to be honored, the consistency group must be enabled and suspended. The consistency group cannot have a RESUME or REMSPLIT process already in progress.

A successful completion of the REMSPLIT process is indicated with message CGRP203I. An unsuccessful completion is indicated with either message CGRP204E or CGRP205E.

Syntax

REMSPLIT congroupname


Command Reference

Parameter

congroupname


CommentsNone.

ExampleThe following example splits the target (R2) devices from their BCV devices for the consistency group named PROD.

REMSPLIT PROD

RESET

PurposeThe RESET command updates the state of a consistency group in ConGroup’s internal tables. When you issue RESET, you allow ConGroup to recognize a change in the state of a consistency group that would ordinarily not be recognized until the next auto-verify cycle executes. ConGroup sets the state of the consistency group based on whether or not the consistency group was enabled for ConGroup protection and suspended/resumed by another LPAR.

RESET does not automatically verify all the attributes of each device (for example, synchronous versus adcopy, contains a page dataset, and so on). If you want full verification, use the VERIFY option.

RESET re-enables trip processing for a consistency group that has had a suspend timeout failure. After a suspend timeout failure, data at the remote site is not guaranteed to be consistent. Most likely, some devices are suspended, while other devices are not. You need to resolve the reason for the suspend timeout failure and than fully resume the consistency group (ENA/ACT) before you issue the RESET command for the consistency group.

Syntax

RESET congroupname [VERIFY]

Parameters

congroupname


VERIFY

Specifying VERIFY is equivalent to issuing a RESET command followed by a VERIFY command.

CommentsNone.

RESET 143

Command Reference

ExampleThe following example updates the state information for a consistency group named SALES.

RESET SALES

RESUME

PurposeWhen data from one source device in a consistency group cannot reach its corresponding secondary device, the following takes place:

◆ All data transmissions from the primary devices in the consistency group are suspended.

◆ The BCVs are split from any STD devices.

When you have resolved the SRDF mirroring issues between the primary and secondary devices that caused the suspension, use RESUME to start the flow of data from all the primary devices in the consistency group to their secondary devices.

When a consistency group is resumed, the secondary devices are in an inconsistent state until all invalid tracks have been transferred to the secondary devices. The consistency group is not enabled until the primary and secondary devices are synchronized.

In configurations with concurrent SRDF (two secondaries for one or more of the standard devices protected by ConGroup), you need to give special consideration to choose which of the secondaries you want to use to accomplish the RESUME.

If STD devices are defined as part of the consistency group, then these devices must have BCV devices established and synchronized to them prior to performing the resume. A consistency group cannot be resumed if there is a STD device either without a BCV or with a BCV that is not synchronized.

You can see this process when you enter a RESUME statement. After an internal RESUME statement is issued to each Symmetrix system in the consistency group and message CGRP006I is issued, the RESUME operation is not completed until message CGRP007I is issued.

In the meantime, you can see the status of the RESUME by message number CGRP022I and a companion message that specifies why the RESUME is not complete. Message CGRP022I is periodically issued until the RESUME is complete.

The SPLIT option of RESUME operates only on the remote secondary (R2) BCVs. The standard devices in the consistency group must use EMC TF/Mirror or EMC SRDF Host Component to split local BCVs.

Syntax

RESume congroupname [SPLIT][{NOWAIT|WAIT}]


Command Reference

Parameters

congroupname


SPLIT

Specifies that all the remote devices for the consistency group are to be split from their BCV devices (if they are attached to one) before the RESUME process starts. In essence, specifying SPLIT is equivalent to entering the REMSPLIT command followed by a RESUME command.

Note: The SPLIT option does not split BCVs established to STD devices. The SPLIT option applies only to BCVs attached to R2 devices.

NOWAIT

If used (or defaulted) NOWAIT specifies that the command is attempted immediately. If the ALL-CONGROUPS lock is already held when the command is entered, the command is failed and message CGRP387W is issued.

WAIT

WAIT allows a command to be “stacked” by waiting until the ALL-CONGROUPS lock is available.

CommentsIf you are operating in multi-LPAR mode, ConGroup automatically implements your RESUME on all LPARs using the same CSC listener port. If you are operating in single-LPAR mode, you have to manually issue RESUMEs on all relevant LPARs.

ExampleThe following example resumes the flow of data for a consistency group named SALES.

RES SALES

SET VERIFY_INTERVAL

PurposeThe SET VERIFY_INTERVAL command specifies the time interval (in seconds) before the new auto-verification subtask attempts to verify the state of all ENABLED/ACTIVE consistency groups. This is to ensure that all consistency group devices are still in the expected state.

Syntax

SET VERIFY_INTERVAL=interval

SET VERIFY_INTERVAL 145

Command Reference

Parameter

interval

The time interval (in seconds). The maximum value you can specify is 99,999,999 (seconds). If you specify zero (0), you disable the verification interval.

CommentsNone.

ExampleThe following example sets the verification interval to 600 seconds, 10 minutes.

SET VERIFY_INTERVAL=600

TAKEOVER

PurposeThe TAKEOVER command transfers ownership of a consistency group from the current owner LPAR to the LPAR from which the TAKEOVER command is issued.

You can issue TAKEOVER from any LPAR running ConGroup.

Note: “GLOBAL” on page 85 discusses ownership. “CAXOPTS” on page 73 discusses the lost owner policy. “ConGroup AutoSwap Extension” on page 45 discusses AutoSwap.

Syntax

TAKEOVER

ConGroup assigns ownership to the LPAR from which you issued the TAKEOVER statement.

CommentsIn a situation where the current owner LPAR is not running, you use TAKEOVER to transfer ownership.

You may use MOVEOWNER LOCAL or TAKEOVER to transfer ownership to the LPAR that is issuing the command.

In normal operations (for example, if you need to transfer ownership because the owner LPAR is going to be IPLed) when both the current and prospective new owner are running, you use MOVEOWNER to transfer consistency group ownership.

As of ConGroup 7.2, MOVEOWNER/TAKEOVER was totally redesigned and rewritten to quickly modify the ownership as requested by the command entered. This replaces the slow previous process of actually recreating the groups again (and in the process re-enabling them).


Command Reference

When you recycle a new LPAR, it inherits the same status of the owner as at startup. The user has the choice of either ensuring the current owner is in a completely enabled state (both consistency group and AutoSwap groups) or of moving ownership back and doing a global ENABLE.


◆ Ownership is moved for every group that ConGroup protects.

◆ Moveowner not allowed with Shared R1s

Note: “MOVEOWNER” on page 138 describes the process of transferring ownership.

Note: “MODE” on page 85 describes multi-LPAR mode.

ExampleTAKEOVER

TRIP

PurposeThe TRIP command trips a consistency group. You can issue a TRIP command from any LPAR. You do not have to trip a consistency group from the owning LPAR.

When you issue a TRIP, standard RDF-ECA processing maintains group consistency while temporarily stalling I/O operations at the controller. At the same time, ConGroup suspends all R1 and R2 relationships in the consistency group.

Syntax

TRip congroupname

Parameter

congroupname


Comments◆ The TRIP command uses the Trip API available to ConGroup and other users. The TRIP

command must pass the same RACF test as the Trip API. In both cases, ConGroup does a RACF check against facility EMC.CG.API.TRIP.

Note: Appendix A provides more information about the Trip API. The Mainframe Enablers Installation and Customization Guide provides more information about the security system.

◆ The TRIP command is not supported for IOSLEVEL consistency groups. (Note that ConGroup V7.0 or higher does not support IOSLEVEL consistency groups.) If you issue a TRIP against an older IOSLEVEL group, you receive message CGRP083E.

TRIP 147

Command Reference

ExampleThe following example trips a consistency group named DB2PROD.

TRIP DB2PROD

#UNPIN

PurposeThe #UNPIN command manually unpins a ConGroup gatekeeper server managed CUU.

Note: For determining proper situations for using this command, refer to the discussion on unpinning gatekeepers in the OPERATIONS section of this manual.

Syntax#UNPIN CUU(nnnn)

ArgumentsCUU(nnnn)

A single channel address of the Gatekeeper to be unpinned.

Example#UNPIN CUU(03C8)

VERIFY

PurposeThe VERIFY command goes through all the verification tests normally done when a consistency group is being enabled. For each device experiencing an error, a message is displayed explaining the reason for the error.

Syntax

VERify congroupname

Parameter

congroupname


CommentsNone.


Command Reference

ExampleThe following is a verify statement for the consistency group DB2PROD and sample output.

VERIFY DB2PROD

CGRP163W R2 DEVICE FOR CUU 0259 IS NOT READYCGRP163W R2 DEVICE FOR CUU 025A IS NOT READYCGRP163W R2 DEVICE FOR CUU 025B IS NOT READYCGRP163W R2 DEVICE FOR CUU 025C IS NOT READYCGRP159W R2 DEVICE FOR CUU 0298 HAS 1 INVALID TRACKSCGRP159W R2 DEVICE FOR CUU 0299 HAS 66 INVALID TRACKSCGRP159W R2 DEVICE FOR CUU 029A HAS 1 INVALID TRACKSCGRP159W R2 DEVICE FOR CUU 029B HAS 46 INVALID TRACKSCGRP159W R2 DEVICE FOR CUU 029C HAS 166 INVALID TRACKSCGRP159W R2 DEVICE FOR CUU 029D HAS 221 INVALID TRACKSCGRP157E RDF CONFIG FOR CUU 029E IS IN ADAPTIVE COPY MODE

VERIFY 149

Command Reference


APPENDIX ATrip API

Invisible Body Tag

This appendix discusses the Trip API.

◆ Introduction.......................................................................................................... 152◆ Trip program ECGTRIP ............................................................................................ 152◆ Prerequisites......................................................................................................... 153◆ Sample Rexx Exec ................................................................................................. 154

Trip API 151

Trip API

IntroductionWhen invoked, the program ECGTRIP requests the trip of a named consistency group.

Distributed with the API in Mainframe Enablers SAMPLIB is a REXX exec, TRIP, that calls ECGTRIP.

You can invoke TRIP from a TSO session as follows:

TRIP groupname,ssid

This command sends a request to ConGroup to trip the named group using the specified ssid to identify the proper SCF connected to ConGroup. Scfname (ssid) is required.

After a group is tripped, that group must be resumed before it can be tripped again. If a trip is attempted against a tripped group, the following message is issued:

CGRP640I (23) Group TESTGRP Not Trippable.

Note: Mainframe Enablers Message Guide provides more information about CGRP640I.

Trip program ECGTRIPECGTRIP is a program that is used to trip a congroup. It is versatile enough to be called from a REXX EXEC, JCL or programmatically from an assembler program.

It may be invoked via JCL as follows:

EXEC PGM=ECGTRIP,PARM=grpname,scfname

Where:

◆ grpname is the name of a congroup.

◆ scfname is the 4 character "ssid" (as in //SCF$ssid DD DUMMY)

It may be called from a REXX EXEC. See sample REXX exec “TRIP” in SAMPLIB to see how this program is called from a REXX exec.

It may be called programmatically from an assembler program. Parms on entry to ECGTRIP:

◆ R1: Parm list - See PARMAREA below

◆ R13: 72 byte save area provided by caller.

◆ R14: Return address.

◆ R15: Entry point address (address of ECGTRIP)

Caller passed parameter area format pointed to by R1.

PARMAREA DC 0F parms DC A(GRPNAME) Groupname

DC A(SCFNAME+X'80000000') SSID …GRPNAME DC CL8'GRP1 ' 8 byte blank filledSCGNAME DC CL4'MY1 ' 4 byte blank filled

Example via z/OS CALL macro:


Trip API

CALL PGM=ECGTRIP,(GROUPNAME,SSID),VL

Return code from ECGTRIP:

◆ R15 - 00 Trip successful (see notes)

◆ R15 - 08 See below RSN codes (7.2 and higher)

◆ R15 - 12 No parm specified

◆ R15 - 16 ConGroup not running

Reason codes associated with return code 8:

◆ RSN=8 - Groupname not found

◆ RSN=9 - Failed security check

PrerequisitesBefore attempting to use the program ECGTRIP to trip a group, your organization should first define the resource EMC.CG.API.TRIP (class FACILITY1) to RACF, and authorize users to update that resource. If you do not define the resource, access is allowed but ConGroup issues messages indicating that access was allowed because the resource was not protected.

For example:

CGRP642I CLASS=FACILITY RESOURCE=EMC.CG.API.TRIP CGRP643I ACCESS ALLOWED - RESOURCE NOT PROTECTED CGRP641I USER001 (T0049902) ASID(0235) Initiating trip for TESTGRP

If the resource is protected and the user is authorized, messages CGRP642I and CGRP643I are not displayed. Only CGRP641I is displayed.

Note: The Mainframe Enablers Message Guide provides more information about CGRP641I, CGRP642I, and CGRP643I. The Mainframe Enablers Installation and Customization Guide provides more information about the EMCSAFI Security Interface.

1. The Mainframe Enablers Installation and Configuration Guide provides more information about ConGroup resource validation requests and classes.

Prerequisites 153

Trip API

Sample Rexx ExecThe following is the sample Rexx Exec. You can find this sample in Mainframe Enablers SAMPLIB.

Note: All members in Mainframe Enablers SAMPLIB are subject to change and may differ slightly from published text.

/* Rexx TRIP - Trip a consistency group. Syntax: >>--%TRIP--group[,ssid]----------------------------------------------->< where: group specifies the name of the consistency group to be tripped. ssid the 1-4 character subsystem id (as in //SCF$ssid DD DUMMY) of the target ConGroup/SCF set. Usages Notes: 1. The DSN-prefix must be customized in the CALL statement below. 2. Requires ConGroup 6.3. 3. Supports both RDF-ECA and IOSlevel groups. 4. Scfname is required for ConGroup 7.2 and later. If supplied and running below release 7.2, the older interface will be attempted before failing. */ arg group .; if group = '' then call exit 16, 'Syntax: %TRIP group[,ssid]'; signal on halt; signal on syntax; "CALL 'DSN-prefix.LINKLIB(ECGTRIP)' '"group"'"; select; when rc = 0 then call exit 0, 'Request for trip of group' group 'sent to ConGroup.'; when rc = -3 then call exit 12, 'Command not found.'; when rc < 0 then call exit 12, 'Abend S'd2x(-rc)'.'; otherwise call exit 8, 'TRIP of' group 'failed with return code', rc // 65536', reason code' rc % 65536'.'; end; ERROR: call exit 12, 'Error' rc 'in: "'sourceline(sigl)'".'; HALT: say time() 'Halted in: "'sourceline(sigl)'".'; trace '?R'; nop; call exit 12; SYNTAX: say time() 'Syntax error' rc 'in: "'sourceline(sigl)'".'; trace '?R'; nop; call exit 12; EXIT: parse arg $er, msg; if msg <> '' then say time() msg;exit $er;


APPENDIX BProblem Diagnosis

Invisible Body Tag

This appendix discusses the diagnostic facilities available to ConGroup users.

◆ ConGroup diagnostic facilities............................................................................... 156

Problem Diagnosis 155

Problem Diagnosis

ConGroup diagnostic facilitiesConGroup uses the following diagnostic facilities available through ConGroup and the operating system:

◆ Diagnostic messages

◆ z/OS dump services

◆ z/OS GTF tracing service

◆ z/OS logrec (EREP) data

Where a condition occurs that prevents continued operation, ConGroup takes the following steps:

◆ Suspends processing

◆ Generates a symptom record in the logrec dataset

If an ABEND is associated with the error, ConGroup formats VRA data and creates a logrec record.

To facilitate problem diagnosis, please retain the logrec software EREP records for EMC Customer Support. You can format the software records using the following JCL. The example assumes that SYS1.LOGREC is being used.

//STEP1 EXEC PGM=IFCEREP1,PARM='CARD' //EREPPT DD SYSOUT=* //TOURIST DD SYSOUT=* //SERLOG DD DSN=SYS1.LOGREC,DISP=SHR //ACCDEV DD DUMMY //SYSIN DD * PRINT=PS HIST=N TYPE=S

ENDPARM

Note: The IBM publication, EREP Reference, has more information about these records.


APPENDIX CCleanup Utility

Invisible Body Tag

This appendix describes ECGUTIL, the cleanup utility.

◆ Introduction.......................................................................................................... 158◆ ADD DEVICES ........................................................................................................ 160◆ AG (ARM GROUP) .................................................................................................. 162◆ DG (DEFINE GROUP) .............................................................................................. 162◆ CG (CLEAN GROUP)................................................................................................ 163◆ SET GROUP ........................................................................................................... 163◆ SET MSGLEVEL ...................................................................................................... 164◆ STOP..................................................................................................................... 164◆ Messages ............................................................................................................. 165◆ Limitations............................................................................................................ 165◆ Example................................................................................................................ 166

Cleanup Utility 157

Cleanup Utility

IntroductionECGUTIL, the cleanup utility, allows you to set or clear specified devices on one or more Symmetrix controllers.1 You would use ECGUTIL to clean up (correct) situations that have left devices in an incorrect state.

Suppose you have a channel failure that forces a swap. The swap leaves ConGroup-enabled R1 devices that ConGroup is now not able to disable. You could use ECGUTIL (from a different host that can still reach the devices) to clean them up.

Using ECGUTIL

When you use ECGUTIL, you first specify an arbitrary group name. The group name does not have to have any relationship to any existing consistency group. You then assign devices to that group. When you have finished assigning devices, you can then alter certain device attributes (for example the CG ENA or RDF-ECA statuses) with the SET command.

Note: “SET GROUP” on page 163 and “SET MSGLEVEL” on page 164 provide more information.

The categories of device attributes you can change include:

◆ ConGroup attributes

◆ RDF-ECA status

◆ USR-Ready status

You can run ECGUTIL as a started task, as a batch job or as a called subroutine. In any case, all utility functions are driven concurrently by JCL DD card image and z/OS console input.

The following is a typical run ECGUTIL JCL:

//STEP EXEC PGM=ECGUTIL[,PARM=’MSGLEVEL(n)’]2//STEPLIB DD DSN=ECGUTIL.LINKLIB,DISP=SHR//HYPPRINT DD SYSOUT=A//SCF$LJC DD DUMMY//COMMAND DD * <-- instream commands (or pds member)

You can enter either:

◆ Instream commands

◆ Console commands

Instream commands can be any length and may span lines. No continuation characters are needed. Columns 72-80 are ignored.

1. Only locally attached controllers are supported.

2. The default MSGLEVEL(5) for ECGUTIL HYPPRINT output my be overridden with a value of 1 through 9 using this parameter.


Cleanup Utility

You can also enter all commands through console modifies. Console commands are identical to instream commands, but no delimiting period is necessary when entered through the console.

ECGUTIL is case insensitive. Upper and lower case work identically because all lower case text is folded to upper case.

ECGUTIL can also honor the following EXEC parameters:

◆ LOCAL — Only access devices directly attached to a channel

◆ REMOTE — Only access devices indirectly via a secondary controller

◆ EITHER — Attempt LOCAL mode, but drop back to REMOTE if no local paths are available. This parameter may be combined with the MSGLEVEL(n) EXEC parameter.

Specifying MSGLEVEL(7) will display all syscalls (including successful ones) so hoplists can be seen.

Security

Use of ECGUTIL requires proper RACF authorization. Your installation should define a RACF class/resource combination of FACILITY/EMC.UTL.ECGUTIL and give authorized users UPDATE access to it. If the resource is not defined, anyone may use the program. ECGUTIL displays the following two messages if the installation has not protected the resource:

ECGC001I CLASS=FACILITY RESOURCE=EMC.UTL.ECGUTILECGC002I ACCESS ALLOWED – RESOURCE NOT PROTECTED

Gatekeepers

ECGUTIL uses an internal gatekeeper server (which is also used by ConGroup) to determine which gatekeeper devices to use. The gatekeeper server obtains a list of gatekeepers from SCF (ResourcePak Base).

Use the SCF.GATEKEEPER.LIST statement in SCF to specify one or more gatekeepers. If you specify multiple gatekeepers, ECGUTIL uses them in parallel (if you define multiple groups). All syscalls for a group are driven serially, but groups are handled in parallel. Each generated syscall object requests a free gatekeeper from the internal gatekeeper server “on the fly” before issuing the actual syscall. After syscall completion, the object returns the gatekeeper to the pool. This technique allows for high levels of parallelism whenever sufficient gatekeepers are available.

Automatic access using hoplists to target devices via secondary controllers is available. It is sometimes useful to force ECGUTIL to access a controller from another controller (rather than directly across the channel). This capability is dependent on the connected SCF configuration and the gatekeeper list provided to ECGUTIL at run time.

Trace messages

Trace messages are written to the HYPPRINT DD, and the absence of that statement causes trace data to be written to ResourcePak Base (SCF). trace datasets

Introduction 159

Cleanup Utility

Commands

The commands available are:

◆ ADD DEVICES

◆ AG (ARM GROUP)

◆ CG (CLEAN GROUP)

◆ DG (DEFINE GROUP)

◆ SET GROUP

◆ SET MSGLEVEL

◆ STOP

The following sections describe these commands.

ADD DEVICESADD DEVICES allows you to add devices to an arbitrary group you previously defined with the DG command. The group allows you to enable or disable characteristics to all the devices you assign to the group with one statement.

Note: “DG (DEFINE GROUP)” on page 162 describes the DG command.

Syntax

ADD DEVICES=(devices) TO GROUP name CNTRL symmser#|name [RAGROUP nn]

Parameters

devices

Symmetrix device numbers or ranges of Symmetrix device numbers separated by commas. (The devices can be either CKD or FBA.) For example:

DEVICES=(4-FF,5,11e,C0-11B)

You can use either upper or lowercase characters. Any duplicate devices specified within a single group is ignored. All the devices in a single ADD DEVICES command must be on a single controller.

name

The name of the group you previously defined with the DG command. The maximum length of a group name is eight characters. The name can start with any alphanumeric character.

RAGROUP nn

This parameter allows the specification of a single RA group to target individual device mirrors, where nn is a two digit hexadecimal RA group value.


Cleanup Utility

For example, the RA parameter in the following statement will restrict action to the 08 leg of the device(s) specified on the statement:

ADD DEVICES=(158-15A) TO GROUP MYGRP CNTRL 000195700079 RA 08

symmser# |name

The serial number or name (that must already have been assigned through ResourcePak Base) of the Symmetrix controller of the devices.

Symmetrix serial numbers are normally 12 characters. However, if needed, a specified value is prepended with zeros to make a 12-digit number. So CNTRL 6185, for example, is valid.

The logical controller name must be a string of up to 64 characters. If the logical controller name has a simple format (single-word string of uppercase alphas), then you may enter the controller name without quotation marks. If the logical controller name is made up of mixed-case characters or contains spaces, then you need to enclose it in quotation marks.

Comments

◆ You can specify multiple ADD DEVICES statements.

◆ You can add the same devices to more than one group.

◆ Any duplicate devices specified within a single group is automatically “weeded out.”

◆ Because commands can span multiple lines, you can split long device lists over multiple lines.

Example

The ability to add devices to more than one group is useful if you want to operate on subsets of a single group. Consider the following example:

DG ALL.DG LEFT.DG RIGHT.DG MIDDLE.DG 107ONLY.ADD DEVICES=(107) TO GROUP 107ONLY CNTRL 6185.ADD DEVICES=(107) TO GROUP ALL CNTRL 6185.ADD DEVICES=(100-10F) TO GROUP ALL CNTRL 6185.ADD DEVICES=(100-102) TO GROUP LEFT CNTRL 6185.ADD DEVICES=(103-10A) TO GROUP MIDDLE CNTRL 6185.ADD DEVICES=(10B-10F) TO GROUP RIGHT CNTRL 6185.

In this example, you can operate on subsets of group ALL by operating on groups LEFT, MIDDLE and RIGHT or 107ONLY.

In the previous example, group 107ONLY consists of just device 107. It is also part of group ALL. Because it is singularly part of group 107ONLY, you can operate on just device 107 with commands specifying group 107ONLY.

ADD DEVICES 161

Cleanup Utility

AG (ARM GROUP)The AG command packages the following set of commands into one command:

◆ SET GROUP name CGENA

◆ SET GROUP name USRNRDY

The AG command exists only for testing the utility because setting devices with these test characteristics serves no other purpose outside the context of ConGroup and may cause operational disruption to an installation if used carelessly.

Syntax

AG name

Parameter

name

The name of a group you previously defined with the DG command. The maximum length of a group name is eight characters. The name can start with any alphanumeric character.

Comments

You must have previously added devices (with ADD DEVICES) to the group.

Examples

None.

DG (DEFINE GROUP)The DG command allows you to define an arbitrary group to which you can then add devices (with the ADD DEVICES command). Each group you define may consist of devices from several controllers. Any number of DG statements are allowed.

Note: “ADD DEVICES” on page 160 describes the ADD DEVICES command.

Syntax

DG name

Parameter

name

The name of the group you want to define. The maximum length of a group name is eight characters. The name can start with any alphanumeric character.


Cleanup Utility

Comments

The group name used here and throughout the ECGUTIL utility has nothing to do with ConGroup or any other EMC product. This group exists only for the duration of ECGUTIL utility execution.

Examples

None.

CG (CLEAN GROUP)The CG command packages three commands into one command. The CG command issues the following SET GROUP commands internally:

Syntax

CG name

Parameter

name

The name of a group you previously defined with the DG command. The maximum length of a group name is eight characters. The name can start with any alphanumeric character.

SET GROUPThe SET GROUP command allows you to set or clear characteristics flag for all devices that are part of the specified group.

Syntax

SET GROUP name [CGDIS|CGENA|RECACLR|USRNRDY|USRRDY]

Parameters

name

The name of the group you previously defined with the DG command. The maximum length of a group name is eight characters. The name can start with any alphanumeric character.

CGDIS

Clears the CG ENA bit on the group devices.

CGENA

Sets the CG ENA bit on the group devices.

CGDIS Clears CG ENA bit

RECACLR Clears RDF-ECA status

USRRDY Makes devices USR Ready.

CG (CLEAN GROUP) 163

Cleanup Utility

RECACLR

Clears the RDF-ECA status on the group devices.

USRNRDY

Sets the USR Not Ready flag for the group devices.

USRRDY

Sets the USR Ready flag for the group devices.

Comments

The ConGroup CG ENA state and the RDF-ECA state consist of fixed default values for group IDs, various masks, and other values because the ECGUTIL does not provide a way to specify these values. The “enabling” operators exist in ECGUTIL only for testing purposes to allow conformation that the cleaning operators function correctly.

SET MSGLEVELThe SET MSGLEVEL command allows you to set the verbosity level of the messages returned from ECGUTIL.

Syntax

SET MSGLEVEL number

Parameter

number

A number from one (1) to nine (9). The higher number you use, the more verbose the messages. The lower number you use, the more terse the messages. If you do not specify SET MSGLEVEL, ECGUTIL uses a default value of five (5).

Comments

None.

Example

None.

STOPThe STOP command tells ECGUTIL to end. If you enter STOP instream, ECGUTIL executes prior instream commands and then stops processing. If you do not enter STOP, ECGUTIL waits for further input from the console after executing any other instream commands.

Syntax

STOP


Cleanup Utility

Parameters

None.

Comments

◆ Avoiding an instream STOP command allows you to specify groups and then operate upon the devices in the groups with console commands. After you finish issuing other console commands to the utility, enter STOP to direct the program to end.

◆ The following are the return codes you can receive:

Examples

None.

MessagesECGUTIL can generate messages with the prefix ECGC. You can find these messages described in the Mainframe Enablers Message Guide.

LimitationsThe ECGUTIL utility has the following limitations:

◆ Except for validating the controller serial number or name, ECGUTIL does not do any checking before issuing its syscalls. ECGUTIL simply issues the needed syscalls to the Symmetrix systems through gatekeepers it receives from ResourcePak Base (SCF). Because no locking or other cooperative protocols are followed, you could be adversely affecting other applications when running this utility.

◆ If you specify DEVICES=(000-FFF) (for example), ECGUTIL issues 4096 syscalls even if there is only one device of those named in the Symmetrix system. If you try to issue syscalls against non-existent devices, you receive a return code 8 and message “ECGC006E Transport Layer Error on Syscall” is written to the joblog for each syscall in error.

0 All generated syscalls succeeded.

Note: All syscalls might succeed and the final return code might not be zero (0). For example, return code 8 is returned if the message ECGC004E is issued (for an extraneous ADD statement for a nonexistent group).a But other statements might very well succeed.

a. Refer to “Messages” on page 165 for information about the messages that ECGUTIL can generate.

4 At least one generated syscall received an application layer error. Search HYPPRINT b for the string “RC=4” and then examine the data fields displayed after the preceding strings “PAYLOAD” and “SYSCALL CALLBACK” for details of the problem.

b. HYPPRINT is a DD name that you put in the job. You can find more information in the sample JCL in “Using ECGUTIL” on page 158 and “Trace messages” on page 159.

8, 12, 16 A variety of possible errors. Look for RC=8, 12, or 16 in HYPPRINT or error messages in the SYSLOG for details.

Messages 165

Cleanup Utility

◆ ECGUTIL supports only Enginuity 5x69 or higher.

◆ ECGUTIL supports only locally-attached controllers.

◆ No post-syscall polling is done to confirm proper execution of the generated syscalls. Individual syscall results may be seen in HYPPRINT and in summary form by way of the final utility return code. Furthermore, because syscalls execute asynchronously in the Symmetrix system, the actual desired state changes can occur slightly after successful completion of the syscalls.

Note: HYPPRINT is a DD name that you put in the job. You can find more information in the sample JCL in “Using ECGUTIL” on page 158 and “Trace messages” on page 159.

ExampleThe following example illustrates how to use ECGUTIL:

DG TEST1.ADD DEVICES=(20,220-22F)0000TO GROUP TEST1 CNTRL 000190100991.SET GROUP TEST1 USRNRDY.SET GROUP TEST1 USRRDY.STOP.//

This example defines the group TEST1, adds devices to it, and defines the serial number of the Symmetrix controller. (A logical name for the controller predefined through ResourcePak Base could also have been used.) It then uses the two SET GROUP commands to clear NR on the DA. (As shown in the SET GROUP “Comments” on page 164.) Finally, it issues a STOP command to end ECGUTIL.


Swap Services Message Formatting

APPENDIX DSwap Services Message Formatting

This appendix describes the message formatting for the EMC SWAP services messages that are listed in the Mainframe Enablers Message Guide.

◆ Swap services conventions ................................................................................... 168

167


Swap services conventionsThe SWAP services are a basic component in several of the Mainframe Enablers component products. SWAP services messages have the following format:

prefyyyz (rrrrr)(PID ppppp)

If messages are routed from a non-owner system to the owner through the RouteMessageToOwner option, the following format is used:

prefyyyz (>hhhh)(PID ppppp)

Where:

pref

Identifies the message prefix. To make it easier to determine which application generated the message, SWAP services uses a message prefix that identifies the application that is the source of the message. The following table shows the prefixes used by various applications:

This chapter uses the following multi-prefix format for all message headers:

ESWPnnnE | CGRSnnnE| FMMSnnnE | SCFSnnnE

Look up the message by the prefix and code you receive.

Note: You may receive other prefixes than the ones listed above. If so, refer to EMC Online Support (registration required) at: https://support.EMC.com.

rrrrr

Is a request sequence number that identifies the AutoSwap command request on a particular host. rrrrr is incremented each time a new command request is made. All messages associated with the same request on the same host are prefixed by the same value for rrrrr.

>hhhh

Is the SMFID of the host where the message was routed. Where the RouteMessagetoOwner AutoSwap option is specified, messages routed from the non-owner to the owner will contain the issuing host ID instead of a request sequence number. The format is >hhhh, where hhhh is the SDMFID.

For example, >HIC3 indicates the message was routed from host HIC3.

Table 5 Swap services messages by application

If the prefix is the message was generated through

ESWP EMC AutoSwap™

CGRS EMC Consistency Groups

FMMS EMC Migrator for z/OS

SCFS EMC ResourcePak® Base




ppppp

Is a PID that is a unique incrementing value for each SWAP validation or swap process (that is, device pair) for the same group definition. This value always follows the request sequence number or host ID to uniquely identify the messages relating to the same device pair swap within the same AutoSwap group.

When a cross system validation or swap is performed, the same PID is used on all hosts. The PID is set by the AutoSwap owner host when the group is created and will remain the same for the life of the AutoSwap group.

Verbose levels

Some messages are only produced when the currently set SWAP verbose level is greater than or equal to the verbose level of the message. Error messages and most warning messages are always produced no matter what verbose level is set. The following verbose levels are used to indicate particular SWAP processing:

Typographical conventions

Within a message, single quotes (‘ ‘) are used around the FROM and TO device specification to denote and prevent confusion with the usage of the words FROM and TO.

The default for messages is mixed-case. Use the SET CAPS command for uppercase format.

The convention of [ ] indicates optional information is added to a message. A | indicates an either (or) condition.

Verbose level Description

0 Messages that are basic summaries of a condition or state. Such messages are initially interesting, but describe a condition that occurs regularly, and thus generates a large number of messages. For example message 238I indicates that a device is available for AutoSwap. Message 238I might be interesting initially but it becomes a nuisance under normal operation. Generally Verbose Level 0 messages are messages that were not originally verbose, but are now verbose because of the volume of such messages that are generated.

1 Messages relating to the initiation and termination of a swap and/or device validation.

2 Messages relating to the initiation of a swap/validation phase.

3 Inter-phase informational messages.

4 Non-RDF swap processing informational messages.

10 SWAP request initiation/termination messages.

Swap services conventions 169


Message substitution fields

The following standard symbols are used for substitution fields:

sdddd (or dddd) The device number consisting of the subchannel set number (s) and the 4 digit z/OS device number (dddd). If the set number is not visible, and the number reads dddd, the set is automatically assumed as the active set number.

ccccc,ssss The format used where an z/OS device number (ccuu) could notbe located.ccccc = The Symmetrix controller serial number.ssss = The Symmetrix device number.

ccccc Symmetrix controller ID

ssss Symmetrix device number

ppppp PID

rrrrr Request sequence number

gg RDF group

xxxxxxxx RC

yyyyyyyy RS

zzzzzzzz Extended RS

uuuuuuuu UCB address

xxxxxxxxxxxxxxxx The host identifier (xxxxxxxxxxxxxxxx) is a 16-digit hexadecimal value describing the EMCSCF host which responded to the request. The value is interpreted as:ttccxxxxxxxxaaaa Where:• tt — is the operating system type. Valid values include:

01 — indicates z/OS.‘- -’ — indicates that EMCSCF is not active or the host type is unknown. This is only displayed where path groups are defined to a device and an active EMCSCF Cross System Communication session cannot be located.

• cc — is the CPU address of LPAR identifier (when in LPAR mode).

• xxxxxxxx — is the CPU identifier and machine type (model number).

• aaaa — is the address space identifier (ASID) of EMCSCF on that host.

• ‘- - - - ‘ — indicates that EMCSCF is not active. This is only displayed where path groups are defined to a device and an active EMCSCF Cross System Communication session cannot be located.


APPENDIX EEnhancements

nvisible Body Tag

This appendix provides a comprehensive list of ConGroup enhancements.

◆ Enhancements by release ..................................................................................... 172

Enhancements 171

Enhancements

Enhancements by releaseTable 6 lists ConGroup enhancements by release:

Table 6 Consistency Groups for z/OS enhancements (page 1 of 5)

Release Enhancements

7.6 This release includes support for adding or removing control units from a congroup.

7.5 There are no new features specifically for ConGroup in this release. However, this manual has been updated with corrections and improvements collected since the previous publishing.

7.4 There are no new features specifically for ConGroup in this release. However, this manual has been updated with corrections and improvements collected since the previous publishing.

7.3 This release includes support for a facility known as multiple subchannel sets. The main aim of such a facility is to allow application addressable devices to remain in 4 digit device range (0000-FEFF) and at the same time allow system addressable devices to be accessed outside this range. To facilitate this, IBM created multiple subchannel sets to be addressable using a subchannel set number. The range of the subchannel set numbers is 0-3. Devices are addressed by z/OS in a particular subchannel set using a 5th digit on the device number (sdddd). For example, subchannel set 0 devices are 00000-0FEFF, subchannel set 1 devices are 10000-1FEFF.

without the REFRESH command and without disruption, either to the affected group or to other groups.

A new MOVEOWNER/TAKEOVER process has been developed to replace the old AutoSwap group delete and rebuild process. The new method applies to both CAX and RDF-ECA. The old method did not support "ownership movement" for RDF-ECA. Ownership means master/centralized control among a set of processes, and both AutoSwap and ConGroup RDF-ECA functions require this functionality. In a multi-node CGSet, you can't have some groups owned by one CG-node and others owned by another CG-node - even though the AutoSwap notion of ownership is at the group level.

The ALLOWABLE_MSS parameter and the related PAIR subparameter of the CONGROUP statement have been added to control the situation when any of the device pairs "straddle" two subchannel sets. The subparameters define what subchannel sets on the R1 devices are allowed. They may also be specified whether or not the device pairs straddle subchannel sets.

7.2 Congroup has a new method of intelligent polling that reduces the amount of polling time and decrease the negative impact on I/O to controllers. The POLLRATE command is now obsolete.

RDF-ECA Group ID number is displayed with the DISPLAY CONGROUP command.

For Multiple ConGroups running in the SAME LPAR, the CGSET parameter must be unique for each instance of ConGroup running in the same LPAR. For example, with the CGSET parameter defaulted to the value “00”, any additional instance must specify a value between “01” and 06”. You can now run up to seven independent ConGroup address spaces in one LPAR, however, only one ConGroup address space may be associated with a given SCF.

New MOVEOWNER/TAKEOVER command logic uses CSC more directly than before and use a new AutoSwap interface that permits a non-disruptive change of ownership, when CAX is involved, driven by the Congroup application.

7.0 ConGroup 7.0 uses RDF-ECA as the only supported protection mode. IOSLEVEL mode is not supported in ConGroup 7.0; but, is still supported for ConGroup 6.4.


Enhancements

ConGroup 7.0 provides support for named controllers. If a controller has been named through the ResourcePak Base utility ESFCTLNM, ConGroup 7.0 allows you to use that name instead of the controller serial number.

ConGroup 7.0 provides support for independent mirror RDF-ECA. This allows for independent ConGroup protection in a Concurrent SRDF/Synchronous configuration. If a user decides to disarm the protection on one leg, the other synchronous let can remain active and continue protecting the primary production site.To enable this feature, ConGroup provides two new parameters: A global ALLOW_SHARED_R1S parameter that establishes definition of R1 groups by mirror rather than by R1 device as the default can for all consistency groups and a group level ALLOW_SHARED_R1S parameter that establishes the definition of R1 groups by mirror as the case for the consistency group currently defined.Setting the group level ALLOW_SHARED_R1S overrides the value of the global ALLOW_SHARED_R1S.

ConGroup 7.0 has a new CAXOPT, [NO]ROUTEMESSAGETOOWNER. [NO]ROUTEMESSAGETOOWNER allows you to consolidate CAX AutoSwap message in a single place (the owner system SYSLOG) to enable you to better locate issues in AutoSwap processing.

ConGroup 7.0 has a changed CAXOPT, UNPLANNEDCONDITIONS. The UNPLANNEDCONDITIONS option replaces and performs the same function as the AUTOSWAPCONDITIONS option used in previous releases of ConGroup. For backward compatibility, however, ConGroup still recognizes AUTOSWAPCONDITIONS.

ConGroup 7.0 no longer supports R1_RO consistency groups.

ConGroup 7.0 supports all currently supported versions of z/OS.

ConGroup 7.0 includes maintenance released for prior versions.

6.4.0 ConGroup 6.4 recognizes the new CAX/AutoSwap command, SETSWAP. SETSWAP is an AutoSwap statement that must be passed to ConGroup through the DAS command. You can use SETSWAP to disable swap processing for short periods of time. Typically this would be done to avert an unplanned swap event which may conflict with customer processing.

ConGroup adds a new swap trigger: SYNCLINKFAILURE as a possible value for the AUTOSWAPCONDITIONS option of the CAXOPTS configuration parameter. This trigger causes a swap by programmatically setting devices to Not Ready whenever an SRDF link failure. occurs.

ConGroup recognizes the R21 device type. The R21 device is the target of one SRDF relationship and simultaneously the source of another SRDF relationship.

ConGroup 6.4 operates with Symmetrix systems that are at Enginuity revision level 5773 as well as the prior levels.

The name of the ECGCLEAN utility has been changed to ECGUTIL

ConGroup supports all currently supported versions of z/OS.

ConGroup includes maintenance released for prior versions.

6.3.0 The two configuration files, CONFIG and CONFIG2, have been combined. There is now only one configuration file, CONFIG. The parameters in CONFIG2 have been incorporated into CONFIG.

ConGroup operates with Symmetrix systems that are at Enginuity revision level 5772 as well as the prior levels.



Enhancements by release 173

Enhancements

ConGroup supports all current versions of z/OS.

ConGroup supports RDF-ECA mode consistency group monitoring. RDF-ECA mode provides an enterprise solution for ensuring dependent write consistency in SRDF/S configurations with more than one SRDF group. ConGroup includes two RDF-ECA global configuration parameters:• USE_RDF_ECA - enables or disables use of RDF-ECA mode to all consistency

groups managed by the current instance of ConGroup that can support RDF-ECA mode.

• USE_FBA_NR_ON_TO - sets ConGroup behavior in situations where ECA Windows time out on FBA devices.

ConGroup has added support for RAID 6 protected devices.

ConGroup has a new CAXOPTS parameter, UNPLANNEDOPTIONS(FBAUSRNRDY). This parameter is intended to handle unplanned swaps only. It makes R2 FBA devices NR on the channel.

ConGroup now has two types of group bypass at startup or refresh complete consistency group bypass and GNS group bypass.Complete consistency group bypass occurs automatically when a group has a local R2 device defined. (Formerly, ConGroup would consider this an error and not start.) GNS group bypass occurs if a GNS group name is not found when ConGroup attempts to include the devices in that group into the consistency group. In such a case, ConGroup activates the consistency group without including the missing GNS group.

ConGroup now includes the TRIP API that allows users to trip a named consistency group programmatically. It supports both RDF-ECA mode and IOSLEVEL mode consistency groups. The TRIP API is implemented through the ECGAPI macro. A sample assembler program and a sample REXX exec are provided.

ConGroup now has the ECGCLEAN utility (now called ECGUTIL) that can enable or disable attributes from specified devices on one or more Symmetrix controllers. Only locally attached controllers are supported.

ConGroup now supports more than one gatekeeper device when polling.

ConGroup includes maintenance released for prior versions.

6.2.0 EMC ConGroup recognizes logical volume groups defined by Group Name Services (a facility of ResourcePak Base). As a result, ConGroup can now include devices from other LPARs, into a consistency group, including devices that are offline to the LPAR running the current instance of ConGroup.This use of Group Name Services enables faster updates to configuration groups. By employing Group Name Services, users can add devices to or remove devices from a consistency group dynamically and online by updating the group name definition without having to modify the ConGroup configuration file.

For users of Enginuity 5x71 and later, EMC ConGroup contains page device support for EMC AutoSwap. With this feature, the customer can swap page devices that were previously not eligible for swapping.

ConGroup supports complement groups. Complement groups are created through the Group Name Services feature in ResourcePak Base should you want to go home using AutoSwap. Here, the logical devices can be defined automatically using the new location attributes (Symmetrix device numbers and so forth) in anticipation of the return voyage.

ConGroup can penetrate host-initiated hardware reserves. Previously, a ConGroup command would fail if it encountered a reserve. Now, with Enginuity 5x71 or later, ConGroup commands run to conclusion when they encounter a reserve.




Enhancements

ConGroup includes the application of accumulated maintenance.

The MODE configuration parameter now has a default value of SINGLE.

6.1.0 EMC ConGroup adds the MOVEOWNER and TAKEOVER operator commands. Both commands allow you to transfer the default ownership of a consistency group from one LPAR to another without the need to reinitialize the task manually.

ConGroup uses, by default, a new multi-LPAR mode. Multi-LPAR mode implements a new coordination process based on CSC that is designed to allow the ENABLE, REFRESH, and RESUME operator commands to execute through all ConGroup instances that monitor the same consistency groups and use the same CSC listener ports. If CAX operations are underway, the MOVEOWNER and TAKEOVER operator commands are also executed through all ConGroup instances that monitor the same consistency group and use the same CSC listener ports.

6.0.0 EMC ConGroup utility supports Symmetrix systems that are at Enginuity revision level 5x69 as well as the prior levels.

ConGroup now includes support for the ConGroup AutoSwap Extension. To use ConGroup AutoSwap, you must obtain a license key from EMC.The ConGroup AutoSwap Extension option adds protection for many types of failures that can occur on the front-end of SRDF. The ConGroup AutoSwap Extension option allows you to make non-disruptive switches from the primary to target volumes.

As part of ConGroup AutoSwap Extension, ConGroup adds a new configuration parameter, CAX. The CAX configuration parameter specifies: • Whether you want to activate the ConGroup AutoSwap Extension for a device

swap group • The name of the CAX options set you want to use for that group

Also as part of ConGroup AutoSwap Extension, ConGroup also adds another new configuration parameter, CAXOPTS. The CAXOPTS parameter defines the desired CAX options for an options set name.

5.1.0 Host based PPRC emulation has been removed from ConGroup V5.1.0. This functionality is now provided directly by Symmetrix at Enginuity 5568 and higher. The emulation layer delivered with ConGroup was only provided for GDPS and P/DAS environments and is no longer needed with the availability of native Symmetrix support for PPRC.

ConGroup now periodically interrogates the state of the consistency group to verify the configuration.

The DISPLAY CONGROUP operator command has been extended to include both a LIST and a NOLIST option. A new start up parameter, DISPLAY_CONGROUP_LISTOPT, has also been added to allow the user to specify which of these options is a default.

The DISPLAY CONGROUP operator command has been enhanced to add a RESET parameter. This parameter causes the state of the consistency group to be reset by interrogating the state of all the devices in the consistency group.

A new startup parameter, REMSPLIT_OPTION=NOESTERR, has been added to generate an error message during REMSPLIT processing if an R2 device is found to have no attached BCV.

A new start parameter, RESUME_OPTION=NOTRNMSG, has been added to allow the user to suppress the transient error messages that the resume processing resolves, such as TNR.

5.0.0 Support added for R1 R2 Swap.



Enhancements by release 175

Enhancements

Allow Semi-Sync SRDF within a Consistency Group definition.

Support of EMC Symmetrix Control Facility (EMCSCF).

Recognition of Sysplex related Couple Datasets. This includes the following Couple Dataset types: Sysplex (XCF), Coupling Facility Resource Manager (CFRM), System Logger (LOGR), Workload Manager (WLM), Automatic Restart Manager (ARM), and Sysplex Failure Manager (SFM).

Security on commands based on authority granted by SAF compliant security packages.

4.0.0 Support added for Concurrent SRDF configurations. The SYMGROUP parameter defines the RDF group that must have consistency maintained.

Support added for Switched SRDF configurations.

Support added to split an attached and synchronized BCV from a STD device defined to the consistency group with the DEVICE_LIST_STD parameter when the group cannot propagate data to the target devices. STD devices can only be defined for SRDF ConGroups. STD devices are not supported in either PPRC or R1_R0 ConGroups.

3.3.1 SRDF_CONGROUP replaces the CONGROUP functionality provided in Consistency Group for MVS Version 3.2.1.

PPRC_CONGROUP and R1_RO_CONGROUP provide new functionality.

The product guide includes a new topic in Chapter 6, “Command Reference,”, to assist with implementing ConGroup in a database environment.

The ConGroup task startup and ENABLE process now reports all devices (at once) that are in error in a ConGroup definition to speed up error diagnosis.

A new remote SPLIT command (REMSPLIT) that SPLITs the BCV devices from the R2 devices that are part of a R1-R2 pair in an SRDF Consistency Group.

A new VERIFY command that tests a ConGroup definition without enabling it, to assist with defining consistency groups.

A new REFRESH command to dynamically update an existing CONGROUP without having to stop the ConGroup task.

A new AUTO_REFRESH feature monitors OS/390 and z/OS VARY ONLINE processing to detect and include new volumes into active consistency groups.

A new CANCEL command that provides the ability to cancel long running ConGroup RESUME, SUSPEND and REMSPLIT processing without stopping the ConGroup task and impacting other active consistency groups.

A new NOLIST parameter for the DISPLAY CONGROUP command that suppresses the active volume list when checking the status of a consistency group.

A new QUERY alias for the DISPLAY command.

A new RESUME_INTERVAL configuration statement to define the interval between message CGRP022I reporting resume processing status.

Support for Symmetrix configurations containing floating mirrors.




EMC Consistency Group for z/OS Version 7.6 Product Guide

Documents

Transcript of EMC Consistency Group for z/OS Version 7.6 Product Guide