Auto Swap

EMC® Mainframe Enablers
AutoSwap for z/OS

Version 7.6
Product Guide
REV 03
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.
2 AutoSwap for z/OS Version 7.6 Product Guide

CONTENTS
Preface
Chapter 1 EMC AutoSwap Overview

EMC Mainframe Enablers and EMC AutoSwap ............................................. 10
Licensing .............................................................................................. 10
Introduction to AutoSwap for the ConGroup user ......................................... 11
Swap types ................................................................................................. 11
Planned swaps...................................................................................... 11
Unplanned swaps ................................................................................. 12
AutoSwap modes........................................................................................ 12
CAX ....................................................................................................... 12
Basic AutoSwap .................................................................................... 12
What you can swap ..................................................................................... 13
Handling High Priority Swap Devices ..................................................... 14
Consistent swaps ........................................................................................ 15
Information about swap service messaging................................................. 15
Information about dynamic auto-swapping services .................................... 16
Chapter 2 Operations
Implementing AutoSwap through ConGroup................................................ 18
Defining configuration parameters ........................................................ 18
Starting the ConGroup address space ................................................... 19
Issuing commands ................................................................................ 20
When a swap needs to take place ............................................................... 22
Scenarios for swapping – some implementation choices............................. 23
Unplanned swaps ................................................................................. 23
Planned swaps...................................................................................... 24
Parameter settings for planned and unplanned swaps ......................... 24
Performing IODF configuration changes ....................................................... 26
Unacceptable configuration ACTIVATE ................................................... 26
Acceptable configuration ACTIVATE ....................................................... 27
Processing unacceptable configuration changes ................................... 27
Processing acceptable configuration changes ....................................... 33
Additional considerations for configuration changes ............................. 34
Chapter 3 Resuming Operations after an AutoSwap

Introduction................................................................................................ 38
Avoid unnecessary swaps ..................................................................... 38
AutoSwap scenarios.................................................................................... 38
Resuming operations with dynamic SRDF devices ................................. 38
Resuming operations without dynamic SRDF devices ............................ 39
Defining complement device groups ........................................................... 39
Using the COMPLEMENT argument ........................................................ 40
Using CONFIGCA.................................................................................... 41
Executing command-initiated swaps ..................................................... 41
Resynchronizing SRDF ........................................................................... 41
AutoSwap for z/OS Version 7.6 Product Guide 3

Contents
Chapter 4 Relevant ConGroup Parameters

Overview..................................................................................................... 44
Syntax Conventions .............................................................................. 44
CAX............................................................................................................. 45
CAXOPTS..................................................................................................... 45
COUPLEDS_ALLOWED.................................................................................. 54
GLOBAL....................................................................................................... 55
PAGEDEV_ALLOWED .................................................................................... 55
Chapter 5 Command Reference

Overview..................................................................................................... 58
SAF command verification ..................................................................... 58
Syntax Conventions .............................................................................. 59
Multiple subchannel device sets ........................................................... 59
DEFINE GROUP ........................................................................................... 60
DELETE GROUP ........................................................................................... 71
DISPLAY ..................................................................................................... 71
DISPLAY GROUP .................................................................................... 71
DISPLAY SDASOPTIONS ......................................................................... 73
DISPLAY OPTIONS ................................................................................. 73
DISPLAY GLOBALOPTIONS ..................................................................... 74
DISPLAY STARTPARMS........................................................................... 74
DISPLAY examples ................................................................................ 74
SET ............................................................................................................ 75
SET SDASOPTIONS ................................................................................ 76
SET PARMS............................................................................................ 77
SET [NO]DEBUG ..................................................................................... 77
SET [NO]CAPS........................................................................................ 77
SET VERBOSE ........................................................................................ 78
SET NOVERBOSE ................................................................................... 78
SET MAXLINECOUNT .............................................................................. 79
SET DEFAULTLINECOUNT........................................................................ 79
SETSWAP .................................................................................................... 80
SWAP ......................................................................................................... 84
SWAP GROUP ........................................................................................ 84
SWAP .................................................................................................... 85
VALIDATE GROUP ........................................................................................ 86
Appendix A Configuration Worksheet

CAXOPTS configuration worksheet .............................................................. 88
Other global configuration parameters ........................................................ 88
Appendix B Long Displays and Linecount Values

Long displays.............................................................................................. 90
Appendix C Swap Services Message Formatting

Swap services conventions ......................................................................... 84
Verbose levels....................................................................................... 85
Typographical conventions.................................................................... 85
Message substitution fields .................................................................. 86

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.
Purpose
This guide describes EMC AutoSwap from the perspective of the EMC AutoSwap for z/OS
user.
Audience
This guide is intended for the host system administrator, system programmer, or operator
who is evaluating, planning for, managing, or using EMC AutoSwap.
Related documentation
The following EMC publications provide more information:
◆ Mainframe Enablers Release Notes
◆ Mainframe Enablers Installation and Customization Guide
◆ Mainframe Enablers Message Guide
◆ ResourcePak Base for z/OS Version Product Guide
◆ Consistency Groups 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
Conventions used in this document

EMC 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.

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

Preface
Where to get help

EMC support, product, and licensing information can be obtained on the EMC Online
Support site as described next.
Note: To open a service request through the EMC Online Support site, 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 the EMC Online Support site (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 http://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
licensing@emc.com 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.

Preface
Your comments
Your suggestions help us continue to improve the accuracy, organization, and overall
quality of the user publications. Send your opinions of this document to:
techpubcomments@emc.com

CHAPTER 1
EMC AutoSwap Overview
Invisible Body Tag
This chapter provides an overview of EMC AutoSwap.

◆ EMC Mainframe Enablers and EMC AutoSwap ......................................................... 10
◆ Introduction to AutoSwap for the ConGroup user ..................................................... 11
◆ Swap types ............................................................................................................. 11
◆ AutoSwap modes.................................................................................................... 12
◆ What you can swap ................................................................................................. 13
◆ Consistent swaps .................................................................................................... 15
◆ Information about swap service messaging............................................................. 15
◆ Information about dynamic auto-swapping services ................................................ 16
EMC AutoSwap Overview 9

EMC Mainframe Enablers and EMC AutoSwap

EMC® AutoSwap™ is packaged with 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 (ConGroup)
◆ SRDF® Host Component for z/OS
◆ TimeFinder®/Clone Mainframe SNAP Facility
◆ TimeFinder/Mirror for z/OS
◆ TimeFinder Utility
◆ AutoSwap for z/OS
When you install the Mainframe Enablers kit, 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 EMC Mainframe Enablers Installation
and Customization Guide lists the LFCs for the Mainframe Enablers components.
Enabling component licensing

To 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 Mainframe Enablers’
components.

Introduction to AutoSwap for the ConGroup user

Although included with ResourcePak Base, AutoSwap is primarily used with EMC
Consistency Groups for z/OS. ConGroup is a utility that ensures the consistency of
remotely mirrored data. ConGroup allows you to move (swap) workload from volumes in
one set of Symmetrix® systems to volumes in other Symmetrix systems either:
◆ Manually, on your command (planned swaps)
◆ Automatically, in response to a problem (unplanned swaps)
Note: The Consistency Groups for z/OS Product Guide provides more information.
AutoSwap handles automatic workload swaps between Symmetrix systems when the
AutoSwap software detects an unplanned outage or problem.
In both cases, ConGroup or ConGroup with AutoSwap performs its swaps transparently,
without operational interruption. Swaps can take place while application workload
continues.
You can use AutoSwap in both shared and non-shared DASD environments. AutoSwap
uses standard z/OS operating system services to ensure serialization and to affect swaps.
AutoSwap uses the Cross System Communication facility (CSC) of SCF 1 to coordinate
swaps across multiple z/OS images in a shared DASD or parallel sysplex environment.
Swap types
As noted previously, there are two types of swaps that ConGroup and AutoSwap can
perform:
◆ Planned swaps
◆ Unplanned swaps
Planned swaps
Planned swaps are swaps that are staged at the direction of site personnel when certain
planned events must take place. Planned swaps can facilitate many functions such as
non-disruptive building maintenance, power reconfiguration, DASD relocation, and
channel connectivity reorganization.
You generally perform planned swaps, either manually or automatically, through
ConGroup.
1. Symmetrix Control Facility (SCF) delivers a “persistent address space” on the host that facilitates
communication between the host and the Symmetrix system as well as other EMC-delivered and
partner-delivered applications.
Introduction to AutoSwap for the ConGroup user 11

Unplanned swaps
Unplanned swaps are automatically initiated when certain situations are detected.
Unplanned swaps can protect systems against outages of various kinds. Examples include
failures occurring to power supply, building infrastructure, air conditioning, channel
connectivity or entire DASD subsystems, operator error or the consequences of intended
or unintended sprinkler discharge.
You set up the conditions under which you want an unplanned swap to occur through the
AutoSwap extension. Then, when such a situation does occur, ConGroup with the
AutoSwap extension executes the swap on your specification.
AutoSwap modes
AutoSwap has two modes of operation.
◆ CAX (ConGroup AutoSwap Extension)
◆ Basic AutoSwap
CAX
CAX is the normal AutoSwap mode. It is an extension of ConGroup. In CAX mode,
AutoSwap functions are invoked:
◆ By you, through commands directed to the ConGroup address space
◆ Automatically, according to rules defined by ConGroup parameters
You must use CAX for automated (unplanned) swaps.
Note: The Consistency Groups for z/OS Product Guide provides more information about
CAX.
Basic AutoSwap
AutoSwap also has a limited “basic” mode that you can invoke without ConGroup,
through the SCF Address Space. Basic AutoSwap only handles manual (planned) swaps.
Basic AutoSwap is used in situations where ConGroup is not, or cannot be, active. (An
example is an R2 to R1 swap.)
Group swaps are always performed with dependent write consistency. This results in a
restartable image, even if single or multiple failures occur during the swap process.
Note: “Consistent swaps” on page 15 and the Consistency Groups for z/OS Product Guide
provide definitions and explanations of dependent write consistency.

What you can swap

The swapping requirements for ConGroup and the AutoSwap extension are the same.
◆ Any volumes you swap must be in a valid SRDF ®/Synchronous relationship.
Usually, volumes to be swapped are defined as members of named groups, and the
swap function applies to the entire group. When a group is swapped, all volumes in
the group are swapped at the same time. AutoSwap briefly suspends I/O to all
volumes in the group during the swap process. This ensures that the destination
volumes contain current data at the completion of the swap.
◆ AutoSwap does not support active XCF couple datasets. You should not configure
sysplex couple datasets on SRDF devices or define sysplex couple datasets in an
AutoSwap group. The only exceptions are LOGR couple datasets.
(You can dynamically activate and deactivate couple datasets.)
◆ You can use PAV devices; however, if you do, you need to keep the following points in
mind:
• Only use the addresses of base PAV devices in your groups. Do not use the
addresses of aliases.
• To continue using the PAV mode after a swap, you should have the PAV enabled for
the target in the Bin file.
◆ If MIDAWs 1 are enabled on a source device, they must be enabled on the target
device.
◆ Considerations for page datasets:
• Page datasets are only supported on Symmetrix systems with the Enginuity™
operating environment for Symmetrix Version 5x71 or later. This applies to both
source and target systems.
• Page volume support requires:
Running your PROC with the parameter SUB=MSTR.
• Each device must be dedicated to page dataset usage, and only online to one host.
• Each device can have more than one page dataset.
• Symmetrix configuration is required. You must change “Enable page data set
mode” from the default NO value to YES. This allows SRDF to put the page device in
synchronous mode, rather than adaptive copy mode. Synchronous mode is
required for AutoSwap.
Ask your EMC support representative to perform this configuration setup.
• So long as the device is configured as above, you may use the z/OS PAGEADD and
PAGEDEL commands to add and delete page datasets on volumes in groups under
AutoSwap control.
1. Modified Indirect Data Address Words. Refer to IBM z/Architecture Principles of Operation,
publication number SA22-7832.
What you can swap 13

• AutoSwap only performs an R1 to R2 swap for paging devices. R2 to R1 swaps are

not supported. Therefore, a return swap must be preceded by a personality swap.
Personality swaps require Dynamic SRDF.
Note: : “When a swap needs to take place” on page 22 provides more information.
◆ Normally, a swap involves many checkpoints. However, to avoid negative system

impact, AutoSwap uses fewer checkpoints for page datasets and OPS/MVS DIV
datasets. To ensure that the special swap procedure works, volumes containing such
datasets must not be shared and must be dedicated to those datasets.
◆ AutoSwap groups that contain devices with page datasets must also include at least
one non-page dataset device. The additional checkpoints for the non-page dataset
device are necessary for complete processing of the AutoSwap group.
Handling High Priority Swap Devices

Particular devices within an AutoSwap group are automatically recognized by AutoSwap
as requiring preferential treatment. Devices containing page datasets and OPS/MVS1 DIV
(Data In Virtual) datasets for OPSLOG and SYSCHK1 are treated preferentially because of
their critical nature and the need to ensure system availability during the swap process.
Due to the need to swap these devices very quickly, AutoSwap uses a streamlined version
of the normal swap that is independent of the group but also done as part of the group.
These types of swap devices are known as High Priority. These can be identified using the
AutoSwap command to find all High Priority swap device pairs. For example:
DISPLAY GROUP <group name> FIND *HP*
During a planned AutoSwap swap the high priority device pairs are swapped prior to the
normal priority devices. During an unplanned swap the high priority and normal priority
devices are swapped concurrently.
High Priority devices have a number of restrictions that limit normal application, non High
Priority, data from or shared data being placed on these devices:
◆ CAX swaps are always consistent, however data on the "streamlined" volumes may
not be consistent with other volumes in the group.
◆ RESERVE transfer processing is not applicable to these device which means that a
RESERVE may be lost if it is held at the time the AutoSwap swap occurs.
◆ To allow these devices to be swapped quickly the normal cross system checkpoint
processing is not performed. High priority R1 devices are set to a NRDY state early in
the swap which prevents any other system updating the device. This might cause a
false unplanned event due to 'intervention required' to be detected on other hosts.
In order to allow RDF reconfiguration processing to complete quickly AutoSwap verifies
during VALIDATE processing that High Priority devices are always in an R1->R2 direction
and that they are part of a CAX group. AutoSwap fails the validation if this is not the case.
In addition, as checkpoint processing is eliminated with High Priority devices, normal
priority devices must be part of the swap group.
1. OPS/MVS is a product of Computer Associates International Inc.

Consistent swaps
Swaps performed by ConGroup or AutoSwap are consistent swaps. Page and OPS/MVS
data are treated with a high priority and volumes containing them swap ahead of other
volumes. If regular data are on these volumes, the result may be an inconsistent swap.
Consistent swaps ensure that the swap is a unique, atomic operation that maintains
dependent write consistency. Consistent swaps use EMCs consistency technology to
temporarily “freeze” write operations to the entire swap group during the swap.
Consistency technology honors a guaranteed sequence of updates in the I/O stream to a
group of devices that are remotely mirrored. Consistency technology is provided by
ConGroup.
Applications, database systems, and system components (such as VTOC processing)
require and ensure sequence integrity by waiting for successful completion of one update
before requesting the next.
In a remote disk copy environment, data consistency cannot be ensured if a later update
was remotely mirrored when its predecessor was not. This can happen when remote link
failure(s) affect only a subset of the disk controllers that are performing the remote copy
function.
When a transmission to a remote Symmetrix system fails, ConGroup halts subsequent
(possibly dependent) writes to all remote DASD systems containing members of the group
of devices. The synchronous relationship is suspended on all subsystems until recovery
action is taken. ConGroup ensures that all LPARs are aware of these changes. Should the
local system fail, the remote system is in a restartable condition.
System users may notice slight performance degradation during a consistent swap. This
usually lasts no more than a few seconds. The degree of impact depends upon factors
such as:
◆ Number of volumes being swapped
◆ Overall workload
◆ Write content
Note: The Consistency Groups for z/OS Product Guide describes the consistent copy
process.
Information about swap service messaging

AutoSwap can generate swap services messages. For more information regarding
AutoSwap and swap services messages, refer to Appendix C, “Swap Services Message
Formatting,” located in this guide.
Consistent swaps 15
Information about dynamic auto-swapping services

If you intend to use dynamic Auto-Swapping services while using z/OS Migrator, you must
add the following entry to your MFE/SCF Initialization deck to ensure the AutoSwap
services are available under your instance of ResourcePak Base (MFE/SCF). This entry also
ensures the Cross Systems Communications (CSC) facility is available.
SCF.DAS.ACTIVE=YES
If there is any question as to whether AutoSwap and/or CSC are running under your
MFE/SCF task, look for the following messages in your MFE/SCF task log:
SCF0301I SCF.DAS.ACTIVE=YES
SCFS175I AutoSwap Initialization complete.
SCFS285W AutoSwap waiting for EMCSCF Cross System Communication
SCFS226I
AutoSwap has initialized with EMCSCF Cross System Communication
For more information concerning this INI parameter, refer to the section in the
ResourcePak Base Product Guide entitled Configuration File and Initialization Parameters.

CHAPTER 2
Operations
Invisible Body Tag
This chapter discusses AutoSwap operations.

◆ Implementing AutoSwap through ConGroup............................................................ 18
◆ When a swap needs to take place ........................................................................... 22
◆ Scenarios for swapping – some implementation choices......................................... 23
◆ Performing IODF configuration changes ................................................................... 26
Operations 17
Operations
Implementing AutoSwap through ConGroup

To implement AutoSwap through ConGroup:
1. Define configuration parameters
2. Start the ConGroup started task
3. Issue commands
Note: The Consistency Groups for z/OS Product Guide describes the ConGroup parameters
and the ConGroup started task. Chapter 5 in this guide describes the AutoSwap
commands.
Defining configuration parameters

The first job in setting up AutoSwap in a ConGroup environment is to define the ConGroup
configuration parameters. You set these parameters to specify the groups of devices to be
swapped and the conditions under which you want the swap to occur.
ConGroup has two types of configuration parameters:
◆ Global configuration parameters
◆ Consistency-group-specific configuration parameters
In addition, there are AutoSwap-specific configuration parameters.
Global configuration parameters

Global configuration parameters describe how you want ConGroup to operate. Global
parameters may be used by any of the defined consistency groups.
One of the more important global configuration parameters is CAXOPTS. You use CAXOPTS
to define named sets of options for the behavior of AutoSwap when it works with
ConGroup. These options include such specifications as:
◆ Which errors cause a swap
◆ How to handle Cache Fast Write devices
◆ The Lost Owner Policy (LOP)
LOP defines what to do in the event of loss of communication with the owning (controlling)
system to ensure that the devices do not have multiple “owners.”
Other parameters that are important to AutoSwap users are:
◆ COUPLEDS_ALLOWED
◆ GLOBAL
◆ PAGEDEV_ALLOWED
COUPLEDS_ALLOWED allows you to add volumes with couple datasets to a consistency
group or explicitly prevent the addition of volumes with couple datasets to a consistency
group.
GLOBAL has one argument, OWNER. OWNER specifies the SMF ID of the LPAR that controls
the consistency group and the ConGroup AutoSwap functions.

Operations
PAGEDEV_ALLOWED allows you to add volumes with page datasets to a consistency group,
or explicitly prevent addition of volumes with page datasets to the consistency group.
Note: These global configuration parameters are described in the Consistency Groups for
z/OS Product Guide and in Chapter 4 of this guide.
Consistency-group-specific parameters
Consistency-group-specific configuration parameters apply to individual consistency
groups.
For example, you use the CONGROUP=name parameter to define a group’s name. After
you define the name, define the devices in the group. You can define the devices through:
◆ The DEVICE_LIST=devices parameter
◆ The SMS_GROUP=smsgroupname parameter
Another consistency group specific configuration parameter, CAXOPTS, is particularly
important for AutoSwap. You define a ConGroup’s AutoSwap behavior with the CAX
parameter, which names the CAXOPTS set to be associated with this ConGroup. This
enables you to create one behavioral definition for multiple consistency groups, and know
that their behaviors are identical.
There are other group-specific parameters not covered here. These consistency group
specific parameters are described in the Consistency Groups for z/OS Product Guide.
AutoSwap-specific configuration parameters

The AutoSwap-specific configuration parameters are called SDAS options. These SDAS
options allow you to specify the kinds of actions you want taken and the general types of
volumes that you want (or don’t want) automatically swapped. For example, SDAS options
allow you to specify:
◆ Whether you want to swap devices with concurrent copy sessions
◆ Whether you want to swap devices with snap sessions
◆ Whether you want to bypass the requirement that all other LPARs with an established
path group to a swapped device have EMCSCF and ConGroup running
There are other SDAS options as well. For more information, refer to “SDAS options” on
page 63.
Starting the ConGroup address space

You initiate AutoSwap through console commands to ResourcePak Base or to ConGroup.
While you can run ConGroup as a batch job, EMC recommends that you run ConGroup as a
started task, with SUB=MSTR.
If any of your consistency groups could ever include devices containing JES2 or JES3
datasets, you must run ConGroup as a started task with SUB=MSTR.
Implementing AutoSwap through ConGroup 19

Operations
If you do not, you may obtain an undesirable result if you run ConGroup under the Job
Entry Subsystem, and ask ConGroup to control JES datasets. In such a case, ConGroup
may request services from JES (such as WTO) at the same time as it suspends I/O to JES
devices. Running as SUB=MSTR resolves this issue and also gives the ConGroup address
space higher priority. This can be advantageous in heavily loaded systems.
Note: AutoSwap version 7.3 and higher does support JES3.
The Mainframe Enablers SAMPLIB contains the sample started task procedure to run the
ConGroup task, EMCCGRP. Customize these members for your installation, and install
them in the appropriate PROCLIB.
Note: The Mainframe Enablers Installation and Customization Guide provides more
information.
Issuing commands
AutoSwap has a series of operator commands that:
◆ Define how processing is to proceed
◆ Allow you to view the state of the AutoSwap configuration
Command categories
The major AutoSwap operator command categories are as follows:
◆ DEFINE GROUP
◆ DELETE GROUP
◆ DISPLAY
◆ SET
◆ SETSWAP
◆ SWAP
◆ VALIDATE GROUP
Command tasks
These commands allow you to:
◆ Concurrently swap large numbers of devices
◆ Perform dynamic workload configuration without application downtime
◆ Handle device group operations
◆ Relocate logical volumes
◆ Perform consistent swaps
◆ Implement planned outages of individual devices, of one or multiple subsystems, or
of a whole site

Operations
Command syntax
After you define the configuration parameters, you may issue these commands (using
MODIFY) to direct AutoSwap and ConGroup processing to the ConGroup started task
through the ConGroup operator console.
Use the following format:
F EMCCGRP,DAS keyword parameter,...
Where:
EMCCGRP
The ConGroup started task name. Your installation may have chosen a different name.
DAS
Tells ConGroup that an AutoSwap command follows.
keyword
An AutoSwap command.
parameter
An AutoSwap parameter.
,...
Additional optional parameters. Separate each optional parameter with a space.
Note: If you are going to a new line, begin the line with a continuation character.
Continuations are indicated with a '-' after the last value on a line, for example:
...
DEF GRP PROD INC CUU=312C-312F -
CFW=RES PREVAL PROCCNT=3 RETAIN REPLACE
...
Example
After you have set up swap groups and behaviors as configuration parameters, you may
request a swap by a command such as:
F EMCCGRP,DAS SWAP GROUP groupname
Where:
EMCCGRP
The ConGroup started task name used in this guide.
Note: Your ConGroup started task name may be different.
DAS
Tells ConGroup that an AutoSwap command follows.

SWAP
Tells AutoSwap that a swap is required.
Implementing AutoSwap through ConGroup 21

Operations
Note: “SWAP ” on page 84 provides more information about the SWAP command.
GROUP
Tells AutoSwap that it’s a group that is swapped, not an individual device.
groupname
Names the group for AutoSwap.
Note: You can enter AutoSwap commands through the CONFIGCA. These commands are
processed at startup.
When a swap needs to take place

Whenever a swap needs to take place, AutoSwap goes through a series of steps outlined
in Figure 1.
1.
Halt I/O to the swap group
2.
Condition RDF devices to disable
access to the source devices and
enable access to the target devices
3.
Transfer reserves to the target devices
4.
Switch UCB contents of the source and
target pairs
5.
Release the halted I/O
Figure 1 Steps taken during a swap
As shown in Figure 1, AutoSwap takes the following steps during a swap:

1. Temporarily halt I/O to the swap group.

Operations
AutoSwap holds all I/O during the swap process to ensure dependent write
consistency. This step protects data and ensures restartability in the swap group
should failures occur in the infrastructure during the swap event.
Note: It is possible to configure Host Read Only devices and make them available to an
AutoSwap group. In addition, an online target R/O R2 can remain R/O following a
swap on selected LPARs.
Refer to the descriptions of the SCF.DEV.ATTR.HRO.INCLUDE.LIST and
SCF.DEV.ATTR.HRO.EXCLUDE.LIST commands in the Initialization chapter in the
ResourcePak Base Product Guide and the description for
“[NO]AllowOnlineToDevice|[NO]AllOnTo” on page 65 in this guide.
2. Condition the RDF devices to disable access to the source devices and enable access
to the target devices.
During the time I/O to the devices is being queued, AutoSwap reconfigures the SRDF
pair to allow the application I/O stream to be serviced by the target SRDF device.
3. Transfer reserves to the target devices.
4. Switch the contents of the Unit Control Blocks (UCBs) of the source and target pairs.
Because the contents of the UCBs are swapped, the redirection of I/O is transparent to
the applications running. The redirection of I/O persists until the next IPL.
5. Release the halted I/O.
AutoSwap uses the Cross System Communication facility of SCF to coordinate swaps
across multiple z/OS images in a shared DASD or parallel sysplex environment.
Because AutoSwap uses SCF, the AutoSwap consistency environment can span
multiple LPARS, within or outside parallel sysplexes, multiplexes, or combinations of
these.
Scenarios for swapping – some implementation choices

This section discusses AutoSwap’s support for both planned and unplanned swaps.
Unplanned swaps
Unplanned swaps provide continuity of operation in the event of certain failures. For
example, if device(s) become unreachable by the host, AutoSwap attempts to switch
access to devices at the other end of the SRDF/S (synchronous) links. This is always a
group swap covering all devices in the group.
An unplanned swap should not be a total surprise. In fact, most unplanned swaps should
be caused by “anticipated” events. Anticipated events are those you would prefer did not
happen, but for which you must plan. An example would be a power failure for which you
already had procedures in place.
Scenarios for swapping – some implementation choices 23

Operations
The objective of an unplanned swap is continuity of operation of the z/OS system(s). In

some cases, the triggering reasons which call for a swap may involve such a serious loss
of resources that the swap fails. Even if operational continuity is not achieved, ConGroup
is there to ensure dependent write consistency. This ensures that you have a restartable
image.
Planned swaps
You can use planned swaps to eliminate the impact of short term unavailability of
Symmetrix DASD at the source side. Such a reason may be as simple as:
◆ The need to move systems as part of a computer room reconfiguration
◆ The need to reconfigure power systems or channel connectivity
In addition to establishing SRDF mirrors of data, EMC recommends that you consider
creating an extra dependent write consistent copy of your data on TimeFinder BCVs for
added protection during this period.
Parameter settings for planned and unplanned swaps

AutoSwap provides many parameters for controlling swaps. Some of these parameters
determine whether a swap should proceed in the case of error conditions.
Unplanned swaps
Unplanned swaps handle emergencies. In emergency cases, you expect errors or unusual
conditions to occur. For example, an LPAR may lose connectivity with other LPARS in the
complex. You generally choose parameter settings that force the swap to continue in an
emergency.
You should consider what you want to happen when you restore the original source
system to an operational state. One of the requirements you should keep in mind is the
need to reestablish protection of your data quickly with two copies across the SRDF/S
links. Until this occurs, you have a reduced level of data protection.
While the original source system was unavailable, the z/OS systems were updating the
target Symmetrix systems, creating differences between this copy of the data and the copy
in the original source. The Symmetrix systems can handle these differences. They use this
information to resynchronize the copies differentially.
Planned swaps
Planned swaps have different needs. They can usually be deferred if failures occur during
the swap setup. For example, if an LPAR becomes unavailable during a swap, it is generally
safer to abort the swap and attend to the problem. Swapping may make the situation
worse.
You have two methods to perform return swaps after the planned swap completes and the
original source systems are once again available to participate in the protection of your
data.
Return swaps with dynamic SRDF devices

With Dynamic SRDF devices, EMC recommends that you take the following steps:

Operations
1. Reverse the direction of the SRDF relationship. To achieve this, use the personality
swap procedure provided by SRDF Host Component for z/OS.
Note: The SRDF Host Component for z/OS Product Guide provides more information.
2. To resume RDF operations, issue the Host Component command below, and wait until
resynchronization is completed:
#SC VOL,devices,RDF-RSUM
3. Update R1s to R2s in ConGroup definition and issue the ConGroup command:
REFRESH congroupname FORCE
Where:
congroupname
The name of the consistency group.

4. Wait until ConGroup reports that refresh is complete and ConGroup is active.
5. When it is convenient, you can use AutoSwap to “go home” again.
Note: “SWAP ” on page 84 provides more information.
Return swaps without dynamic SRDF devices

If you do not have Dynamic SRDF device capability, you may want to wait until the original
source systems are ready, and then use AutoSwap commands to swap back.
After the original swap, the following steps cause a “swap home” and a reestablishment
of ConGroup protection:
1. Use the DEFINE GROUP complementgroup COMPLEMENT originalgroup command to
assign a name to the devices that were successfully swapped.
Note: The Consistency Groups for z/OS Product Guide provides more information.
2. Issue SWAP for the complement group.
3. Delete the ConGroup CAX group.

4. Wait until resynchronization is complete. Then, issue:
#SQ VOL,devices,INV_TRKS
5. Issue the ConGroup command:

ENABLE congroupname
Where:
congroupname
The name of the consistency group.
Scenarios for swapping – some implementation choices 25

Operations
Performing IODF configuration changes
This section describes the effect of dynamic configuration changes on AutoSwap, and
which changes AutoSwap considers acceptable and unacceptable.
A dynamic configuration change is requested by using the z/OS ACTIVATE IODF= operator
command, or through the HCD ISPF interface. The ACTIVATE can be a software-only
change, or both software and hardware change. A software-only change is requested using
the ACTIVATE SOFT keyword, and only affects operating system structures. Where SOFT is
not requested, then both a hardware and software change is performed. The IBM
documented usage of software versus the hardware ACTIVATE is to perform the
software-only activate on LPARs N-1 and then, finally, the software and hardware on LPAR
N. Hardware changes can affect LPARs, including the LPAR where the ACTIVATE is
performed. IBM is explicit on the ordering of the software-only as opposed to a software
and hardware change.
Additionally, a TEST keyword can be specified to exercise (or rehearse) the configuration
change without actually doing any real work. This is to verify that the intended IODF
ACTIVATE is likely to succeed. Its success does not mean that the real ACTIVATE will be
successful, as certain blocking actions may only be present at the real ACTIVATE time.
AutoSwap blocks unacceptable configuration changes that could cause a group to become
invalid or cause the triggering of an unplanned swap.
As of version 7.6, AutoSwap interfaces with dynamic configuration processing in order to
prevent unacceptable configuration changes. This is through the z/OS programmatic ENF
31/32 (CONFCHG CHGREQ/CHGCOMPL) interfaces that are documented for this usage:
◆ ENF 31 is equivalent to CONFCHG CHGREQ to notify changes that will be made by the
ACTIVATE. ENF31 is called a second time if the configuration change is rejected due to
affected device(s) and/or path(s) remaining pinned.
◆ ENF 32 is equivalent to CONFCHG COMPL to notify the completion (success) of the
ACTIVATE.
The blocking of a configuration change by AutoSwap does not mean that the configuration
change cannot be performed, but does mean that additional actions may be required to
allow the configuration change to proceed.
Unacceptable and acceptable software configuration changes are detected by AutoSwap,
and processed as described in the following sections.
Unacceptable configuration ACTIVATE

An unacceptable configuration ACTIVATE is blocked by AutoSwap in the following
circumstances.
◆ A hardware- or software-only change is deleting a ’TO’ device UCB where its ’FROM’
partner device is online and therefore (presumably) in use. AutoSwap requires a
partner ’TO’ device where the ’FROM’ device is online. Specifically, AutoSwap needs
something to SWAP ’TO’.

Operations
◆ A hardware- or software-only change is deleting the AutoSwap access device on the

’TO’ device controller. AutoSwap maintains an access, or gatekeeper, device on each
’TO’ controller to allow IO to be performed to the Symmetrix devices in the AutoSwap
group. This access device is used to process controller level commands during the
VALIDATE and SWAP processing in addition to facilitating CSC communications. The
access device is the same device as the currently used CSC gatekeeper device. A UCB
PIN is always maintained on this device during the life of an AutoSwap group and
changes as the CSC gatekeeper device changes.
◆ A hardware change is deleting a ’FROM’ device UCB. This is to prevent an unplanned
SWAP trigger from occurring on another LPAR.
◆ A hardware change is deleting a ’TO’ device UCB where its partner ’FROM’ UCB is
enabled for unplanned SWAP; specifically, the device status is AutoAble on the
DISPLAY GROUP DETAIL output. This is to prevent a ’TO’ device being unavailable on
another LPAR which might have the ’FROM’ device online.
Acceptable configuration ACTIVATE

An acceptable configuration ACTIVATE is allowed by AutoSwap in the following
circumstances.
◆ A software only change is deleting a ’FROM’ device UCB.
◆ A software only change is deleting a ’TO’ device UCB where its ’FROM’ device partner is
offline, not defined (ungenned), or is also being deleted.
Processing unacceptable configuration changes

Unacceptable configuration changes as previously described results in the ACTIVATE being
failed (blocked) by AutoSwap. This is performed by PINning an affected device UCB during
the ENF 31 configuration change notify processing. Not all affected UCBs will be PINned,
as only one UCB PIN is required to fail the ACTIVATE.
The PIN text displayed on the resulting IOS500I message indicates that deleting the device
causes an issue with AutoSwap.
IOS500I ACTIVATE RESULTS
NOTE = 0100,SOFTWARE-ONLY CHANGE
REASON=0151,CAN NOT DELETE DEVICE 8000
DESCTEXT=DEVICE PINNED, ASID = 0099
Dynamic Configuration change blocked by AutoSwap
In this example, the dynamic configuration change is blocked by AutoSwap.

In addition, a long term PIN is held on the ’TO’ controller access device for the life of the
AutoSwap group. Where this device is being deleted its PIN text will, on z/OS 1.13 and
higher, be displayed during ACTIVATE TEST mode. As previously discussed, the access
device is the current CSC gatekeeper, and changes as the CSC gatekeeper is changed. An
attempt to delete the access device is rejected, as shown by the following PIN text.
ACTIVATE FAILED - ERROR MESSAGE(S) ISSUED
AutoSwap 'TO' controller access device
Performing IODF configuration changes 27

Operations
In this example, the ACTIVATE is the AutoSwap ’TO’ controller access device.
To clarify the reason for the rejection, AutoSwap displays message CGRS646I. It also lists
the devices that the ACTIVATE is attempting to delete and the reason why the delete is
unacceptable.
The ’TO’ and ’FROM’ error device ranges (those blocking the configuration change)
precede the ’TO’ and ’FROM’ informational and warning device ranges. For an
unacceptable change, one or more reason lines describe why the change is not acceptable
and is being rejected.
All unacceptable changes can be overridden using the AutoSwap SETSWAP GROUP
DISABLE command. Unacceptable changes do not mean that the configuration change is
not possible. AutoSwap indicates those circumstances where a SETSWAP DISABLE is a
valid action with the following reason.
Reason: SETSWAP DISABLE required prior to ACTIVATE
SETSWAP DISABLE temporarily disables the AutoSwap group from performing SWAP
processing. This includes unplanned and planned SWAPs. On the subsequent SETSWAP
ENABLE, AutoSwap performs a local host validate to ensure the configuration is still
healthy and valid for SWAP processing. If it validates successfully, then all devices once
again have their unplanned triggers installed.
However, SETSWAP DISABLE can also be used to override AutoSwap, blocking the change
where SETSWAP is NOT a valid action. Performing such an action does not cause an
unplanned SWAP on the subsequent SETSWAP ENABLE. However, the group might be
marked invalid when the SETSWAP ENABLE command is issued.
Valid usage of SETSWAP DISABLE

Valid usage of SETSWAP DISABLE is indicated by the ‘Reason’ line in the CGRS646I
message:
For example, on a hardware change, the following ‘Reason’ lines indicate why the change
is rejected.
ACTIVATE IODF=0E,FORCE
CGRS646I AutoSwap ACTIVATE results

ACTIVATE rejected by AutoSwap
'TO' AutoSwap device(s) in CSS 0 being deleted by hardware ACTIVATE:
Reason: 'FROM' partner device UNPLANNED ENABLEd
Reason: Device(s) are blocking the configuration change
03980-03981
'FROM' AutoSwap device(s) in CSS 0 being deleted by hardware
ACTIVATE:
01E00-01E02
Devices Affected : 5
Blocking 00000000: 5
Ranges displayed : 2
Not displayed 00 : 0
IOS500I ACTIVATE RESULTS 127

NOTE = A886,FOLLOWING DEVICES ARE TO BE DELETED FROM PROCESSOR X1:

Operations
1.3980-1.3981,1.1E00-1.1E0F,0.3980-0.3981,0.1E00-0.1E0F
COMPID=SC1XL
DESCTEXT=DEVICE PINNED
0Dynamic Configuration change blocked by AutoSwap
In this example, the dynamic configuration change is blocked by AutoSwap.

The rejecting reason associated with each range indicates that a SETSWAP DISABLE is
required to allow the ACTIVATE to be successful:
Each ‘Reason’ must be carefully examined and considered, as a SETSWAP DISABLE allows
an ACTIVATE to be performed for situations where it is not valid to do so. This is discussed
in the next section.
The SETSWAP disable can be for a specific group, or by using the generic ‘*’. While
SETSWAP DISABLE is in effect, all groups DISABLED indicate this at 30-second intervals
with the CGRS599W message. This is a reminder message to indicate during this period of
time that AutoSwap is unavailable for SWAP processing:
F CONGROUP,DAS,SETSWAP GRP * DISABLE
CGRS598I (00170) SETSWAP DISABLE completed: 151

Group SSA3 now DISABLED
Total groups processed : 1
Successful : 1
Failed : 0
CGRS599W (00165) Group SSA3 has been SWAP DISABLED for 30 seconds.
And now retry the ACTIVATE. This time AutoSwap permits the ACTIVATE ‘Note’
informational messages are displayed to indicate the SETSWAP DISABLE had been
requested:
CGRS646I AutoSwap ACTIVATE results 166

ACTIVATE permitted by AutoSwap
'TO' AutoSwap device(s) in CSS 0 being deleted by hardware ACTIVATE:
Note: UNPLANNED had been DISABLED prior to ACTIVATE
03980-03981
ACTIVATE:
01E00-01E02
Devices Affected 00 : 5
Blocking 000000000: 0
Ranges displayed0 : 0 2
Not displayed : 0000
IOS502I I/O CONFIGURATION CHANGED 167

INVOKER = *MASTER*
NEW IODF = SYS$X1.IODF0E
EDT REBUILT, NEW EDT ID = 00
DEVICE(S) DELETED FROM SOFTWARE CONFIGURATION
1E00-1E0F 3980-3981.

Operations
DEVICE(S) DELETED FROM CSS 0

3980-3981 1E00-1E0F.
3980-3981 1E00-1E0F.
Now that the ACTIVATE is complete, the SETSWAP ENABLE can be entered. This results in
AutoSwap performing a local system validate to ensure that the configuration still looks
healthy. Any deleted devices are messaged by the CGRS644W and CGRS643W messages.
F CONGROUP,DAS,SETSWAP GRP * ENABLE
CGRS595I (00165) Group SSA3 SWAP processing ENABLED from host X006
(010E01F7281800D0).
CGRS644W (00165)(PID 00005) ‘TO’ device 03980 UCB has been deleted.
CGRS598I (00171) SETSWAP ENABLE completed: 193
Group SSA3 now ENABLED
Total groups processed 0: 1
Successful 00: 1
Failed 0 : 0
CGRS643W (00165)(PID 00001) ‘FROM’ device 01E00 UCB has been deleted.
CGRS614W (00165) Alternate SS1 has 444 devices not in group SSA3
CGRS292I (00165) Group SSA3 216
Total Devices : 6 Highest PID : 6
Valid : 6 Invalid : 0
Auto Swappable: 3 Auto Pending : 0
Swapped : 0 Failed Swap : 0
Offline : 3 Not Defined : 5
Alternate SS : 4
Invalid usage of SETSWAP DISABLE

If a ’TO’ or ’FROM’ reason for a device range on message CGRS646I does not contain an
indication of the SETSWAP DISABLE, then it is not appropriate to use this command to
allow the configuration ACTIVATE to be performed. In this case, other actions may be
required.
For example, in the following hardware activation, a couple of reason lines for device
ranges indicate that the ACTIVATE should not be performed. In the first instance, the
’FROM’ partner device for a ’TO’ device being deleted is online.
Reason: 'FROM' partner device is ONLINE and delete
will result in an invalid AutoSwap group
This is an error, as deleting the ’TO’ device in this circumstance doesn’t allow AutoSwap to
SWAP to a device.
In the second instance, the group access device is being deleted:
Reason: 'TO' controller ACCESS device

Operations
Deleting this device might cause an issue for AutoSwap in both successfully completing a
SWAP and also in the usage of EMCSCF CSC:
ACTIVATE rejected by AutoSwap
'TO' AutoSwap device(s) being deleted:
Reason: 'FROM' partner device is ONLINE and delete
03980
Reason: 'TO' controller ACCESS device
03981
'FROM' AutoSwap device(s) being deleted:
Note: UNPLANNED is now DISABLED
01E00-01E02
Blocking : 2
Not displayed : 0

ACTIVATE was rejected
'FROM' AutoSwap device(s) UNPLANNED re-ENABLEd:
01E00-01E02
Blocking : 0
Not displayed : 0

DESCTEXT=DEVICE PINNED
Dynamic Configuration change blocked by AutoSwap
AutoSwap 'TO' controller access device
As previously discussed, all unacceptable changes can be overridden using the AutoSwap
SETSWAP GROUP DISABLE command.
However, SETSWAP DISABLE can also be used to override AutoSwap blocking the change
which may subsequently result in the group being marked invalid when the SETSWAP
ENABLE command is issued.
SETSWAP DISABLE can be used to override AutoSwap, blocking the change which may
subsequently result in the group being marked invalid when the SETSWAP ENABLE
command is issued.
For example, following the previous activate rejection, an attempt is made to invalidly use
the SETSWAP DISABLE command. As soon as the DELETE actions are performed, CSC
looses access to its gatekeeper, since it is the AutoSwap access device. In this case, swap
processing cannot be validated or swapped successfully. The ’FROM’ device that is online
is now issuing a warning that the group will be marked invalid when the SETSWAP ENABLE
is performed.

Operations
F CONGROUP,DAS,SETSWAP GROUP * DIS
CGRS595I (00158) Group SSA4 SWAP processing DISABLED from host X006
(010E01F7281800D0).
CGRS598I (00163) SETSWAP DISABLE completed: 116
Group SSA4 now DISABLED
Successful : 1
Failed : 0
CGRS646I AutoSwap ACTIVATE results 130

'TO' AutoSwap device(s) in CSS 0 being deleted:
Warn: 'FROM' partner device is ONLINE and delete
03980
ACTIVATE:
01E00-01E02
Devices Affected 00 0: 4
Blocking 00 : 0
Ranges displayed0 : 2
Not displayed000 : 0
SCF0604E CSC (0001957-00079) UNABLE TO LOCATE A GATEKEEPER DEVICE

DURING PROCESSING
IOS502I I/O CONFIGURATION CHANGED 132

INVOKER = *MASTER*
NEW IODF = SYS$X1.IODF0E
1E00-1E0F 3980-3981.
3980-3981 1E00-1E0F.
3980-3981 1E00-1E0F.
And now the SETSWAP ENABLE is performed, which results in the group now being marked
as invalid:
F CONGROUP,SETSWAP G * ENABLE
CGRS595I (00158) Group SSA4 SWAP processing ENABLED from host X006
(010E01F7281800D0).
CGRS598I (00164) SETSWAP ENABLE completed:

Group SSA4 now ENABLED
Successful 0: 1
Failed 00000000 00: 0
CGRS648E (00158)(PID 00005) Cannot locate 'TO' device for 'FROM'

device 03A62. 'FROM' device is ONLINE.
CGRS244E (00158)(PID 00005) No 'TO' device configured for
RDFgrp/SymDV#/
Ctrl#/CUU: --/0CC0/000195700079/-----
CGRS239W (00158)(PID 00005) Device 3A62 (NDef) is no longer eligible

for unplanned AutoSwap.

Operations
To correctly process this configuration change, the following planning actions must be
performed:
◆ The CSC gatekeeper must be changed in the EMCSCF SCFINI parameter file to a device
not being affected by the change and an INI,REFRESH performed. This automatically
results in AutoSwap unpinning and repining the new access device.
◆ In the case of the ’TO’ device being deleted where the ’FROM’ device was online, the
delete must be reconsidered, the ’FROM’ device varied offline, or the ’FROM’/’TO’
device ranges must be deleted from the CONGROUP CAX group using the CONGROUP
dynamic delete commands.
Processing acceptable configuration changes

Acceptable configuration changes are allowed, and the ACTIVATE is allowed to continue
without the usage of SETSWAP DISABLE processing. If the ACTIVATE is completed
successfully, AutoSwap performs a minimal (UCB only) VALIDATE on the local LPAR only to
determine UCB changes. Where device deletions have occurred, AutoSwap marks the
device as now being undefined, and displays these deletions in the CGRS643W and
CGRS644W messages.
Additionally, for an acceptable configuration change, AutoSwap temporarily marks the
affected devices as not eligible for unplanned SWAP processing. This prevents AutoSwap
from performing an unplanned SWAP during this period of time. The triggers are allowed
after the ENF 31 (change rejected) or ENF 32 (change complete) is processed.
For example, in the following configuration (software only), ACTIVATE is deleting devices
that are acceptable to the current AutoSwap group status. During the ACTIVATE, all swap
triggers for only these devices are disabled. Following the ACTIVATE completion, a group
validate is automatically performed.
ACTIVATE CFID=UIFDEL6

03980-03981
'FROM' AutoSwap device(s) being deleted:
Note: UNPLANNED is now DISABLED
01E00-01E02
Blocking : 0
Not displayed : 0
IOS502I I/O CONFIGURATION CHANGED

INVOKER = *MASTER*
NEW IODF = SYS$X1.IODF03
1E00-1E0F 3980-3981.
CGRS614W (00165) Alternate SS1 has 444 devices not in group SSA3
CGRS292I (00165) Group SSA3 378

Operations
Total Devices : 6 Highest PID : 6

Auto Swappable: 3 Auto Pending : 0
Alternate SS 000: 4
Additional considerations for configuration changes

The following considerations should be taken into account when performing dynamic
configuration changes.
◆ Where the SETSWAP DISABLE command has been entered prior to the ACTIVATE, then
AutoSwap does not block an unacceptable change. When the SETSWAP ENABLE
command is entered, AutoSwap verifies any configuration changes through its normal
minimal (UCB level) VALIDATE processing. This could result in a group becoming
invalid where the activated IODF does not satisfy AutoSwap requirements; for
example, a ’TO’ device UCB is deleted where the ’FROM’ device UCB is online.
◆ Only CAX groups defined with an unplanned trigger are processed through ENF 31/32.
Where a CAX group is defined with no unplanned triggers (a planned-only group), then
AutoSwap does not prevent an unacceptable change to the configuration. AutoSwap
verifies any unacceptable changes during the next VALIDATE or SWAP request, and
marks the group as invalid. This applies to non-CAX groups, such as those defined by
zMigrator.
◆ AutoSwap does not remove any Symmetrix device pairings automatically from the CAX
group where the ’FROM’/’TO’ devices are deleted from the configuration. AutoSwap
cannot determine if this is the intention of the configuration change. The devices still
exist within the group as undefined devices. If it is the intention of the ACTIVATE to
remove the device pair from the CAX group, then the existing Congroup dynamic
ADD/DELETE service must be used prior to the ACTIVATE.
◆ During all AutoSwap VALIDATE and SWAP processing, AutoSwap serializes processing
with IODF ACTIVATE using the SYSZIOS/DYNAMIC ENQ. This prevents AutoSwap and
dynamic configuration changes from interfering with each other:
• If an IODF ACTIVATE is performed at the time of an AutoSwap VALIDATE or SWAP,
then AutoSwap waits before proceeding.
• If AutoSwap acquires the ENQ prior to the IODF ACTIVATE, then the ACTIVATE fails
with the following message. If this occurs, then retry the ACTIVATE following the
completion of the current AutoSwap processing. The AutoSwap DISPLAY GROUP *
command is used to get the current status of AutoSwap groups.
IOS500I ACTIVATE RESULTS 522
REASON=0183,DYNAMIC I/O ENQUEUE COULD NOT BE OBTAINED
COMPID=SC1C3
• It is possible that a third party incorrectly serializes this ENQ as EXCL. If AutoSwap
determines that an IODF ACTIVATE is not really in progress, then processing
continues after a minimal wait period. The GRS operator command D
GRS,RES=(SYSZIOS,DYNAMIC) can be used to show the current holders of this
ENQ.

Operations
◆ Devices added by a dynamic configuration change have no special requirements or

preparation to AutoSwap. If a device was undefined to an LPAR and part of an
AutoSwap group, it is known by its Symmetrix device details. However, if the device is
subsequently added by an IODF ACTIVATE, then AutoSwap automatically recognizes
the device definition by resolving them to the group following the ACTIVATE
completion.

Operations

CHAPTER 3
Resuming Operations after an AutoSwap
Invisible Body Tag
This chapter describes the steps you must take to resume AutoSwap protected host
operations after a ConGroup AutoSwap event.
◆ Introduction ............................................................................................................ 38
◆ AutoSwap scenarios................................................................................................ 38
◆ Defining complement device groups ....................................................................... 39
Note: This chapter describes procedures that involve two other components: EMC
Consistency Groups for z/OS (ConGroup) and SRDF Host Component for z/OS. You can find
more information about these products in the Consistency Groups for z/OS Product Guide
and the SRDF Host Component for z/OS Product Guide.
Resuming Operations after an AutoSwap 37

Introduction
This section discusses options for “return swaps.” The discussion is not exhaustive.
Effective protection of your information requires more than just acquiring the best tools.
Use of SRDF, ConGroup, AutoSwap and TimeFinder requires careful planning. You must
have rigorously designed and documented procedures.
If you need assistance in developing such procedures, EMC recommends that you engage
EMC Business Continuity Services.
Avoid unnecessary swaps

You should always keep in mind what a swap means for your data. Online swaps involve
suspension of SRDF and ConGroup operations.
When a swap starts, the primary copy is frozen at that point in time. Only the secondary
copy is updated. Until SRDF and ConGroup are operational again, there is reduced
duplication and protection of the data in your SRDF configuration. After the swap at your
site, the applications may still be running and the target (R2) devices have become the
new primary devices.
For these reasons, you should only initiate swaps when you have a good reason to do so;
for example, as a necessary planned outage requiring a swap.
AutoSwap scenarios
There are two basic scenarios for resuming operation after a swap:
◆ Resuming operations with dynamic SRDF devices
◆ Resuming operations without dynamic SRDF devices
These scenarios are discussed in the following sections.
Resuming operations with dynamic SRDF devices

When resynchronization is complete, you can resume ConGroup protection. ConGroup can
protect only the R1, or the source side of SRDF.
The fastest and safest way of resuming ConGroup protection is to perform a personality
swap. In a personality swap, R1s become R2s, and R2s become R1s.
After the personality swap is complete, you can start ConGroup on the new R1 (former R2)
side. When ConGroup finds that the invalid track count has dropped to zero, it resumes
protection.
There are several advantages to using personality swaps:
◆ Personality swaps allow symmetry in the DASD subsystems. Either end of the SRDF
relationship can be used for production work. Without dynamic SRDF, protection is
complete only while operating on the static R1 side. The R1 side becomes the
preferred side.
◆ Personality swaps allow you to postpone a swap back until an external event makes it
necessary.

Resuming operations without dynamic SRDF devices

Personality swaps work only on Symmetrix systems with Dynamic SRDF devices. They are
not possible with nondynamic SRDF devices. R1s remain as R1s and R2s remain as R2s.
Because ConGroup only works on R1 devices, you must execute an AutoSwap swap back
to the R1s before you can enable ConGroup again on systems without dynamic SRDF. You
can accomplish a swap back, using either AutoSwap or ConGroup as follows:
1. Reestablish the SRDF relationship. Then, you swap back to the R1 side, even if the
resynchronization is not complete.
2. Define a “complement” device group. A complement group is a “swap-back” group.
3. Issue an AutoSwap SWAP command to swap from the original protected group (now
on the R2 devices) to the complement group and return access from the complement
group to the original R1 group.
4. Resynchronize SRDF so that I/O can resume on the restored primary R1 devices.
You can restart ConGroup. After starting, ConGroup monitors invalid tracks. When this
count is zero, ConGroup resumes protection.
Note: It may be prudent to use SRDF Host Component PREFRESH/PRE-RSUM to refresh R1

tracks from the updating R2 version and wait until this resynchronization is at least close
to complete. If you do not wait, reads to unsynchronized tracks on the R1 side are satisfied
by “pulling” from the R2 side over the SRDF links. This adds to response time when
accessing invalid tracks.
Defining complement device groups

A complement group is the complement of a consistency group that was swapped to the
secondary R2 devices. You can define a complement group in two ways:
◆ With a complement definition through the COMPLEMENT argument of the AutoSwap
DEFINE GROUP command.
◆ With a complement group definition in the CONFIGCA DD file.
Before defining a compliment of a consistency group, AutoSwap must be running and the
base group must be previously defined.
Note: “DEFINE GROUP ” on page 60 provides more information.
Defining complement device groups 39

Using the COMPLEMENT argument

If the AutoSwap or 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 swapped to the secondary R2 devices.
You create the complement group using the COMPLEMENT argument of the AutoSwap
DEFINE GROUP command, as follows:
DEFINE GROUP complementgroup COMPLEMENT originalgroup [options]
Where:
complementgroup
The name for the complement group. This name has the same requirements as other
consistency groups: no more than eight characters.
originalgroup
The name for the original group that was part of the AutoSwap event.
options
The optional arguments defined for the complement group. The options specified in
this statement apply to the complement group, not the original group.
The arguments for the original group and its complement do not have to be the same.
For example:
DEFINE GROUP returngroup COMPLEMENT prodgroup RETAIN SWAPCONTROL=BYDEVICE
Where:
prodgroup
The monitored group.
returngroup
The complement group.
Note: As a ConGroup AutoSwap group, prodgroup is defined with

SWAPCONTROL=BYGROUP. In the example above, the returngroup is defined with
SWAPCONTROL=BYDEVICE.
Note: You can only define the complement group 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
You can use a complement group definition created through the COMPLEMENT argument
only if the ConGroup task that executed the AutoSwap event is still running and the base
group has already been defined.
For those instances where the ConGroup task is not running, you need to create your own
complement definition in an external file. Then, specify this file in the ConGroup start up
JCL, as the CONFIGCA DD statement.
However, using the CONFIGCA DD statement in the start up JCL may generate an error if
ConGroup has not been started and the base group has not been defined prior to
executing the CONFIGCA DD statement.
In this event, you need to issue the following statement to identify the group definition:
F CG,DAS,T PARMS
Note: You can also specify the user-defined complement-definition file in the AutoSwap
JCL CONFIGCA DD statement.
Executing command-initiated swaps

When you have the consistency groups defined, you can perform swaps through
ConGroup.
To execute a command-initiated manual swap through ConGroup, you use the DAS
command, as follows:
F EMCCGRP,DAS SWAP returngroup
Where:
returngroup
The complement group.
Resynchronizing SRDF
The swap back operation using DAS SWAP or 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 Product Guide.
Defining complement device groups 41


CHAPTER 4
Relevant ConGroup Parameters
Invisible Body Tag
This chapter describes ConGroup parameters that are relevant to you, the AutoSwap user.
This chapter also provides guidance for using these ConGroup parameters.
◆ Overview................................................................................................................. 44
◆ CAX......................................................................................................................... 45
◆ CAXOPTS................................................................................................................. 45
◆ COUPLEDS_ALLOWED.............................................................................................. 54
◆ GLOBAL................................................................................................................... 55
◆ PAGEDEV_ALLOWED ................................................................................................ 55
Note: Refer to the Mainframe Enablers Message Guide for information about the error and
event messages that AutoSwap can produce.
Relevant ConGroup Parameters 43

Overview
ConGroup has five configuration parameters that are relevant for AutoSwap:
◆ CAX
◆ CAXOPTS
◆ COUPLEDS_ALLOWED
◆ GLOBAL
◆ PAGEDEV_ALLOWED
You specify these configuration parameters through the ConGroup configuration file.
CAXOPTS, COUPLEDS_ALLOWED, GLOBAL, and PAGEDEV_ALLOWED are global
configuration parameters. CAX is a consistency-group specific configuration parameter.
You can only use these parameters when defining a ConGroup AutoSwap group. You
cannot use it in the CONFIGCA DD or in the operator modify command set.
You can include a comment on a parameter line as follows:
keyword=value /* comment text */
Note: ConGroup configuration parameters are described in the Consistency Groups for
z/OS Product Guide.
Syntax Conventions
The parameter syntax shown in this chapter follow these conventions:
◆ italics = An argument.
◆ [ ] = Enclosed item is optional.
◆ item1|item2 = Item1 and item2 are alternative values. Either item1 or item2 can be
entered.
◆ Keywords appear in uppercase (for example, FROM). 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 with an underline. For example, (YES|NO) indicates 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.

CAX
Purpose
CAX specifies that you want to activate AutoSwap for a device swap group and specifies
the CAX options set you want to use for that group.
You can only use these parameters when defining a ConGroup AutoSwap group. You
cannot use it in the CONFIGCA DD or in the operator MODIFY command set.
CAX requires that the ConGroup AutoSwap Extension feature is available.
Before you use CAX, you need to define a CAX option set by using CAXOPTS.
Note: “CAXOPTS” on page 45 provides more information. The Consistency Groups for z/OS
Product Guide provides an extended description of CAX.
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. The option set name can be one through eight
characters in length.
Comments
To activate AutoSwap, you must have installed the EMC AutoSwap for z/OS Licensed
Feature Code (LFC). The Mainframe Enablers Installation and Customization Guide and the
ResourcePak Base for z/OS Product Guide discuss Licensed Feature Codes.
Example
CAX=(CAXOPTS=CASOPT1)
CAXOPTS
Purpose
CAXOPTS defines a set of ConGroup AutoSwap options and assigns a name to the set. You
can then associate that options set with a consistency group through CAX.
Note: The Consistency Groups for z/OS Product Guide describes CAX.
Syntax
CAXOPTS options_set=(cax_option[,cax_option[,...]])
CAX 45
Arguments
options_set
The name given to the set of CAXOPTS statements to use for 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 all in parentheses and
separate them with commas and no intervening spaces.
CAX options
You can use the following as CAX options (default values are underlined).
Page
Parameter and range of valid values link
[NO]AllowSystemsCountMismatch|[NO]ASCM 47
CFW=OFFVAL|NO|ALLOW 47
CROSSSYSTEMTIMEOUT=300|time_interval 48
LOSTOwnerpolicy 48
ONSWAP=[OPERATOR|HOLDIO|BACKOUT|SYSRESET(wait_code)]
[No]ROUTEMESSAGEtoowner [ALL|Warn|Error] 49
QUIESCETimeout=MIH|time_interval 49
UNPLANNEDCONDitions=INTERVENTIONREQUIRED|NOPATHS|SYNCLINKFAILURE 50
UNPLANNEDOPTIONS=FBAUSRNRDY 51
CSD=NRDY|USRNRDY 51
[NO]AllowOnlineToDevice|[NO]AllOnTo 52
[NO]AllowOnlineUndefinedDevice|[NO]ALLONUNDEFDEV 52

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 write (CFW).2 The values can be:
OFFVAL
(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.
1. If LPARs and path groups for LPARs cannot be found at validation time, the message CGRP195E is
issued. The Mainframe Enablers Message 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.
CAXOPTS 47
NO
If CFW is active on any devices in the consistency group, then validation of the
consistency group fails. ConGroup AutoSwap processing is disabled.
ALLOW
CFW is checked during ConGroup validation processing. However, no change in a

device’s CFW state is performed. If a ConGroup AutoSwap swap event occurs, then
jobs using CFW functionality 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|HOLDIO|BACKOUT|SYSRESET(wait_code)]
Specifies the action for ConGroup AutoSwap if all communication with the owner or
controlling system is lost during the swap process. Loss occurs when the owner
crashes or when SRDF and channel paths to the consistency group devices become
disconnected. LOSTOwnerpolicy affects the system behavior only during a swap
process. LOSTOwnerpolicy can stop different hosts from accessing different views of
the same data.
Note: The ConGroup GLOBAL configuration parameter controls which smfid is the
owner. The Consistency Groups for z/OS Product Guide provides more information.
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 TAKEOVERasowner command.
In some circumstances, the owner could back out of the swap without the owner being
able to contact the non-owners or the non-owners being able to contact the owner.
You can abbreviate LOSTOwnerpolicy as LOP.
OPERATOR
(Default) Specifies that the operator should be asked what LOSTOwnerpolicy to

execute.
OPERATOR is intended for automatic operations environments. AutoSwap issues
the WTOR message:
ESWP485A (rrrrr) Reply HOLDIO, BACKOUT, SYSRESET, TAKEOVERasowner
HOLDIO, BACKOUT, SYSRESET are values documented in this section.

TAKEOVERasowner requests that the current LPAR assume ownership.
You must be careful to ensure that the owner is really dead and not just isolated
before using TAKEOVERasowner.
Note: Refer to the Mainframe Enablers Message Guide for error message details.

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 occur 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. (This alias
is ROUTEMSG.)
The keywords are:
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.
If you use ROUTEMESSAGEtoowner with no keywords, ConGroup uses the ERROR

keyword as the default. That is, only E (error) messages is 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.
CAXOPTS 49
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=INTERVENTIONREQUIRED
UNPLANCOND=NOPATHS
UNPLANCOND=SYNCLINKFAILURE
UNPLANCOND=INTERVENTIONREQUIRED NOPATHS SYNCLINKFAILURE
IMPORTANT
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.
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 when a paging device generates an intervention (intreq) condition. 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 SYSCLINKFAILURE, 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.
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.
Note: Use of SYNCLINKFAILURE requires Enginuity patch 36705.
IMPORTANT
Use SYNCLINKFAILURE with caution. SYNCLINKFAILURE is not sensitive to
Concurrent SRDF or SRDF/Star configurations.
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 state is set during AutoSwap checkpoint 2 processing in order to
prevent any further access to the R1 device.
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 during the AutoSwap event.
USRNRDY
Sets the R1 devices that were swapped to User-Not-Ready state during the
AutoSwap event.
Note: Currently, high priority processing supports the CSD=USRNRDY option from
MFE 7.5 and some levels at MFE 7.3 and 7.4. Where an AutoSwap host with High
Priority devices without this support is detected, message CGRS642W will be
displayed and CSD=NRDY will be for High Priority devices instead.
CAXOPTS 51
[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.
“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.
Example
In this example the ConGroup AutoSwap Extension is required. If ConGroup AutoSwap is
not operating or the consistency group device group fails validation, ConGroup does not
enable the consistency group.
CAX=(CAXOPTS=CASOPT1)
CAXOPTS CASOPT1=(AUTOCOND=NOPATHS,CFW=OFFVAL,LOSTO
ONSWAP=SYSRESET(0FF0),ALLOWSYSTEMSCOUNTMISMATCH)
The CAX statement declared that CAXOPT1 specifies the 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 device group that the failure
event actions begin.
◆ CFW=OFFVAL turns off 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 owner system.
Other systems that can no longer communicate with the owner system enter a
non-restartable wait state 0FF0.
◆ ALLOWSYSTEMSCOUNTMISMATCH 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.
CAXOPTS 53
COUPLEDS_ALLOWED
Purpose
COUPLEDS_ALLOWED allows you to add volumes with couple datasets to a consistency
group, or explicitly prevent addition of volumes with couple datasets to the consistency
group.
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 the ConGroup consistency group specific configuration parameter
DEVICE_LIST=ALL and also specify COUPLEDS_ALLOWED=YES, then volumes with
couple datasets are NOT added to the consistency group.
Note: The Consistency Groups for z/OS Product Guide describes DEVICE_LIST.
Comments
◆ There are seven types of couple datasets:
• SYSPLEX
• CFRM
• WLM
• OMVS
• ARM
• SFM
• LOGR
AutoSwap only supports LOGR 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 contain the information necessary to restart CICS.
◆ If you specify DEVICE_LIST=ALL, then volumes with couple datasets are not added to
the consistency group unless you take one of the following steps:
– Identify the couple devices for specific inclusion in the group by using
DEVICE_LIST=device.
– Specify COUPLEDS_ALLOWED=YES.
Example
COUPLEDS_ALLOWED=YES

GLOBAL
Purpose
GLOBAL has one argument, OWNER. OWNER specifies the SMF ID of the LPAR that controls
the consistency group and the ConGroup AutoSwap functions. If a failure occurs that
results in all communication being lost between the primary and secondary sites, the
system specified in OWNER proceeds while the other site halts.
Syntax
GLOBAL=(OWNER=SMFid)
Argument
OWNER=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 groups.
PAGEDEV_ALLOWED
Purpose
PAGEDEV_ALLOWED allows you to add volumes with page datasets to a consistency group,
or explicitly prevent addition of volumes with page datasets to the consistency group.
Syntax
PAGEDEV_ALLOWED=NO|YES
Arguments
NO
(Default) Prohibits volumes with page datasets to be explicitly added to the

consistency group.
YES
Allows volumes with page datasets to be explicitly added to the consistency group.
Comments
If you specify the ConGroup, consistency group specific configuration parameter,
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.
Note: The Consistency Groups for z/OS Product Guide describes DEVICE_LIST.
Example
PAGEDEV_ALLOWED=YES
GLOBAL 55

CHAPTER 5
Command Reference
Invisible Body Tag
This chapter provides guidance for using AutoSwap commands and arguments.
◆ Overview................................................................................................................. 58
◆ DEFINE GROUP ....................................................................................................... 60
◆ DELETE GROUP ....................................................................................................... 71
◆ DISPLAY ................................................................................................................. 71
◆ SET ........................................................................................................................ 75
◆ SETSWAP ................................................................................................................ 80
◆ SWAP ..................................................................................................................... 84
◆ VALIDATE GROUP .................................................................................................... 86
Note: The Mainframe Enablers Message Guide provides more information about the error
and event messages that AutoSwap can produce.
Command Reference 57
Command Reference
Overview
The following sections provide reference pages for the following AutoSwap commands:
◆ DEFINE GROUP
◆ DELETE GROUP
◆ DISPLAY
◆ SET
◆ SETSWAP
◆ SWAP
◆ VALIDATE GROUP
You can enter these AutoSwap operator commands through the ConGroup operator
console.
Note: ConGroup commands are described in the Consistency Groups for z/OS Product
Guide.
SAF command verification

Starting with Version 7.4, AutoSwap now verifies all operator commands through the SAF
interface. This SAF verification is also done for other EMC products, such as ResourcePak
Base (EMCSCF) and ConGroup (CG) command interfaces (F SCF,DAS, and F CG,DAS).
The AutoSwap commands require UPDATE access to the resource, with the exception of
DISPLAY, which only requires READ access to the resource.
Note: There is no SAF checking for commands that are read from the startup configuration
file (e.g. CONFIGCA).
To change the automatic verification, refer to the Mainframe Enablers Installation and
Configuration Guide for instructions on how to customize the security interface.
The resource information includes the following:
Resource Name EMC.ADMIN.CMD.AUTOSWAP[.<command name>]
Class XFACILIT
Attribute Update for commands that affect AutoSwap, or Read for commands
that are display only.
Where:
<command name>
One of the operator enterable AutoSwap commands.

Command Reference
Syntax Conventions
The parameter syntax shown in this chapter follow these conventions:
◆ italics = An argument.
◆ [ ] = Enclosed item is optional.
◆ item1|item2 = Item1 and item2 are alternative values. Either item1 or item2 can be
entered.
◆ Keywords appear in uppercase (for example, FROM). 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 with an underline. For example, (YES|NO) indicates 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.
Multiple subchannel device sets

AutoSwap allows target (TO) devices in a AutoSwap swap group to be placed in an
alternate subchannel set to provide device addressing constraint relief.
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
dddd
The 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. AutoSwap allows 3390D
(secondary) devices to be defined as the target (TO) devices in an AutoSwap group.
AutoSwap source (FROM) devices are always in the base, or active, subchannel set.
Overview 59
Command Reference
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 AutoSwap 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.
DEFINE GROUP
Purpose
Use DEFINE GROUP to define a set of devices to be monitored or swapped as a group. Use
of this command is not recommended because it creates a group that is NOT managed by
ConGroup. These groups have a significant limitation. Because they are not
ConGroup-managed, they have no unplanned swap mode.
Syntax
DEFine GROUP|GRP groupname [arguments][SDAS options]
Parameters
groupname
The name of the group to which you are assigning devices. The groupname can be
from 1 to 8 alphanumeric and special characters.

Command Reference
Arguments
Define Group arguments include:
Page
Parameter and range of valid values link
EXClude CCUU|CUU=(ccuu_lower[-ccuu_upper]| 61
[ccuu_lower[-ccuu_upper][,ccuu_lower[-ccuu_upper]]
)
EXClude VOLumes=(volser|volser_mask| 61
volser|volser_mask[,volser|volser_mask])
INClude VOLumes=(volser|volser_mask| 61
volser|volser_mask[,volser|volser_mask])
INClude CCUU|CUU=(ccuu_lower[-ccuu_upper]| 62
[ccuu_lower[-ccuu_upper][,ccuu_lower[-ccuu_upper]])
RDFGROUP|RDFGRP=ragrp#|CONFIGUREDDEVICE|CONF|CONFDEV 62
REPlace 62
Descriptions
EXClude CCUU|CUU=
(
ccuu_lower[-ccuu_upper]|
[ccuu_lower[-ccuu_upper][,ccuu_lower[-ccuu_upper]]
)
Exclude cuu devices or a range of cuu devices.
EXClude VOLumes=
(
volser|volser_mask|
volser|volser_mask[,volser|volser_mask]
)
Exclude a volser or volser mask.
In volser_mask, the mask characters are *, % ,?, where:
* Represents any number of characters (including a null string).
% or ? Matches a single character.
Note: If a volser contains special characters that conflict with the masking characters
(*, %, ?), the volser must be contained in quotes. For example: VOLUMES='VOL%01'
INClude VOLumes=
(
volser|volser_mask|
volser|volser_mask[,volser|volser_mask]
)
The INCLUDE argument only specifies volumes which are on the R1 side of an SRDF
R1/R2 set. You do not have to identify the associated R2 device(s) to AutoSwap. This
identification is automatic. By the time you issue the DEFINE GROUP command,
DEFINE GROUP 61
Command Reference
EMCSCF has performed a roll call and created an internal list of z/OS device
addresses, their matching Symmetrix ID and device numbers, and has a knowledge of
the R1/R2 relationships.
In volser_mask, the mask characters are *, % ,?, where:
* Represents any number of characters
(including a null string).
Note: If a volser contains special characters that conflict with the masking characters
(*, %, ?), the volser must be contained in quotes. For example: VOLUMES='VOL%01'
INClude CCUU|CUU=
(
ccuu_lower[-ccuu_upper]|
ccuu_lower[-ccuu_upper][,ccuu_lower[-ccuu_upper]]
)
Include cuu devices or a range of cuu devices.
RDFGROUP|RDFGRP=ragrp#|CONFIGUREDDEVICE|CONF|CONFDEV
This argument is used for concurrent SRDF devices, where the ragrp# indicates which
R2 to swap to. CONFIGUREDDEVICE is used if only 1 of the 2 concurrent R2 SRDF
devices is defined to the host. If the ragrp# is used, it must be valid for all concurrent
RDF devices defined in the group.
REPlace
Replace groups that have already been defined. This argument does not replace
groups that are active.
Note: An “active” group is one that has been validated.
You should use REPLACE when a consistency group’s content has changed. When a
group is validated, AutoSwap communicates the group definition to all other LPARs,
thus achieving a global knowledge of group membership.
If a group with this group name is already active (validated and not subsequently
deleted), the validation with the new group definition fails.
You may change the definition of active groups using DELETE followed by DEFINE
GROUP.

Command Reference
SDAS options
Separate each SDAS option with a space.
Note: If you are going to a new line, begin the line with a continuation character.
Continuations are indicated with a '-' after the last value on a line, for example:
...
CFW=RES PREVAL PROCCNT=3 RETAIN REPLACE
...
The SDAS options are (default values are underlined):
Page
SDAS options Link
[NO]ALLOWCOUPLEDATASETS 64
[NO]AllowConcurrentCopy|[NO]ACC 64
[NO]AllowOnlineToDevice|[NO]AllOnTo 65
[NO]AllowOnlineUndefinedDevice|[NO]ALLONUNDEFDEV 65
[NO]AllowSnapSession|[NO]ALLSNAP 66
[NO]AllowSystemsCountMismatch|[NO]ASCM 66
CFW=OFFVAL[IDATION]|NO|OFF|RES[UME]|ALLOW 67
CHANGESOURCEdevice|CSD=[NRDY|NONRDY|NRDYAFTER | 67
USRNRDY] [NOVOLP
|VOLUMEPrefix=volser_pref|VOLP=volser_pref]
CROSSSYSTEMTIMEOUT|XSYSTO=[300|timeinterval] 67
FORCE=[NOLINK|LOSTSYStem] 68
MAXRC=maxrc 68
NOPREVALidate|NOPV|PREVALidate|PV 68
[PROCESSCOUNT=|PCNT=|PROCCNT=]64|process_count 68
[QUIESCETimeout=|QTimeo=] [MIH|number of seconds] 68

Note: Default value is 15.
RETAIN=SWAPCmplt|NORETAIN 69
Notes:
Default value SWAPCmplt for a compliment group.
Default value NORETRAIN for a normal consistency group.
[No]ROUTEMESSAGEtoowner [ALL|Warn|Error] 69
NOSWAPimmediate|SWAPimmediate 69
ValidateINTerval=timeinseconds 69
NOVOLserCHeck|VOLserCHeck 69
DEFINE GROUP 63
Command Reference
Descriptions
[NO]ALLOWCOUPLEDATASETS
Allows (or disallows with NOALLOWCOUPLEDATASETS) devices to be swapped where
they contain couple datasets.
Exercise caution when specifying the ALLOWCOUPLEDATASETS option. The only couple
datasets that should be processed are LOGR.
When defined in a CAX group, the ALLOWCOUPLEDATASETS specification is made
through the ConGroup COUPLEDS_ALLOWED specification. This is a ConGroup
argument specified in the definition of the consistency group.
• To set ALLOWCOUPLEDATASETS, use the ConGroup COUPLEDS_ALLOWED=YES
specification.
• To set the AutoSwap NOALLOWCOUPLEDATASETS option, use the ConGroup
COUPLEDS_ALLOWED=NO specification.
NOALLOWCOUPLEDATASETS is the default.
Note: The Consistency Groups Product Guide discusses the restrictions on couple
datasets specification.
[NO]AllowConcurrentCopy|[NO]ACC
Allows or prohibits (default) swaps of devices with Concurrent Copy sessions.
Note: Concurrent Copy (CC) and Snap Sessions
Note: Both CC and Snap create sessions in which a local point-in-time-copy of data is
created. The location of this data depends on whether the data has been updated or
not. This mapping is kept in the local Symmetrix system. Remote Symmetrix systems
(at the other end of SRDF links) have no knowledge of these sessions. If you swap
devices involved in CC or Snap sessions, the sessions are lost.
Note: If you do not want to lose of these sessions, EMC suggests you don’t place these
sessions on swappable devices. AutoSwap can not prevent the use of CC or Snap
sessions. But AutoSwap can identify their existence, and may be used to control the
swap environment.
Note: You may use NOACC and NOALLSNAP to identify devices with active CC or Snap
sessions. If you specify NOACC or NOALLSNAP, a validation fails on devices with active
CC or SNAP sessions.This can be useful in a planned swap situation. If you intend
allowing unplanned swaps, then you can use ACC and ALLSNAP to ensure that
accidental use of CC or Snap does not interfere with unplanned swapping. You can use
VALIDATE to detect and report on the existence of CC and Snap sessions.

Command Reference
[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.
“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.
DEFINE GROUP 65
Command Reference
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.
[NO]AllowSnapSession|[NO]ALLSNAP
Allows or prohibits (default) swaps of devices with snap sessions.
[NO]AllowSystemsCountMismatch|[NO]ASCM
Specifies whether or not to bypass the requirement that all other LPARs with an
established path group to the device belonging to the consistency group have EMCSCF
and ConGroup running.
During validation processing, the number of participating LPARS and path groups is
taken. Then, at swap time, the number of participating LPARS and path groups is taken
again.
If you specify AllowSystemsCountMismatch, the LPAR count at swap time does not
have to match the number of path groups for the device established at validation
time.1 The swap can continue.
Note: This option is recommended when you are using AutoSwap to protect against
failure events or unplanned outages. This is because loss of communication with one
or more LPARs may be a part of the failure scenario. This should not disable AutoSwap.
If you specify NoAllowSystemsCountMismatch, the LPAR count at swap time must be

equal to or greater than the number of participating systems not currently
participating 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.
Note: This option is recommended for use in planned swaps. If your swap is planned,
and not the result of failure, the number of LPARs involved should not change. If it
does, there either has been a failure or an operational error.
EMC recommends, where you specify SWAPCONTROL=BYRANGE or BYGROUP, that you

use (or default to) AllowSystemsCountMismatch and validate the group before
performing a planned swap. This is because AutoSwap optimizes the validation
processing in this instance.
If you specify NoAllowSystemsCountMismatch, devices must be individually validated
across all hosts to be certain that all hosts with paths to the devices correctly validate
the device. In addition, a message is output for each device mismatch with an
associated CGRS19I message.
1. If LPARs and pathgroups for LPARs cannot be found at validation time, the message CGRS195I
(ESWP195I for AutoSwap) is issued. Refer to the Mainframe Enablers Message Guide.

Command Reference
Note: The Mainframe Enablers Messages and Codes Guide provides more information
about messages you can receive.
CFW=OFFVAL[IDATION]|NO|OFF|RES[UME]|ALLOW
Controls cache fast write.

OFFVALidation Turn cache fast write off during validation. (Default)
NO Prohibits swapping if cache fast write is active.
OFF Turn off cache fast write.

RES[UME] Turn cache fast write on after the swap on the swap to
control unit.
ALLOW Bypass check cache fast write status.
CHANGESOURCEdevice|CSD=[NRDY|NONRDY|NRDYAFTER] [NOVOLP
|VOLUMEPrefix=volser_pref|VOLP=volser_pref]
Where:
NRDY Sets the source device to NRDY status during the swap (at
checkpoint 2) to prevent access to the source device.
USRNRDY Sets the source device to USR-NRDY status during the swap
(at checkpoint 2) to prevent access to the source device.
NONRDY
Leaves the device in a RDY status upon the swap.
NRDYAFTER
Changes the device to NRDY following checkpoint 4 at the
successful completion of the swap.
VOLUMEPrefix Changes the volser prefix of the source device. The
VOLUMEPrefix must be one or two-characters in length. If
NRDY is specified then it will be changed to NRDYAFTER.
NOVOLP (Default) No volume prefix.
VOLUMEPrefix= Specifies the volume prefix of the source device.

volser_pref
CROSSSYSTEMTIMEOUT|XSYSTO=[300|timeinterval]
Specifies the cross host timeout value. This is the time AutoSwap waits for
acknowledgement from other AutoSwap instances on other hosts. The default timeout
interval is 300 seconds.
DEFINE GROUP 67
Command Reference
FORCE=[NOLINK|LOSTSYStem]
NOLINK
FORCE allows a swap to be performed in extreme circumstances. NOLINK allows

the swap to occur if the FROM device cannot be accessed by way of the local or
remote link. This option is not merged with the global defaults options.
LOSTSYStem
You use this argument to define the action to be taken when an LPAR disappears
during swap processing. Before you swap, validation counts the number of running
LPARs. During swap processing, AutoSwap uses multiple checkpoints to
synchronize the activity between all the LPARs involved in the swap.
If an LPAR does not return status during checkpoint processing and you do not
specify FORCE=LOSTSYS, the swap aborts.
This option is complementary to the ALLOWSYSTEMSCOUNTMISMATCH option in
that the ALLOWSYSTEMSCOUNTMISMATCH has meaning during the validation for
path comparison processing and the FORCE=LOSTSYSTEM has meaning during the
swap processing. Either, both, or neither, option can be specified based on site
requirements.
The FORCE options are not merged with the global options.
MAXRC=maxrc
Specifies the MAXIMUMALLOWED return code.
NOPREVALidate|NOPV|PREVALidate|PV
NOPREVALidate|NOPV
(Default) Prohibit pre-validation of the group. This allows AutoSwap to validate the
group fully in the event of a manual swap.
PREVALidate|PV
Perform the first seven steps of the swap process, allowing the full swap to process
in a much shorter time.
[PROCESSCOUNT=|PCNT=|PROCCNT=]64|process_count
Specifies the number of swaps processed concurrently within a group. The default
PROCESSCOUNT is 64. Zero sets the maximum process count.
Note: This value cannot be changed with ConGroup CAX. ConGroup CAX always uses a
PROCESSCOUNT of zero.
[QUIESCETimeout=|QTimeo=] [MIH|number of seconds]
Specifies the quiescent period (in seconds). The number of seconds can be between
zero (0) and 300. The default value is 15 seconds. A value of zero is equivalent to
specifying MIH (missing interrupt handler). If the resolved timeout value is less than
15 seconds, AutoSwap uses 15 seconds.

Command Reference
RETAIN=SWAPCmplt|NORETAIN
RETAIN=SWAPCmplt
(Default if the group is a complement group) RETAIN=SWPCmplt allows a group to

remain active until all devices in the group have been swapped successfully. You
cannot specify RETAIN=SWAPCmplt to ConGroup CAX.
NORETAIN
(Default if the group is a normal consistency group) NORETAIN prevents a group, its
device definitions and AutoSwap options from being kept.
[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. (This alias
is ROUTEMSG.)
The keywords are:
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.
If you use [No]ROUTEMESSAGEtoowner with no keywords, AutoSwap uses the ERROR

keyword as the default. That is, only E (error) messages is 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
NOSWAPimmediate|SWAPimmediate
(Default.) NOSWAPimmediate prohibits swapping the UCBs in a group immediately
after the group has been defined and validated.
SWAPimmediate Swap the UCBs in a group as soon as the group is defined and
validated.
ValidateINTerval=timeinseconds
Specifies validating a group periodically as the server is running.
NOVOLserCHeck|VOLserCHeck
(Default) NOVOLSERCHECK instructs AutoSwap not to perform, volume serial
verification during the device validation; that is, this argument ensures that the FROM
and TO device volume serials are equivalent.
VOLSERCHECK instructs AutoSwap to perform volume serial verification during the
device validation; that is, this argument ensures that the FROM and TO device volume
serials are equivalent.
DEFINE GROUP 69
Command Reference
In the synchronous R1R2 environment this test is not required as the Symmetrix
system ensures that the volumes serials are equal as the devices are always
equivalent.
Note: The arguments for the original group and its complement do not have to be the
same.
Comments
◆ The DEFINE GROUP command has a special COMPLEMENT argument that allows you to
define a complement group to any currently defined swap group. The group defined
by COMPLEMENT is a set of devices to which normal operations is restored after an
outage.
The format for defining a complement group with DEFINE GROUP and the
COMPLEMENT argument is as follows:
DEFINE GROUP complementgroup COMPLEMENT originalgroup [SDAS options]
Where:
complementgroup
The name for the complement group. The groupname can be from one (1) to eight
(8) alphanumeric and special characters.
originalgroup
The name of the original group. This name also has the same requirements as that
of any consistency group: no more than eight (8) characters.
SDAS options
The optional SDAS options defined for the complement group. The options
specified in this statement apply to the complement group, not the original group.
The arguments for the original group and its complement do not have to be the
same. For example:
DEFINE GRP swapback COMPLEMENT origgrp AO ASCM CFW=RES
Note: Chapter 3 in this guide and to the Consistency Groups for z/OS Product Guide
provide more information.
◆ To add documentation to your configuration file, you can add comments to

configuration parameter lines. The format for comments is:
keyword=value /* comment text */
This syntax applies to any parameter in the configuration file.
Example
None.

Command Reference
DELETE GROUP
Purpose
Use DELETE GROUP to delete groups no longer needed to monitor devices. Also use
DELETE GROUP to delete an active group that cannot be replaced with the REPLACE
command.
Syntax
DELete GROUP|GRP groupname|groupname_mask
Parameters
groupname
The name of the group. The groupname can be from one (1) to eight (8) alpha-numeric
and special characters.
groupname_mask
The mask for the groupname.
In groupname_mask, the mask characters are *, % ,?, where:
* Represents any number of characters (including a null
string).
Example
The following example deletes the group PROD:
DEL GRP PROD
DISPLAY
This section describes the DISPLAY commands. The DISPLAY commands are:
◆ DISPLAY GROUP
◆ DISPLAY SDASOPTIONS
◆ DISPLAY OPTIONS
◆ DISPLAY GLOBALOPTIONS
◆ DISPLAY STARTPARMS
DISPLAY GROUP
Purpose
Use DISPLAY GROUP to display groups that have been successfully defined.
Syntax
DISPLAY GROUP|GRP groupname|groupname_mask [arguments]
DELETE GROUP 71
Command Reference
Parameters
groupname
The name of the group. The groupname can be from one (1) to eight (8) alphanumeric
groupname_mask
In groupname_mask, the mask characters are *, % ,?, where:
Arguments
Optional arguments that can be any of the following:
SDASOPTions|SOPT|OPTIONS|OPT
Displays the AutoSwap options used to define the group, or the AutoSwap default
values. For example:
DIS GRP PROD OPT
SUMmary|[DETails[sort options][filter options]]

Displays either the high level (SUM) view of the group. For example:
DIS GRP PROD SUM
Or displays the detail level (DET) view of the group. For example:
DIS GRP PROD DETAILS
sort options
[SORT[PID|PHASE|VOLSER|FROMDEVN|TODEVN|FROMSYMD|TOSYMD|
NO][ASCENDING|DESCENDING]]
Sorts the device pairs in the detail level display of a group by the specified column.
The NO option produces an unsorted display. The default sort option is PID
ASCENDING.
For example:
DIS GRP PROD DET SORT VOLSER ASCENDING
filter options
[FILTER FROMDEVN(xxxx-yyyy)|TODEVN(xxxx-yyyy)|
FROMSYMDEV(xxxx-yyyy)[,CTRLID(xxxxxxxxxxxx)]|
TOSYMDEV(xxxx-yyyy)[,CTRLID(xxxxxxxxxxxx)]|
PID(xxxxx-yyyyy)|VOLSER(mask)|CTRLID(xxxxxxxxxxxx)|
ALTSS|BASESS]
Filters the device pairs in the detail level display of a group, showing only the
groups that match on the specified value in the specified column.
FILTER ALTSS displays only the device pairs with TO devices that are in the alternate
subchannel set.

Command Reference
FILTER BASESS displays only the device pairs with TO devices that are in the active
base subchannel set.
For example:
DIS GRP PROD DET FILT FROMSYMD(009C-009F)
DIAG
Displays diagnostic information about a group. For example:
DIS GRP PROD DIAG
FIND findstring
Displays GROUPs containing findstring.
EXCLUDE findstring
Prohibits displaying GROUPs containing findstring.
For a DIS GRP DET command, the FIND and EXCLUDE arguments apply to the device pair
entries. The findstring applies to both lines.
Note: With the DISPLAY GROUP command, the OPTIONS argument works similarly to
SDASOPTIONS.
Example
The following example displays only the summary values for an AutoSwap group:
DIS GRP * DET F TOTAL
DISPLAY SDASOPTIONS
Purpose
Use DISPLAY SDASOPTIONS to display the default AutoSwap options in effect globally.
These can be changed by DEFINE GROUP commands. Note that use of this command is not
recommended because it operates outside of ConGroup.
Syntax
DISPLAY SDASOPTions|SOPT
Example
The following example displays all AutoSwap options in effect:
DISPLAY SOPT
DISPLAY OPTIONS
Purpose
Use DISPLAY OPTIONS to display all relevant options (SDASOPT, GOPT, and SPARMS) in a
single display.
Syntax
DISPLAY OPTions
DISPLAY 73
Command Reference
Example
The following example results in all relevant option displays (SDASOPT, GOPT, and
SPARMS) being appended and presented in a single display.
DISPLAY OPT
DISPLAY GLOBALOPTIONS
Purpose
Use DISPLAY GLOBALOPTIONS to display the global debugging and diagnostics in use.
Syntax
DISPLAY GLOBALOPTions|GOPT
Example
The following example displays the current global debugging and diagnostics:
DISPLAY GOPT
DISPLAY STARTPARMS
Purpose
Use DISPLAY STARTPARMS to display the current subsystem (LPAR) name.
Syntax
DISPLAY STARTPARMS|SPARMS
Example
The following example displays the current LPAR name:
DISPLAY SPARMS
DISPLAY examples
Consider the following examples:
◆ To find all devices marked as invalid to all groups, enter:
DISPLAY GRP * DET F INVALID
◆ To find all devices with UGL* volsers, but display those devices which are also invalid,
enter:
DISPLAY GRP * DET F UGL*INVALID
◆ To find all devices with UGL* volsers, but display those that are valid, enter:
DISPLAY GRP * DET F UGL*VALID
◆ To find all devices with UGL* volsers, but display those that are not invalid, enter:
DISPLAY GRP * DET X UGL*VALID
◆ To display all devices for PL* groups where they are not volser UGL*, enter:

Command Reference
DISPLAY GRP PL* DET X UGL*
◆ To display all devices for PL* groups where they are not volser U????1, enter:
DISPLAY GRP PL* DET X U????1
◆ To display all devices where it is an R1>R2 pair, enter:

DISPLAY GRP * DET F R1*R2
◆ To display all devices where it is an R2>R1 pair, enter:

DISPLAY GRP * DET F R2*R1
◆ To display all devices where it is an R2>R1 pair and a swap is in progress, enter:
DISPLAY GRP * DET F R2*SWAP*R1
◆ To display all devices where the volser is not resolved, enter:

DISPLAY GRP * DET F '??????'
For a DISPLAY GRP SUMM command, the FIND and EXCLUDE arguments apply to the group
entry display.
Consider the following examples:
◆ To display all groups which are idle, enter:
DISPLAY GRP * F IDLE
◆ Display all groups which are swapping, enter:

DISPLAY GRP * F SWAP
◆ Display all groups which are not swapping, enter:

DISPLAY GRP * X SWAP
For a DISPLAY GRP SOPT command, the FIND and EXCLUDE applies to the options for the
group.
SET
This section describes the SET commands. The SET commands are:
◆ SET SDASOPTIONS
◆ SET PARMS
◆ SET [NO]DEBUG
◆ SET [NO]CAPS
◆ SET VERBOSE
◆ SET NOVERBOSE
◆ SET MAXLINECOUNT
◆ SET DEFAULTLINECOUNT
SET 75
Command Reference
SET SDASOPTIONS
Purpose
SET SDASOPTIONS sets the SDAS (AutoSwap) options globally for groups or for individual
swaps. The effect differs depending on whether you are setting options globally or within
a swap.
Setting options globally

AutoSwap merges any options you define with SET SDASOPTIONS with any options
previously defined with the DEFINE GROUP command. Options you specify with DEFINE
GROUP override options requested in the SET SDASOPTIONS command.
Setting options within a swap

AutoSwap merges options you define within a swap (with the SWAP command) with those
specified in the previous SET SDASOPTIONS command. The SWAP command overrides the
previous SET SDASOPTIONS command.
Note: You can use SET SDASOPTIONS in CONFIGCA DD init deck, as well. See the examples
below for more detail.
Syntax
seT SDASOPTions|SOPT SDAS_options
Parameters
SDAS_options
Are one or more options you want to assign. The SDAS (AutoSwap) options are those
listed as SDAS (AutoSwap) options under “DEFINE GROUP ” on page 60. However, you
cannot use the four DEFINE GROUP arguments, EXCLUDE, INClude, RDFGRP, or
REPLACE as SDAS (AutoSwap) options with SET SDASOPTIONS.
Note: “SDAS options” on page 63 describes the SDAS options.
Example
SET SOPT CFW=RES

0000CFW=RES PREVAL PROCCNT=3 RETAIN REPLACE
DEFINE GRP PROD2 INC CUU=(B66C-B66F,A06A) RDFGRP=0 REPLACE AO ASCM
DEFINE GRP PROD3 INC VOL=(UGL*,UGM*) PV NOAO NOASCM

Command Reference
SET PARMS
Purpose
Use SET PARMS to reprocess the commands specified in the CONFIGCA DD. You can use
this to bring in groups that have been deleted because of a swap or an operator
command.
Syntax
seT PARMS
Example
You can use the following command to reprocess parameters in the CONFIGCA DD:
F EMCCGRP,DAS T PARMS
SET [NO]DEBUG
Purpose
Use SET [NO]DEBUG to enable or disable debugging.
Syntax
seT DEBUG|NODEBUG
Parameters
DEBUG
Enables debugging information to be created. You should only set DEBUG if you are
instructed to do so by EMC Customer Support.
NODEBUG
Disables debugging information from being created.
Example
The following example disables debugging:
T NODEBUG
SET [NO]CAPS
Purpose
Use SET [NO]CAPS to whether AutoSwap logs displays in mixed or upper case. NOCAPS is
the default. That is, if you do not use this command, AutoSwap logs displays in mixed
case.
Syntax
seT CAPS|NOCAPS
SET 77
Command Reference
Example
The following example specifies that AutoSwap log displays in upper case:
T CAPS
SET VERBOSE
Purpose
Use SET VERBOSE to establish the level of detail (and indirectly the number) of messages
produced. The level can be set from zero (0) to 255, where zero is the least (terse) and 255
is the most (verbose). SET VERBOSE is generally only used at the request of EMC support
staff.
Syntax
seT VERBose verbose_level
Parameter
verbose_level
A number between zero (0) and 255. Refer to Table 1 for standard values and their
meanings.
Table 1 Verbose levels
Verbose Level Meaning
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 pref238I indicates that a device is available for AutoSwap.
Message pref238I 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.
SET NOVERBOSE
Purpose
Use SET NOVERBOSE to remove verbose-level messaging. This is the recommended
setting unless requested by the EMC staff.
Syntax
seT NOVERBose

Command Reference
SET MAXLINECOUNT
Purpose
Use SET MAXLINECOUNT to specify the global maximum number of lines produced on long
displays. The default value for this command is 1000. The maximum value you can use is
99999.
The DEFAULTLINECOUNT value cannot exceed the MAXLINECOUNT value. Thus, you need to
examine the current MAXLINECOUNT value before you change the DEFAULTLINECOUNT
value.
Note: “Long Displays and Linecount Values” on page 89 provides more information.
Syntax
seT MAXLinecount linecount
Parameter
linecount
A numeric value that specifies the maximum number of lines to be produced on long
displays. You do not have to specify a line count value if you choose to use the default.
SET DEFAULTLINECOUNT
Purpose
Use SET DEFAULTLINECOUNT to specify the default number of lines for displays. The
default value for this command is 100. The maximum value you can use is 99999.
The DEFAULTLINECOUNT value cannot exceed the MAXLINECOUNT value. Thus, you need to
examine the current MAXLINECOUNT value before you change the DEFAULTLINECOUNT
value.
Note: Appendix Appendix B provides more information.
Syntax
seT DEFAULTLinecount linecount
Parameter
linecount
A numeric value that specifies the default number of lines to be produced on long
displays.
SET 79
Command Reference
SETSWAP
Purpose
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.
You can abbreviate SETSWAP as TS.
Note: Using the SETSWAP DISABLE command does not affect the trip operation of a
consistency group. Only the swap processing is disabled.
Syntax
seTSwap GROUP|GRP groupname ENAble|DISable parameter[,parameter[,...]]
Where:
parameter equals any of the following:

[CROSSSYSTEM|LocalSYStem]
[CoMmanDTimeout timeout]
[SUMmary|DETail]
[RUN|NORUN]
Parameters
CROSSSYSTEM
(Default) Process the request across all AutoSwap systems.
Note: You can abbreviate CROSSSYSTEM as XSYS.
LocalSYStem
Only process the request on the local (command issuing) system.
This prevents a planned or unplanned swap from being initiated on this system. Other
AutoSwap systems that remain ENABLEd still allows the swap to be initiated. In this
instance, the DISABLEd systems also participate in the swap. However, where high
priority devices existed in the group prior to being DISABLEd these are no longer
performed at a high priority until the group is ENABLEd.
Note: You can abbreviate LOCALSYSTEM as LSYS.
CoMmanDTimeout
Cross system communication timeout value in seconds. The default value is 60
seconds. If the command is not completed in this period of time then command
completion is forced.
Note: You can abbreviate COMMANDTIMEOUT as CMDT.

Command Reference
SUMmary
(Default) If the command completes successfully then only generate output showing
the status change of the group.
If an error condition occurs then additionally generate output showing the hosts that
failed and the reason for the failure.
DETail
Output a summary line and a host line to show the status change for that host.
Note: You can abbreviate DETAIL as DET.
DISable
DISABLE a group or groups for SWAP processing. A message is displayed every 30
seconds to indicate that the group remains DISABLEd. The DISABLE period should be
kept to a minimum as no swap processing, either planned or unplanned, is allowed
during this period.
CAX devices in the affected groups become AutoPend in the DISPLAY GROUP DETAIL
output.
If an error condition occurs during DISABLE processing the group is returned to its
original state through backout processing. The original state was likely ENABLEd;
however, if the original state was DISABLEd, it remains DISABLEd. An additional
MLWTO is issued to display the status of the backout process.
ENAble
ENABLE a group or groups for SWAP processing. ENABLE processing results in a basic
validation of the group.
GROUP groupname
The groupname may be any active AutoSwap group and may contain masking
characters (* or %). For example GROUP * includes all AutoSwap groups.
Only active groups are applicable. If a group is marked ’inactive,’ then it is not
processed.
Note: You can abbreviate GROUP as GRP.
RUN
Check to see if the command is applicable and perform the required processing.
NORUN
Only check to see if the command is applicable. No active processing is performed.
Comments
None.
SETSWAP 81
Command Reference
Examples:
1. The following example1 disables and then enables a group.
F EMCCGRP,DAS,TS GRP PAGE DIS
CGRS598I (00104) SETSWAP DISABLE completed:
Group PAGE now DISABLED
Successful : 1
Failed : 0
F EMCCGRP,DAS,TS GRP PAGE ENA

Group PAGE now ENABLED
Successful : 1
Failed : 0
2. The following example uses the DISPLAY GROUP command to display the state of the
current group. In this example the groups PAGE and PAGEC are disabled:
F EMCCGRP,DAS,D GRP PAGE%
CGRS162I (00106)
Group ID Owning System Host Defined Status
Name Identifier MM/DD/YY HH:MM:SS
-------- ----- ---- ---------------- -------- -------- --------
PAGE 00005 Group Owner 09/20/08 20:29:29 Idle *DISABLD
PAGEA 00006 Group Owner 09/20/08 20:29:29 Idle
PAGEB 00007 Group Owner 09/20/08 20:29:29 Idle
PAGEC 00008 Group Owner 09/20/08 20:29:29 Idle *DISABLD
PAGE2 00009 Group Owner 09/20/08 20:29:29 Inactive
Groups Matched : 7
3. The following example uses the DAS FIND DIS command to display only the groups
marked disabled. In this example the groups PAGE and PAGEC are disabled:
F EMCCGRP,DAS,D GRP PAGE% FIND DIS
CGRS162I (00106)
Name Identifier MM/DD/YY HH:MM:SS
-------- ----- ---- ---------------- -------- -------- --------
PAGE 00005 Group Owner 09/20/08 20:29:29 Idle *DISABLD
PAGEC 00008 Group Owner 09/20/08 20:29:29 Idle *DISABLD
Groups Matched : 7 Find Excluded : 5
4. The following example disables and then enables a group using the DETAIL output
F EMCCGRP,DAS,TS GRP PAGE DIS DET
Group PAGE now DISABLED:
X04 (010435DE2096002F) : Warning, AutoSwap not active
X04 (010435DE20960062) : Request valid, RS 00
X06 (010635DE20960054) : Warning, AutoSwap not active
X06 (010635DE2096004A) : Warning, AutoSwap not active
Successful : 1
Failed : 0
1. Because all the examples are ConGroup examples, the messages generated use the ConGroup
prefix CGRP.

Command Reference

Group PAGE now DISABLED:
X04 (010435DE20960062) : Request valid, already in required state
X06 (010635DE20960052) : Request valid, already in required state
Successful : 1
Failed : 0
F EMCCGRP,DAS,TS GRP PAGE ENA DET

Group PAGE now ENABLED :
Successful : 1
Failed : 0
5. The following example attempts to DISABLE a group where processing (validate or

swap) is active on one of the AutoSwap hosts. This results in BACKOUT processing if
necessary.
CGRS598E (00110) SETSWAP DISABLE completed: 980
Group PAGE DISABLE error :
X06 (010635DE20960052) : Error, other processing active
Successful : 0
Failed : 1
CGRS598I (00110) SETSWAP BACKOUT DISABLE completed: 983

Group PAGE now ENABLED
Successful : 1
Failed : 0
SETSWAP 83
Command Reference
SWAP
This section describes the SWAP commands. The SWAP commands are:
◆ SWAP GROUP
◆ SWAP
SWAP GROUP
Purpose
Use SWAP GROUP to swap the UCBs of the devices defined in the group. The group does
not need to be pre-validated. The group is validated as it is swapped.
Syntax
SWAP|G GROUP|GRP groupname
[VALidate|VAL][CROSSSYSTEM|XSYS]
Parameter
groupname
The name of the group to swap. The groupname can be from one (1) to eight (8)
alphanumeric and special characters.
VALidate
Specifies to re-validate the group.
Note: VALIDATE is always performed unless the SWAP group contains the
PREVALIDATE specification. If you issue the VALIDATE command (page 86) for a
group, AutoSwap considers that group to have had the PREVALIDATE specification.
This means that if you issue the SWAP command for such a group, it is not
re-validated, unless you specify this VALIDATE option of the SWAP command.
CROSSSYSTEM|XSYS
When a define group is owned by another host, you must specify the
CROSSSYSTEM (or XSYS)argument on hosts other than the owning host in order to
initiate the request.

Command Reference
SWAP
Purpose
Use SWAP to swap individual devices or ranges of devices. You can also use SWAP to set
AutoSwap options.
Options you set through SWAP are merged with those set by the most recent SET
SDASOPTIONS command. If the same option is specified by SWAP and by SET
SDASOPTIONS, then the SWAP value overrides the similar specification for the SET
SDASOPTIONS command.
Note: “DEFINE GROUP ” on page 60 describes the SDAS options.
This version of SWAP maintains functional compatibility (not keyword compatibility) with
the functionality provided by previous versions of S/DAS.
Syntax
SWAP|G from-cuu to-cuu count [SDAS_options]
Parameters
from-cuu to-cuu
from-cuu and to-cuu are SRDF mirrors of each other. Concurrent devices may be
specified here since primary and secondary devices are explicitly stated.
count
The number of devices to be swapped. The default value is one (1).
SDAS_options
Are one or more options you want to assign. The options are the same as those listed
as arguments under “DEFINE GROUP ” on page 60 with the exception of EXCLUDE,
INClude, RDFGRP, and REPLACE.
Example
The following example lists the from-cuu (312E) and the to-cuu (34AE) and indicates that
four devices are to be swapped:
G 312E 34AE 4
SWAP 85
Command Reference
VALIDATE GROUP
Purpose
Use VALIDATE GROUP to validate groups explicitly to make sure that devices are still in
their intended state.
Note: After you issue the VALIDATE command for a group, AutoSwap considers that group
to have had the PREVALIDATE specification. This means that if you issue the SWAP
command for such a group, it is not re-validated, unless you specify the SWAP VALIDATE
option.
Syntax
VALidate GROUP|GRP groupname|groupname_mask
Parameters
groupname
The name of the group. The groupname can be from one (1) to eight (8) alphanumeric
groupname_mask
In groupname_mask, the mask characters are *, % ,?, where
Example
VAL GRP X

APPENDIX A
Configuration Worksheet
This appendix contains a worksheet you can use to gather the information you need for
your AutoSwap installation. You can also use this information when you enable and
customize AutoSwap.
◆ CAXOPTS configuration worksheet .......................................................................... 88
◆ Other global configuration parameters .................................................................... 88
Configuration Worksheet 87
Configuration Worksheet
CAXOPTS configuration worksheet

The following worksheet allows you to collect CAXOPTS parameter values. Make a
photocopy of the blank worksheet for each CAXOPTs specification you need to supply.
Host:
CAXOPTS specification Default value Value used

CFW= OFFVAL ❏
CROSSSYSEMTIMEOUT= 300 Seconds ❏
LOSTownerpolicy= OPERATOR ❏
[No]AllowSystemsCountMismatch AllowSystemsCountMismatch ❏
QUIESCETimeout= MIH ❏
[No]ROUTEMESSAGEtoowner ERROR ❏
UNPLANNEDCONDitions= none ❏
Other global configuration parameters
The following work table allows you to collect information for the other AutoSwap
configuration parameters.
Host:
Configuration Parameter Default Value Value to Set
CAX=(CAXOPTS=options_set) ❏
COUPLEDS_ALLOWED=(NO | YES) NO ❏
GLOBAL=(OWNER=smfid)
PAGEDEV_ALLOWED=(NO | YES) NO ❏

APPENDIX B
Long Displays and Linecount Values
Invisible Body Tag
This appendix describes how linecount settings can affect the displays of available
devices.
◆ Long displays.......................................................................................................... 90
Long Displays and Linecount Values 89

Long displays
The following explains how the linecount settings affect displays of large numbers of
devices:
◆ If a linecount is specified, it is validated against the maxlinecount value. If the
specified value is greater than the maxlinecount value, the value for maxlinecount is
used.
Note: “SET MAXLINECOUNT” on page 79 provides more information.
◆ If a linecount value is not specified, the defaultlinecount value is used.
Note: “SET DEFAULTLINECOUNT” on page 79 provides more information.
◆ In general, a summary line is always displayed. This does not undergo the linecount
restriction (this being a useful feature for D GRP DET).
◆ A fixed heading line that is part of the message (for example, D GRP SUMMARY is not
included in the linecount.
◆ Multiline output is generated (batched) in parts. To limit MLWTO memory
usage/contention the displays are produced in 32K batches. Each continuation is
marked by a message line indicating continuation and a part number.
For example:
Note: The following output has been truncated.
F PALSDAS2,D GRP * DET

ESWP217I (00047)
Group:A, ID:00002, Mode:Inactive
Creation Date (DD/MM/YY):09/04/08
Time (HH:MM:SS):14:18:14
Group:A1, ID:00003, Mode:Inactive

.....
.....
.....
Group:B, ID:00004, Mode:Inactive

ESWP217I (00047) continued, part(2)

Group:C, ID:00005, Mode:Inactive
TO device subchannel set; Active:NONE, Alternate:SS1
Group:P, ID:00006, Mode:Idle

PID Phase Volser| 0FROM/TO Device |Counts Status/
|Ty 0Devn CCA SSID Symd Ctrl#|Sys Pth Mode
----- ----- ------+-- ---- ---- -------- --- --+------ --------
00001 005 UGL068|R1 03068 ?? ???? 0068 01175|001 001 Invalid

|R2 03468 ?? ???? 0068 00399| Idle

00002 005 UGL069|R1 03069 ?? ???? 0069 01175|001 001 Valid
|R2 03469 ?? ???? 0069 00399| Idle
.....
.....
ESWP217I (00047) continued, part(3)
03000 001 ??????|R1 0F06A ?? ???? ???? ?????|000 000 Invalid
|?? 0F46A ?? ???? ???? ?????| Idle
03004 001 ??????|?? 0F06B ?? ???? ???? ?????|000 000 Invalid
Idle
Total Group Devices: 3004
and so on...
◆ If at least one group display cannot be produced because the value is too small, the
following is appended to the associated message:
Line count too small. No groups displayed.
For example:
F PALSDAS2,D GRP T1 L 2 DET
ESWP217I (00033)
Line count too small. No groups displayed.
◆ If a group display is being truncated, then the 'more...' line is added to the end of the
MLWTO. The groups matched summary line indicates the number of groups displayed.
For example:
F PALSDAS2,D GRP * L 2
ESWP162I (00035)
Name Identifier 09/04/08 14:14:10
-------- ----- ---- ---------------- -------- -------- --------
A 00002 Group Owner 09/04/08 14:18:14 Inactive
A1 00003 Group Owner 09/04/08 14:18:14 Inactive
More....
Groups Matched : 2
Note: In the above example, the linecount does not include the fixed header line since
it is fixed; that is, it is only displayed once.
◆ Related parts of a message are excluded where the linecount is reached for any of the
related parts. This means that a complete coherent message is produced and not
truncated.
For example:
Note: The following two groups can only be displayed if a linecount of at least 27 is
specified (since there are 27 lines).
F PALSDAS2,D GRP * OPT L 27

ESWP163I (00039)
Group:A, ID:00002, S/DAS options:
NoBypassOfflineDevices
CFW=Resume
ChangeSourceDevice=NRDY
NoVolumePrefix
Long displays 91
MAXRC=4
NoPrevalidate
ProcessCount=1
NoRetain
NoSwapImmediate
Group:A1, ID:00003, S/DAS options:
CFW=Resume
NoVolumePrefix
MAXRC=4
NoPrevalidate
ProcessCount=1
Retain
NoSwapImmediate
More....
Groups Matched : 2
The following shows that the second group is not displayed (and thus truncated) when a
value lesser than 27 is given:
F PALSDAS2,D GRP * OPT L 26
ESWP163I (00040)
Group:A, ID:00002, S/DAS options:
NoPaths
CFW=Resume
NoVolumePrefix
MAXRC=4
NoPrevalidate
ProcessCount=1
NoRetain
NoSwapImmediate
More....
Groups Matched : 1
◆ If a detail group display reaches the linecount in the detail output, then the
summaries are still produced and an indicator of the number of lines lost is output.
The summary is still calculated as it would have been had the Linecount not been
exceeded. This is useful because it allows you to use the Find and Exclude options
without having too much display. As for not truncating related data, the two lines
which you normally get for the From and To device is only displayed when both can be
displayed. That is, if the linecount is reached for the second line, then the first line is
not done.
For example:
F PALSDAS2,D GRP P DET L 7 F ' VALID'
ESWP217I (00046)
Group:P, ID:00006, Mode:Idle
TO device subchannel set; Active:NONE, Alternate:SS1
PID Phase Volser| FROM/TO Device |Counts Status/
|Ty Devn CCA SSID Symd Ctrl#|Sys Pth Mode
----- ----- ------+-- ---- ---- -------- --- --+------ --------
Total Group Devices: 4 Missing Lines : 2
Selected: 1 Find Excluded : 3
Groups Matched : 1

Swap Services Message Formatting
APPENDIX C
This appendix describes the message formatting for the EMC SWAP services messages
that are listed in the Mainframe Enablers Message Guide.
◆ Swap services conventions .................................................................................. ... 84
83
Swap services conventions

The 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:
Table C-1
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
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 you do, go to EMC
support as described in “Where to get help” on page 7.
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.

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:
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.
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.
Swap services conventions 85

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 not
be 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.

Auto Swap

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Auto Swap

Hochgeladen von

Copyright:

Verfügbare Formate

EMC® Mainframe Enablers

AutoSwap for z/OS

Published February, 2015

2 AutoSwap for z/OS Version 7.6 Product Guide

Chapter 1 EMC AutoSwap Overview

Chapter 3 Resuming Operations after an AutoSwap

AutoSwap for z/OS Version 7.6 Product Guide 3

Chapter 4 Relevant ConGroup Parameters

Chapter 5 Command Reference

Appendix A Configuration Worksheet

Appendix B Long Displays and Linecount Values

Appendix C Swap Services Message Formatting

4 AutoSwap for z/OS Version 7.6 Product Guide

Conventions used in this document

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

AutoSwap for z/OS Version 7.6 Product Guide 5

6 AutoSwap for z/OS Version 7.6 Product Guide

Where to get help

AutoSwap for z/OS Version 7.6 Product Guide 7

8 AutoSwap for z/OS Version 7.6 Product Guide

This chapter provides an overview of EMC AutoSwap.

EMC AutoSwap Overview 9

EMC Mainframe Enablers and EMC AutoSwap

Enabling component licensing

10 AutoSwap for z/OS Version 7.6 Product Guide

Introduction to AutoSwap for the ConGroup user

Introduction to AutoSwap for the ConGroup user 11

12 AutoSwap for z/OS Version 7.6 Product Guide

What you can swap

What you can swap 13

• AutoSwap only performs an R1 to R2 swap for paging devices. R2 to R1 swaps are

◆ Normally, a swap involves many checkpoints. However, to avoid negative system

Handling High Priority Swap Devices

1. OPS/MVS is a product of Computer Associates International Inc.

14 AutoSwap for z/OS Version 7.6 Product Guide

Information about swap service messaging

Information about dynamic auto-swapping services

16 AutoSwap for z/OS Version 7.6 Product Guide

This chapter discusses AutoSwap operations.

Implementing AutoSwap through ConGroup

Defining configuration parameters

Global configuration parameters

18 AutoSwap for z/OS Version 7.6 Product Guide

AutoSwap-specific configuration parameters

Starting the ConGroup address space

Implementing AutoSwap through ConGroup 19

Note: AutoSwap version 7.3 and higher does support JES3.

20 AutoSwap for z/OS Version 7.6 Product Guide

Additional optional parameters. Separate each optional parameter with a space.

The ConGroup started task name used in this guide.

Note: Your ConGroup started task name may be different.

Tells ConGroup that an AutoSwap command follows.

Tells AutoSwap that a swap is required.

Implementing AutoSwap through ConGroup 21

Names the group for AutoSwap.

When a swap needs to take place

Halt I/O to the swap group

Transfer reserves to the target devices

Release the halted I/O

Figure 1 Steps taken during a swap

As shown in Figure 1, AutoSwap takes the following steps during a swap:

22 AutoSwap for z/OS Version 7.6 Product Guide

Scenarios for swapping – some implementation choices

Scenarios for swapping – some implementation choices 23