TimeFinder/Mirror for z/OS Version 7.6 Product Guide

EMC® Mainframe Enablers TimeFinder®/Mirror for z/OSVersion 7.6

Product GuideREV 02

TimeFinder/Mirror for z/OS Version 7.6 Product Guide2

Copyright © 2015 EMC Corporation. All rights reserved. Published in the USA.

Published March, 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.

CONTENTS

Preface

Chapter 1 TimeFinder/Mirror Overview

Mainframe Enablers and TF/Mirror .............................................................. 16Licensing .............................................................................................. 16

Introduction to TF/Mirror ............................................................................. 17Mainframe-specific features.................................................................. 17TF/Mirror local replication technologies ................................................ 17

The TF/Mirror process ................................................................................. 19BCV operations under Enginuity 5773 and lower ................................... 20BCV operations under Enginuity 5874 and higher.................................. 20BCV pairs .............................................................................................. 21

TF/Mirror features ....................................................................................... 21TF/Mirror and SRDF ............................................................................... 21Improved Consistent Split operations.................................................... 21EMC Symmetrix automated replication (SRDF/AR) ................................. 22Security interface .................................................................................. 22

Chapter 2 TimeFinder/Mirror Operations

Using EMCSCF............................................................................................. 24Running multiple copies of EMCSCF ...................................................... 24

Executing EMCTF ......................................................................................... 25JCL parameters ...................................................................................... 25Comments ............................................................................................ 27Return code processing......................................................................... 27MAXRC and TolerateDesiredState .......................................................... 28

Using TF/Mirror for BCV operations.............................................................. 29Valid command relationships................................................................ 30Online checking .................................................................................... 30

ESTABLISH command operations................................................................. 32BCV pairs .............................................................................................. 32Mirror structure ..................................................................................... 33ESTABLISH functions............................................................................. 33Protected BCV ESTABLISH ..................................................................... 35ESTABLISH multi-attach......................................................................... 35Mixing ESTABLISH and RE-ESTABLISH commands.................................. 36ESTABLISH under Enginuity 5874 and higher......................................... 36

SPLIT command operations......................................................................... 36SPLIT functions ..................................................................................... 37Remote Consistent SPLITs ..................................................................... 38Multi-hop consistent split ..................................................................... 39SPLIT with Protected RESTOREs ............................................................. 39SPLIT under Enginuity 5874 and higher ................................................. 39

RE-ESTABLISH command operations............................................................ 40RE-ESTABLISH functions ........................................................................ 41RE-ESTABLISH multi-attach.................................................................... 41RE-ESTABLISH under Enginuity 5874 and higher.................................... 41

RESTORE command operations ................................................................... 42

TimeFinder/Mirror for z/OS Version 7.6 Product Guide 3

Contents

RESTORE functions................................................................................ 42Protected RESTOREs.............................................................................. 43RESTORE under Enginuity 5874 and higher............................................ 44

Incremental RESTORE command operations ................................................ 44Incremental RESTORE functions............................................................. 45Incremental RESTORE under Enginuity 5874 and higher ........................ 46

QUERY command operations....................................................................... 46Basic queries ........................................................................................ 46Extended queries .................................................................................. 47

Clone Emulation mode ................................................................................ 47Using clone emulation mode with Enginuity 5874 and higher ............................................................................................ 47Using Clone Emulation with Enginuity 5773 and lower .......................... 51TF/Mirror clone emulation and security ................................................. 54

Validating standard and BCV devices .......................................................... 54 Device parameter requirements .................................................................. 55 Setting and clearing explicit device holds.................................................... 55

Placing a hold on a device..................................................................... 55Releasing a hold on a device ................................................................. 56

Additional business continuance operations............................................... 56MultBCV................................................................................................ 56Concurrent BCV ..................................................................................... 57R1BCV................................................................................................... 57SRDF-connected BCV............................................................................. 58Parallel TimeFinder................................................................................ 59R21 device recognition.......................................................................... 60Concurrent R2 (R22) device recognition................................................. 61Gatekeeper devices............................................................................... 61

TF/Mirror restrictions................................................................................... 61

Chapter 3 TimeFinder/Mirror With SRDF

Symmetrix Remote Data Facility (SRDF) overview ......................................... 64SRDF configurations .............................................................................. 64TF/Mirror and SRDF ............................................................................... 66

Using BCVs with source (R1) devices ........................................................... 67ESTABLISH/ RE-ESTABLISH .................................................................... 67SPLIT..................................................................................................... 67RESTORE/Incremental RESTORE ............................................................ 67

Using BCVs with target (R2) devices............................................................. 69ESTABLISH/ RE-ESTABLISH .................................................................... 69SPLIT..................................................................................................... 70RESTORE/ Incremental RESTORE............................................................ 70

Remote operations...................................................................................... 71

Chapter 4 Command Reference

Customer task guide ................................................................................... 74 TF/Mirror commands................................................................................... 74

Command syntax conventions............................................................... 74 BCVGROUP and BCVLIST ............................................................................. 75 CONFIG ....................................................................................................... 76 ESTABLISH .................................................................................................. 82 GLOBAL....................................................................................................... 89 QUERY ........................................................................................................ 98

4 TimeFinder/Mirror for z/OS Version 7.6 Product Guide

Contents

RE-ESTABLISH ........................................................................................... 107 RESTORE ................................................................................................... 114 SPLIT......................................................................................................... 121 USEREXIT .................................................................................................. 133

Chapter 5 SRDF/AR

Introduction to SRDF/AR processing .......................................................... 136Terms and concepts ............................................................................ 136Mainline SRDF/AR processing ............................................................. 137SRDF/AR in multi-hop configurations................................................... 141

Defining a SAR (Symmetrix Automated Replication) environment............... 142 Using SRDF/AR.......................................................................................... 143

Reading command syntax maps.......................................................... 143 ADD .......................................................................................................... 144 DELETE...................................................................................................... 145 GLOBAL..................................................................................................... 145 MODIFY..................................................................................................... 145 SRDF/AR storage estimates ....................................................................... 153 Example.................................................................................................... 153 Performing restart in a SRDF/AR environment............................................ 159

Getting started .................................................................................... 159Recovering using operational host ...................................................... 159Making the SRDF/AR restart volumes available.................................... 159How device locks work ........................................................................ 160Clearing SRDF/AR locks ....................................................................... 161

Testing SRDF/AR recovery procedures ....................................................... 161Procedure 0: BCV state and the restart environment............................ 162Procedure 1: All R2s are split from their BCVs...................................... 163Procedure 2: No R2 is split from its BCV............................................... 164Procedure 3: Some R2s are split from their BCVs ................................. 165

Operational considerations ....................................................................... 166 Drive failure recovery procedures .............................................................. 167 Documenting problems............................................................................. 170

Data collection reference..................................................................... 170Failure information checklist ............................................................... 170

Appendix A Error Codes

User abend codes ..................................................................................... 174 DOIO error codes....................................................................................... 174 TimeFinder/Mirror reason codes................................................................ 175 EXTENTS reason codes .............................................................................. 179

Appendix B Enhancements

Enhancements by release ......................................................................... 182


Contents


Title Page

FIGURES

1 TF/Mirror under Enginuity 5773 and lower................................................................... 182 TF/Mirror under Enginuity 5874 and lower................................................................... 193 Initial configuration..................................................................................................... 324 Establishing a BCV pair ............................................................................................... 335 Establishing a concurrent BCV pair.............................................................................. 346 Splitting a BCV pair ..................................................................................................... 377 Re-establishing a BCV pair .......................................................................................... 408 Restoring a BCV device................................................................................................ 429 Incrementally restoring a BCV device........................................................................... 4510 Cascaded clone operation........................................................................................... 4911 Cascaded clone to cascaded clone emulation ............................................................. 4912 Cascaded clone emulation to cascaded clone ............................................................. 4913 Cascaded clone emulation to cascaded clone emulation............................................. 5014 SRDF-connected BCV devices mirroring the local standard .......................................... 5815 SRDF-connected BCV mirroring the local BCV............................................................... 5916 Concurrent RDF ........................................................................................................... 6517 SRDF uni-directional configuration .............................................................................. 6518 SRDF bi-directional configuration ................................................................................ 6619 Using BCVs with source (R1) devices ........................................................................... 6720 Using BCVs with a target (R2) device ........................................................................... 6921 Using BCVs with concurrent asynchronous legs and multiple targets (R2) devices

(Enginuity level 5875 or higher) ................................................................................... 6922 Remote control............................................................................................................ 7123 SRDF/AR multi-hop configuration .............................................................................. 14124 Remote Symmetrix protection of local standard devices ............................................ 15425 Remote Symmetrix protection with additional local devices ...................................... 15626 DOIO error code format ............................................................................................. 174


Figures


Title Page

TABLES

1 EMCTF JCL parameters ................................................................................................. 252 TF/Mirror commands ................................................................................................... 293 Valid command relationships...................................................................................... 304 Online checking .......................................................................................................... 315 TF/Mirror mapping operations: Enginuity 5874 and higher .......................................... 486 TF/Mirror mapping operations: Enginuity 5773 and lower............................................ 537 Standard and BCV device validation............................................................................ 548 Valid command relationships...................................................................................... 559 Customer Task Guide .................................................................................................. 7410 Extended mode QUERY fields .................................................................................... 10011 SRDF/AR control block defaults ................................................................................. 15312 Customer action matrix ............................................................................................. 16713 Abend codes............................................................................................................. 17414 TimeFinder/Mirror (EMCTF) reason codes .................................................................. 17515 EXTENTS error codes ................................................................................................. 17916 TimeFinder enhancements ........................................................................................ 182


Tableses


PREFACE

As part of an effort to improve its product lines, EMC periodically releases revisions of its software and hardware. Therefore, some functions described in this document might not be supported by all versions of the software or hardware currently in use. The product release notes provide the most up-to-date information on product features.

Contact your EMC representative if a product does not function properly or does not function as described in this document.

Note: This document was accurate at publication time. New versions of this document might be released on the EMC online support website. Check the EMC online support website to ensure that you are using the latest version of this document.

PurposeThis document describes how to configure and use EMC TimeFinder/Mirror for z/OS.

AudienceThis document is intended forthe host system administrator, system programmer, or operator who is involved in managing or operating TF/Mirror for z/OS.

Related documentationThe following EMC publications provide additional information:

◆ Mainframe Enablers Release Notes

◆ Mainframe Enablers Installation and Customization Guide

◆ Mainframe Enablers Message 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

◆ TimeFinder/Clone Mainframe SNAP Facility Version Product Guide

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.

IMPORTANT

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


Preface

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 helpEMC 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 [email protected] or call:

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

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


http://support.EMC.com

https://support.EMC.com/products

http://support.EMC.com

Preface

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

[email protected]


CHAPTER 1TimeFinder/Mirror Overview

This chapter introduces TimeFinder/Mirror for z/OS, including its features, requirements, and processing options.

◆ Mainframe Enablers and TF/Mirror .......................................................................... 16◆ Introduction to TF/Mirror ......................................................................................... 17◆ The TF/Mirror process ............................................................................................. 19◆ TF/Mirror features ................................................................................................... 21

TimeFinder/Mirror Overview 15

TimeFinder/Mirror Overview

Mainframe Enablers and TF/MirrorEMC® TimeFinder®/Mirror is one of the EMC Mainframe Enablers. The EMC Mainframe Enablers include the following components that you can use to monitor and manage your storage:

◆ ResourcePak® Base for z/OS

◆ EMC Consistency Groups for z/OS

◆ SRDF® Host Component for z/OS

◆ TimeFinder/Clone Mainframe SNAP Facility

◆ TimeFinder/Mirror for z/OS

◆ TimeFinder Utility

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

However, to enable any of the 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 EMC Mainframe Enablers Installation and Customization Guide and the EMC ResourcePak Base for z/OS Product Guide to install the Mainframe Enablers and enable TF/Mirror.

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.



Introduction to TF/MirrorEMC TF/Mirror is a business continuance solution. It enables you to make full-volume copies of production data from a standard Symmetrix® device (which is online for regular I/O operations from the host) to a Business Continuance Volume (BCV) with which the standard device is paired.

The BCV device can then be separated (split) from the standard device and then be used for backup, restore, decision support, or applications testing. After host processing on the BCV device is complete, the BCV can again be mirrored to a standard device, either the same device to which it was previously paired, or with a different device.

Mainframe-specific features

Mainframe-specific features of the TF/Mirror product include:

◆ Creating dependent write consistent BCVs locally or remotely (with TF/Consistency Group) without the need to quiesce production jobs.

◆ Performing BCV operations important to IS departments including:

• Using the BCV as the source for backup operations.

• Using the BCV for test LPARs with real data. The speed with which a BCV can be reconstituted means that multiple test cycles can occur rapidly and sequentially. Applications can be staged using BCVs before committing them to the next application refresh cycle.

• Using the BCV as the source for data warehousing applications rather than the production volumes. Because the BCVs are a point-in-time mirror image of the production data, they can be used as “gold” copies of data to be written and rewritten repeatedly.

◆ With SRDF®/Automated Replication (SRDF/AR), making point-in-time safety copies of data sent across links to remote system.

Note: Chapter 5 provides more information about SRDF/AR.

◆ Support for mainframe TimeFinder-based queries.

◆ Compatible with mainframe security mechanisms such as RACF.

◆ Integration with database management system (DBMS) utilities available from several Independent Software Vendors (ISVs) and their products.

◆ Integration with many mainframe-specific ISVs and their products.

TF/Mirror local replication technologies

TF/Mirror has two local replication technologies.

◆ The two technology solution used under the Enginuity™ operating environment for Symmetrix, 5773 and lower

◆ The single technology solution use under Enginuity 5874 and higher

Introduction to TF/Mirror 17


The two technology solutionUnder Enginuity 5773 and lower, TF/Mirror used two local-replication technologies as shown in Figure 1 on page 18.

Figure 1 TF/Mirror under Enginuity 5773 and lower

Under Enginuity 5773 or lower versions, the BCV was a specially tagged volume established when the Symmetrix unit was configured. The BCV functioned as a mirror that you could manipulate with the TF/Mirror ESTABLISH, SPLIT, RE-ESTABLISH, and RESTORE commands.

In Enginuity 5x71, a second method was added that used TF/Clone (a component of TF/Clone Mainframe SNAP Facility) to control the business continuance process. This technology was clone emulation. Under clone emulation, an internal API function converts TF/Mirror commands to EMC TF/Clone Mainframe SNAP Facility commands.

Clone emulation was first used with RAID 5 and RAID 6 BCVs (in all cases). In time, TF/Mirror let users control, at their option, all other types of BCVs through clone emulation.

In all cases, clone emulation was transparent. As shown in Figure 1 on page 18, users could continue to employ the standard TF/Mirror commands and parameters. The TF/Mirror commands pass through an emulation layer to control clone copy BCVs.

To use clone emulation, users needed to enable the TF/Clone component of TF/Clone Mainframe SNAP Facility (and the TF/Consistency Group component if they want consistent split operations).

TimeFinder/MirrorCommands

TimeFinder/CloneCommands

Emulation API

CloneMirror



The single technology solutionStarting with Enginuity 5874, TF/Mirror uses clone emulation for all operations, as shown in Figure 2.

Figure 2 TF/Mirror under Enginuity 5874 and lower

There are no specific steps you need to take. Whenever it internally detects a Symmetrix controller running at Enginuity level 5874 and higher, TF/Mirror automatically sets the mode to clone emulation. There are few changes you have to make to TF/Mirror commands and parameters. (“Using clone emulation mode with Enginuity 5874 and higher” on page 47 details the changes you need to make.)

To use TF/Mirror with Enginuity 5874, you need to install the Mainframe Enablers and enable the TF/Clone component of TF/Clone Mainframe SNAP Facility (and the TF/Consistency Group component if you want consistent split operations).

The TF/Mirror processThe TF/Mirror process involves the following steps:

1. Establishing the BCV device as a clone (Enginuity 5874 or higher) or mirror (Enginuity 5773 or lower) of a specific standard Symmetrix device.

2. After the BCV device is synchronized and data is copied to the BCV, you can separate (split) the BCV from the standard device to which it is paired.

3. After host processing on the BCV device is complete, you can synchronize the BCV again to a standard Symmetrix device.

TimeFinder/MirrorCommands

TimeFinder/CloneCommands

Emulation API

Clone

The TF/Mirror process 19


BCV operations under Enginuity 5773 and lower

Under Enginuity 5873 and lower, BCV operations were supported by controlling Enginuity through the EMC TF/Mirror application.

BCV devices must already exist in the Symmetrix configuration. Configuring Symmetrix devices as BCV devices is done by your EMC Customer Service Engineer during Symmetrix installation or service.

A BCV device may be configured as:

◆ A single mirror.

◆ A locally mirrored device (requires at least Enginuity™ level 5x64).

◆ An SRDF source (R1) device (requires at least Enginuity level 5x64).

◆ A RAID protected device (including RAID 5 and RAID 6 protected devices1).

◆ TF/Mirror is an interface that controls the use of BCV devices that already exist in the Symmetrix configuration.

Note: Configuring Symmetrix devices as BCV devices is done by your EMC Customer Service Engineer during Symmetrix installation or service.

The BCV can function either as:

• An additional mirror to a Symmetrix logical volume

• An independent, host-addressable volume

Note: Chapter 2 provides details about TF/Mirror process.

BCV operations under Enginuity 5874 and higher

As mentioned in “The single technology solution” on page 19, all TimeFinder operations are conducted in clone emulation mode. Under Enginuity 5874, a BCV is a clone copy. (Note, however, that the devices used must be configured with the BCV attribute.)

As such, the BCV does not require Symmetrix mirror positions. However, the BCV under Enginuity 5874 can have any configuration except VDEV (virtual device); that is, they can have any form of RAID protection.

Note: The EMC TimeFinder/Clone Mainframe SNAP Facility Product Guide provides more information about VDEV.

1. RAID 5 usage requires at least Enginuity level 5x71. RAID 6 usage requires at least Enginuity level 5772.



BCV pairs

After a BCV device is established as a clone or mirror of a standard device, the standard and BCV devices together are referred to as a BCV pair.

The pair has two types of copies:

◆ The standard device mirror(s)

◆ The BCV

The standard device mirrors each contain copies of the data contained in the standard device. There can be up to four standard device mirrors.

A BCV mirror is a standard device mirror that is assigned upon creation of the BCV pair.

The BCV pair are synchronized. Data sent to the standard device is written to the BCV device. The BCV device is inaccessible from its original device address while it is in an established BCV pair.

After the BCV device is synchronized, you may separate (split) it from the standard device to which it is paired. After the split, the BCV device with the synchronized data is available for backup or other host processes through its original device address.

After host processing on the BCV device is complete, you can synchronize the BCV again to a standard Symmetrix device, either:

• The same device to which it was previously paired.

• A different device.

TF/Mirror featuresTimeFinder Mirror offers the following additional features:

◆ TimeFinder on a Symmetrix Remote Data Facility (SRDF) system

◆ Improved Consistent Split operations

◆ SRDF/AR

◆ Security interface

TF/Mirror and SRDF

Enginuity level 5x65 and higher releases include remote BCV control capabilities. This gives a host attached to the Symmetrix system at the source location the ability to issue TF/Mirror commands across SRDF links to devices in a remote Symmetrix system at a target location.

Note: Chapter 3 describes how to use TF/Mirror over SRDF links.

Improved Consistent Split operations

TF/Mirror offers several improved Consistent Split and remote consistent split operations. “SPLIT functions” on page 37, “Remote Consistent SPLITs” on page 38, and “SPLIT under Enginuity 5874 and higher” on page 39 provide more information.

TF/Mirror features 21


EMC Symmetrix automated replication (SRDF/AR)

SRDF®/AR1 offers customers data protection with consistency across a distance. This protection is accomplished by using geographically separated replicas with hardware and software products and facilities from EMC Corporation.

SRDF/AR allows you to automate data copies across Symmetrix Remote Data Facility (SRDF) links to provide a restartable image of the data at a remote site if a disaster occurs at the production site. You can use SRDF/AR in single-hop or multi-hop configurations.

Note: Chapter 5 describes SRDF/AR.

Security interface

TF/Mirror uses SAF calls to validate access to resources. This feature is turned on by default. The source code for the TF/Mirror SAF interface routine is provided in the SCF (ResourcePak Base) SAMPLIB so that you can tailor it to your specific needs.

Note: The EMC Mainframe Enablers Installation and Configuration Guide describes the Security Interface and the class and resource names used.

1. SRDF/AR was formerly called SAR, Symmetrix Automatic Replication.


CHAPTER 2TimeFinder/Mirror Operations

Invisible Body Tag

This chapter contains an overview of TF/Mirror, a description of its key components, and a discussion of how to use these components for business continuance.

◆ Using EMCSCF......................................................................................................... 24◆ Executing EMCTF ..................................................................................................... 25◆ Using TF/Mirror for BCV operations.......................................................................... 29◆ ESTABLISH command operations............................................................................. 32◆ SPLIT command operations..................................................................................... 36◆ RE-ESTABLISH command operations........................................................................ 40◆ RESTORE command operations ............................................................................... 42◆ Incremental RESTORE command operations ............................................................ 44◆ QUERY command operations................................................................................... 46◆ Clone Emulation mode ............................................................................................ 47◆ Validating standard and BCV devices ...................................................................... 54◆ Device parameter requirements .............................................................................. 55◆ Setting and clearing explicit device holds................................................................ 55◆ Additional business continuance operations........................................................... 56◆ TF/Mirror restrictions............................................................................................... 61

TimeFinder/Mirror Operations 23

TimeFinder/Mirror Operations

Using EMCSCF TF/Mirror requires that EMCSCF (ResourcePak Base) is running. If EMCSCF is not running, any TF/Mirror commands issued receive the following message:

EMC SCF IS NOT AVAILABLE - reasonIEF450I STON01B EMCSMMF - ABEND=000 U0806 REASON=00000000

Where:

reason

One of the following:

• SERVICE EMCSAI FAILED• SERVICE SAICALL FAILED

Running multiple copies of EMCSCF

You can run multiple instances of EMCSCF as separate z/OS sub-systems. You may want to do this when you test new versions of EMCSCF or EMCSCF-enabled products.

You can accomplish this by adding the following DD statement to the test EMCSCF procedure.

//SCF$nnnn DD DUMMY

Where:

nnnn

Any task needing to use this instance of EMCSCF would add a connection DD statement. If a TimeFinder task needs to use this version of EMCSCF, the JCL for that TimeFinder task would add the DD statement:

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

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

//TFTEST EXEC PGM=EMCTF//SYSOUT DD SYSOUT=A//SYSIN DD *//SCF$0100 DD DUMMY



Executing EMCTFThe interface to TF/Mirror is through the program EMCTF. You normally execute EMCTF as a batch job.

The following is example JCL for running EMCTF as a batch job:

//EMCTF EXEC PGM=EMCTF,REGION=0M,PARM=jcl_parm //STEPLIB DD DISP=SHR,DSN=your.timefinder.library//SYSOUT DD SYSOUT=* //SCF$nnnn DD DUMMY //TFBCVGRP DD DUMMY //SYSIN DD *

Notes:

◆ The STEPLIB DD statement is optional if you have copied EMCTF to a system LINKLIST library.

◆ The SCF$nnnn statement is optional. It is used to match the batch job to the SCF task that you would like to run against. If you do not specify it, the default SCF subsystem name is SCF$EMC.

◆ To utilize group processing, you can specify TFBCVGRP as DD * or have it reference a disk file.

Note: TFBCVGRP in “BCVGROUP and BCVLIST” on page 75 describes TFBCVGRP.

◆ The SYSIN DD statement can reference a disk file: DISP=SHR,DSN=dsn.

JCL parameters

As shown in the example JCL shown in the previous section, EMCTF accepts special JCL parameters (jcl_parm in the example under “Executing EMCTF” on page 25). Table 1 shows these parameters, their abbreviations, and a description of their functions.

Table 1 EMCTF JCL parameters (page 1 of 2)

Parameter Abbreviation Description

ECACLEAR ECACLR Clears ECA a on all standard devices in a Consistent SPLIT referenced in the input stream.

FORCESUSPENDRESUME This parameter forces syscall 8133 to suspend or resume an R1BCV after SAR processing was interrupted.

MAXREQ=nnnnn Specifies the maximum number of requests (default is 4095).The maximum value for MAXREQ is (65536).

Executing EMCTF 25


ECACLEAR, RELEASEDEVICELOCK, and RESETIOSLEVEL are used in a recovery situation after a job or system failure. The action is to clear or reset the devices to their original (normal) state.

The input command stream must be the same as was run in the failing job. These statements are not executed as TF/Mirror commands. They are used solely to determine the devices which need to be reset or cleared.

After the recovery action completes, you can resume normal operation by submitting the job again without the parameter.

RELEASEDEVICELOCK RELDLOCK Releases the device lock for all BCV devices referenced in the input stream.

RESETIOSLEVEL RIOSL Resets the IOS Level for all standard devices in a Consistent SPLIT referenced in the input stream (when ECA is not used).

SAR_PAUSED(process_name) Bypasses the device locks when the specified SRDF/AR process is in a “paused’ state, allowing TF/Mirror operations to be run on SRDF/AR devices when the SRDF/AR is paused.Used in a recovery situation; after a drive failure, to restore devices to their proper state before continuing the SRDF/AR process.When the SRDF/AR process pauses the following message is issued:*nn BCVA058A Process process_name,

Paused in Step nn (reason)- reply CONTinue or CANcel

An immediate Pause occurs just before the next API call. A Step level Pause occurs before the next API call for the desired step. Either type of Pause is deferred during the Consistent Split phase to prevent impacting the Consistent Split, possibly causing a loss of consistency for the affected cycle. For example, an immediate Pause issued during the Consistent Split phase of Step 02 is deferred until the Consistent Split processing has completed (Step 03). You can schedule a PAUSE to take effect for a step in the SRDF/AR process by specifying that step number on the PAUSE.

a. ECA, Enginuity Consistency Assist is an EMC technology that requires the TF/Consistency Group eLicense or Licensed Feature Code. The EMC Mainframe Enablers Installation and Customization Guide provides more information.

Table 1 EMCTF JCL parameters (page 2 of 2)

Parameter Abbreviation Description



Comments

Start any separate comment lines you want to include in command text with an asterisk (*) in column one. For example:

GLOBAL MAXRC(8,SETMAX)* DISPLAY BCVS IN TESTSYMM QUERY 1,4210,ALL * DISPLAY BCVS IN PRODSYMM QUERY 1,C120,ALL

Note: These comments are not included in the output.

To include comments on individual command statements, indicate them as follows:

command statement /* comment */

For example:

QUERY 1,4210,ALL /* DISPLAY BCVS IN TESTSYMM */ QUERY 1,C120,ALL /* DISPLAY BCVS IN PRODSYMM */

Note: These comments are included in the output.

Return code processing

The GLOBAL command MAXRC parameter is a primary tool for controlling return code processing. The value you set in MAXRC specifies the maximum return code that can allow the continuation of processing.

The messages you receive from TF/Mirror can be returned with an informational suffix (I), with a warning suffix (W), or with an error suffix (E). The message class you receive with these messages depends on the return code encountered. The values that can be returned as the jobstep return code range from zero (0) to eight (8). Zero would be the least serious; for example, informational. Eight would be an error.

You can also receive a return code of 12. A return code of 12 a serious error, but is returned as an error (E).

You can set MAXRC to a value for between 0 and 8. When you set MAXRC to a numeric value and do not receive a return code higher than that value, TF/Mirror sets the jobstep return code to zero (0) and returns the message as a warning (W). Processing continues.

If you set MAXRC to a value and receive a return code higher than that value, TF/Mirror sets the jobstep return code to that value and sets the message as an error (E). Processing stops.

If you receive a return code of 12, which is higher than the maximum value to which you can set MAXRC, TF/Mirror takes the following steps:

◆ Sets the jobstep to 12.

◆ Sets the message as a serious error.

Processing stops.

Executing EMCTF 27


For example, if you use the parameter:

MAXRC(8)

Because you do not normally receive a return code higher than this value, processing continues and the jobstep return codes are zero (0). If you do receive a return code of 12, processing stops and the jobstep return code is 12.

TF/Mirror returns a non-zero jobstep return code only under the following conditions:

◆ When you do not specify the GLOBAL parameter MAXRC, TF/Mirror returns the highest return code observed during execution as the jobstep return code. The message generated is an error.

◆ When the return code encountered in the jobstep is greater than MAXRC.(n) value, TF/Mirror returns that code as the jobstep return code. The message generated is an error.

◆ When you specify the SETMAX argument on the GLOBAL parameter (MAXRC=(n,SETMAX), SETMAX returns the highest return code observed during execution as the jobstep return code. If that return code is higher than the value of n, the message returned is an error.

If you use the parameter:

MAXRC(8,SETMAX)

Processing continues and the jobstep return codes are the highest return code returned from any jobstep.

The following return code processing considerations apply to EMCTF with MAXRC=8 set on the GLOBAL command.

◆ Any ACTION statement that has a return code of 8 or less causes a jobstep return code of 0 to be set by EMCTF.

◆ If your job scheduler is testing jobstep return codes to make sure that any process completed before another process is started, then the user should code MAXRC=7 or less for ACTION statements.

◆ A return code of 8 is issued for all suffix E TF/Mirror error messages. Suffix E indicates that a process did not complete as expected.

Note: “GLOBAL” on page 89 describes the MAXRC parameter. The EMC Mainframe Enablers Message and Code Guide lists the messages that you can receive.

MAXRC and TolerateDesiredState

You can also use the MAXRC GLOBAL parameter with the TolerateDesiredState GLOBAL parameter to determine whether processing takes the current state of devices under consideration during an ESTABLISH, RE-ESTABLISH, RESTORE or SPLIT operation. If you set TolerateDesiredState and set MAXRC to a value of four (4) or higher, TF/Mirror ignores the current state of any specified devices during ESTABLISH, RE-ESTABLISH, RESTORE or SPLIT command execution.



Note: “GLOBAL” on page 89 describes the MAXRC and TolerateDesiredState parameters in more detail.

Using TF/Mirror for BCV operationsAs shown in Table 2, TF/Mirror offers a suite of commands to perform BCV operations.

Table 2 TF/Mirror commands

Command Action

CONFIG The CONFIG command specifies HOLD, RELEASE, NR, DELINC, and READY conditions for BCV devices The CONFIG command can also specify HOLD or RELEASE for standard devices with Enginuity level 5x66 and higher, and DELINC with Enginuity level 5875 and higher.

ESTABLISH Establishes a BCV pair. Assigns the BCV and copies the contents of the standard device to the BCV.

QUERY Reports the status of BCV devices in the Symmetrix system. Symmetrix systems respond to a valid QUERY operation by returning device records for each BCV currently defined.

RE-ESTABLISH Reassigns a BCV device to the standard device to which it was assigned before it was split. Any data written to the BCV while it was split from the standard device is overwritten on the BCV. The BCV receives its updates from the standard device.

RESTORE Assigns the BCV to a standard device. RESTORE then copies the contents of the BCV to the standard device. The standard device does not need to be the same device originally established with the BCV.A variety of RESTORE, Incremental RESTORE, incrementally restores from a BCV device. Incremental RESTORE reassigns the BCV to the standard device to which it was assigned before it was split. Any data written to the BCV while it was split from the standard device is overwritten on the standard device. Any updates made to the standard device while the BCV pair was split are discarded.

SPLIT Splits the BCV from the standard Symmetrix device and makes the BCV available (with the data from the standard device with which it was paired) to hosts through its separate device address.

Note: Variations of the split process are available for locally or remotely mirrored BCVs with Enginuity level 5x65 (or higher) releases.

Using TF/Mirror for BCV operations 29


Valid command relationships

Table 3 on page 30 shows the valid commands and their relationship with the other parameters when not using the DSN or RMT format. The cuup parameter specifies the z/OS device number of the standard device. The cuus parameter specifies the z/OS device number of the BCV device. The WAIT parameter specifies whether to wait for the action to complete.

Note: When using the DSN option, cuup and cuus are not applicable. Volumes are located using the DSN only.

1. This command can be run against any device (standard or BCV) on the controller.

2. When using LCL and RMT, cuus should be replaced with sym#bcv.

3. When using LCL and RMT, cuup should be replace with sym#std.

4. CONFIG RELEASE, CONFIG HOLD and CONFIG DELINC may be used against a standard device.

Note: The operations you perform on the BCVs may alter the change bits and the last reference date in the VTOC. This information is not reflected back to the standard device, unless you execute a RESTORE command.

Online checking

Take special care when performing BCV operations on a Symmetrix system attached to multiple hosts. During certain operations, the BCV device is unavailable to the host(s).

TF/Mirror provides online checking for BCV and standard devices. Table 4 on page 31 lists the scope of checking performed for each command.

Table 3 Valid command relationships

Action cuus b cuup c WAIT

QUERY a N/A N/A N/A

ESTABLISH Required Required Y/N

RE-ESTABLISH Required N/A Y/N

SPLIT Required N/A Y/N

RESTORE Required Optional Y/N

CONFIG Required N/A d N/A



Note: The online checks can be bypassed using the SAF Security Interface. The EMC Mainframe Enablers Installation and Customization Guide describes the SAF Security Interface.

1. Local Only = Online check is only performed on the host issuing the TF/Mirror command.

2. None = No online checking is performed.

3. All Hosts = Online checking is performed on all hosts by checking the path groups to the device.

4. N/A = Not applicable - online checking not required.

The type of online checking performed depends on the Enginuity version. Online checking is not supported in Enginuity levels 5x64.23.xx, 5x64.24.xx, or 5x64.25.xx. If your Symmetrix system is running one of these Enginuity versions, have your EMC Customer Service engineer upgrade to the current Enginuity version.

The following sections describe how these TF/Mirror commands operate. Chapter 4 describes the syntax and parameters of these commands.

Table 4 Online checking

TF/Mirror commands

Enginuity 5x63 Enginuity 5x64 or higher

BCV check STD check BCV check STD check

ESTABLISH Local Only a N/A d All Hosts c N/A

ESTABLISH DSN None b N/A All Hosts N/A

RE-ESTABLISH Local Only N/A All Hosts N/A

RE-ESTABLISH DSN None N/A All Hosts N/A

Incremental RESTORE Local Only N/A All Hosts N/A

Incremental RESTORE DSN None N/A All Hosts N/A

RESTORE Local Only Local Only All Hosts All Hosts

Using TF/Mirror for BCV operations 31


ESTABLISH command operationsThe BCV devices, like the standard devices, have unique host addresses and are online and Ready to the host(s) to which they are connected.

Figure 3 illustrates the initial Symmetrix configuration before you perform any TF/Mirror operations. In this figure, the host views the Symmetrix M1/M2 mirrored pair as a single device (VOL A). The host views the BCV device as VOL B.

Figure 3 Initial configuration

BCV pairs

To obtain a copy of the data on a standard Symmetrix device, you must establish a BCV pair. A BCV pair consists of:

◆ A standard device

◆ A BCV device

In the case of a concurrent BCV, the relationship can consist of:

◆ One standard device

◆ Two BCV devices

If you are using clone emulation, the relationship can consist of:

◆ One standard device

◆ Two BCV devices

Note: Keep in mind that BCV devices must be configured with the BCV attribute.

Vol A Vol B

M1 M2 BCV

Host

Symmetrix



Mirror structure

The standard device can have any mirror structure (normal, RAID 1, RAID S, RAID 5, RAID 6, RAID 10, RAID 1 with SRDF 1), as long as the number of mirrors does not exceed three. In the case of concurrent BCVs, two mirror positions are required.

Starting with Enginuity 5773, three dynamic mirrors are allowed. These can be any combination of BCVs, Dynamic RDF, and Dynamic Spares. However, there is still a limit of two attached BCVs for each STD device, regardless of dynamic mirror support.

With clone emulation, no mirror positions are required or used.

ESTABLISH functions

When a Symmetrix system receives an ESTABLISH command from the host, it performs several functions. Figure 4 on page 33 shows a BCV pair being established.

Figure 4 Establishing a BCV pair

These ESTABLISH functions include:

◆ Checking specified operation validity. For example, a Symmetrix system makes sure that:

– Both the standard device and the BCV device are the same size.

– The device specified as the BCV has the BCV attribute.

– The standard device does not already have a BCV device assigned to it, and so on.

◆ Setting the BCV device Not Ready and offline to the host.

◆ Assigning the BCV device as the next available mirror2 of the standard device. A BCV may be the second, third, or fourth mirror of the standard device. For example, in Figure 4, the BCV is the third mirror (M3).

1. RAID 10 standard devices can be used only with RAID 10 mirrors.

M1 M2

Copy

M3

Host

BCVNot Ready

Vol A Vol B

Establish

Symmetrix

ESTABLISH command operations 33


◆ Copy the contents of the standard device to the BCV. For example, in Figure 4 on page 33 the BCV device receives its data from both the M1 and M2 devices.

◆ Copy the contents of the standard device to both BCVs. For example, in Figure 5, the two BCV devices receive their data from both the M1 and M2 devices.

Figure 5 Establishing a concurrent BCV pair

Each BCV in a concurrent BCV pair operates as an independent BCV paired with a standard device. An optional parameter of the ESTABLISH command (CBCV) indicates the intent to add a second BCV to the existing relationship.

The BCV(s) are synchronized when the standard device mirrors1 and the BCV mirror contain identical data.

Note: A BCV device is not available for host use during the time that it is assigned (established) as a BCV mirror with a standard device. Any new data written to the standard device is copied to the BCV device(s) while the BCV pair exists.

To use a BCV device for business continuance procedures, split the BCV pair to make the BCV device available to the host. If you wish to use a fully synchronized copy of the data, use either of the following options to achieve a consistent copy of the data:

◆ Suspend all applications that are using the standard device(s), and make sure that all host buffering and intermediate caching is flushed to the appropriate logical device on the Symmetrix system before performing the SPLIT operation.

◆ Use the CONSISTENT option of the SPLIT command with either the LOCAL or GLOBAL parameter. LOCAL specifies a single image Consistent SPLIT. GLOBAL specifies a multi-image Consistent SPLIT. The CONSISTENT option halts host I/O to the standard devices of the BCV pair for the short duration of an Instant SPLIT.

2. If you are using clone emulation, no mirror positions are used.

M1 M2

Symmetrix

Copy

M3 M4

Host

Vol A Vol B Vol C

BCV Not Ready

BCV Not Ready

ESTABLISH

1. If you are using clone emulation, no mirror positions are used.



IMPORTANT

If you do not require a consistent copy of the data for running a business continuance process, the consistency step is unnecessary.

Protected BCV ESTABLISH

This feature involves locally mirrored 1 BCVs only. When issued on an ESTABLISH or a RESTORE with Protected BCV Mirror Establish, both mirrors of the BCV are added as mirrors of the standard device. If there are no available mirror positions, this operation fails. On a BCV SPLIT of the BCV, both mirrors are synchronized from the beginning. This ensures that there is no point in time at which data is unprotected on the BCV.

ESTABLISH multi-attach

Starting with Enginuity 5x71, TF/Mirror includes a new multi-attach feature. Multi-attach allows multiple device pairs to be attached on the same ESTABLISH or RE-ESTABLISH command syscalls.

You control multi-attach through:

◆ The MULTIATTach(NONE|ALL|EST|REEST) parameter on the GLOBAL command

◆ The MULTIATTach(Yes|No) parameter on the ESTABLISH command

Note: “GLOBAL” on page 89 and “ESTABLISH” on page 82, describe these commands.

You can use MULTIATTach on the GLOBAL command to enable or disable all multi-attach operations, or unconditionally enable multi-attach operations on ESTABLISH commands.

If you specify a value of NONE for the GLOBAL MULTIATTach parameter, TF/Mirror unconditionally disables multi-attach for all attach operations. If you specify a value of ALL for the GLOBAL MULTIATTach parameter, TF/Mirror conditionally enables multi-attach for all attach operations. On the other hand, if you specify the following values for GLOBAL MULTIATTach:

◆ EST = You conditionally enable multi-attach for all ESTABLISH operations.

◆ REEST = You conditionally enable multi-attach for all RE-ESTABLISH operations.

Although a value of NONE on the GLOBAL MULTIATTach parameter unconditionally disables multi-attach, if you use ALL, EST, or REEST (or do not specify any GLOBAL MULTIATTach parameter) you can override the global value by using the MULTIATTach parameter on individual ESTABLISH commands.

Multi-attach ESTABLISH functions like Multi-Instant SPLIT, where commands at the same sequence level are eligible for multi-attach. For example, the following two ESTABLISH commands result in a multi-attach operation:

ESTABLISH 10,6EFE,6E7E,MULTIATT(Y)

ESTABLISH 10,6EFF,6E7F,MULTIATT(Y)

1. When you use clone emulation, no mirror positions are used.

ESTABLISH command operations 35


However, changing the sequence level on one of these commands results in individual ESTABLISH syscalls.

Mixing ESTABLISH and RE-ESTABLISH commands

You can mix ESTABLISH and RE-ESTABLISH commands. Consider the following example:

BCVI018I (0001) GLOBAL MAXRC(8,SETMAX),MULTA(ALL)BCVI018I (0002) ESTABLISH 1,LCL(831F,3AA,3BA) BCVI018I (0003) ESTABLISH 1,LCL(831F,3AB,3BB) BCVI018I (0004) RE-ESTABLISH 1,LCL(831F,200) BCVI018I (0005) RE-ESTABLISH 1,LCL(831F,201) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0002) Process input statement BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I MULTI ESTABLISH LOCAL devices through 831F: BCVM004I 03AA/03BA(0002),03AB/03BB(0003) BCVM140I Command processed via TF/Clone emulation

BCVM039I (0004) Process input statement BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I MULTI RE-ESTABLISH LOCAL devices through 831F: BCVM004I 0200(0004),0201(0005) BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

ESTABLISH under Enginuity 5874 and higher

Under Enginuity 5874, ESTABLISH uses clone emulation for all functions. Under clone emulation, all ESTABLISH operations are Protected BCV ESTABLISH. “Protected BCV ESTABLISH” on page 35 and “ESTABLISH” on page 82 provide more information.

There are also several important general differences between TF/Mirror 7.0 with Enginuity 5874 and lower versions that you should keep in mind. “Using clone emulation mode with Enginuity 5874 and higher” on page 47 discusses these differences. Table 5 on page 48 provides more information about how ESTABLISH maps to the TF/Clone Mainframe SNAP Facility command structure.

SPLIT command operationsAfter an ESTABLISH operation in which the standard device mirrors are synchronized (Figure 4 on page 33 has more information), the BCV device contains a copy of the data from the standard device. That data is valid up to the point in time when a SPLIT command is issued. You can now execute Business Continuance (BC) processes with the BCV device.

Note: The SPLIT command can apply independently to either of the BCV devices in a concurrent BCV relationship.



SPLIT functions

When a Symmetrix system receives a SPLIT command from the host, it performs several steps. Figure 6 shows the result of the SPLIT operation.

Figure 6 Splitting a BCV pair

The functions performed by a Symmetrix system during the SPLIT operation include:

◆ Check command validity. For example, the Symmetrix system makes sure that:

• The standard device has an active BCV mirror.

• The standard and BCV devices comprise a BCV pair.

• The BCV device is fully synchronized with the standard device.

• For MSC: if the MSC session is globally consistent.

◆ Check for a mixture of SRDF/A and non-SRDF/A devices in a Consistent SPLIT. If TF/Mirror finds such a mixture, it returns message BCVI122W (or E depending on the MAXRC value). Mixed SRDF/A and non-SRDF/A does not guarantee consistency.

◆ Suspend I/O to the standard device until the SPLIT operation completes. In Enginuity 5x67 and higher, TF/Mirror always issues Instant SPLITs. This results in a much shorter suspend I/O time.

◆ Destage any write pendings to the standard device and the BCV device.

◆ Split the BCV device from the BCV pair. In the case of either a differential or reverse differential split, SPLIT automatically opens an internal Symmetrix Differential Data Facility (SDDF) session on the standard device. The SDDF session begins to log track changes on the standard device after the standard and BCV devices are established. Second and subsequent differential or reverse differential splits benefit from the SDDF session because it enables only those changed tracks to be copied:

• To the BCV local or remote mirrors (differential split)

• From the BCV local or remote mirrors (reverse differential split)

M1 M2 BCV

Host

Symmetrix

Vol A Vol B

SPLIT

SPLIT command operations 37


The SDDF session is removed on the first non-differential or reverse non-differential SPLIT operation.

◆ Change the BCV device state to ready, enabling host access through its separate address (VOL B).

◆ Resume operation with the standard device and flag any new writes to the standard device. This is necessary for updating the BCV device if it is reestablished with the same standard device at a later time.

After you finish running any business continuance processes on the BCV device, the following options are available:

◆ Reestablish the BCV pair.

Note: You have the option to establish a new BCV pair (consisting of the same BCV device but with a different standard device).

◆ Restore data to the standard device from the BCV device.

◆ Incrementally restore data to the standard device from the BCV device.

“RE-ESTABLISH command operations” on page 40 and “RESTORE command operations” on page 42 describe these TF/Mirror operations (and their matching commands).

Controller-level ECA ClearTimeFinder has been enhanced optionally to Clear ECA on a controller basis for an RMT Consistent SPLIT when polling has completed for all BCVs on the controller. To enable controller level ECA Clear for a RMT Consistent SPLIT, specify the GLOBAL parameter CONS(ECACLEAR(CONTROLLER)). The default value is SEQLEVEL. When you choose the default SEQLEVEL, the clearing of ECA windows is deferred until all of the Consistent SPLIT requests at the current sequence level are processed.

CNTRL is an alias for CONTROLLER and SEQLVL for SEQLEVEL.

Remote Consistent SPLITs

Remote consistency allows you to execute a Consistent SPLIT of TF/Mirror BCVs in an SRDF/S or SRDF/A environment where the BCV is attached to any SRDF device. The BCV can be in a locally attached Symmetrix system or in a Symmetrix system up to two hops away.

If an SRDF/S R2 device with which the BCV is established is active on the SRDF link, the remote Consistent SPLIT function of TF/Mirror automatically locates the Symmetrix system that contains the associated R1 (up to three hops away) and sets ECA accordingly in that Symmetrix system before performing the SPLIT operation.

If an SRDF/S R2 device with which the BCV is established is not active on the SRDF link, TF/Mirror sets ECA in the Symmetrix system containing the SRDF/S R2 device before performing the SPLIT operation.

If an SRDF/A R2 device with which the BCV is established is active on the SRDF link, the remote Consistent SPLIT function of TF/Mirror suspends the SRDF/A delta set switch process in the R2 Symmetrix system before performing the SPLIT operation.



For example, assume site A is where the SRDF/S R1s are located and site B is where the SRDF/S R2s and attached BCVs are located. A host at site C running TF/Mirror can issue the remote Consistent SPLIT to the BCVs in site B (two hops away), and TF/Mirror locates the R1s in site A (three hops away) and sets ECA there before performing the split in site B.

For MSC:

TimeFinder/Mirror checks if the MSC session is globally consistent. When global consistency cannot be guaranteed, TimeFinder/Mirror issues the BCVM169W (or BCVI119E, depending on the MAXRC parameter value of the GLOBAL command.

If the R2 STDs of the STD/BCV pair are in multiple SRDF/A groups, MSC for thesegroups is required. If these SRDF/A groups are not in one active MSC group,consistency cannot be guaranteed. TimeFinder/Mirror issues the BCVI150W messageand performs a non-consistent SPLIT if MAXRC is >= 4 or issues the BCVI150E messageand stops processing when MAXRC is less than 4 (the MAXRC value is a parameter ofthe GLOBAL command).

Multi-hop consistent split

Starting with V7.0, TF/Mirror allows you to perform two-hop (at a maximum) remote consistent splits. To do so, use the multi-hop list syntax you would use for any multi-hop operation, but with the CONS (consistent) parameter form.

The following example issues a multi-hop consistent split using ECA I/O control. The example issues the command through cuu 9A10 and RDF group 50. Then, the command hops through RDF group 13 and issues the consistent split to the EF8 through EF9 range of devices.

SPLIT 64,RMT(9A10,EF8-EF9,50.13),CONS(GLOBAL(ECA))

SPLIT with Protected RESTOREs

A Protected RESTORE is one in which a BCV is protected against host writes to its companion standard device until the next SPLIT command is issued. By default, you may have to set the SPLIT command PROTECTEDRESTORE parameter to Y when you issue a SPLIT after a Protected RESTORE. However, you can set the GLOBAL command PROTECTEDRESTORE parameter to preclude the need to do this.

“Protected RESTOREs” on page 43 provides more information about the PROTECTEDRESTORE parameter available with RESTORE, GLOBAL, and SPLIT.

SPLIT under Enginuity 5874 and higher

Under Enginuity 5874, SPLIT uses clone emulation for all functions. SPLIT:

◆ Captures a point-in-time image of the source volume.

◆ Causes the BCV volume to become Ready to the host as an instant point-in-time copy.

Table 5 on page 48 provides more information about how SPLIT maps to the TF/Clone Mainframe SNAP Facility command structure.

SPLIT command operations 39


You cannot use the BCVREFRESH parameter on the SPLIT command. A BCVREFRESH(Y) included on a SPLIT returns a BCVM138W warning message and a return code of four (4) when no MAXRC is coded.

You do not need to use the PROTECTEDRESTORE parameter with the SPLIT command after a Protected RESTORE. Under clone emulation, all RESTORE operations are Protected RESTOREs. In such a situation, the SPLIT PROTECTEDRESTORE parameter is ignored.

Note: “SPLIT” on page 121 provides more information about the SPLIT command and the BCVREFRESH and PROTECTEDRESTORE parameters.

There are also several important general differences between TF/Mirror 7.0 with Enginuity 5874 and lower versions that you should keep in mind. “Using clone emulation mode with Enginuity 5874 and higher” on page 47 discusses these differences.

RE-ESTABLISH command operationsRE-ESTABLISHING a BCV pair (Figure 7) accomplishes the same result as the ESTABLISH operation, with one time-saving exception: the standard device (VOL A) copies to the BCV device only new data updated on the standard device while the BCV pair was split. Any changed tracks on the BCV are also overwritten by the data on the corresponding track on the standard device. This operation maximizes the efficiency of the synchronization.

Note: The information necessary for a restore is lost (necessitating a full copy from the BCV mirror) if a spare is invoked against a standard device, then removed while the standard device is split from the BCV device.

This operation is useful if the data yielded from running an application on the BCV device is not needed or if a fresh copy of current data is needed.

Figure 7 Re-establishing a BCV pair

M1 M2 M3

Host

Symmetrix

Sync

BCV Not Ready

Vol A Vol B

RE-ESTABLISH



RE-ESTABLISH functions

When receiving a RE-ESTABLISH command from the host, a Symmetrix system performs the following functions on the standard and BCV devices specified by the command:

◆ Check command validity. For example, reject the command if the BCV device and the standard device are not the same size, or they were not previously paired.

◆ Set the BCV device Not Ready and offline to the host.

◆ Assign the BCV device as the next available mirror of the standard device.

◆ Copy the tracks from the standard device to the BCV. Any new data written to the standard device while the BCV pair was split are written to the BCV device. Any new data written to the BCV device while the BCV pair was split are overwritten by the data on the corresponding track on the standard device.

The BCV pair is synchronized when the standard device and the BCV device contain identical data.

Note: The BCV device is not available for host use during the time that it is assigned as a BCV mirror to a standard device. However, any new data written to the standard device is copied to the BCV device while the BCV pair exists.

To use a BCV device for business continuance procedures, you must again split the BCV pair to make the BCV device available to its host. To use a fully synchronized copy of the data:

◆ Suspend all applications that are using the standard device.

◆ Make sure that all host buffering and intermediate caching is flushed to the appropriate logical device on the Symmetrix system before performing the SPLIT operation.

If you do not require a coherent copy of the data for running a business continuance process, this step is unnecessary.

RE-ESTABLISH multi-attach

Starting with Enginuity 5x71, TF/Mirror includes a new multi-attach feature. Multi-attach allows multiple device pairs to be attached on the same RE-ESTABLISH command syscalls.

You control multi-attach through:

◆ The MULTIATTach(NONE|ALL|EST|REEST) parameter on the GLOBAL command

◆ The MULTIATTach(Yes|No) parameter on the RE-ESTABLISH command

Note: “ESTABLISH multi-attach” on page 35, “GLOBAL” on page 89, and “RE-ESTABLISH” on page 107 describe these commands.

RE-ESTABLISH command operations 41


RE-ESTABLISH under Enginuity 5874 and higher

Under Enginuity 5874, RE-ESTABLISH uses clone emulation for all functions. There are several other important general differences between TF/Mirror 7.0 with Enginuity 5874 and lower versions that you should keep in mind. “Using clone emulation mode with Enginuity 5874 and higher” on page 47 discusses these differences.

RESTORE command operationsRESTORE operations differ from the ESTABLISH or RE-ESTABLISH operations in that the entire contents of the BCV device are copied to the standard device.

RESTORE functions

When receiving a RESTORE command from the host, Symmetrix systems perform the following functions:

◆ Check command validity. For example, reject the command if the BCV device and the standard device are not the same size.

◆ Set the BCV device Not Ready to the host.

◆ Assign the BCV as the next available mirror of the standard device.

◆ Copy the contents of the BCV device to the standard device and all its mirrors. For example, in Figure 8, the Symmetrix system copies the contents of M3 to both M1 and M2, overwriting the data present on those devices.

The restoration process (Figure 8 on page 42) is complete when the standard device and BCV device contain identical data.

Figure 8 Restoring a BCV device

M1 M2 M3

Host

Symmetrix

Copy

BCVNot Ready

Vol A Vol B

RESTORE



Note: The BCV device is not available for host use during the time that it is assigned as a BCV to a standard device. However, any new data written to the standard device is copied to the BCV device while the standard-BCV pair exists, unless the RESTORE is a Protected RESTORE.

To use a BCV device for business continuance procedures, split the BCV pair again to make the BCV device available to its host. To use a fully synchronized copy of the data, perform either of the following options:

◆ Suspend all applications that are using the standard device, and make sure that all host buffering and intermediate caching is flushed to the appropriate logical device on the Symmetrix system before performing the SPLIT operation. If you do not require a consistent copy of the data for running a business continuance process, this step is unnecessary.

◆ To continue operation on the standard device and protect the image on the BCV, perform a RESTORE. The BCV remains protected against changes to the standard, until an ESTABLISH or RE-ESTABLISH command is executed.

You can perform additional RESTOREs from the protected image on the BCV. This is useful for situations where the standard device may need to be returned to the point of the previous SPLIT operation.

Protected RESTOREs

A Protected RESTORE is one in which a BCV is protected against host writes to its companion standard device until the next SPLIT command is issued. TF/Mirror has several parameters that help you handle Protected RESTOREs:

◆ PROTECTEDRESTORE on the RESTORE command

◆ PROTECTEDRESTORE on the GLOBAL command

◆ PROTECTEDRESTORE on the SPLIT command

If you set the PROTECTEDRESTORE parameter on the RESTORE command to YES, the restore process is protected against host writes on its related standard device until the next SPLIT command executes.

You can then control how TF/Mirror handles that next SPLIT command through the GLOBAL command PROTECTEDRESTORE parameter. The GLOBAL PROTECTEDRESTORE has three possible keywords:

◆ REQUEST

◆ CLONE

◆ ALLBCV

REQUEST is the default. If you do not set the GLOBAL PROTECTEDRESTORE, or if you specifically set the GLOBAL PROTECTEDRESTORE to REQUEST, you need to set the SPLIT command PROTECTEDRESTORE parameter to Yes after any Protected RESTORE.

If you set the GLOBAL PROTECTEDRESTORE to CLONE, you do not need to set the SPLIT command PROTECTEDRESTORE parameter to Yes after a clone emulation RESTORE. (With clone emulation mode, restores are always protected.)

RESTORE command operations 43


If you set the PROTECTEDRESTORE to ALLBCV, you do not need to set the SPLIT command PROTECTEDRESTORE parameter to Yes after any kind of Protected RESTORE.

PROTECTEDRESTORE abbreviationsYou can use any of the following abbreviations for the PROTECTEDRESTORE parameters on the RESTORE, GLOBAL, and SPLIT commands:

◆ PROTRESTORE

◆ PROTRSTR

◆ PRSTR

◆ PROT

RESTORE under Enginuity 5874 and higher

Under Enginuity 5874, RESTORE uses clone emulation for all functions. Keep in mind the following points when you use RESTORE under TF/Mirror Version 7.0 with Enginuity 5874:

◆ All RESTORE operations are Protected RESTOREs. To handle Protected RESTOREs, you do not need to set the RESTORE, GLOBAL, or SPLIT PROTECTEDRESTORE parameters. TF/Mirror ignores these parameters.

◆ TF/Mirror accepts a RESTORE only if all tracks were copied from the source device before the RESTORE operation was initiated.

◆ All blocks that previously prevented concurrent TF/Mirror restores and R2 to R1 synchronization are removed. You can perform an SRDF R2 to R1 synchronization if a Clone Emulation RESTORE operation to the R2 is in progress.

“RESTORE/ Incremental RESTORE” on page 70 provides more information.

There are also several important general differences between TF/Mirror 7.0 with Enginuity 5874 and lower versions that you should keep in mind. “Using clone emulation mode with Enginuity 5874 and higher” on page 47 discusses these differences. Table 5 on page 48 provides more information about how RESTORE maps to the TF/Clone Mainframe SNAP Facility command structure.

Incremental RESTORE command operationsIncremental RESTORE operations (Figure 9 on page 45) accomplish the same thing as RESTORE operations with one time-saving exception: the BCV (VOL B) copies to the standard device (VOL A) only any data that was updated on the BCV device while the BCV pair was split.

Any changed tracks on the standard device are also overwritten by the data on the corresponding track on the BCV device. This maximizes the efficiency of the synchronization process.

Note: The information necessary for an Incremental RESTORE is lost (necessitating a full copy from the BCV mirror) if a spare is invoked against a standard device and then removed while the standard device is split from the BCV device.



This process is useful if the results from running a new application on the BCV device were desirable, and if you want to port the data and the new application to the standard device.

Figure 9 Incrementally restoring a BCV device

Incremental RESTORE functions

When receiving an Incremental RESTORE from the host, Symmetrix systems perform the following functions on the standard and BCV devices specified:

◆ Check command validity. For example, reject the command if the BCV device and the standard device are not the same size or were not previously paired.

◆ Set the BCV device Not Ready to the host.

◆ Assign the BCV device as the next available mirror of the standard device.

◆ Copy the tracks from the BCV device to the standard device. Any new data written to the BCV device while the BCV pair was split are written to the standard device. Any new data written to the standard device while the BCV pair was split are overwritten by the data on the corresponding track on the BCV device.

The BCV pair is synchronized when the standard device and the BCV device contain identical data.

Note: The BCV device is not available for host use during the time that it is assigned as a BCV mirror on a standard device. However, any new data written to the standard device is copied to the BCV device while the BCV pair exists.

To use a BCV device for business continuance procedures, split the BCV pair again to make the BCV device available to its host. To use a fully synchronized copy of the data, suspend all applications that are using the standard device.

Also, make sure that all host buffering and intermediate caching is flushed to the appropriate logical device on the Symmetrix system before performing the SPLIT operation. If you do not require a coherent copy of the data for running a business continuance process, this step is unnecessary.

M1 M2 M3

Host

BCV Not Ready

Sync

Symmetrix

Vol A Vol B

INCR RESTORE

Incremental RESTORE command operations 45


Incremental RESTORE under Enginuity 5874 and higher

Under Enginuity 5874, RESTORE uses clone emulation for all functions. Keep in mind the following points when you use RESTORE under TF/Mirror Version 7.0 with Enginuity 5874:

◆ All RESTORE operations are Protected RESTOREs.

◆ TF/Mirror accepts an Incremental RESTORE only if all tracks were copied from the STD device before the RESTORE operation was initiated.

◆ All blocks that previously prevented concurrent TF/Mirror restores and R2 to R1 synchronization are removed. You can perform an SRDF R2 to R1 synchronization if a Clone Emulation RESTORE operation to the R2 is in progress.

“RESTORE/ Incremental RESTORE” on page 70 provides more information.

There are also several important general differences between TF/Mirror 7.0 with Enginuity 5874 and lower versions that you should keep in mind. “Using clone emulation mode with Enginuity 5874 and higher” on page 47 discusses these differences. Table 5 on page 48 provides more information about how RESTORE maps to the TF/Clone Mainframe SNAP Facility command structure.

QUERY command operationsQUERY operations report the status of BCV devices in the Symmetrix system. You can use the reported information to assist in performing business continuance operations.

Symmetrix systems respond to a valid QUERY command by returning device records for each BCV defined.

Basic queries

The QUERY command provides the following information:

◆ BCV device number

◆ BCV attribute

◆ Standard device number (only valid for BCVs that have been paired)

◆ Number of tracks left to copy

◆ Number of cylinders on the BCV

◆ Mirror protection type

◆ BCV availability states:

• The BCV device is available for use, and was never paired. Only the BCV device number is valid.

• The BCV device is available for use, and was last paired to the standard device whose number was returned and was fully synchronized.

• The BCV device is available for use, and was last paired to the standard device whose number was returned, but it was not fully synchronized.



• The BCV pair is established/restored, the standard device number is valid, and the BCV mirror is fully synchronized.

• The BCV pair is established/restored, the standard device number is valid, and the BCV mirror is being synchronized. Therefore, the invalid track count is accurate.

• A split is in progress, and the returned standard device number is valid.

• The BCV device was reserved with the Hold option. This was done either through a SPLIT with the HOLD parameter, or a CONFIG action. To release the BCV for standard TF/Mirror operations, run a CONFIG action with RELEASE specified.

Extended queries

To specify an extended query with the QUERY command, use the Extended(Y) parameter. In this case, the extended format QUERY display is sorted in order by the standard device and the time since the split. The display begins with the first BCV that has had a BCV/standard relationship. BCVs that do not have an BCV/standard relationship are not displayed.

However, if you also specify the keyword SBCV with the Extended parameter (Extended (Y, SBCV)), then the display begins with the BCV whose Symmetrix device number you specified in the QUERY symdv# parameter.

Clone Emulation modeClone Emulation mode is a mapping procedure designed to make the use of RAID-protected BCVs transparent to the TF/Mirror user.

Under Clone Emulation mode, an internal API function converts TF/Mirror commands to EMC TF/Clone Mainframe SNAP Facility commands.

Using clone emulation mode with Enginuity 5874 and higher

If you are using Enginuity 5874 and higher, TF/Mirror uses Clone Emulation mode for all operations. There are some differences, discussed in the following sections, that you need to keep in mind when using Enginuity 5874.

License requirements prior to Enginuity 5874TF/Mirror issues error message BCVM142E (as well as possible operation-specific messages) and does not execute if the License Feature Code keys for TF/Clone, and TF/Consistency Group (required if you are performing Consistent SPLIT operations) have not been installed in the initialization parameters file of ResourcePak Base.

License requirements for Enginuity 5875 and higherStarting with Enginuity 5875 and higher, the eLicense entitlement for TF/Clone only needs to be checked to ensure it is enabled. The license for TF/Consistency Group is still required if you are performing Consistent SPLIT oerations.

Clone Emulation mode 47


Note: The EMC Mainframe Enablers Installation and Configuration Guide and the EMC ResourcePak Base for z/OS Product Guide provide more information about eLicensing or installing License Feature Code keys.

Command mappingUnder Enginuity 5874 and higher, TF/Mirror commands map to TF/Clone Mainframe SNAP Facility commands. Table 5 summarizes the mapping of TF/Mirror commands to TF/Clone Mainframe SNAP Facility commands:

CBCV parameterThe ESTABLISH and RE-ESTABLISH CBCV parameter is not needed for clone emulation.

Mirrors and clone emulationMirrors are not required or used with clone emulation.

Diskless RDF devicesTF/Mirror 7.0 with Enginuity 5874 recognizes diskless RDF devices; but, does not perform operations against diskless RDF devices. If you attempt to issue a command against a diskless RDF device, TF/Mirror logs an error.

Thin devicesTF/Mirror supports thin devices beginning with Enginuity 5874 or higher. A thin device can be an STD or BCV device. Prior versions do not support thin device operations.

Extended address volumesUnder Enginuity 5874, TF/Mirror can perform operations against extended address volumes (EAVs)

Multi-device operationsFor TF/Mirror clone emulation only, when multiple device requests are specified together on ESTABLISH, SPLIT, and RESTORE commands, or on the DELINC parameter of the CONIFG command, TF/Mirror uses the new multi-device syscalls to process the requests together. These operations do not require any syntax changes. However, they should provide improved performance.

Note: The new multi-device syscalls are not processed together for non-clone TF Mirror operations.

Table 5 TF/Mirror mapping operations: Enginuity 5874 and higher

TF/Mirror command TF/Clone MainFrame SNAP Facility command

ESTABLISH SNAP VOLUME PRECOPY(YES) DIFFERENTIAL (YES)

RE-ESTABLISH SNAP VOLUME DIFFERENTIAL (YES)

RESTORE SNAP VOLUME DIFFERENTIAL(YES)

SPLIT ACTIVATE



Cascaded clone emulation operationsStarting with Enginuity 5874, TF/Clone Mainframe SNAP Facility allows for cascaded clone operations. This allows a clone operation to take place with a device that is already involved in a clone operation without ending the first clone session.

For instance, as shown in Figure 10, you can use TF/Clone Mainframe SNAP Facility to clone device A to device B. Then, while the relationship between A and B is preserved, clone device B to device C.

Figure 10 Cascaded clone operation

Note: The EMC TimeFinder/Clone Mainframe SNAP Facility Product Guide provides more information about cascaded operations.

Enginuity 5874 allows a cascaded-like operation for clone emulation. Under Enginuity 5874, you can cascade from a device involved in a clone operation to a device involved in a clone emulation operation as shown in Figure 11 on page 49.

Figure 11 Cascaded clone to cascaded clone emulation

However, as shown in Figure 12, you cannot cascade from a device involved in a clone emulation operation to a device involved in a clone operation.

Figure 12 Cascaded clone emulation to cascaded clone

Clone 1: The relationship between A and B is preserved, allowing differential resynchronization following clone 2.

Clone 2: Operation is allowed after Clone 1 copy is finished.

A B C

Clone 1: The relationship between A and B is preserved, allowing differential resynchronization following clone emulation 2.

Clone Emulation 2: Operation is allowed after Clone 1 copy is finished .

A B C

Clone Emulation 1. Clone 2: Operation is not allowed..

A B C



For instance, you can use TF/Clone MainFrame SNAP Facility to clone device xxx to a STD device. Then, after the clone operation is complete, but while the clone session is still active, use TF/Mirror clone emulation to clone the STD device to a BCV.

However, you cannot use TF/Clone MainFrame SNAP Facility to clone the BCV to device yyy. This last would be a cascade from an active clone emulation session to an active clone session.

In addition, as shown in Figure 13 on page 50, operations A to B and B to C cannot both be clone emulation.

Figure 13 Cascaded clone emulation to cascaded clone emulation

Note: This limitation only exists for cascaded clone emulations, where one clone session passes data on to the next session connected to it. Concurrent BCV and MultBCV use a one-to-many relationship, where one STD is the source for two or more BCVs.

Example

Consider the following more complex example of cascading from an device to an use TF/Clone Mainframe SNAP Facility to clone from a device to an STD device and then using clone emulation to copy from the STD device to a BCV:

1. A user employs TF/Mirror clone emulation to establish a pairing of an STD device and a BCV device.

2. The user needs to update the STD with any data on device AAA that has changed during a specified time period. The user employs TF/Clone Mainframe SNAP Facility to perform a differential SNAP VOLUME from device AAA to the STD device.

3. The user ensures that all background copy operations have completed.

4. The user splits the STD and the BCV.

5. The user ensures that the background copy has completed and that the changes are on the BCV.

6. The user issues a DELINC to remove the STD and BCV association.

Note: Refer to “CONFIG” on page 76 for more information about DELINC.

Requirements

There are a few requirements to keep in mind TF/Mirror clone emulation as part of a cascaded clone operation:

◆ There cannot be any indirect tracks on the STD device.

◆ There cannot be any protected tracks on the BCV device.

Clone Emulation 1. Clone Emulation 2: Operation is not allowed..

A B C



◆ A virtual device (VDEV) cannot have a relationship with an BCV device.

◆ If the new source device is already a target of another operation, the corresponding session must be active.

◆ You cannot use clone emulation to cascade clone emulation. However, you can use clone emulation to cascade from a regular clone session.

Command-specific differences In addition to the general differences and restrictions outlined in the previous sections, TF/Mirror Version 7.0 with Enginuity 5874 has some command-specific differences. You can find them discussed in:

◆ “ESTABLISH under Enginuity 5874 and higher” on page 36.

◆ “SPLIT under Enginuity 5874 and higher” on page 39.

◆ “RE-ESTABLISH under Enginuity 5874 and higher” on page 41.

◆ “RESTORE under Enginuity 5874 and higher” on page 44.

◆ “Incremental RESTORE under Enginuity 5874 and higher” on page 46.

Using Clone Emulation with Enginuity 5773 and lower

If you are using Enginuity 5773 and lower, TF/Mirror uses Clone Emulation with RAID 5 or RAID 6 BCVs in all instances. The only specific step you need to take is to install TF/Clone Mainframe SNAP Facility.

Starting with Version 5.5, TF/Mirror supports using clone emulation with non-RAID 5 or RAID 6 BCVs in the following situations:

◆ With commands that establish Clone Emulation mode on a BCV (ESTABLISH or a full RESTORE).

◆ With incremental commands (RE-ESTABLISH and Incremental RESTORE) and SPLIT commands for BCVs that already have a Clone Emulation mode session initiated by a prior ESTABLISH or full RESTORE.

To use clone emulation for non-RAID 5 and non-RAID 6 BCVs either:

◆ Set the GLOBAL parameter CLONEemulation to ALLBCV.

◆ Set the GLOBAL parameter CLONEemulation to REQUEST.

ALLBCVCLONEemulation(ALLBCV) specifies that:

◆ Clone emulation is to be used with any ESTABLISH or full RESTORE commands that you issue regardless of the BCV type.

◆ Clone emulation is to be used with any SPLIT and incremental operations (RE-ESTABLISH and Incremental RESTORE) that are part of a clone emulation session established by a prior, related ESTABLISH or full RESTORE.

For SPLIT and incremental operations that do not have a clone emulation session, TF/Mirror does not use clone-emulation mode.



REQUESTCLONEemulation(REQUEST) requires that you take specific steps to initiate a clone emulation session. CLONEemulation(REQUEST) specifies that:

◆ Clone emulation is to be used with any ESTABLISH or full RESTORE commands that you issue if you append a CLONEemulation(YES) parameter with the ESTABLISH or full RESTORE command.

◆ Clone emulation is to be used with any SPLIT and incremental operations (RE-ESTABLISH and Incremental RESTORE) that are part of a clone emulation session established by a prior, related ESTABLISH or RESTORE on which you have appended a CLONEemulation(YES) parameter.

◆ Clone emulation is not to be used for any ESTABLISH or RESTORE commands that do not have an appended CLONEemulation(Yes).

◆ Clone emulation is not to be used for SPLIT or incremental operations (RE-ESTABLISH and Incremental RESTORE) that are not part of a previously established clone emulation session.



Command mappingUnder Enginuity 5773 and lower, TF/Mirror commands map to TF/Clone Mainframe SNAP Facility commands. Table 6 summarizes the mapping of TF/Mirror commands to TF/Clone Mainframe SNAP Facility commands.

Limitations and differencesThe underlying differences in the way TF/Clone Mainframe SNAP Facility and TF/Mirror make copies creates some limitations that are based on the mirror architecture of traditional BCV technology. The following differences exist for BCVs manipulated using clone emulation mode:

◆ Mirror positions are neither required or used.

◆ BCVREFRESH options on SPLIT operations are not supported. A BCVREFRESH(Y) included on a SPLIT returns a BCVM138W warning message and a return code of four (4) when no MAXRC is coded.

◆ All BCV ESTABLISH operations are protected ESTABLISH operations.

◆ All RESTORE operations are Protected RESTOREs.

◆ A RESTORE or Incremental RESTORE operation can be accepted only if all tracks were copied from the source device prior to initiating the RESTORE operation.

◆ TF/Clone emulation supports thin devices (starting with Enginuity 5874 or higher). A thin device can be an STD or BCV device. Prior versions do not support thin device operations.

◆ The HOLD attribute (signifying that a device is Not Ready for operations) does not appear on the BCV REPORT for BCVs in a clone emulation session.

Clone emulation support requirementsIf the available TF/Mirror maintenance, TF/Clone, TF/Consistency Group (required if you are performing consistency operations) or their eLicense or License Feature Codes are not present when you attempt a clone emulation operation, you receive message BCVM142E as well as additional operation-specific messages.

Note: The EMC Mainframe Enablers Message and Code Guide contains further descriptions of these messages.

Table 6 TF/Mirror mapping operations: Enginuity 5773 and lower

TF/Mirror command TF/Clone MainFrame SNAP Facility command

ESTABLISH SNAP VOLUME PRECOPY(YES) DIFFERENTIAL (YES)

RE-ESTABLISH SNAP VOLUME DIFFERENTIAL (YES)

RESTORE SNAP VOLUME DIFFERENTIAL(YES)

SPLIT ACTIVATE



TF/Mirror clone emulation and security

EMC TF/Clone Mainframe SNAP Facility has implemented an option for enhanced SAF security checking using the XFACILIT resource class. This means that TF/Mirror operations that invoke clone emulation may be affected.

Note: Chapter 4 of the EMC Mainframe Enablers Installation and Customization Guide provides more information about enhanced security checking.

Validating standard and BCV devices On systems using Enginuity 5773 and lower, TF/Mirror verifies that the devices specified in commands are BCV and standard devices. Table 7 lists the scope of checking performed for each command.

Note: Validating standard and BCV devices can be bypassed using the SAF Security Interface. EMC Mainframe Enablers Installation and Customization Guide describes the SAF Security Interface.

1. Local Only = Device validation is only performed on the host issuing the TF/Mirror command.

2. None = No device validation is performed.

3. All Hosts = Device validation is performed on all hosts by checking the path groups to the device.

4. N/A = Not applicable — device validation not required.

The type of validation performed depends on the Enginuity version. Device validation (also referred to as online checking) is not supported in Enginuity levels 5x64.23.xx, 5x64.24.xx, or 5x64.25.xx. If your Symmetrix system is running one of these Enginuity versions, have your EMC Customer Service engineer upgrade to the current Enginuity version.

Table 7 Standard and BCV device validation

TF/Mirror commands

Enginuity 5x63 Enginuity 5x64 or higher

BCV check STD check BCV check STD check

ESTABLISH Local Only a N/A d All Hosts c N/A

ESTABLISH DSN None b N/A All Hosts N/A

RE-ESTABLISH Local Only N/A All Hosts N/A

RE-ESTABLISH DSN None N/A All Hosts N/A

Incremental RESTORE Local Only N/A All Hosts N/A

Incremental RESTORE DSN None N/A All Hosts N/A

RESTORE Local Only Local Only All Hosts All Hosts



Device parameter requirementsTable 8 on page 55 shows the commands and their relationship with the basic parameters that specify standard and BCV devices when you are not using the DSN or RMT format. Table 8 uses the following terms.

Note: When using the DSN option, cuup and cuus are not applicable. Volumes are located using the DSN only.

1. This command can be run against any device (standard or BCV) on the controller.

2. When using LCL and RMT, cuus should be replaced with sym#bcv.

3. When using LCL and RMT, cuup should be replace with sym#std.

4. CONFIG RELEASE, CONFIG HOLD and CONFIG DELINC may be used against a standard device.

Note: The operations you perform against the BCVs may alter the change bits and the last reference date in the VTOC. This information is not reflected back to the standard device, unless you execute a RESTORE command.

Setting and clearing explicit device holdsThe CONFIG command parameters, HOLD and RELEASE work together to set and clear device holds for both BCV and STD devices.

Placing a hold on a device

You can use the HOLD parameter to obtain an explicit hold on the devices specified in the CONFIG command. HOLD can be used for both BCS and STD devices. After you place a CONFIG HOLD on a device:

◆ You cannot make that device the object of an ESTABLISH, RE-ESTABLISH, RESTORE, or SPLIT command. If you try, you receive an error (BCVM146E).

◆ You no longer see the STD to which the BCV is paired on standard QUERY reports.

cuup A parameter that specifies the z/OS device number of the standard device.

cuus parameter A parameter that specifies the z/OS device number of the BCV device.

WAIT parameter A parameter that specifies whether to wait for the action to complete.

Table 8 Valid command relationships

Action cuus b cuup c WAIT

QUERY a N/A N/A N/A

ESTABLISH Required Required Y/N

RE-ESTABLISH Required N/A Y/N

SPLIT Required N/A Y/N

RESTORE Required Optional Y/N

CONFIG Required N/A d N/A

Device parameter requirements 55


Consider the following example. Notice in the following QUERY that, after the HOLD is placed on the device, you no longer see the STD with which the BCV is paired.

BCVI018I (0001) QUERY 1,861F,4,480 BCVM004I QUERY STATUS ON DEVICE 861F, MICRO-CODE LEVEL 5X75 TYPE VMAX-1, S/N 0001926-00304...BCV... ...STD... ACTION LAST PROT MIRROR BCV CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYLS TYPE SYNC MODE---- 0480 0 0 HOLD-U 0480 3390 1113 R1 YES CLONE---- 0481 0 0 HOLD-U 0481 3390 1113 R1 YES CLONE---- 0482 0 0 HOLD-T 0482 3390 1113 R1 YES CLONE---- 0483 0 0 HOLD-T 0483 3390 1113 R1 YES CLONE BCVM047I ALL CONTROL STATEMENTS PROCESSED, HIGHEST RC 0 END OF DISPLAY

The HOLD-U status indicates a “user hold.” A user hold is one in which a user issued a CONFIG HOLD against the device. (The HOLD-T indicates that the device is the target of a SNAP operation.)

Releasing a hold on a device

To release the device, issue a CONFIG RELEASE. CONFIG RELEASE releases the HOLD device lock and the TF/Clone Mainframe SNAP Facility (fsmmf) hold.

Additional business continuance operationsThe following sections provide an introduction to other business continuance available with TF/Mirror.

Note: For clarity, there is one significant difference between MultBCV, Concurrent BCV and Cascaded Clone emulation sessions. Concurrent BCV and MultBCV sessions allow a one-to-many relationship, where one STD is the source for two or more BCVs. However, with Cascaded Clone emulations, there is a limitation where only one clone session is allowed to pass data on to the next session connected to it.

MultBCV

The MultBCV (available at Enginuity level 5x66 and higher) feature permits a standard device to keep track of changes to multiple BCVs to interleave RE-ESTABLISH (or RESTORE) and DIFFERENTIAL SPLIT commands. MultBCV uses the Symmetrix Differential Data Facility (SDDF) sessions to track changes, opening one session for each BCV that attaches to a standard device.

With clone emulation you can ESTABLISH 8 BCVs to the same STD at the same time. A 9th one causes an error. This ESTABLISH limitation works regardless if MULTBCV is coded or not. However, If you try to establish a non-cloned BCV to a STD, you have to SPLIT it before the 2nd one will work, otherwise TF/Mirror issues one of several potential messages appropriate for the specific error condition.

The differences in Enginuity support for clone and non-clone MultBCV operations are:

◆ For non-clone operations with Enginuity levels lower than 5874, a maximum of 8 BCVs can be paired to the same STD, one at a time.



◆ For clone operations, with Enginuity levels lower than 5874, a maximum of 8 BCVs all at the same time, or only 6 BCVs one at a time can be paired to the same STD.

◆ With Enginuity levels 5874 and higher, clone emulation is used for all TF/M operations. Therefore, the clone operations maximum of 8 BCVs all at the same time and a maximum of only 6 BCVs one at a time can be paired to the same STD.

Concurrent BCV

Concurrent BCV (available at Enginuity level 5x67 and higher) has two BCV devices and one standard device.

In Enginuity level 5x67, the two BCV devices can be established individually, but are split as a pair. In Enginuity level 5x68. the two BCV devices can be split independently. The standard device can have any mirror structure (normal RAID 1, RAID S, RAID 5, RAID 6, RAID 10, RAID 1 with SRDF), as long as the number of standard device mirrors does not exceed three. In the case of concurrent BCVs, two available mirror positions are required.

With Enginuity 5773, there can be three dynamic mirrors for each Symmetrix device, whether a standard or BCV. A dynamic mirror can be:

◆ A BCV

◆ A dynamic RDF mirror

◆ A dynamic spare mirror

◆ A dynamic relocation volume (DRV)

However, you can have, at most, two BCVs attached to a standard device. This limitation affects the number of BCVs that can attach to a standard device at the same time not using clone emulation.

This limitation is unrelated to MultBCV, where a single standard can have up to eight (only six for clone emulation when doing operations one at a time) BCV independent relationships.

Other restrictions include:

◆ RESTOREs (either incremental or full) cannot be issued if the standard device has an active BCV paired.

◆ A second concurrent BCV pair cannot be established or restored with the standard device if the first BCV pair was a Protected RESTORE.

◆ Protected BCV Establish is mutually exclusive with concurrent BCV because all the available mirror positions are used.

◆ A concurrent BCV is not allowed if the standard device is a Dynamic RDF device.

With clone emulation, you no longer have to set the CBCV parameter. and can have up to eight (8) BCVs with one STD.

R1BCV

An R1BCV is a BCV that also has the SRDF attribute. When an R1BCV is paired with a standard device, the R1BCV operates as a normal BCV. When an R1BCV is split from the standard device, the R1BCV is paired and synchronized with an R2 target according to the specified SRDF mode.

Additional business continuance operations 57


SRDF-connected BCV

An SRDF-connected BCV device resides on a remote Symmetrix system. Commands to control that remote BCV are sent by way of the host-connect (local) Symmetrix system to the remote Symmetrix system over the SRDF links (Figure 14 on page 58). A gatekeeper cuu is used to send the commands to the host-connect (local) Symmetrix system.

There are two types of SRDF-connected BCV devices:

◆ SRDF-connected BCVs paired with the R2 mirrors of local RDF standard devices (Figure 14 on page 58).

Figure 14 SRDF-connected BCV devices mirroring the local standard

◆ SRDF-connected BCVs paired with the R2 mirrors of the local RDF devices (Figure 15).

Site A Site B

Host

RDF Pair

I/O Transfer

RemoteSymmetrix

Symmetrix

BCV Pair

RemotelyAssociated

BCVRBCV01

Local(R1)

DEV001

LocalBCV

BCV001

Target(R2)

Device

Locally associated R1 BCVs: BCV001Remotely associated BCVs: RBCV01

SRDF Links



Figure 15 SRDF-connected BCV mirroring the local BCV

Parallel TimeFinder

Parallel TimeFinder gives you the capability of multi-tasking TimeFinder commands. You can control Parallel TimeFinder through the PARALLEL parameter on the GLOBAL command. You use PARALLEL to specify whether you want parallel processing and, if so, how many subtasks you want to allow.

If you allow parallel processing, the requests within each sequence level is divided among subtasks based on the following:

◆ All Instant SPLITs for the same Symmetrix system go to one subtask.

◆ All multi-attach requests for the same Symmetrix system go to one subtask.

◆ All config ready requests for consecutive devices in the same Symmetrix system go to one subtask.

◆ All config not ready requests for consecutive devices in the same Symmetrix system go to one subtask.

◆ All RMT commands to the same Symmetrix system through the same gatekeeper go to one subtask.

◆ All remaining requests are sent to separate subtasks unless the device and the Symmetrix system are the same as another request. In that case, the remaining requests are sent to the same subtask.

◆ If the dynamic subtask limit is reached, remaining requests are held and assigned to subtasks as they finish the already assigned work.

Site A Site B

Host

RDF Pair

I/O Transfer

RemoteSymmetrix

Symmetrix

BCV Pair

RemotelyAssociated

BCVRBCV01

Local(R1)

DEV001

LocalBCV

BCV001

Target(R2)

Device

Locally associated R1 BCVs: BCV001Remotely associated BCVs: RBCV01

SRDF Links

Additional business continuance operations 59


One consideration with parallel processing is that command output within a sequence level is no longer presented in the order the commands were input. The order in which the output appears is determined by the order in which the commands complete execution.

For example, if you have the following commands

(0002) SPLIT 5,1234(0003) CONFIG 5,1235,HOLD(0004) RESTORE 5,1236

The output might appear in order 0002, 0003, 0004 or 0002, 0004, 0003 or 0004, 0003, 0002 or any other permutation. If you must preserve execution order, take either of the following steps:

◆ Turn off parallel processing by setting PARALLEL to NO.

◆ Use distinct sequence levels.

In some cases, non-parallel TF/Mirror ends without processing all commands when a severe error occurs. Parallel TF/Mirror takes the same action in those circumstances, except that commands at the current sequence level that have already begun execution in another subtask continues until they end. However, new work is not dispatched after such a severe error has occurred.

Note: “GLOBAL” on page 89 provides more information about the PARALLEL parameter.

R21 device recognition

Starting with Version 5.6, TF/Mirror recognizes R21 devices. An R21 device is a dual-role SRDF R1/R2 device used in Cascaded SRDF.

Cascaded SRDF is a three-site disaster recovery configuration where data from a primary site is synchronously replicated to a secondary site, and then asynchronously replicated to a tertiary site. The core benefit behind a “cascaded” configuration is its inherent capability to continue replicating from the secondary site to the tertiary sites in the event that the primary site goes down. This enables a faster recovery at the tertiary site.

Located at the secondary site, the R21 device simultaneously acts as an R2 device to the primary site and as an R1 to the tertiary site.

Note that R21 devices need to be defined as Adaptive Copy devices. If you are using an R21 device as a standard device in a Consistent SPLIT, you need to specify the ALLOWNONSYNC parameter on a GLOBAL command.

Note: The EMC SRDF Host Component for z/OS Product Guide presents more information about Cascaded SRDF.



Concurrent R2 (R22) device recognition

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

TF/Mirror treats R22 devices like R2 devices. However, an R22 device cannot be a BCV device. Enginuity does not support BCVs with more than one RDF Mirror. If the R22 is diskless, all TF/Mirror operations is prevented.

Note: The SRDF Host Component for z/OS Product Guide provides more information about R22 devices.

Gatekeeper devices

You issue TF/Mirror commands either:

◆ Directly to the Symmetrix device being operated upon

◆ Through a Symmetrix device that is designated as a gatekeeper device

Issuing commands to a gatekeeper allows you to retrieve configuration and status information or perform a TF/Mirror function on a Symmetrix system without interfering with other operations that may temporarily block access to the standard or BCV device.

In TF/Mirror commands, the gatekeeper address is usually specified as cuu in LCL or RMT parameters and cuu_gatekeeper in the SRDF/AR SRCSTD statement.

Usually, the first available Symmetrix device is specified as a gatekeeper. Alternatively, you can use any addressable devices as a gatekeeper.

Note: The gatekeeper device should not be actively involved in the TF/Mirror command. For example, it should not be one of the STD devices in a Consistent SPLIT request.

TF/Mirror restrictions◆ To use the DSN keyword support, the Symmetrix Enginuity level on the controller must

be at 5x64.21.18 or higher.

◆ If you have a large number of devices to split and the split time is an issue, you can separate the SPLIT operations into multiple jobs to perform the operations in parallel.

◆ Take special care when performing BCV operations on a Symmetrix system attached to multiple hosts. During certain operations, the BCV device is unavailable to the host(s).

◆ The following operations require Enginuity level 5x66 and higher:

• CONFIG DELINC

• Extended Format Query

• Instant and Consistent SPLIT

◆ Concurrent BCV operations require Enginuity level 5x67 and higher.

TF/Mirror restrictions 61


◆ The following operations require the following Enginuity levels:

• Enginuity Consistency Assist (ECA) - 5x68 and higher

• Protected RESTORE - 5x70.50 and higher

• Protected BCV Establish - 5x70.50 (Not supported with RESTORE at 5x71)

• Parallel TimeFinder -- 5773 and higher


CHAPTER 3TimeFinder/Mirror With SRDF

Invisible Body Tag

This chapter explains how TF/Mirror operations on a Symmetrix Remote Data Facility (SRDF) system differ from those on a non-SRDF system.

◆ Symmetrix Remote Data Facility (SRDF) overview ..................................................... 64◆ Using BCVs with source (R1) devices ....................................................................... 67◆ Using BCVs with target (R2) devices......................................................................... 69◆ Remote operations.................................................................................................. 71

TimeFinder/Mirror With SRDF 63

TimeFinder/Mirror With SRDF

Symmetrix Remote Data Facility (SRDF) overviewSymmetrix Remote Data Facility (SRDF) is a business continuance solution that maintains a mirror image of data at the logical volume level in two or more Symmetrix systems located in physically separate sites.

Note: The description outlined in this section is a high-level overview that does not discuss many SRDF capabilities. The SRDF Host Component for z/OS Product Guide describes SRDF and its full capabilities.

Symmetrix SRDF offers the following major features and benefits:

◆ High data availability

◆ High performance

◆ Flexible configurations

◆ Host and applications software transparency

◆ Automatic recovery from a component or link failure

◆ Significantly reduced recovery time after a disaster

◆ Reduced backup and recovery costs

◆ Reduced disaster recovery complexity, planning, testing, and so forth

◆ Increased integrity of recovery procedures

SRDF is transparent to the host operating system and to host applications. SRDF does not require additional host software for duplicating data on Symmetrix systems at geographically separate sites. The participating Symmetrix systems manage all SRDF functions.

SRDF configurations

For synchronization and coordination of SRDF activity, the individual Symmetrix systems are designated as either:

◆ A primary (source) unit

◆ A secondary (target) unit

An SRDF configuration has at least one source unit and one target unit. Enginuity 5x67 and higher supports the ability for a single primary volume to be remotely mirrored to two secondary volumes concurrently, as shown in Figure 16.



Figure 16 Concurrent RDF

This feature is called Concurrent RDF and is supported in both ESCON and Fibre Channel RDF configurations.

SRDF configurations may transfer data either:

◆ Uni-directionally

◆ Bi-directionally

Figure 17 shows a uni-directional configuration.

Figure 17 SRDF uni-directional configuration

As shown in Figure 17, all primary (source R1) volumes in a uni-directional configuration reside in one Symmetrix system and all secondary (target R2) volumes in the other Symmetrix system. Data flows from the primary (source R1) volumes to the secondary (target R2) volumes in the respective Symmetrix systems under normal operating conditions.

Symmetrix B

R1

R2

R2

Symmetrix C

Symmetrix A

Symmetrix A Symmetrix B

R1

R1

R1

R2

R2

R2

Symmetrix Remote Data Facility (SRDF) overview 65


Figure 18 shows a bi-directional configuration.

Figure 18 SRDF bi-directional configuration

As shown in Figure 18 on page 66, both primary (source R1) and secondary (target R2) volumes in a bi-directional configuration reside in each Symmetrix system. Under normal operating conditions, data flows from the source R1 volumes in the respective Symmetrix system to the corresponding target R2 volumes in the other Symmetrix system.

With Enginuity 5x67 and higher, using Fibre Channel RDF connections, the SRDF configuration becomes more flexible with the introduction of RDF Groups. The synchronization direction is then managed at the RDF Group level, allowing a single Symmetrix system to be either a source, a target, or both source and target, depending on need and connectivity.

With Enginuity 5x68 and higher, these relationships can be dynamically configured. This is referred to as Dynamic RDF.

TF/Mirror and SRDF

Enginuity level 5x65 and higher releases include remote BCV control capabilities. This gives a host attached to the Symmetrix system at the source location the ability to perform TF/Mirror operations across SRDF links to devices in the Symmetrix system at a target location.

The following sections discuss how TF/Mirror operations on a Symmetrix Remote Data Facility (SRDF) system differ from those on a non-SRDF system.


R1

R1

R1

R2

R2

R2



Using BCVs with source (R1) devicesIf the Business Continuance Volumes (BCVs) are used with source (R1) devices (Figure 19 shows a sample SRDF system), all Business Continuance (BC) processes operate as described in Chapter 2, with the clarifications provided in the following sections.

Figure 19 Using BCVs with source (R1) devices

ESTABLISH/ RE-ESTABLISH

To maximize the efficiency of the copy operation, Symmetrix systems copy the data locally from the standard source (R1) device mirrors unless problems or data unavailability requires obtaining the data from the target (R2) device in the Symmetrix system attached to Host B.

SPLIT

Executing a SPLIT on a BCV pair, composed of a standard source (R1) device and a BCV device, does not affect data transfers with the target (R2) device.

RESTORE/Incremental RESTORE

When you perform a RESTORE or Incremental RESTORE to a source R1 device while SRDF is active, the RESTORE/Incremental RESTORE is made locally to the source (R1) device and remotely to the target (R2) device.

However, when you perform a RESTORE or Incremental RESTORE to a source R1 device while SRDF is not active (suspended), the RESTORE/Incremental RESTORE is only made locally to the source (R1) device. The information about changed tracks is retained for later synchronization with the target device.

BCV

R1 R2


Mirrors Mirrors

Host A Host B

Using BCVs with source (R1) devices 67


When you perform a RESTORE or Incremental RESTORE to a target R2 device while using Enginuity 5773 or lower, you must suspend SRDF to allow the RESTORE/Incremental RESTORE before performing R2 to R1 synchronization with SRDF Host Component procedures 4 and 6. Otherwise, you receive an error stating the device is an active R2 or part of an SRDF/A process (BCVM114E or BCVI100E).

When you perform a RESTORE or Incremental RESTORE to a target R2 device while using Enginuity 5874 or higher, you can perform SRDF Host Component procedures 4 and 6 for R2 to R1 synchronization while a Clone/Clone Emulation RESTORE operation to the R2 is in progress. (SRDF Host Component now forces TF/Clone protected tracks to become RDF remote invalid tracks.)

Note: The SRDF Host Component for z/OS Product Guide provides more information about the recovery procedures.

After the restore is complete, you need to execute the appropriate SRDF procedure to copy the changed tracks from the target (R2) to the source (R1).



Using BCVs with target (R2) devicesIf BCVs are used with target (R2) devices (Figure 20 and Figure 21), the BC processes may differ from those described in Chapter 2. The following sections discuss where the differences are found.

Figure 20 Using BCVs with a target (R2) device

Figure 21 Using BCVs with concurrent asynchronous legs and multiple targets (R2) devices(Enginuity level 5875 or higher)

ESTABLISH/ RE-ESTABLISH

The ESTABLISH and RE-ESTABLISH operations are not changed if the BCV devices are used with a target (R2) standard device. “ESTABLISH command operations” on page 32 or “RE-ESTABLISH command operations” on page 40 provide process details.

To maximize the efficiency of the copy operation on the Symmetrix system attached to Host B (or Host C), the Symmetrix system copies the data locally from the standard device mirrors.

R1 R2


BCV

SRDF/A

HOST BHOST A

R11

R2

Symmetrix A

Symmetrix B

Symmetrix C

R2

BCV

BCV

SRDF/A

SRDF/A

HOST A

HOST B

HOST C

Using BCVs with target (R2) devices 69


SPLIT

To execute the Consistent SPLIT operation on the Symmetrix system attached to Host B (and Host C if there is a concurrent asynchronous leg configuration), the following steps are performed. (Figure 20 and Figure 21 illustrate the two different topologies.)

1. The Symmetrix system containing the target (R2) device(s) associated with the BCV pair locks the device from further updates.

2. If the SRDF source (R1 or R11)/target (R2) device pair(s) is not already suspended, the remotely mirrored pair is suspended for a few seconds to execute the SPLIT.

3. The Symmetrix system containing the target (R2) device(s) associated with the BCV pair executes the SPLIT command.

4. If the remotely mirrored pair was not previously suspended, the link is resumed. Any changed tracks from the source (R1 or R11) device (because of updates while the pair was suspended) are propagated to the target (R2) device(s) for synchronization purposes.

A BCV device containing a copy of the target (R2) standard device data is now available for use by its host.

Comments on PiT consistent splitRegarding the PiT consistent split on two different R2 devices off the legs of an R11 device, the following notes apply:

◆ Enginuity 5875 or higher is required.

◆ Each Symmetrix device must be on the same sequence level

◆ The split occurs in both R2 boxes while SRDF/A cycle swtiching is suspended in both boxes and a common split time is achieved

◆ A consistent split on only one leg and not the other can be performed.

◆ A consistent split can be performed on each leg separately in different sequence levels. In this situation a common split time is not achieved.

RESTORE/ Incremental RESTORE

Under Enginuity 5773 and lower, you could not perform an SRDF R2 to R1 synchronization if a Clone/Clone Emulation RESTORE operation to the R2 was in progress. This means that you could not use the SRDF Host Component synchronization procedures (4 and 6) while the Clone/Clone Emulation RESTORE operation was in progress.

Under Enginuity 5874, you can perform SRDF Host Component procedures 4 and 6 for R2 to R1 synchronization while a Clone/Clone Emulation RESTORE operation to the R2 is in progress. (SRDF Host Component now forces TF/Clone protected tracks to become RDF Remote invalid tracks.)

Note: The SRDF Host Component for z/OS Product Guide provides more information about the recovery procedures.



Remote operations Enginuity level 5x65 and higher releases include remote BCV control capabilities. This gives a host attached to the Symmetrix system at the source location the ability to issue BCV commands across SRDF links to devices in the Symmetrix system at a target location. These commands are basically pass-through commands that travel either:

◆ Across a link defined by an R1/R2 device pair.

◆ Through an internal socket device that is a member of the specified RDF group.

This R2 device need not be the recipient of the BCV command. Figure 22 shows this.

Figure 22 Remote control

The TF/Mirror Batch Utility facilitates BCV remote control through various command parameters. You must understand the following points to use this functionality properly:

◆ If you specify an R1 device for the cuu parameter, you do not need to specify an RDF group. The host program can determine this mapping based on its knowledge of the Symmetrix configuration.

◆ If you do not specify an R1 device for the cuu parameter, you must specify an RDF group so that the host program can define a path to the target site.

◆ If you specify both an R1 device for the cuu parameter and an RDF group, the RDF group is used to define a communication path.

Production Site

Host/Server

R1

ManagementStation

SRDF Source SRDF Target

R2

Remote operations 71



CHAPTER 4Command Reference

Invisible Body Tag

This chapter provides a description of the TF/Mirror commands.

◆ Customer task guide ............................................................................................... 74◆ TF/Mirror commands............................................................................................... 74◆ BCVGROUP and BCVLIST ......................................................................................... 75◆ CONFIG ................................................................................................................... 76◆ ESTABLISH .............................................................................................................. 82◆ GLOBAL................................................................................................................... 89◆ QUERY .................................................................................................................... 98◆ RE-ESTABLISH ....................................................................................................... 107◆ RESTORE ............................................................................................................... 114◆ SPLIT..................................................................................................................... 121◆ USEREXIT .............................................................................................................. 133

Command Reference 73

Command Reference

Customer task guideThe customer task guide table allows you to quickly find the corresponding command for the basic TF/Mirror tasks.

The actions to be performed are defined in the SYSIN DDname file. You may specify up to 4,095 actions and up to 128 different sequence levels.

During operations that change the state of a device, the host issues an ENQ for the device to serialize requests. The host uses the resource QNAME of EMCTF and the RNAME is serial-number.dv#.

TF/Mirror commandsThe following reference sections describe the TF/Mirror commands.

Command syntax conventions

The commands in this chapter follow these conventions:

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

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

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

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

◆ Any CAPITALIZATION (whole or partial word) must be typed

◆ [ ] = optional entry

◆ Italics = argument

◆ | = alternative argument values

Table 9 Customer Task Guide

Task Associated Command

Configure default vales for all TF/Mirror commands. “GLOBAL” on page 89

Specify conditions for BCV devices. “CONFIG” on page 76

Define and name the BCV groups, and list the specific BCVs within a group.

“BCVGROUP and BCVLIST” on page 75

Display all the BCVs on the specified controller along with their current status.

“QUERY” on page 98

Copy the contents of a standard device to a BCV, “ESTABLISH” on page 82

Copy data from a BCV to a standard device. “RESTORE” on page 114

Stop the mirroring process between the two devices. “SPLIT” on page 121

Synchronize a previously split standard/BCV pair. “RE-ESTABLISH” on page 107

Pass control to a user-written program during the processing of TF/Mirror actions.

“USEREXIT” on page 133


Command Reference

BCVGROUP and BCVLIST

PurposeThe BCVGROUP and BCVLIST commands allow you to define multiple BCVs as a BCV group. You can then specify the BCV group in the ESTABLISH command through the GROUP parameter. The record length for the file containing the statements must be 80 bytes.

The BCVGROUP command specifies the name of the BCV group and the controller that contains the BCVs.

The BCVGROUP used in EMCTF is very limited. It serves a single purpose. The BCVGROUP is used to determine the available BCVs to be used when the DSN= option is used on an ESTABLISH only. Once a BCV has been used, it is not selected again on an ESTABLISH with DSN= and GROUP=.

The DDName TFBCVGRP specifies the file containing the statements. This allows you to limit the selection of a BCV by EMCTF to the group specified.

The BCVLIST command specifies the list of Symmetrix BCV devices contained in the group.

Required syntaxBCVGROUP name,CUU=cuu|VOLSER=volserBCVLIST bcv-devices

Optional parametersNone.

Parameter descriptions

name

Specifies a 1 to 20 character name that represents the BCV group.

cuu

Specifies a device on the controller.

volser

Specifies a device on the controller.

BCV-devices

Specifies BCV devices. The value specified must be four hex digits, and is the Symmetrix BCV device address as shown as the result of a QUERY command. You may use the ‘-’ character to specify a range.

Examples1. The following example defines a BCV group called PRODUCTION that contains BCV

symdev#s 0020, 0028-002F, and 0040 from the Symmetrix system where volser PROD00 is found.

BCVGROUP PRODUCTION,VOLSER=PROD00BCVLIST 0020,0028-002F,0040

BCVGROUP and BCVLIST 75

Command Reference

2. The following example defines a BCV group called TEST that contains BCV symdev#s 00C0-0100 from the Symmetrix system where cuu F000 resides.

BCVGROUP TEST,CUU=F000BCVLIST 00C0-0100

CONFIG

PurposeThe CONFIG command specifies HOLD, RELEASE, NR, DELINC, MULTIDELINC and READY conditions for BCV devices (and HOLD, RELEASE, DELINC and MULTIDELINC for standard devices with Enginuity level 5x66 and higher). The conditions indicating failure of these commands are Warning (RC=4) messages. This allows you to specify MAXRC(4) on the GLOBAL command if you are unsure of the state of the device.

Required syntax

CONFIG seq#,cuup,RELEASE|DELINC|HOLDCONFIG seq#,cuup-cuup,RELEASE|DELINC|MULTIDELINC|HOLDCONFIG seq#,cuus,DELINC|HOLD|RELEASE|NR|READYCONFIG seq#,cuus-cuus,DELINC|MULTIDELINC|HOLD|RELEASE|NR|READYCONFIG seq#,LCL(cuu,sym#bcv),DELINC|HOLD|RELEASE|NR|READYCONFIG seq#,LCL(cuu,sym#bcv-sym#bcv),DELINC|MULTIDELINC|HOLD|RELEASE|NR|READYCONFIG seq#,LCL(cuu,sym#std),RELEASE|DELINC|HOLDCONFIG seq#,LCL(cuu,sym#std-sym#std),RELEASE|DELINC|MULTIDELINC|HOLDCONFIG seq#,RMT(cuu,sym#bcv[,rdfgrp]),DELINC|HOLD|RELEASE|NR|READYCONFIGqseq#,RMT(cuu,sym#bcv-sym#bcv[,rdfgrp]),DELINC|MULTIDELINC|HOLD|RELEASE|NR

|READYCONFIG seq#,RMT(cuu,sym#std[,rdfgrp]),RELEASE|DELINC|HOLDCONFIG seq#,RMT(cuu,sym#std-sym#std[,rdfgrp]),RELEASE|DELINC|MULTIDELINC|HOLD



cuu

Specifies any device on a controller for a local (LCL) or remote (RMT) operation. For a RMT operation, if you do not specify the RDF group (rdfgrp), then cuu must be an R1 device.

cuup

Specifies a standard device.

cuup-cuup

Specifies a range of standard devices. The first cuup value is the starting standard device and the second cuup value is the ending standard device. The range must be contained on the same physical control unit.

cuus

Specifies a BCV device.


Command Reference

cuus-cuus

Specifies a range of BCV devices. The first cuus value is the starting BCV device and the second cuus value is the ending BCV device. The range must be contained on the same physical control unit.

DELINC

Specifies that the BCV to standard device relationship is to be removed for this BCV device or range (Enginuity level 5x66 and higher).

For TF/Mirror clone emulation only, when multiple device requests are specified together on ESTABLISH, SPLIT, and RESTORE commands, or on the DELINC parameter of the CONIFG command, TF/Mirror uses the new multi-device syscalls to process the requests together. The syscall operations do not require any syntax changes, but they should provide improved performance.

Note: The new multi-device syscalls are not processed together for non-clone TF Mirror operations.

After you execute a CONFIG DELINC command, you are not able to successfully execute a ConvertFullEstablish for BCVs in clone emulation mode.

Note: With Enginuity level 5874 and higher, even if the devices are not RAID protected, Clone Emulation is the default for this level of microcode and the ConvertFullEstablish parameter does not work.

You can specify a STD device number, instead of a BCV, to request that all incomplete Clone Emulation sessions (session IDs 45/C5/F5) on the STD device are terminated.

MULTIDELINC

(Default) Specifies that the BCV to standard device relationship is to be removed for this range of BCV devices.

TF/Mirror uses a single syscall to process the requests together in a multi-device list.

After you execute a CONFIG MULTIDELINC command, you are not able to successfully execute a ConvertFullEstablish for the BCVs in clone emulation mode.


You can specify a STD device number, instead of a BCV, to request that all incomplete Clone Emulation sessions (session IDs 45/C5/F5) on the STD device are terminated.

HOLD

HOLD obtains an explicit device lock on the specified device(s).

The reason for this change is to provide for a better method to hold a BCV. Note that HOLD can be used for a STD device. (“Examples” on page 79 provides more information.)

CONFIG 77

Command Reference

LCL

Specifies that the action affects local devices specified by the Symmetrix device number (sym#bcv).

NR

Specifies that the BCV device is made Not Ready to the host.

rdfgrp

Specifies the RDF group through which you wish to perform a remote operation.

This must be a one or two-digit value representing the RDF group.For multi-hop remote configurations, the rdfgrp can be a single RDF group or a list of up to four one or two-digit RDF groups (hops) separated by periods. For example:

nn.nn.nn.nn

READY

Specifies that the BCV device is made Ready to the host.

If you issue a QUERY command immediately after this action, the status of the BCV may show AVAILB for up to five seconds.

Note: “QUERY” on page 98 describes the QUERY command.

RELEASE

Starting with version 5.5, CONFIG RELEASE attempts to release the device holds and the TF/Clone Mainframe SNAP Facility hold on the specified device(s). The reason for this change is to overcome the interoperability problems of the automatic TF/Clone Mainframe SNAP Facility hold and the explicit CONFIG HOLD hold.

RMT

Specifies that the action affects remote device in an SRDF configuration.

seq#

A decimal number from one through 128 that indicates in what order in which the specified command is executed. All actions on the same sequence level are executed in parallel.

sym#bcv

Specifies the Symmetrix device number of the BCV device.

sym#bcv-sym#bcv

Specifies a range of Symmetrix device numbers of the BCV devices. The first sym#bcv value is the starting device number, and the second sym#bcv is the ending device number.

sym#std

Specifies the Symmetrix device number of the standard device.

sym#std-sym#std

Specifies a range of Symmetrix device numbers of the standard devices. The first sym#std value is the starting device number, and the second sym#std is the ending device number.


Command Reference

Comments◆ You can include the CONFIG command parameters as parameters in the SPLIT

command, or issue them separately to a device that has been split. Use the RELEASE command to allow access to a device that is held.

◆ The CONFIG parameters, HOLD and RELEASE work together to set and release device locks. When you place a CONFIG HOLD on a device:

• You can no longer make that device the object of an ESTABLISH, RE-ESTABLISH, RESTORE, or SPLIT command. If you try, you receive an error (BCVM146E).

• You no longer see the STD to which the BCV is paired on QUERY reports

To release the device, issue a CONFIG RELEASE. CONFIG RELEASE releases the HOLD device lock and the TF/Clone Mainframe SNAP Facility (fsmmf) hold.

Note: The EMC Mainframe Enablers Message and Code Guide provides a description of BCVM146E.

◆ Under 5x68 Enginuity, Symmetrix SRDF Host Component #SC VOL CREATEPAIR jobs can fail with EMCMN001 and EMCCV25I messages when the devices are TF/Mirror Mainframe SNAP Facility (SNAP) devices. To solve the problem, run CONFIG RELEASE on the SNAP target volumes only to clear the SNAP target sessions. Then, you can run #SC VOL CREATEPAIR against the SNAP devices.

The EMC Mainframe Enablers Message and Code Guide contains descriptions of the EMCMN001 and EMCCV25I messages. The Symmetrix SRDF Host Component Product Guide contains a description of the #SC VOL command.

◆ Under 5874, the HOLD attribute (signifying that a device is Not Ready for operations) does not appear on the BCV Report for BCVs.

Examples1. The following example changes the BCV with CUU DE18 to HOLD status.

CONFIG 2,DE18,HOLD

BCVI020I Start of INPUT control statement(s) from SYSINBCVI018I (0002) CONFIG 2,DE18,HOLDBCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0002) Process input statementBCVM004I HOLD BCV device DE18

2. The following example releases the BCV with CUU DE18, which was in HOLD status

CONFIG 2,DE18,RELEASE

Start of INPUT control statement(s) from SYSIN (0002) CONFIG 2,DE18,RELEASE

End of INPUT control statement(s) from SYSIN

BCVM039I (0002) Process input statement BCVM004I RELEASE BCV device DE18

3. The following example changes the BCV with CUU DE18 to NR (Not Ready) status.

CONFIG 2,DE18,NR

CONFIG 79

Command Reference

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) CONFIG 2,DE18,NR BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM004I NOT-READY BCV device DE18

4. The following example changes the BCV with CUU DE18 to Ready status.

CONFIG 2,DE18,READY

BCVG000I DDname TFBCVGRP not found BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) CONFIG 2,DE18,READY BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0002) Process input statement BCVM004I READY BCV device DE18

5. The following example issues the CONFIG command remotely from CUU 4D10, through RDF group 05, to change the remote BCV symdev# 170 to NR (Not Ready) status.

CONFIG 20,RMT(4D10,170,05),NR

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) CONFIG 20,RMT(4D10,170,05),NR BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM004I NOT-READY REMOTE BCV SYMDEV 0170 through 4D10

6. The following example issues the CONFIG command remotely from CUU 4D10, through RDF group 05 to change the remote BCV symdev# range 170 – 173 to NR (Not Ready) status.

CONFIG 20,RMT(4D10,170-173,05),NR

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) CONFIG 20,RMT(4D10,170-173),NR BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM004I NOT-READY REMOTE BCV SYMDEV 0170 through 4D10 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM039I (0002) Process input statement BCVM004I NOT-READY REMOTE BCV SYMDEV 0171 through 4D10 BCVM069I Security Exit allowed the bypassing of the online state check BCVM039I (0002) Process input statement BCVM004I NOT-READY REMOTE BCV SYMDEV 0172 through 4D10 BCVM069I Security Exit allowed the bypassing of the online state check

BCVM039I (0002) Process input statement BCVM004I NOT-READY REMOTE BCV SYMDEV 0173 through 4D10 BCVM069I Security Exit allowed the bypassing of the online state check BCVM039I (0003) Process input statement

7. The following example remotely issues a multi-hop CONFIG command through CUU 9A10 and RDF group 50. Then, the command ‘hops’ through RDF group 13 and issues a DELINC to symdev# range EF8-EF9. DELINC removes the BCV and STD pair association.


Command Reference

CONFIG 64,RMT(9A10,EF8-EF9,50.13),DELINC

BCVG000I DDname TFBCVGRP not found BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) CONFIG 64,RMT(9A10,EF8-EF9,50.13),DELINC BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM004I DELINC REMOTE BCV SYMDEV 0EF8 through 9A10 BCVM039I (0002) Process input statement BCVM004I DELINC REMOTE BCV SYMDEV 0EF9 through 9A10

8. This example issues a CONFIG command locally to the Symmetrix system that contains CUU DE20 and places symdev# range 1FD-1FF in HOLD status.

CONFIG 13,LCL(DE20,1FD-1FF),HOLD

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) CONFIG 13,LCL(DE20,1FD-1FF),HOLD BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0002) Process input statement BCVM004I HOLD LOCAL BCV SYMDEV 01FD through DE20 BCVM039I (0002) Process input statement BCVM004I HOLD LOCAL BCV SYMDEV 01FE through DE20 BCVM039I (0002) Process input statement BCVM004I HOLD LOCAL BCV SYMDEV 01FF through DE20

9. In the following example, after a CONFIG(HOLD) is placed on the device, the STD with which the BCV is paired no longer shows on a QUERY report.

BCVI018I (0001) QUERY 1,861F,4,480 BCVM004I QUERY STATUS ON DEVICE 861F, MICRO-CODE LEVEL 5X75 TYPE VMAX-1, S/N 0001926-00304...BCV... ...STD... ACTION LAST PROT MIRROR BCV CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYLS TYPE SYNC MODE---- 0480 0 0 HOLD-U 0480 3390 1113 R1 YES CLONE---- 0481 0 0 HOLD-U 0481 3390 1113 R1 YES CLONE---- 0482 0 0 HOLD-T 0482 3390 1113 R1 YES CLONE---- 0483 0 0 HOLD-T 0483 3390 1113 R1 YES CLONE BCVM047I ALL CONTROL STATEMENTS PROCESSED, HIGHEST RC 0 END OF DISPLAY

The HOLD-U status indicates a “user hold.” A user hold is one in which user issued a CONFIG HOLD against the device. (The HOLD-T indicates that the BCV is the target of a SNAP.)

CONFIG 81

Command Reference

ESTABLISH

PurposeThe ESTABLISH command copies the contents of the standard device to the BCV. The BCV becomes Not Ready to the host.

Required syntax

ESTABLISH seq#,cuus,cuup[,optional parameter(s)]ESTABLISH seq#,cuus-cuus,cuup-cuup[,optional parameter(s)]ESTABLISH seq#,DSN=datasetname[,optional parameter(s)]ESTABLISH seq#,LCL(cuu,sym#bcv,sym#std)[,optional parameter(s)]ESTABLISH seq#,LCL(cuu,sym#bcv-sym#bcv,sym#std-sym#std)[,optional parameter(s)]ESTABLISH seq#,RMT(cuu,sym#bcv,sym#std[,rdfgrp])[,optional parameter(s)]ESTABLISH seq#,RMT(cuu,sym#bcv-sym#bcv,sym#std-sym#std[,rdfgrp])[,optional

parameter(s)]

Optional parametersThe optional parameters must be separated from the required syntax and from each other by commas and must not have any embedded spaces.

[CBCV(Y|N)][CLONEemulation(Yes|No)] [GROUP=bcvgroup] [MULTIATTach(Yes|No)][PROTECTEDBCVEstablish(Y|N)][WAIT[(nn)]|NOWAIT]


CBCV(Y|N)

IMPORTANT

The CBCV is ignored on clone emulation operations.

The BCV device specified in this command is allowed as a concurrent BCV for the specified standard device. If mirror positions are available, you can define a maximum of two BCVs for a standard device.

There are several limitations with concurrent BCVs:

• You can use concurrent BCVs only with microcode level 5x68 or higher.

• A Concurrent BCV ESTABLISH is not allowed if the first pair was attached with a RESTORE command.

CLONEemulation(Yes|No)

IMPORTANT

Under Enginuity 5874, all operations are processed in clone emulation mode. On such operations, the CLONEemulation parameter is ignored.


Command Reference

With TF/Mirror Versions using 5x73 and lower:

• If you set CLONEemulation to Yes and have set the GLOBAL CLONEemulation parameter to REQUEST, TF/Mirror processes the BCV device specified in the ESTABLISH statement in clone emulation mode no matter what its RAID protection type.

TF/Mirror also uses clone emulation mode on any incremental ESTABLISH, Incremental RESTORE, or SPLIT command that is operating in clone emulation mode.

• If you set CLONEemulation to No or do not specify the CLONEemulation parameter (and thus use the No default) TF/Mirror does not use clone emulation for the ESTABLISH command or any related command if that BCV is a non-RAID 5 or non-RAID 6 protected device.

TF/Mirror uses clone emulation regardless of the value of the CLONEemulation parameter if the specified BCV is a RAID 5 or RAID 6 protected device.

Note: “Clone Emulation mode” on page 47 provides a description of clone emulation mode. “GLOBAL” on page 89 describes the global CLONEemulation parameter.

cuu

Specifies any device on a controller for a local (LCL) or remote (RMT) operation. For a remote (RMT) operation, if the RDF group (rdfgrp) is not specified, then cuu must be an R1 device.

cuup


cuup-cuup

Specifies a range of standard devices. The first cuup value is the starting standard device and the second cuup value is the ending standard device. The range must be contained on the same physical control unit.

cuus


cuus-cuus


DSN=datasetname

Specifies the dataset name used to locate the volume or volumes on which to perform the ESTABLISH command. For multi-volume files, the ESTABLISH command is performed on all volumes.

To use the DSN option, the dataset must be catalogued. You can locate the dataset by using the standard catalog search order.

GROUP

Specifies the BCV group name used in the selection of BCVs. If no group is specified, all BCVs are eligible.

ESTABLISH 83

Command Reference

Note: “BCVGROUP and BCVLIST” on page 75 describes BCV group names.

MULTIATTach(Yes|No)

Enables or disables multi-attach operations for this ESTABLISH command. The alias for MULTIATTach is MULTA.

Yes

Enables multi-attach for the command, unless the GLOBAL MULTIATTach parameter specifies NONE.

No

Disables multi-attach for the command, regardless of any specification on the GLOBAL MULTIATTach parameter.

Note: “GLOBAL” on page 89 describes the GLOBAL MULTIATTach parameter.

PROTECTEDBCVEstablish(Y|N)

IMPORTANT

For clone emulation operations, all ESTABLISH operations are Protected BCV Establish. On such operations, the PROTECTEDBCVEstablish parameter is ignored.

Disables or enables Protected BCV Establish. Allowable abbreviations are PBCVE, PROTECTEDBCVE, and PROTBCVE. This feature involves locally mirrored BCVs only. When you issue an ESTABLISH with PROTECTEDBCVEstablish, both mirrors of the BCV are added as mirrors of the standard device. If there are no available mirror positions, this operation fails.

On a BCV Split, both BCV mirrors are synchronized with the standard, ensuring that there is no point in time at which data is unprotected on the BCV.

LCL

Specifies that the action affects local devices specified by the Symmetrix device number (sym#bcv and sym#std).

rdfgrp



xx.xx.xx.xx

RMT

Specifies that the ESTABLISH command affects remote devices in an SRDF configuration.

seq#

Specifies a decimal number from one through 128 that indicates in what order the specified command is executed. All actions on the same sequence level are executed in parallel.


Command Reference

sym#bcv


sym#bcv-sym#bcv

Specifies a range of Symmetrix device numbers of the BCV devices.The first sym#bcv value is the starting device number. The second sym#bcv is the ending device number.

sym#std


sym#std-sym#std


WAIT[(nn)]|NOWAIT

Specifies either waiting for the completion of the action or continuing after the command is passed to the controller.

WAIT = wait for the completion of the specified action

NOWAIT = pass the command to the controller, and assume the action is complete

Note: “GLOBAL” on page 89 describes the default.

The default wait times are 10 minutes for a SPLIT command and 120 minutes for ESTABLISH, RE-ESTABLISH, and RESTORE commands.

The optional nn allows the default wait interval to be changed. Specify nn as a numeric value that specifies how many minutes you want to wait. For example, WAIT(10) specifies a 10-minute wait.

Comments◆ The standard and BCV devices must have the same device type. The BCV device size

can be equal to or larger than the standard device size; however, the standard device cannot be larger than the BCV device. In addition, the BCV must be offline to all attached hosts. If the BCV was previously split, all tracking of the changed data for the previous standard/BCV pair is discarded. You must specify both the cuup and cuus parameters if you do not specify the DSN option. The WAIT parameter is optional and, if specified, overrides the GLOBAL command setting.

◆ To use the device-range feature, you must specify cuus-cuus and cuup-cuup parameters. The number of devices specified by the cuus-cuus and cuup-cuup parameters must be the same. BCV and standard devices are paired together. The Symmetrix system processes them sequentially. The range must be contained on the same physical control unit.

◆ When you specify DSN, the automatic multi-BCV feature of Enginuity level 5x66 and higher is disabled. Incremental tracking/history is only maintained for one BCV for each standard device.

◆ When you use clone emulation, all ESTABLISH operations are Protected BCV Establish.

ESTABLISH 85

Command Reference

Examples1. The following example establishes BCV CUU C518 to STD device CUU C438.

ESTABLISH 111,C518,C438

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) ESTABLISH 111,C518,C438 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I ESTABLISH STANDARD device C438 to BCV C518 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check

2. The following example establishes BCV CUUs DF68-DF6B to STD CUUs DE84-DE87. The BCV devices are Raid5 BCVs Clone Emulation is used.

ESTABLISH 111,DF68-DF6B,DE84-DE87

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) ESTABLISH 111,DF68-DF6B,DE84-DE87 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I ESTABLISH STANDARD device DE84 to BCV DF68 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I ESTABLISH STANDARD device DE85 to BCV DF69 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I ESTABLISH STANDARD device DE86 to BCV DF6A BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I ESTABLISH STANDARD device DE87 to BCV DF6B BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation

3. The following example establishes the STD device where the DSN resides to the first available BCV in the Symmetrix system.

ESTABLISH 1,DSN=SYST.TEST.DSN

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) ESTABLISH 1,DSN=SYST.TEST.DSN BCVI033I * SYST.TEST.DSN SPANS 1 VOLUME(S) BCVI033I * CUU LIST: 8248 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I ESTABLISH STANDARD device 8248 to BCV 0048 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation


Command Reference

4. The following example establishes the STD device where the DSN resides to the first available BCV in the group LISTBCV, as defined by the BCVGROUP and BCVLIST statements of the TFBCVGRP DD statement.

ESTABLISH 1,DSN=SYST.TEST.DSN3,GROUP=LISTBCV

BCVG018I BCVGROUP LISTBCV,CUU=831F BCVG018I BCVLIST 48-4A,58-5C BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) ESTABLISH 1,DSN=SYST.TEST.DSN3,GROUP=LISTBCV BCVI033I * SYST.TEST.DSN3 SPANS 1 VOLUME(S) BCVI033I * CUU LIST: 8249 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I ESTABLISH STANDARD device 8249 to BCV 004A BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation

5. The following example issues the ESTABLISH command remotely via CUU DE20, through RDF group E0 and establishes BCV symdev# 01FD to standard symdev# 00CD.

ESTABLISH 1,RMT(DE20,01FD,00CD,E0)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) ESTABLISH 1,RMT(DE20,01FD,00CD,E0) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I ESTABLISH REMOTE STANDARD SYMDEV 00CD to BCV SYMDEV 01FD through DE20BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check

6. The following example issues the ESTABLISH command remotely via CUU DE20, through RDF group E0, and establishes BCV symdev#s 01FD-01FF to standard symdev#s 00CD-00CF.

ESTABLISH 1,RMT(DE20,01FD-1FF,00CD-00CF,E0)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) ESTABLISH 1,RMT(DE20,01FD-1FF,00CD-00CF,E0) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I ESTABLISH REMOTE STANDARD SYMDEV 00CD to BCV SYMDEV 01FD through DE20BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM039I (0001) Process input statement BCVM004I ESTABLISH REMOTE STANDARD SYMDEV 00CE to BCV SYMDEV 01FE through DE20BCVM069I Security Exit allowed the bypassing of the online state check BCVM039I (0001) Process input statement BCVM004I ESTABLISH REMOTE STANDARD SYMDEV 00CF to BCV SYMDEV 01FF through DE20BCVM069I Security Exit allowed the bypassing of the online state check

7. The following example sets up a concurrent BCV. Standard symdev# 03D is established with BCV symdev# 16A and then with 16D on the Symmetrix system associated with CUU 9A10.

BCVI020I Start of INPUT control statement(s) from SYSIN

ESTABLISH 87

Command Reference

BCVI018I (0001) ESTABLISH 3,LCL(9A10,16A,03D) BCVI018I (0002) ESTABLISH 6,LCL(9A10,16D,03D),CBCV(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I ESTABLISH LOCAL STANDARD SYMDEV 003D to BCV SYMDEV 016A through 9A10BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM039I (0002) Process input statement BCVM004I ESTABLISH LOCAL STANDARD SYMDEV 003D to BCV SYMDEV 016D through 9A10BCVM069I Security Exit allowed the bypassing of the online state check

8. The following example shows a multi-attach ESTABLISH.

Note: For the ESTABLISH, the BCV and standard devices are displayed, separated by a slash (/).

BCVI020I Start of INPUT control statement(s) from SYSINBCVI018I (0001) GLOBAL MAXRC(8,SETMAX),WAIT,MULTATT(ALL)BCVI018I (0002) ESTABLISH 10,D02C,CF0C,MULTIATT(Y)BCVI018I (0003) ESTABLISH 10,D02D,CF0D,MULTIATT(Y)BCVI018I (0004) ESTABLISH 10,LCL(D02F,15E,00E),MULTIATT(Y)BCVI018I (0005) ESTABLISH 10,LCL(D02F,15F,00F),MULTIATT(Y)BCVI018I (0006) ESTABLISH 10,RMT(9401,23C,1B8,07),MULTIATT(Y)BCVI018I (0007) ESTABLISH 10,RMT(9401,23D,1B9,07),MULTIATT(Y)BCVM039I (0002) Process input statementBCVM004I MULTI ESTABLISH devices:BCVM004I * D02C/CF0C(0002),D02D/CF0D(0003)BCVM039I (0004) Process input statementBCVM004I MULTI ESTABLISH LOCAL devices through D02F:BCVM004I * 015E/000E(0004),015F/000F(0005)BCVM039I (0006) Process input statementBCVM004I MULTI ESTABLISH REMOTE devices through 9401:BCVM004I * 023C/01B8(0006),023D/01B9(0007)

9. The following is an example of a remote multi-hop ESTABLISH command specifying MULTIATTach and clone emulation. The multi-hop command is issued remotely through CUU 9A10, through RDF group 50, and then ‘hops’ through RDF group 13 to symdev# range EF8-EF9.

BCVI018I (0001) GLOBAL MAXRC(8,SETMAX),MULTA(ALL),CLONE(REQUEST) BCVI018I (0002) ESTABLISH 2,RMT(9A10,EF8-EFA,548-54A,50.13),CLONE(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I MULTI ESTABLISH REMOTE devices through 9A10: BCVM004I * 0EF8-0EFA/0548-054A(0002) BCVM140I Command processed via TF/Clone emulation


Command Reference

GLOBAL

PurposeThe GLOBAL command sets default values for all TimeFinder/Mirror commands.

Note: If you are executing a TimeFinder command from the EMC Mainframe Enablers Host Component, GLOBAL commands and parameter values set from the Host Component are not transferred to TimeFinder/Mirror. Therefore only the default values of the TimeFinder/Mirror GLOBAL command parameters are used during execution.

Required syntaxGLOBAL [parameter,...}

Optional parametersThe optional parameters must be separated from each other by commas and must not have any embedded spaces.

[ATTach[(nn,wait_int)][AUTORELease(Yes|No)][BYPASSPARSEERROR(Yes|No)][CLONEemulation(RAID5BCV|ALLBCV|REQUEST)]1[CONSistent([MODE(IOSLEVEL|ECA)][[,]TIMEOUT(15|nn)]

[[,]ALLOWNONSYNC][[,]ECACLEAR(SEQLEVEL|CONTROLLER)])][CONVertFullEstablish(Y|N)][DEBUG[(ECA|SRDFA)]][FASTESTablish(Y|N)][FBAMETA(ALLOWINCOMPLETE)][LCLR1BCV|LCLSTD][MAXRC(0|n[,SETMAX])][MAXGrp(nnnn)][MULTBCV(NEW|OLD|REJ)][MULTIATTach(NONE|ALL|EST|REEST)][NOCUU][NOTYPE][PROTECTEDRESTORE(REQUEST|CLONE|ALLBCV)][PARallel(Yes[,number]|No)][TolerateDesiredState[(ANY|[EST][[,]SPLIT][[,]RESTORE])]][WAIT|NOWAIT]


ATTach[(nn,wait_int)]

Allows multiple attach requests (on ESTABLISH or RESTORE commands) to be processed before TF/Mirror queries the Symmetrix unit to ensure the BCVs are attached.

nn

The number of requests to issue before checking the Symmetrix unit for status. Valid values are from zero (0) to 64. The default value is eight (8).

1. Under Enginuity 5874 or higher this parameter is has a value of ALLBCV.

GLOBAL 89

Command Reference

wait_int

The interval (in seconds) to wait before checking for status. Valid values are from zero (0) to 60. The default value is one (1).

You can use ATTach without parameters. If you do, TF/Mirror uses the defaults.

AUTORELease(Yes|No)

AUTORELease applies to the ESTABLISH and RE-ESTABLISH commands.

If an ESTABLISH or RE-ESTABLISH fails because of a hold on the STD, TF/Mirror automatically issues a release and retries the command.

Previously, an ESTABLISH or RE-ESTABLISH would fail if the STD was the target of a snap operation, and a SPLIT would fail if the operation was running under Enginuity level 5x68 or lower.

The default is No for TF/Mirror and Yes for SRDF/AR.

Comments regarding AUTORELEASE and Enginuity levels:

• A SPLIT does not fail for a held STD device or devices in installations running Enginuity level 5x68 or higher.

• For Enginuity level 5773 and lower:

– AUTORELEASE is required for non-CLONE devices.

– AUTORELEASE is not required for CLONE EMULATION (e.g., RAID5 devices), ESTABLISH ignores HOLD-T.

• For Enginuity level 5874 and higher:

– STD SNAP TARGET does not become HOLD-T, and AUTORELEASE is not required.

BYPASSPARSEERROR(Yes|No)

Controls whether parse errors are ignored. The default is No. Allowable abbreviations are BYPPARSEERR, BYPPERROR, and BYPPERR.

BYPASSPARSEERROR requires that the GLOBAL command have a MAXRC value of eight (8) or higher. Refer to “MAXRC(0|n[,SETMAX])” on page 93 for more information about MAXRC.

CLONEemulation(RAID5BCV|ALLBCV|REQUEST)

IMPORTANT

Under Enginuity 5874 and higher, all operations are processed in clone emulation mode. On such operations, the CLONEemulation parameter is ignored.

With TF/Mirror Versions using Enginuity 5773 and lower:

RAID5BCV

(Default) Only RAID 5 or RAID 6 protected BCVs is given clone emulation mode. Regular BCVs do not receive clone emulation mode.


Command Reference

ALLBCV

Clone emulation is always used for RAID 5 and RAID 6 protected BCVs and is also always used on any ESTABLISH or RESTORE command and on any incremental command (Incremental RESTORE or RE-ESTABLISH) or SPLIT command that is part of a clone emulation session (that is, is operating on a BCV in clone emulation mode).

REQUEST

Clone emulation is always used for RAID 5 and RAID 6 protected BCVs. TF/Mirror also uses clone emulation for any non RAID 5 or RAID 6 operations if you append CLONEemulation(Yes) on an initial ESTABLISH or RESTORE command. TF/Mirror then uses clone emulation mode on any following, related incremental and SPLIT command that are operating on a BCV in clone emulation mode.

Note: The ESTABLISH, RE-ESTABLISH, SPLIT, and full RESTORE commands under Enginuity 5773 and lower have a CLONEemulation(Yes|No) parameter. “ESTABLISH” on page 82, “RE-ESTABLISH” on page 107, “RESTORE” on page 114, and “SPLIT” on page 121 provide more information about CLONEemulation(Yes|No).

TF/Mirror does not use clone emulation in the following cases:

– For any ESTABLISH or RESTORE that do not have CLONEemulation(Yes|No) set or that have CLONEemulation(Yes|No) set to No.

– For any incremental (RE-ESTABLISH or Incremental RESTORE) or SPLIT command that is not operating on a BCV in clone emulation mode.

Note: Under Enginuity 5874 or higher this parameter has a value of ALLBCV.

[CONSistent([MODE(IOSLEVEL|ECA)][[,]TIMEOUT(15|nn)] [[,]ALLOWNONSYNC][[,]ECACLEAR(SEQLEVEL|CONTROLLER)])]

MODE

Allows an override to default I/O control. ECA is the default and is used if you make no MODE specification. To override ECA and use IOSLEVEL, specify MODE(IOSLEVEL) and specify CONSISTENT(LOCAL|GLOBAL(IOSLEVEL)) on the SPLIT command(s).

Note: “SPLIT” on page 121 provides more information.

TIMEOUT

Specifies the maximum time in seconds that TF/Mirror holds host I/O to process a Consistent SPLIT. The default value is 15 (seconds) and the maximum is 60 (seconds).

When both the GLOBAL and the SPLIT TIMEOUT are set, the most restrictive (lowest) value is used.

GLOBAL 91

Command Reference

For example, if the GLOBAL TIMEOUT is set at 15 and the SPLIT TIMEOUT is set at 30, TF/Mirror would use a value of 15. If the GLOBAL TIMEOUT is set at 22 and the SPLIT TIMEOUT is set at 30, TF/Mirror would use a value of 22.

ALLOWNONSYNC

Allows a Consistent SPLIT to continue, even though the STD device in the split has been identified as an R2 or R21 device in an RDF relationship with an R1 device that is in adaptive copy mode.

Keep in mind that R21 devices must be defined as Adaptive Copy devices. If you are using an R21 device as a standard device in a Consistent SPLIT, you need to specify the ALLOWNONSYNC parameter on a GLOBAL command.

ECACLEAR

Enables you to control controller level ECA Clear. If you choose the default SEQLEVEL, ECA window clearing is deferred until all of the Consistent SPLIT requests at the current sequence level are processed. If you select the CONTROLLER keyword, TF/Mirror clears ECA on for a controller for an RMT Consistent SPLIT when polling has completed for all BCVs on that controller.

The alias for SEQLEVEL is SEQLVL. The alias for CONTROLLER is CNTRL.

CONVertFullEstablish(Yes|No)

No is the default. If you specify Yes, an incremental RE-ESTABLISH and the standard device and the BCV do not have a valid existing relationship, the RE-ESTABLISH is converted into a full ESTABLISH instead of failing the RE-ESTABLISH command.


DEBUG[(ECA|SRDFA)]

Only specify DEBUG under the direction of EMC technical support.

ECA

The optional ECA parameter provides details while processing a operation where ECA may be active.

SRDFA

The optional SRDFA parameter provides details while processing a Consistent SPLIT where SRDF/A is active.

FASTESTablish(Y|N)

FASTESTablish converts a full ESTABLISH to an incremental RE-ESTABLISH if a valid relationship exists between the standard device and BCV. N is the default.

FBAMETA(ALLOWINCOMPLETE)

Allows a partial list of FBA meta group member to be specified in a TF/Mirror command, instead of requiring all members of the group to be coded.


Command Reference

LCLR1BCV |LCLSTD

Specifies that the R1 BCVs or R1 STDs are not mounted to the host and are identified by Symmetrix device numbers. This parameter only applies to SRDF/AR processes.

MAXRC(0|n[,SETMAX])

Some messages you receive from TF/Mirror can be returned with a warning (W), an error (E), or a serious error (E with a return code of 12) message class. The message class you receive with these messages depends on the return code encountered. The values that can be returned as the jobstep return code range from zero (0) to eight (8). Zero would be the least serious; for example, informational. Eight would be an error.

Note: You can also receive a return code of 12. Although the messages returned with jobstep return code of 12 are prefixed with an E, they are considered serious errors.

MAXRC sets the maximum return code accepted for the continuation of processing if you should receive one of these messages. The values to which you can set MAXRC are from zero (the default) to 8.

When you specify the SETMAX argument, SETMAX returns the highest return code observed during execution as the jobstep return code. If that return code is higher than the value of n, the message returned is an error.

If you do not specify MAXRC, TF/Mirror always returns the highest return code encountered as the jobstep return code. The returned message is an error.

The MAXRC default value is zero (0). With zero, TF/Mirror always treats messages as errors and returns the highest return code encountered as the jobstep return code. The returned message is an error

If you set MAXRC to a value of from one to eight (8), and you receive no return code higher than the value, the jobstep return code is set to zero, and any message is treated and displayed as a warning (W). Processing continues.

If you set MAXRC to a value of from one to eight (8) and you receive a return code higher than that value, then the jobstep return code is set to that value and the message is treated and displayed as an error (E). Processing stops.

If you receive a return code of 12, that value is greater than any possible MAXRC value, TFCMSF displays the message as a serious error. Processing stops.

Note: “Return code processing” on page 27 describes return codes in more detail.

MAXGrp(nnnn)

Specifies the maximum number of SRDF/AR groups (1-9999, default 64).

MULTBCV(NEW|OLD|REJ)

Specifies the action to be taken by the ESTABLISH, RE-ESTABLISH, and RESTORE commands should the maximum number of multiple BCVs for a standard device be exceeded.

NEW Delete the most recent incremental relationship.

OLD (Default) Delete the oldest incremental relationship.

GLOBAL 93

Command Reference

REJ Reject the command.

MULTIATTach(NONE|ALL|EST|REEST)

Allows multiple device pairs to be attached (through ESTABLISH or RE-ESTABLISH) by one syscall. This ability is called multi-attach. The parameter alias is MULTIATTach. There is no default for the GLOBAL MULTIATTach parameter.

If you specify no value for MULTIATTach, you can enable multi-attach through the MULITIATTach(Yes|No) parameter on individual ESTABLISH and RE-ESTABLISH commands.

Note: MULTIATTach(YES|NO) in “ESTABLISH” on page 82 or and “RE-ESTABLISH” on page 107.provides more information.

NONE

Unconditionally disables multi-attach for all attach operations, regardless of whether it is enabled on individual ESTABLISH or RESTORE commands.

Note: MULTIATTach(YES|NO) in “ESTABLISH” on page 82 and in “RE-ESTABLISH” on page 107 provides more information.

ALL

Conditionally enables multi-attach for all attach operations. You can disable this on individual ESTABLISH or RESTORE commands.


EST

Conditionally enables multi-attach for all ESTABLISH command. You can disable this on individual ESTABLISH commands.


REEST

Conditionally enables multi-attach for all RE-ESTABLISH commands. You can disable this on individual RE-ESTABLISH commands.

Note: MULTIATTach(YES|NO) in “ESTABLISH” on page 82 and in “RE-ESTABLISH” on page 107 provide more information.

NOCUU

Disables a standard and BCV device search when the QUERY command is executed.


Command Reference

NOTYPE

Disables the type check in the QUERY command. On certain Enginuity levels, the type check lengthens the processing time.

PROTECTEDRESTORE(REQUEST|CLONE|ALLBCV)

IMPORTANT

Under clone emulation, all RESTORE operations are Protected RESTOREs. In such a situation, the PROTECTEDRESTORE parameter is ignored. “RESTORE under Enginuity 5874 and higher” on page 44, “Incremental RESTORE under Enginuity 5874 and higher” on page 46, and “Limitations and differences” on page 53 provide more information.

This parameter determines the requirements for a SPLIT command after a Protected RESTORE.

REQUEST

(Default) With REQUEST, you must specify that you want a Protected RESTORE by specifying PROTECTEDRESTORE(Y) on the SPLIT command.

CLONE

With clone emulation mode, restores are always protected. CLONE specifies that PROTECTEDRESTORE(Y) is not required on the SPLIT command after a clone emulation RESTORE.

ALLBCV

ALLBCV specifies that PROTECTEDRESTORE(Y) is not required after any type of Protected RESTORE.

Note: “SPLIT” on page 121 provides more information about the PROTECTEDRESTORE(Y) SPLIT parameter.

You can abbreviate PROTECTEDRESTORE to any of the following:

• PROTRESTORE

• PROTRSTR

• PRSTR

• PROT

PARallel(Yes[,number]|No)

Controls whether you use Parallel Timefinder (parallel processing).

No

(Default) TimeFinder does not use parallel processing.

Yes

TimeFinder uses parallel processing.

number

GLOBAL 95

Command Reference

Can be used with Yes. Optionally specifies the maximum number of subtasks allowed. You can specify a number between 1 and 256. If you do not specify a number when you choose Yes, TimeFinder uses a maximum of 16 subtasks.

TolerateDesiredState[(ANY|[EST][[,]SPLIT][[,]RESTORE])]

Allows a TF/Mirror request to be issued for a range of devices without regard to the state. Normally, all devices being ESTABLISHed must be SPLIT and all devices in range to be SPLIT must be ATTACHed.

ANY

(Default) Ignore the current state of any devices specified in any commands if the MAXRC parameter is set to four (4) or higher.

EST

Ignore the current state of any devices specified in ESTABLISH command if the MAXRC parameter is set to four (4) or higher.

SPLIT

Ignore the current state of any devices specified in SPLIT commands if the MAXRC parameter is set to four (4) or higher.

RESTORE

Ignore the current state of any devices specified in RESTORE commands if the MAXRC parameter is set to four (4) or higher.

You can use one or more operands with TolerateDesiredState. If you use TolerateDesiredState with no operands, the value of the parameter is ANY.

TolerateDesiredState is ignored for Consistent SPLITs. If you issue TolerateDesiredState(SPLIT) or TolerateDesiredState(ANY) in the same jobstep as a Consistent SPLIT, you receive message BCVI127W.

Note: The EMC Mainframe Enablers Message and Code Guide describes BCVI127W and the actions you need to take if you receive it.

WAIT|NOWAIT

Specifies waiting for the completion of the action or continuing after the command is passed to the controller.

WAIT

(Default) Wait for the completion of the specified action (the default).

NOWAIT

Pass the command to the controller, and assume the action is complete.

Comments◆ Only one GLOBAL command is allowed. If you use a GLOBAL command, you must

specify at least one optional parameter. If you specify WAIT|NOWAIT at the command level, those values override the global setting. Specifying WAIT at the global or


Command Reference

command level indicates that the action must complete before the command is considered done. If there are multiple commands at a seq# level all wait conditions must be satisfied before the next level can be executed.

◆ The nocuu parameter disables the CUU-BCV search when specifying the QUERY command.

◆ You should use the debug parameter only under the direction of EMC technical support.

◆ CONSistent(TIMEOUT) specifies the maximum time in seconds that TF/Mirror holds host I/O to process a Consistent SPLIT. I/O is released after completion of the Consistent SPLIT or after this timeout, whichever occurs first. A BCVM088W message is issued if the I/O is released before the Consistent SPLIT is completed.

Note: The EMC Mainframe Enablers Message and Code Guide describes BCVM088W.

Examples1. The following example sets the GLOBAL parameter WAIT to wait for the completion of

commands to continue or end. The example also sets the maximum return code to 8.

GLOBAL WAIT,MAXRC(8,SETMAX)

2. The following example sets the GLOBAL parameter NOWAIT to not wait for the completion of commands to continue or end. The example also sets the TIMEOUT value to 5 for Consistent SPLITs.

GLOBAL NOWAIT,CONS(TIMEOUT(5))

3. The following example sets the GLOBAL parameter for maximum return code to 8 and specifies that clone emulation is utilized when requested, that multi-attach is used for ESTABLISH, RE-ESTABLISH, or RESTORES, and that auto release is set to release any STD snap holds automatically.

GLOBAL MAXRC(8,SETMAX),CLONE(REQUEST),MULTA(ALL),AUTOREL(Y)

4. The following example performs the following:

• Sets the GLOBAL parameter for maximum return code to 8.

• Converts any BCVs RE-ESTABLISHes that do not have a valid pair to a full ESTABLISH (using the last known STD).

• Utilizes multi-attach for RE-ESTABLISHes only.

• Tolerates any established, split, or restored devices in a range.

• Rejects a command if the maximum number of multiple BCVs for a standard device is exceeded by an ESTABLISH, RE-ESTABLISH, and RESTORE command.

GLOBAL MAXRC(8,SETMAX),CONVERTFULLESTABLISH(Y),MULTIATTACH(REEST),TDS(ALL),MULTBCV(REJ)

GLOBAL 97

Command Reference

QUERY

PurposeThe QUERY command displays all the BCVs on the specified controller and their current status.

Required syntaxQUERY seq#,cuu[,optional parameter(s)]QUERY seq#,DSN=dsn name[,optional parameter(s)]QUERY seq#,LCL(cuu)[,optional parameter(s)]QUERY seq#,RMT(cuu[,rdfgrp])[,optional parameter(s)]QUERY seq#,RMT(cuu[,rdfgrp]),count[,symdv#][,optional parameter(s)]QUERY seq#,LCL(cuu),count[,symdv#][,optional parameter(s)]QUERY seq#,cuu,count[,symdv#][,optional parameter(s)]QUERY seq#,DSN=dsn name,count[,symdv#][,optional parameter(s)]


[,ALL|count][,EXtended(Y[,SBCV][,SNAPHold])]


ALL

Requests a display that includes all BCV devices on the controller.

Note: If the gatekeeper device is a higher symdv# than the BCV's in the box no BCV's are found unless you code the ALL parameter. Allowing it to default , it only lists BCV's that have a symdv# higher than the gatekeeper.

count

Specifies the number of BCV devices on which you wish to obtain information. If a count value is not specified, this command displays information on all BCV devices, begining with cuu (the device number on the control unit where the query started).

cuu

Specifies the z/OS device number on the control unit to start the query. BCVs at or above this device number are returned.

If you are performing a remote operation (see RMT) and do not specify the RDF group (see rdfgrp), then cuu must be an R1 device.

DSN

Specifies a dataset name on the controller you wish to query. If you specify a multi-volume file, only one query is generated since information is for the entire controller.


Command Reference

EXtended(Y[,SBCV][,SNAPHold])

Requests the Extended Format Query to show multi-BCV status. Multi-BCV status shows:

• The incremental relationship status of all BCVs for each standard device

• The time elapsed since each BCV was established with its last standard device

• The number of tracks remaining to be synchronized or the number of tracks changed since last synchronized

Optional keyword SBCV starts the display with the BCV entered as the symdv# on the QUERY command.

Prior to Enginuity level 5874, the optional keyword SNAPHold would show whether a volume is the source (HOLD-S) or the target (HOLD-T) of a Snap.

Note: The multi-BCV feature and Extended Format Query are only available at Enginuity level 5x66 and higher.

LCL


rdfgrp


This must be a one or two-digit value representing the RDF group. For multi-hop remote configurations, the rdfgrp can be a single RDF group or a list of up to four one or two-digit RDF groups (hops) separated by periods. For example:

xx.xx.xx.xx

RMT

Specifies that the query is to gather information on the remote devices in an SRDF configuration.

seq#


symdv#

Specifies the starting device number for the display. For an Extended Format Query, symdv# normally refers to a standard device because the Extended Format Query report is sorted by standard device. The symdv# value does not have to be a standard device, it is the starting device number for the display.

Note: The default start device number for a Query is the Symm device number of the Gatekeeper. If this device number is higher than the last BCV on the remote box, no BCVs are displayed. If there is no Gatekeeper with a lower Symm device number than the BCVs to be displayed, a Start parameter of 0000 can be specified.

QUERY 99

Command Reference

When you specify the optional SBCV keyword (Extended(Y,SBCV), then symdv# refers to the BCV with which to start the display.

Comments◆ The cuu specifies any device number on the controller of interest. When you specify

DSN, TF/Mirror identifies the volume on which that DSN is cataloged, and creates the query as if the volume’s device number were specified for cuu. The z/OS cuu for the BCV is the inquiry output if the cuu to Symmetrix address relationship can be determined and nocuu is not specified on the GLOBAL command. count allows you to limit the number of BCVs displayed by this action.

Note: The BCVM003I message description in the EMC Mainframe Enablers Message and Code Guide shows an example of the output for QUERY.

The Extended Format Query display is normally sorted in order by standard device and time since the split. The display always begins with the first BCV that has had a BCV/standard relationship. BCVs that do not have an BCV/standard relationship are not displayed.

When you specify the optional SBCV keyword (Extended(Y,SBCV), then symdv# refers to the BCV with which to start the display.

Table 10 lists the fields that you can receive for the Extended Format Query are:

Table 10 Extended mode QUERY fields (page 1 of 3)

SYMDV#-BCV Specifies the internal EMC device number of the BCV.The suffix on the BCV device number is:-r if a RMT query-l if a LCL query

SYMDV#-STD Specifies the internal EMC device number for the standard device.The suffix on the BCV device number is:-r if a RMT query-l if a LCL query

LAST-BCV Specifies the most recent of multi-BCV for the standard device.

TIME-FROM-SPLIT

Shows the time in ddd.hh:mm:ss since this BCV was split from the standard device.

BCV-CNFG Specifies the configuration of the BCV:


Command Reference

R1 BCV is an R1 device.

R2 BCV is an R2 device.

MIRR BCV has more than one local mirror. There is more than one physical copy of the data.

NONE BCV is not mirrored. There is only one physical copy of data.

NONE-M The device is a meta (RAID) device. BCV is not mirrored. There is only one physical copy of data.

NONE-6 The device is a meta, RAID-6 device.

BCV-CNFG Suffix

-M Striped meta.

-5 RAID5.

-6 RAID6.

-C Clone.

BCV-STATE Specifies the status of the BCV:

ATTACH BCV is attached.

ATT(2) Both BCV mirrors attached.

CPYFMM BCV is synchronizing FROM the moving mirror (it is synchronizing to its mirror after a normal split).

CPYTMM BCV is synchronizing TO the moving mirror (it is being refreshed from its mirror after a reverse split).

HOLD-S BCV is the hold source of a Snap.

HOLD-T BCV is the hold target of a Snap.

HOLD-U User hold. The user issued a CONFIG HOLD against the device. (“Examples” on page 103 provides more information about HOLD-U.)

HOLD-NR Hold not ready.

NR Not ready.

SYNC BCV is synchronized with standard device.

STD-STATE Specifies the status of the standard device:

AVAIL Standard device is available for an establish.

NAVAIL Standard device is not available.

HOLD-T FSMM hold.

HOLD-U User hold. The user issued a CONFIG HOLD against the device.


QUERY 101

Command Reference

Note: “GLOBAL” on page 89 describes the GLOBAL HOLD parameter. The BCVM073I message description in the EMC Mainframe Enablers Message and Code Guide shows an example of the output for Extended Format QUERY.

◆ The extended QUERY output now supports listing EAV devices in under #CYLS and the extended mode TRACK COUNT field.

◆ There are some differences in running BCV QUERY reports that include both regular mode BCVs and BCVs that are part of a clone emulation session and BCV QUERY reports that only cover the same clone emulation BCVs.

In BCV QUERY reports covering both regular mode and clone emulation mode BCVs, the clone emulation BCVs show HOLD relationship. In BCV QUERY reports covering only the clone emulation mode BCVs, the clone emulation BCVs show as Snap targets.

PAIR-STATE Specifies the status of this BCV - standard pair:

AVAIL Valid ready mirror.

AVAILB Split before synchronization on BCV. (SPLIT with FORCE useda).

INUSE Pair is synchronized.

INUSEX Pair is in process of synchronizing.

SPLITB Background SPLIT is in progress, SPLIT with INSTANT(Y) (must complete before another operation can be done with this BCV or standard).

SPLITO Traditional SPLIT is in progress, SPLIT with INSTANT(N) or default. Indicates a transient state of an Instant SPLIT.

LAST-ACTION Specifies the command used to pair this BCV and standard device:

EST ESTABLISH or RE-ESTABLISH command used.

RSTR RESTORE command used.

PRSTR Protected RESTORE.

TRACK-COUNT1 Specifies the number of tracks remaining to be synchronized:• From a standard to a BCV, when the BCV is paired with a

standard device.• From a BCV to its mirror after a normal split.• To the BCV from its mirror after a reverse split.• From a BCV to a standard when the BCV is paired with a

standard device during a RESTORE operation.

TRACK-COUNT2 Specifies the number of tracks that must be synchronized in the next incremental operation.

TRACK-COUNT3 Specifies the percent of tracks split for background (instant) split.

a. Starting with Version 7.0, use of FORCE with the SPLIT command in clone emulation mode is no longer prohibited.



Command Reference

This is because the HOLD attribute is suppressed on the BCV QUERY report for BCVs with a clone emulation session to provide compatibility for clone emulation.

Because a HOLD is implicitly set on the BCV as a result of a clone emulation ESTABLISH, that HOLD needs to be ignored for subsequent TF/Mirror operations. Otherwise, a RE-ESTABLISH or another ESTABLISH would be denied.

◆ The maximum number of BCVs in multi-BCV support is six (6) BCVs for each standard device when using clone emulation BCVs and eight (8) BCVs for each standard device when using non-RAID 5 and non-RAID 6 BCVs.

Each of these maximums applies to specific types of BCVs. Therefore, if you have a mixed set of BCVs, the maximum applies to each type within the set. For example, if you have some RAID 5 BCVs and non-RAID 5 BCVs, you can have up to 6 RAID 5 and up to 8 non-RAID 5 BCVs.

◆ If you place a CONFIG HOLD on a device, a QUERY report no longer shows the STD with which the BCV is paired. (“CONFIG” on page 76 shows an instance of this.)

◆ To specify an extended query with the QUERY command, you use the Extended(Y) parameter. In this case, the extended format QUERY display is sorted in order by the standard device and the time since the split. The display begins with the first BCV that has had a BCV/standard relationship. BCVs that do not have an BCV/standard relationship are not displayed.

◆ When you specify the keyword SBCV with the Extended parameter (Extended (Y, SBCV)), then the display begins with the BCV whose Symmetrix device number you specified in the QUERY symdv# parameter.

◆ Starting with Version 7.0, the QUERY command now supports EAV devices.

Examples1. In the following example, the QUERY displays all BCVs starting with the specified CUU

831F.

Note: ALL is the default, so if you do not specify a number, QUERY displays ALL BCVs.

QUERY 1,831F BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,831F BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status on device 831F, MICRO-CODE level 5x75 type VMAX-1, S/N 0001234-56789BCVM003I ...BCV... ...STD... ACTION LAST PROT MIRROR BCV BCVM003I CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYL TYPE SYNC MODEBCVM003I 831F 0207 0 0 AVAIL 3390 3339 NONE RD6 BCVM003I 8330 0218 8320 0208 0 0 INUSE EST 0218 3390 3339 MIRR CLONE BCVM003I 8331 0219 8321 0209 0 0 INUSE EST 0219 3390 3339 MIRR CLONEBCVM003I 8332 021A 8322 020A 0 0 INUSE EST 021A 3390 3339 MIRR CLONEBCVM003I 8333 021B 8323 020B 0 0 INUSE EST 021B 3390 3339 MIRR CLONEBCVM003I 8334 021C 8324 020C 0 0 INUSE EST 021C 3390 10017 R1 CLONEBCVM003I 8335 021D 8325 020D 0 0 NR 021D 3390 10017 R1 CLONEBCVM003I 8336 021E 8326 020E 0 0 AVAIL 021E 3390 10017 R1 CLONEBCVM003I 8337 021F 0 0 HOLD-U 021F 3390 10017 R1 CLONEBCVM003I 8338 0220 8328 0210 0 0 AVAIL 0220 3390 1113 NONE RD6/CLONEBCVM003I 8339 0221 8329 0211 0 0 AVAIL 0221 3390 1113 NONE RD6/CLONE BCVM003I 833A 0222 832A 0212 0 0 INUSE EST 0222 3390 1113 NONE RD6/CLONEBCVM003I 833B 0223 832B 0213 0 0 INUSE EST 0223 3390 1113 NONE RD6/CLONEBCVM003I 833C 0224 832C 0214 0 0 INUSE EST 0224 3390 3339 MIRR CLONEBCVM003I 833D 0225 832D 0215 0 0 INUSE EST 0225 3390 3339 MIRR CLONE

BCVM047I All control statements processed, highest RC 0

QUERY 103

Command Reference

2. In the following example, QUERY displays three BCVs starting at CUU 8330.

QUERY 3,8330,3

BCVI020I Start of INPUT control statement(s) from SYSINBCVI018I (0001) QUERY 1,8330,3 BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I QUERY status on device 831F, MICRO-CODE level 5x75 type VMAX-1, S/N 0001234-56789BCVM003I ...BCV... ...STD... ACTION LAST PROT MIRROR BCV BCVM003I CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYL TYPE SYNC MODEBCVM003I 8330 0218 8320 0208 0 0 INUSE EST 0218 3390 3339 MIRR CLONE BCVM003I 8331 0219 8321 0209 0 0 INUSE EST 0219 3390 3339 MIRR CLONEBCVM003I 8332 021A 8322 020A 0 0 INUSE EST 021A 3390 3339 MIRR CLONE

BCVM047I All control statements processed, highest RC 0

3. In the following example, the QUERY displays 8 BCVs starting at symdev# 690. CUU 881F is used as a gatekeeper.

QUERY 1,881F,8,690

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,881F,8,690 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status on device 881F, MICRO-CODE level 5x74 type VMAX-1, S/N 0009876-54321BCVM003I ...BCV... ...STD... ACTION LAST PROT MIRROR BCV BCVM003I CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYL TYPE SYNC MODE BCVM003I ---- 0690 8970 01B2 0 0 INUSE EST 0690 3390 1113 NONE RD5/CLONE BCVM003I ---- 0691 8971 01B3 0 0 INUSE EST 0691 3390 1113 NONE RD5/CLONE BCVM003I ---- 0692 8972 01B4 0 0 INUSE EST 0692 3390 1113 NONE RD5/CLONE BCVM003I ---- 0693 8973 01B5 0 0 INUSE EST 0693 3390 1113 NONE RD5/CLONE BCVM003I ---- 0694 8974 01B6 0 0 INUSE EST 0694 3390 1113 NONE RD5/CLONE BCVM003I ---- 0695 8975 01B7 0 0 INUSE EST 0695 3390 1113 NONE RD5/CLONE BCVM003I ---- 0696 8976 01B8 0 0 INUSE EST 0696 3390 1113 NONE RD5/CLONE BCVM003I ---- 0697 8977 01B9 0 0 INUSE EST 0697 3390 1113 NONE RD5/CLONE BCVM047I All control statements processed, highest RC 0

4. In the following example, the local QUERY displays 4 BCVs starting at symdev# 47A. CUU 831F is used as a gatekeeper.

QUERY 1,LCL(831F),4,47A

BCVM039I (0002) Process input statement BCVM004I QUERY status through device 831F, MICRO-CODE level 5x75 type VMAX-1, S/N 0001926-00215BCVM003I ...BCV... ...STD... ACTION LAST PROT MIRROR BCVBCVM003I CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYLS TYPE SYNC MODEBCVM003I ---- 047Al ---- 046Al 0 0 INUSE EST 047A 3390 1113 NONE RD6/CLONEBCVM003I ---- 047Bl ---- 046Bl 0 0 INUSE EST 047B 3390 1113 NONE RD6/CLONEBCVM003I ---- 047Cl ---- 046Cl 0 0 INUSE EST 047C 3390 1113 NONE RD6/CLONEBCVM003I ---- 047Dl ---- 046Dl 0 0 INUSE EST 047D 3390 1113 NONE RD6/CLONE

5. In the following example, QUERY displays all BCVs in the remote Symmetrix , using gatekeeper CUU 831F and RDF group 0D.

QUERY 2,RMT(831F,0D),ALL

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) QUERY 2,RMT(831F,0D),ALL BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I QUERY status on device 831F, MICRO-CODE level 5x75 type VMAX-1, S/N 0009876-54321BCVM003I ...BCV... ...STD... ACTION LAST PROT MIRROR BCV BCVM003I CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYL TYPE SYNC MODEBCVM003I ---- 0615r ---- 0515r 0 0 AVAIL 0615 3390 3339 NONE RD6/CLONEBCVM003I ---- 0616r ---- 0516r 0 0 AVAIL 0616 3390 3339 NONE RD6/CLONEBCVM003I ---- 0617r ---- 0517r 0 0 AVAIL 0617 3390 3339 NONE RD6/CLONE BCVM003I ---- 0618r ---- 0518r 0 0 AVAIL 0618 3390 3339 NONE RD6/CLONE


Command Reference

BCVM003I ---- 0619r ---- 0519r 0 0 AVAIL 0619 3390 3339 NONE RD6/CLONE BCVM003I ---- 061Ar ---- 051Ar 0 0 AVAIL 061A 3390 3339 NONE RD6/CLONEBCVM003I ---- 061Br ---- 051Br 0 0 AVAIL 061B 3390 3339 NONE RD6/CLONEBCVM003I ---- 061Cr ---- 051Cr 0 0 AVAIL 061C 3390 3339 NONE RD6/CLONEBCVM003I ---- 061Dr ---- 051Dr 0 0 AVAIL 061D 3390 3339 NONE RD6/CLONEBCVM003I ---- 061Er ---- 051Er 0 0 AVAIL 061E 3390 3339 NONE RD6/CLONEBCVM003I ---- 061Fr ---- 051Fr 0 0 AVAIL 061F 3390 3339 NONE RD6/CLONE

6. In the following example, QUERY displays the extended query of three STD devices, starting at symdev# 0FC2 via CUU 831F.

QUERY 1,831F,4,FC2,EX(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,831F,4,FC2,EX(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status on device 831F, MICRO-CODE level 5x75 type VMAX-1, S/N 0001234-56789BCVM073I .SYMDV#.. LAST TIME-FROM BCV BCV STD PAIR LAST TRACK TRACK TRACK BCVM073I STD BCV BCV ...SPLIT.... CNFG STATE STATE STATE ACTION COUNT1 COUNT2 COUNT3 BCVM073I 0FC2 0FD2 0FD2 000.00:00:11 MIRR-C SYNC AVAIL AVAIL N/A 0 N/ABCVM073I 0FC3 0FD3 0FD3 000.00:00:10 MIRR-C SYNC AVAIL AVAIL N/A 0 N/ABCVM073I 0FC4 0FD4 0FD4 MIRR-C ATTACH AVAIL INUSE EST N/A 0 N/ABCVM073I 0FC5 0FD5 0FD5 MIRR-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM047I All control statements processed, highest RC 0

7. In the following example, QUERY displays an extended query of all the STD and BCV pairs in the Symmetrix at CUU 8320. The QUERY display also shows whether a volume is a SNAP volume.

QUERY 1,8320,EX(Y,SBCV,SNAPH)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,8320,EX(Y,SBCV,SNAPH) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status on device 8320, MICRO-CODE level 5x75 type VMAX-1, S/N 0001234-56789BCVM073I .SYMDV#.. LAST TIME-FROM BCV BCV STD PAIR LAST TRACK TRACK TRACKBCVM073I STD BCV BCV ...SPLIT.... CNFG STATE STATE STATE ACTION COUNT1 COUNT2 COUNT3BCVM073I 006B 004B 004B 005.00:02:19 NONE-6 NR AVAIL AVAIL N/A 0 N/A BCVM073I 006C 004C 004C 005.00:02:19 NONE-6 NR AVAIL AVAIL N/A 0 N/A BCVM073I 006D 004D 004D 005.00:02:19 NONE-6 NR AVAIL AVAIL N/A 0 N/ABCVM073I 006E 004E 004E 005.00:02:19 NONE-6 NR AVAIL AVAIL N/A 0 N/A BCVM073I 006F 004F 004F 005.00:02:19 NONE-6 NR AVAIL AVAIL N/A 0 N/A BCVM073I 0080 00A0 00A0 NONE-C HOLD-T AVAIL INUSE EST N/A 0 N/ABCVM073I 0081 00A1 00A1 NONE-C HOLD-T AVAIL INUSE EST N/A 0 N/ABCVM073I 0082 00A2 00A2 NONE-C HOLD-T AVAIL INUSE EST N/A 0 N/ABCVM073I 0083 00A3 00A3 NONE-C HOLD-T AVAIL INUSE EST N/A 0 N/ABCVM073I 0084 00A4 00A4 NONE-C HOLD-T AVAIL INUSE EST N/A 0 N/A

8. In the following example, the QUERY displays an extended query of eight (8) devices starting at STD symdev# 20C in the Symmetrix at CUU 8320.

QUERY 1,8320,8,20C,EX(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,8320,8,20C,EX(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status on device 8320, MICRO-CODE level 5x75 type VMAX-1, S/N 0001234-56789BCVM073I .SYMDV#.. LAST TIME-FROM BCV BCV STD PAIR LAST TRACK TRACK TRACK BCVM073I STD BCV BCV ...SPLIT.... CNFG STATE STATE STATE ACTION COUNT1 COUNT2 COUNT3 BCVM073I 020C 021C 021C MIRR-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM073I 020D 021D 021D 000.01:01:47 MIRR-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 020F 021F 021F 000.01:01:46 MIRR-C HOLD-U AVAIL AVAIL N/A 0 N/A BCVM073I 0210 0220 0220 000.01:01:45 MIRR-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 0211 0221 0221 000.01:01:44 MIRR-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 0212 0222 0222 MIRR-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM073I 0213 0223 0223 MIRR-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM047I All control statements processed, highest RC 0

QUERY 105

Command Reference

9. In the following example, the QUERY displays an extended query of 8 remote devices starting at BCV symdev# 100C. It uses CUU 8320 and RDF group 0D.

QUERY 1,RMT(8320,0D),8,100C,EX(Y,SBCV)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,RMT(8320,0D),8,100C,EX(Y,SBCV) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status through device 8320, MICRO-CODE level 5x75 type VMAX-1, S/N 0001234-56789BCVM073I .SYMDV#.. LAST TIME-FROM BCV BCV STD PAIR LAST TRACK TRACK TRACK BCVM073I STD BCV BCV ...SPLIT.... CNFG STATE STATE STATE ACTION COUNT1 COUNT2 COUNT3 BCVM073I 0C0C 100Cr 100C 005.00:37:09 NONE-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 0C0D 100Dr 100D 005.00:37:09 NONE-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 0C0E 100Er 100E 005.00:37:09 NONE-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 0C0F 100Fr 100F 005.00:37:09 NONE-C SYNC AVAIL AVAIL N/A 0 N/A BCVM073I 0C10 1010r 1010 NONE-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM073I 0C11 1011r 1011 NONE-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM073I 0C12 1012r 1012 NONE-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM073I 0C13 1013r 1013 NONE-C ATTACH AVAIL INUSE EST N/A 0 N/A BCVM047I All control statements processed, highest RC 0

10. In the followinge example, the QUERY provides a remote, multi-hop display starting at CUU 851F. Routes the command via RDF group F). Then goes out of RDF group 52 in the second Symmetrix and displays 8 BCVs starting at symdev# 5E0.

QUERY 1,RMT(851F,F0.52),8,5E0

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) QUERY 1,RMT(851F,F0.52),8,5E0 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I QUERY status through device 851F, MICRO-CODE level 5x74 type VMAX-1, S/N 0009876-54321BCVM003I ...BCV... ...STD... ACTION LAST PROT MIRROR BCVBCVM003I CUU SYM# CUU SYM# ITRK-BCV ITRK-STD STATUS USED BCV EMUL #CYLS TYPE SYNC MODEBCVM003I ---- 05E0r ---- 01A2r 0 0 AVAIL 05E0 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E1r ---- 01A3r 0 0 INUSE EST 05E1 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E2r ---- 01A4r 0 0 AVAIL 05E2 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E3r ---- 01A5r 0 0 INUSE EST 05E3 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E4r ---- 01A6r 0 0 AVAIL 05E4 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E5r ---- 01A7r 0 0 INUSE EST 05E5 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E6r ---- 01A8r 0 0 AVAIL 05E6 3390 1113 MIRR RD5/CLONEBCVM003I ---- 05E7r ---- 01A9r 0 0 INUSE EST 05E7 3390 1113 MIRR RD5/CLONE BCVM047I All control statements processed, highest RC 0


Command Reference

RE-ESTABLISH

PurposeThe RE-ESTABLISH command synchronizes a previously split standard/BCV pair. The BCV becomes Not Ready to the host.

Required syntaxRE-ESTABLISH seq#,cuus[,optional parameter(s)]RE-ESTABLISH seq#,cuus-cuus[,optional parameter(s)]RE-ESTABLISH seq#,DSN=dsn name[,optional parameter(s)]RE-ESTABLISH seq#,LCL(cuu,sym#bcv)[,optional parameter(s)]RE-ESTABLISH seq#,LCL(cuu,sym#bcv-sym#bcv)[,optional parameter(s)]RE-ESTABLISH seq#,RMT(cuu,sym#bcv[,rdfgrp])[,optional parameter(s)]RE-ESTABLISH seq#,RMT(cuu,sym#bcv-sym#bcv[,rdfgrp])[,optional

parameter(s)]


[,CBCV(Y|N)][,CLONEemulation(Yes|No)] [,MULTIATTach(Yes|No)][,PROTECTEDBCVEstablish(Y|N)][,WAIT[(nn)]|NOWAIT]


CBCV

IMPORTANT

The CBCV is ignored on clone emulation operations.

The BCV device specified in this command is allowed as a concurrent BCV for the specified standard device. If mirror positions are available, you can define a maximum of two BCVs for the same standard device.

There are several limitations with concurrent BCVs:

• You can only use concurrent BCVs with Enginuity level 5x68 or higher.

• A Concurrent BCV RE-ESTABLISH is not allowed if the first pair was attached with a RESTORE command.


IMPORTANT


When you use Enginuity 5573 and lower versions, RE-ESTABLISH always uses clone emulation with RAID 5 and RAID 6 BCVs.

With non-RAID 5 or RAID 6 BCVs, RE-ESTABLISH commands use clone emulation if they are in a clone emulation session already established by an ESTABLISH or a full RESTORE. Otherwise, RE-ESTABLISH does not use clone emulation.

RE-ESTABLISH 107

Command Reference

cuu

Specifies any device on a controller for a local (LCL) or remote operation (RMT). For a RMT operation, if the RDF group (rdfgrp) is not specified, then cuu must be an R1 device.

cuus


cuus-cuus


DSN

Specifies the dataset name used to locate the volume or volumes on which to perform the RE-ESTABLISH command. For multi-volume files, the RE-ESTABLISH command is performed on all volumes.

LCL


MULTIATTach(Yes|No)

Enables or disables multi-attach operations for this RE-ESTABLISH command. The alias for MULTIATTach is MULTA.

YesEnables multi-attach for the command, unless the GLOBAL MULTIATTach parameter specifies NONE.

No(Default) Disables multi-attach for the command, regardless of any specification on the GLOBAL MULTIATTach parameter.

Note: The MULTIATTach parameter on “GLOBAL” on page 89 describes multi-attach.

PROTECTEDBCVEstablish(Y|N)

IMPORTANT

For clone emulation operations, all ESTABLISH operations are Protected BCV Establish. On such operations, the PROTECTEDBCVEstablish parameter is ignored.

Protected BCV Establish. Allowable abbreviations are PBCVE, PROTECTEDBCVE, and PROTBCVE. This feature involves locally mirrored BCVs only. When you issue an ESTABLISH command with PROTECTEDBCVEstablish, both mirrors of the BCV are added as mirrors of the standard device. If there are no available mirror positions, this operation fails.

On a BCV Split, both BCV mirrors are synchronized with the standard device, ensuring that there is no point in time at which data is unprotected on the BCV.

rdfgrp



Command Reference


xx.xx.xx.xx

RMT

Specifies that the RE-ESTABLISH command affects remote devices in an SRDF configuration.

seq#


sym#bcv


sym#bcv-sym#bcv

Specifies a range of Symmetrix device numbers of the BCV devices.The first sym#bcv value is the starting device number, and the second sym#bcv is the ending device number.

WAIT[(nn)]|NOWAIT

Specifies the ability to wait for the completion of the action or to continue after the command is passed to the controller.

WAIT = wait for the completion of the specified action

NOWAIT = pass the command to the controller, and assume the action is complete


The default wait times are 10 minutes for a SPLIT command and 120 minutes for ESTABLISH, RE--ESTABLISH, and RESTORE commands.


Comments◆ The data flow is from the standard device to the BCV. The BCV must be offline to all

attached hosts. Only the data changed on the standard device is copied to the BCV. If there was any changed data on the BCV device, that data is lost.

◆ The RE-ESTABLISH process may take a period of time to complete if there was a large amount of update activity to the standard device and/or BCV.

RE-ESTABLISH 109

Command Reference

Examples1. The following example uses clone emulation to reestablish the BCV with CUU 7B35

and does not wait until the device is synched with the STD to execute the next command or end the job. Synching continues.

RE-ESTABLISH 1,7B35,NOWAIT

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) GLOBAL MAXRC(8,SETMAX) BCVI018I (0002) RE-ESTABLISH 1,7B35,NOWAIT BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM004I RE-ESTABLISH BCV device 7B35 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

2. The following example uses clone emulation to reestablish the BCVs with CUU 7B35-7B38 and waits until the RE-ESTABLISHis complete before going to next command or ending job.

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RE-ESTABLISH 3,7B35-7B38 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH BCV device 7B35 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH BCV device 7B36 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH BCV device 7B37 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH BCV device 7B38 BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

3. The following example reestablishes the BCV where the DSN resides.

RE-ESTABLISH 1,DSN=SYST.TEST.DSN

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RE-ESTABLISH 1,DSN=SYST.TEST.DSN BCVI033I * SYST.TEST.DSN SPANS 1 VOLUME(S) BCVI033I * CUU LIST: 8248 BCVI021I End of INPUT control statement(s) from SYSIN


Command Reference

BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH BCV device 0048 BCVM069I Security Exit allowed the bypassing of the online state checkBCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

4. The following example issues the RE-ESTABLISH command locally through gatekeeper CUU 881F to reestablish symdev# 690-693.

RE-ESTABLISH 1,LCL(881F,690-693)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RE-ESTABLISH 1,LCL(881F,690-693) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 0690 through 881F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 0691 through 881F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 0692 through 881F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 0693 through 881F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

5. The following example issues the RE-ESTABLISH command remotely through gatekeeper CUU 851F and RDF group 2F, to reestablish the remote BCV symdev# 690-693.

RE-ESTABLISH 1,RMT(851F,690-693,2F)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RE-ESTABLISH 1,RMT(851F,690-693,2F) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH REMOTE BCV SYMDEV 0690 through 851F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH REMOTE BCV SYMDEV 0691 through 851F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement

RE-ESTABLISH 111

Command Reference

BCVM004I RE-ESTABLISH REMOTE BCV SYMDEV 0692 through 851F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RE-ESTABLISH REMOTE BCV SYMDEV 0693 through 851F BCVM069I Security Exit allowed the bypassing of the online state check BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

6. The following example issues the RE-ESTABLISH command remotely through gatekeeper CUU 85B0 to reestablish the remote BCVs symdev#s 5F0-5FF with the MULTIATTACH(YES) parameter. Because a RDF group was not specified, the RE-ESTABLISH command uses the RDF group of the gatekeeper.

RE-ESTABLISH 1,RMT(85B0,5F0-5FF),MULTATT(YES)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RE-ESTABLISH 1,RMT(85B0,5F0-5FF),MULTATT(YES) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I MULTI RE-ESTABLISH REMOTE devices through 85B0: BCVM004I 05F0-05FF(0001) BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

7. The following example issues the RE-ESTABLISH command remotely through gatekeeper CUU 851F and multi-hops thru RDF groups F0 and 52, to reestablish the remote BCVs symdev#s 5E0-5EF with the PROTECTEDBCVESTABLISH parameter. This means the BCV and the BCV mirror are reestablished with the STD. Also, MULTIATTACH is specified in the GLOBAL statement to cause the multi reestablish of the devices.

GLOBAL MULTA(ALL) RE-ESTABLISH 1,RMT(851F,5E0-5EF,F0.52),PBCVE(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) GLOBAL MULTA(ALL) BCVI018I (0002) RE-ESTABLISH 1,RMT(851F,5E0-5EF,F0.52),PBCVE(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0002) Process input statement BCVM069I Security Exit allowed the bypassing of the online state check BCVM004I MULTI RE-ESTABLISH REMOTE devices through 851F: BCVM004I 05E0-05EF(0002) BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0


Command Reference

8. The following example tries to issue RE-ESTABLISH commands on hold devices and receives BCV146E error messages indicating that the operation was denied because the devices are in hold status.

BCVI018I (0002) RE-ESTABLISH 1,LCL(861F,4B0-4B3) BCVM039I (0002) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 04B0 through 861F BCVM069I Security Exit allowed the bypassing of the online state check BCVM146E Re-establish denied - BCV in HOLD status (Lockid 0BC16681) BCVM039I (0002) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 04B1 through 861F BCVM069I Security Exit allowed the bypassing of the online state check BCVM146E Re-establish denied - BCV in HOLD status (Lockid 0B998A84) BCVM039I (0002) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 04B2 through 861F BCVM069I Security Exit allowed the bypassing of the online state check BCVM146E Re-establish denied - BCV in HOLD status (Lockid 0BE1C484) BCVM039I (0002) Process input statement BCVM004I RE-ESTABLISH LOCAL BCV SYMDEV 04B3 through 861F BCVM069I Security Exit allowed the bypassing of the online state check BCVM146E Re-establish denied - BCV in HOLD status (Lockid 0BA90704) BCVM047I All control statements processed, highest RC 8

Note: “Examples” on page 79 provides examples of the effect of CONFIG HOLD on QUERY reports.

RE-ESTABLISH 113

Command Reference

RESTORE

PurposeThe RESTORE command copies data from a BCV to a standard device. The BCV becomes Not Ready to the host.

SyntaxFull Restore:

RESTORE seq#,cuus,cuup,VERIFY(volser|FBADEV)

Incremental RESTORE:

RESTORE seq#,cuus[,optional parameter(s)]RESTORE seq#,cuus-cuus[,optional parameter(s)]RESTORE seq#,DSN=datasetname[,optional parameter(s)]RESTORE seq#,LCL(cuu,sym#bcv)[,optional parameter(s)]RESTORE seq#,LCL(cuu,sym#bcv-sym#bcv)[,optional parameter(s)]RESTORE seq#,RMT(cuu,sym#bcv[,rdfgrp])[,optional parameter(s)]RESTORE seq#,RMT(cuu,sym#bcv-sym#bcv[,rdfgrp])[,optional parameter(s)]


[,CLONEemulation(Yes|No)][,PROTECTEDRESTORE(Yes|No)][,R1SYNC(Yes|No)] [,VERIFY(volser|FBADEV)][,WAIT[(nn)]|NOWAIT]



IMPORTANT


With TF/Mirror 5.5 and 5.6, CLONEemulation has a different effect depending on whether you are doing a full or Incremental RESTORE.

Full RESTORE:

When the value of CLONEemulation is Yes and you previously set the GLOBAL CLONEemulation parameter to REQUEST, TF/Clone processes the BCV device specified in this statement in clone emulation mode no matter what its RAID protection type.

When the value of CLONEemulation is NO (either specifically set or left as the default) and you previously set the global CLONEemulation parameter to REQUEST:

• The BCV device(s) specified in this statement is not processed in clone emulation mode if that BCV is a non-RAID 5 or non-RAID 6 protected device.

• The BCV device(s) specified in this command is still processed in clone emulation mode if that BCV is a RAID 5 or RAID 6 protected device. TF/Mirror uses clone emulation regardless of the value of the CLONEemulation parameter.


Command Reference

Note: “Clone Emulation mode” on page 47 provides a description of clone emulation mode. “GLOBAL” on page 89 describes the GLOBAL CLONEemulation parameter.

For an Incremental RESTORE:

This parameter is ignored.

Incremental RESTORE commands use clone emulation with RAID 5 and RAID 6 BCVs.

With non-RAID 5 or RAID 6 BCVs, Incremental RESTORE commands use clone emulation if they are in a clone emulation session already established by an ESTABLISH or a full RESTORE. Otherwise, Incremental RESTOREs do not use clone emulation.

cuu

Specifies any device on a controller for a local (LCL) or remote (RMT) operation. For a RMT operation, if the RDF group (rdfgrp) is not specified, then cuu must be an R1 device.

cuup


If you do not specify the standard device, then an Incremental RESTORE to the previously established device is performed.

cuus


cuus-cuus


DSN=datasetname

Specifies the dataset name used to locate the volume or volumes to perform the restore on. For multi-volume files the restore is performed on all volumes.

PROTECTEDRESTORE(Yes|No)

IMPORTANT


If you set PROTECTEDRESTORE to Yes, the restore process proceeds normally, except that the BCV is protected against host write in its related standard until the next SPLIT command. PROTECTEDRESTORE requires Enginuity level 5x70 or higher.

If you set PROTECTEDRESTORE to No (the default), the restore proceeds normally; but, the BCV is not protected against host writes in its related standard until the next SPLIT command.

RESTORE 115

Command Reference

You can abbreviate PROTECTEDRESTORE to any of the following:

• PROTRESTORE

• PROTRSTR

• PRSTR

• PROT

LCL


rdfgrp



xx.xx.xx.xx

R1SYNC(Yes|No)

N is the default and specifies no automatic R2 to R1 synchronization. Y specifies automatic R2 to R1 synchronization. The source (R1) device goes to a TNR (target not ready) state and the target device has invalid tracks for the source (R1) device.

A restore to an R2 device is prohibited if R1SYNC(Y) is specified on Enginuity level 5x68 and higher.

RMT

Specifies that the RESTORE command affects remote devices in an SRDF configuration.

seq#


sym#bcv


sym#bcv-sym#bcv


sym#std


sym#std-sym#std



Command Reference

VERIFY(volser)

This is a required parameter for a full RESTORE operation (cuup is specified). Ensures that the volser specified by this parameter is the same as the standard device specified by cuup. If the BCV specified is an FBA device, then you must specify VERIFY(FBADEV). For an Incremental RESTORE, the operand is ignored.

WAIT[(nn)]|NOWAIT

Specifies waiting for the completion of the action or continuing after the command is passed to the controller.

WAIT = wait for the completion of the specified action.

NOWAIT = pass the command to the controller, and assume the action is complete.


The default wait times are 10 minutes for a SPLIT command and 120 minutes for ESTABLISH, RESTABLISH, and RESTORE commands.


Comments◆ The standard and BCV device sizes must be equal.

◆ If you do not specify cuup, then the operation is an Incremental RESTORE to the last standard device attached to the BCV and only the changed data on the standard device and BCV is synchronized. If there was any changed data on the standard device, that data is lost.

If you do specify cuup, then TF/Mirror copies the entire contents of the BCV to the specified standard device. The VERIFY parameter is required on a full RESTORE operation.

◆ The BCV must be offline to the operating system for both full and Incremental RESTORE operations. The standard device must be offline to the operating system for a full RESTORE operation. If you perform an Incremental RESTORE with the standard device online, you may need to switch the device offline then online again depending on the data that was refreshed.

◆ When in Clone Emulation mode, if a FULL RESTORE action is performed against a pair of devices that do not have an existing relationship, the microcode requires a new session to be created between them. In this case, a microcode ESTABLISH is performed, instead of a microcode RESTORE.

◆ A WTOR is issued to the system console for operator confirmation for both full and Incremental RESTORE operations.

◆ The RESTORE command process may take a period of time to complete if there was a large amount of update activity to the standard device and/or BCV. You may not specify a range of devices on a full RESTORE operation.

◆ The standard device must be online to perform an Incremental RESTORE while using the DSN option.

RESTORE 117

Command Reference

◆ You may also change the standard device associated with a BCV, in which case the entire device would be copied.

Note: The BCV must be offline to all attached hosts for both incremental and full RESTORE operations. The standard device must be offline to all hosts for full RESTORE operations.

◆ Keep in mind that this process can be destructive to the BCV because any new writes made to the standard volume are also made to the BCV. If you want to keep the original point-in-time copy after a full or Incremental RESTORE, perform the following sequence to preserve the BCV:

• Make sure the standard device is offline to all hosts.• Restore to the standard volume.• With standard volumes remaining offline, split the BCV.• VARY online the standard device only after the split is accomplished.

◆ TF/Mirror accepts a RESTORE or Incremental RESTORE only if all tracks were copied from the source device before the RESTORE operation was initiated.

◆ Keep in mind that if you issue multiple Incremental RESTORE commands to multiple Symmetrix systems simultaneously that specify as the gatekeeper the same STD devices that are the targets of the RESTORE operations, the requests fail. To avoid the problem, change the RESTORE commands to specify a BCV device as the gatekeeper.

◆ TF/Mirror denies RESTORE commands to active R2 standard devices. Currently, ECA can be employed on the local Symmetrix only. If the R1 device is on a remote Symmetrix controller, ECA is not set.

◆ Under Enginuity 5773 and lower, you can not use SRDF Host Component synchronization procedures 4 and 6 while Clone Emulation restores were taking place. However, under Enginuity 5874 and higher, you can, you can use SRDF Host Component synchronization procedures 4 and 6 while Clone Emulation restores are taking place.

Examples1. In the following example, a RESTORE command performs a full restore of BCV CUU

DE18 to STD CUU DE10, with volser USK272. The RESTORE command also waits until it has completed before continuing on or ending. Note that clone emulation is being used, therefore the restore is protected.

RESTORE 1,DE18,DE10,WAIT,VERIFY(USK272)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RESTORE 1,DE18,DE10,WAIT,VERIFY(USK272) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I RESTORE BCV device DE18 to DE10 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM069I Security Exit allowed the bypassing of the online state check BCVM070I Security Exit allowed the bypassing of the WTOR on a Full Restore BCVM139I BCV DE18 is TF/Clone, Restore is PROTECTED BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0


Command Reference

2. The following example performs a partial restore (changed tracks only) of BCV CUUs DF21 and DF22.

RESTORE 1,DF21-DF22

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RESTORE 1,DF21-DF22 BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I RESTORE BCV device DF21 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM039I (0001) Process input statement BCVM004I RESTORE BCV device DF22 BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM047I All control statements processed, highest RC 0

3. In the following example the RESTORE command is issued remotely through CUU C120 and RDF group 70 to perform a partial restore for BCV symdev# 01CC using clone emulation.

RESTORE 1,RMT(C120,01CC,70)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RESTORE 1,RMT(C120,01CC,70) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I RESTORE REMOTE BCV SYMDEV 01CC through C120 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM139I BCV 01CC is TF/Clone, Restore is PROTECTED BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

4. In the following example, the RESTORE command is issued remotely through CUU C120 and RDF group E0 to perform a partial restore for BCV symdev#s 1D4, 1D5, and 1D6 using clone emulation.

RESTORE 1,RMT(C120,01D4-1D6,E0)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RESTORE 1,RMT(C120,01D4-1D6,E0) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I RESTORE REMOTE BCV SYMDEV 01D4 through C120 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM139I BCV 01D4 is TF/Clone, Restore is PROTECTED BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RESTORE REMOTE BCV SYMDEV 01D5 through C120 BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore

RESTORE 119

Command Reference

BCVM139I BCV 01D5 is TF/Clone, Restore is PROTECTED BCVM140I Command processed via TF/Clone emulation BCVM039I (0001) Process input statement BCVM004I RESTORE REMOTE BCV SYMDEV 01D6 through C120 BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM139I BCV 01D6 is TF/Clone, Restore is PROTECTED BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

5. The following example performs a partial restore on symdev#s 1FD-1FF through CUU DF60.

RESTORE 1,LCL(DF60,01FD-01FF)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RESTORE 1,LCL(DF60,01FD-1FF) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I RESTORE LOCAL BCV SYMDEV 01FD through DF60 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM039I (0001) Process input statement BCVM004I RESTORE LOCAL BCV SYMDEV 01FE through DF60 BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM039I (0001) Process input statement BCVM004I RESTORE LOCAL BCV SYMDEV 01FF through DF60 BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM047I All control statements processed, highest RC 0

6. In the following example, the RESTORE command is issued remotely through CUU DE20 and RDF group E0, to restore symdev#s 18D and 18E. BCVs are protected.

RESTORE 4,RMT(DE20,18D-18E,E0),PROTRSTR(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) RESTORE 4,RMT(DE20,18D-18E,E0),PROTRSTR(Y) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I RESTORE REMOTE BCV SYMDEV 018D through DE20 BCVM080I ACCESS ALLOWED BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM039I (0001) Process input statement BCVM004I RESTORE REMOTE BCV SYMDEV 018E through DE20 BCVM069I Security Exit allowed the bypassing of the online state check BCVM071I Security Exit allowed the bypassing of the WTOR on a Partial Restore BCVM047I All control statements processed, highest RC 8


Command Reference

SPLIT

PurposeThe SPLIT command stops the mirroring process between the two devices. After the standard-to-BCV relationship is split, the changed tracks for both devices are logged, and the BCV becomes Ready to the host.

Required syntaxSPLIT seq#,cuus[,VOLID(volser[,E])][,optional

parameter(s)]SPLIT seq#,cuus-cuus[,optional parameter(s)]SPLIT seq#,DSN=datasetname[,optional parameter(s)]SPLIT seq#,LCL(cuu,sym#bcv)[,optional parameter(s)]SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv)[,optional

parameter(s)]SPLIT seq#,RMT(cuu,sym#bcv[,rdfgrp])[,optional

parameter(s)]SPLIT seq#,RMT(cuu,sym#bcv-sym#bcv[,rdfgrp])[,optional

parameter(s)]


[,BCVRefresh(Yes|No)][,ChangedOnly(Yes|No)][CLONEemulation(Yes|No)] [,CONSistent(GLOBAL[(ECA|IOSLevel)][,STDcuu(cuu)]

[,TIMEOUT(nnnn)])] [,CONSistent(LOCAL[(BYPassonlinecheck[,ECA|IOSLevel)]

[,STDcuu(cuu][,TIMEOUT(nnnn)])][,FORCE|NOFORCE][,HOLD][,INStant(Yes|No)][,NR][,PROTECTEDRESTORE(Y)][,R2Sync(Yes|No)][,WAIT[(nnnn)]|NOWAIT] [,WaitSync(WTO(Yes|No))]

SPLIT 121

Command Reference


BCVRefresh(Yes|No)

IMPORTANT

The BCVREFRESH parameter on the SPLIT command is ignored when you are using clone emulation.

Specifies that the BCV (M1) is synchronized from BCV mirror (M2). Normal processing is from M1 to M2.

Note: The EMC Mainframe Enablers Message and Code Guide provides more information about BCVM138W.

BYPassonlinecheck(Yes|No)

Specifies bypassing the online check for the standard devices on other LPARs. Coding BYPassonlinecheck specifies that there is no dependent I/O from other LPARS to the volume(s) in a LOCAL (single image) Consistent SPLIT.

ChangedOnly(Yes|No)

Specifies that only changed tracks on the BCV mirrors are synchronized. If you are using an Enginuity level of 5x67 or below, the default is No for a regular (non-instant) split. If you are using an Enginuity level of 5x68 or higher, all Instant SPLITs are differential and specifying No generates a BCVI101W message.


IMPORTANT

Under Enginuity 5874, all operations are processed in clone emulation mode. For such operations, the CLONEemulation parameter is ignored.

In TF/Mirror 5.5 and 5.6 systems using Enginuity 5573 and lower versions, SPLIT commands use clone emulation with non-RAID 5 or RAID 6 BCVs if they are in a clone emulation session already established by an ESTABLISH or a full RESTORE. Otherwise, SPLIT does not use clone emulation.

CONSistent

Only valid with Enginuity level 5x66 and higher. Specifies a Consistent SPLIT. You can specify the RMT parameter to achieve a Consistent SPLIT in a remote Symmetrix system.

Note: “GLOBAL” on page 89 describes the values that can be used CONSISTENT(GLOBAL).

cuu

Specifies any device on a controller for a local (LCL) or remote (RMT) operation. For a remote (RMT) operation, if you do not specify the RDF group (rdfgrp), then cuu must be an R1 device.


Command Reference

You do not have to initiate a remote Consistent SPLIT in a multi-hop environment from the host attached to the array on which you want to obtain the point of consistency (site A). You can now initiate a Consistent SPLIT from site B or site C. TF/Mirror dynamically validates the location of the R1 device.

In addition, the R1 in a remote Consistent SPLIT must be in Synchronous mode. It cannot be in Semi-Synchronous or Adaptive Copy modes. If the R1 is in either if these latter two modes, TF/Mirror issues message BCVI119W (or E depending on the MAXRC value).

cuus


cuus-cuus


DSN

Specifies the dataset name used to locate the volume or volumes on which to perform the SPLIT command. For multi-volume files, the SPLIT command is performed on all volumes.

ECA

Specifies using ECA I/O control. ECA is the default and is used if you make no specification.

FORCE|NOFORCE

(Default.) NOFORCE specifies that the pair may not be split until the ESTABLISH or RESTORE command operation completes.

FORCE allows you to split the pair during an ESTABLISH or RESTORE command operation (invalid tracks exist on the device).

Starting with Version 7.0, FORCE is supported in clone emulation mode.

GLOBAL

Specifies a multi-image Consistent SPLIT.

SPLIT 123

Command Reference

HOLD

Specifies that the BCV device is made not available for TF/Mirror commands from all hosts.

[INStant(Yes|No)]

Only valid with Enginuity level 5x66 and higher. INStant specifies whether to perform an Instant SPLIT. An Instant SPLIT is done in the background after completion of the SPLIT I/O request.

If you specify INStant(Y) on a cuu-cuu range request, all devices are split in one I/O operation. You must specify INStant when splitting concurrent BCVs. If you are splitting a BCV that was ESTABLISHed with the CBCV option, you must code INStant(Y) on the SPLIT command.

IOSLEVEL

Specifies using IOSLEVEL I/O control. I/O control is then accomplished using IOSLEVEL even if the control unit is ECA capable.

LCL


LOCAL

Specifies a single-system Consistent SPLIT.

NR

Specifies that the BCV is Not Ready after the split. This prevents a duplicate volser condition at IPL time if you do not relabel the device. In this state, the BCV can not be varied online or accessed.

PROTECTEDRESTORE(Y)

IMPORTANT


Required for a SPLIT command to succeed after a Protected RESTORE if you set the GLOBAL PROTECTEDRESTORE parameter to REQUEST or, because REQUEST is the default, if you did not set the GLOBAL PROTECTEDRESTORE parameter.

You can abbreviate the PROTECTEDRESTORE parameter to any of the following:

• PROTRESTORE

• PROTRSTR

• PRSTR

• PROT


Command Reference

Note: “PROTECTEDRESTORE(REQUEST|CLONE|ALLBCV)” on page 95 provides more information about PROTECTEDRESTORE.

[R2Sync(Yes|No)]

Only valid with Enginuity level 5x65 and higher. Specifies in the case of a R1 BCV if after the split the data is propagated to the R2.

If you specify R2Sync (N) and the BCV RDF pair is suspended, a subsequent split with R2SYnc(Y) resumes the BCV RDF pair. A SPLIT with R2SYNC(Y) resumes the R1-BCV link regardless of any prior SPLIT with R2SYNC(N).

rdfgrp


This must be a one or two-digit value representing the RDF group. For multi-hop remote configurations, the rdfgrp can be a single RDF group or a list of up to four one or two-digit RDF groups (hops) separated by periods. For example:

xx.xx.xx.xx

SPLIT now supports up to two hops for remote Consistent SPLITs.

RMT

Specifies that the split affects remote devices in an SRDF configuration.

seq#


STDcuu(cuu)

When the relationship between the standard and BCV devices is not symmetric, TF/Mirror cannot determine the STDcuu that is paired with the BCV. In this case, the STDcuu parameter is needed. When specified with LOCAL and RMT keywords that specify a range, the STDcuu references the first standard device in the range.

The STDcuu parameter is optional for a remote Consistent SPLIT and for any other form of a Consistent SPLIT. If you do specify the STDcuu parameter, TF/Mirror validates the specification. If the STDcuu parameter does not reference the correct R1, TF/Mirror issues message BCVI120W (or E depending on the MAXRC value) and substitutes the correct R1.

(cuu) is a z/OS logical address enclosed in parentheses.

sym#bcv


sym#bcv-sym#bcv


SPLIT 125

Command Reference

TIMEOUT(nnnn)

The default is 15 seconds. When both the GLOBAL and the SPLIT TIMEOUT are set, the most restrictive (lowest) value is used.

For example, if the GLOBAL TIMEOUT is set at 15 and the SPLIT TIMEOUT is set at 30, TF/Mirror would use a value of 15. If GLOBAL TIMEOUT is set at 22 and the SPLIT TIMEOUT is set at 30, TF/Mirror would use a value of 22.

VOLID

Changes the volser of the BCV after the BCV pair splits. VOLID is allowed only for a single cuu SPLIT when the WAIT option is specified by this command or is implied by the GLOBAL command.

The E option expands the processing of the BCV device by updating the VVDS and index VTOC names, updating the VVDS name entry, and updating the DSCBs to reflect the new volser.

The VOLID parameter is invalid for FBA cuus.

Note: When Clone Emulation is in use, the NOWAIT parameter is allowed in combination with the VOLID parameter.

WAIT[(nnnn)]|NOWAIT

Specifies the time allotted for either waiting for the completion of the action or continuing immediately after the command is passed to the controller. A maximum of up to 9999 minutes can be specified.

Note: If WaitSync was specified, the time (nnnn) also includes the waiting time allocated to synchronize the BCV mirror.

WAIT = Wait for the completion of the specified action.

NOWAIT = Pass the command to the controller, and assume the action is complete.

Note: “GLOBAL” on page 89 provides the default.

The default wait time is 60 minutes for a SPLIT command. With Instant SPLIT, the processing of the split is done in the background. If you specify WAIT, the split process is elongated.

The optional (nnnn) allows the default wait interval to be changed. Enter nnnn as a numeric value that specifies how many minutes you want to wait. For example, WAIT(10) specifies a 10-minute wait.

WaitSync(WTO(Yes|No))

If the BCV device has a mirror (M2, M3, or M4), then wait for the mirrors to synchronize (M1-M4). The optional parameter WTO issues a WTO to route code 11 specifying the start and stop points. BCVM060I indicates the start of the synchronization while BCVM061I indicates the end of the synchronization.

Note: The EMC Mainframe Enablers Message and Code Guide describes BCVM060I.


Command Reference

Comments◆ The Instant SPLIT capability is available with Enginuity level 5x66 or higher.

Note: To process a RESTORE command immediately after an Instant SPLIT, you must specify WAIT in the Instant SPLIT command.

◆ After the split occurs, you may then resume the relationship between the two devices. In that case, only the modified tracks are synchronized.

◆ The FORCE option allows you to split the pair during an ESTABLISH or a RESTORE (invalid tracks on device) command operation.

Note: Starting with Version 7.0, FORCE is supported in clone emulation mode.

◆ You can use the TimeFinder Utility after the split to process the files on the BCV.

Note: The TimeFinder Utility for z/OS Product Guide describes the TimeFinder Utility.

◆ The VOLID Extended option allows you to perform logical restores from a physical backup. The updated VVDS and Index VTOC allow subsequent processing of VSAM files using the IBM utility program IDCAMS or the TimeFinder Utility, EMCTFU.

Note: The TimeFinder Utility for z/OS Product Guide provides more information about EMCTFU.

◆ When splitting a BCV that was established with CBCV(Y) options, INS(Y) must be specified on the SPLIT command.

◆ You use BCVREFRESH to select one of the differential data modes as described below:

Reverse split and reverse differential SPLIT operations are supported with Enginuity level 5x68 and higher. Both are Instant SPLITs.

When specifying a reverse split or reverse differential split (BCVR (Y)), be sure that the BCV is locally mirrored and that BCV mirror (M2) was fully synchronized with the BCV before the BCV was established. If you attempt a reverse split when the BCV is not local and the BCV and its mirror were never synchronized, the reverse split fails and you receive a BCVM148W (or E depending on the MAXRC value) error message.

Note: TF/Mirror validates reverse splits. Under Enginuity 5773 and lower, when the BCV is not locally mirrored or when the fixed mirror is not synchronized, you receive the message BCVM148. The EMC Mainframe Enablers Message and Code Guide provides a description of this message.

BCVREFRESH Split type

BCVR (N) Differential split

BCVR (Y) Reverse differential split

SPLIT 127

Command Reference

When you specify CO(Y) and BCVR(Y), the BCV is updated from its mirror and only changed tracks on the BCV are replaced with its mirrored tracks (M2 tracks). This feature can cause the resynchronization to complete faster. A Consistent SPLIT command requires that the standard device be online and available to the host.

◆ The TF/Mirror REVERSE SPLIT command is designed to refresh a BCV only from a local mirror. However, there is a workaround you can use to refresh a BCV from a remote mirror:

1. Do a normal SPLIT with R2SYNC(N).

2. Set SYNCH_DIRECTION = R1< R2 for the RA-group of this R1BCV.

3. Make the R1BCV RDF-NRDY.

4. Issue a REFRESH command against this R1BCV.

5. Issue a RFR-RSUM command against this R1BCV.

6. Reset SYNCH_DIRECTION to previous value.

◆ When you issue a remote consistent SPLIT, TF/Mirror examines the SRDF environment you specified. If the environment consists of mixed ECA and non ECA protected volumes, TF/Mirror uses non-ECA protection. If all the volumes are using ECA, then TF/Mirror uses ECA protection.

◆ When you issue a consistent SPLIT for a BCV attached to an R2 (STD), TF/Mirror checks the RDF status of the R2. If the R2 is active, TF/Mirror does not set ECA on the R2 and issues message BCVI119W (or E depending on the MAXRC value).

◆ A consistent split operation of a mixture of SRDF/A and non-SRDF/A devices cannot guarantee consistency. If you issue a remote consistent split of an environment consisting of mixed SRDF/A and non-SRDF/A, TF/Mirror converts the operation to an Instant SPLIT and issues message BCVI122W (or E depending on the MAXRC value) to inform you of the change.

◆ TF/Mirror disables ECA for an SRDF/A remote Consistent SPLIT. Consistency for BCVs attached to SRDF/A R2 devices is managed by suspending SRDF/A during the Split and does not require ECA.

Examples1. The following example splits the BCV with CUU DF21

SPLIT 1,DF21

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,DF21 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I INSTANT SPLIT BCV device DF21 BCVM047I All control statements processed, highest RC 0

2. The following example performs a multiple, Instant SPLIT of the BCV range with CUUs DF60 through DF62. Also, note that clone emulation is utilized by default because the devices are Raid 5.

SPLIT 1,DF60-DF62,INS(Y)


Command Reference

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,DF60-DF62,INS(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I * MULTI INSTANT-SPLIT BCV devices: BCVM004I * DF60-DF62(0001) BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

3. The following clone-emulation example issues the SPLIT to the BCV that is paired with the STD where the DSN resides. The SPLIT command waits until the split is completed before continuing or ending the job. (The WAIT parameter is the default.)

SPLIT 6,DSN=LVALIQ1.TEST.DSN2,WAIT

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 6,DSN=SYST.TEST.DSN2,WAIT BCVI033I * SYST.TEST.DSN2 SPANS 1 VOLUME(S) BCVI033I * CUU LIST: 8248 BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I INSTANT SPLIT BCV device 0049 BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

4. The following example issues the SPLIT command remotely through CUU C121 and RDF group 06 to split symdev# 27C using clone emulation.

SPLIT 1,RMT(C121,27C,06)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,RMT(C121,27C,06) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I INSTANT SPLIT REMOTE BCV SYMDEV 027C through C121 BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

5. The following example splits BCV CUU DE18 and changes the volser to TST27A using clone emulation.

SPLIT 1,DE18,VOLID(TST27A)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,DE18,VOLID(TST27A) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I INSTANT SPLIT BCV device DE18 BCVM140I Command processed via TF/Clone emulation BCVM030I CLIP VOLID(TST27A) complete on BCV DE18 BCVM047I All control statements processed, highest RC 0

6. The following clone-emulation example splits BCV CUU DE19 and changes the volser to TST27B. It also updates the VTOC, IXVTOC, and VVDS.

SPLIT 129

Command Reference

SPLIT 1,DE19,WAIT,VOLID(TST27B,E)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,DE19,WAIT,VOLID(TST27B,E) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I INSTANT SPLIT BCV device DE19 BCVM140I Command processed via TF/Clone emulation BCVM030I CLIP VOLID(TST27B) complete on BCV DE19 BCVM038I VTOC, IXVTOC, and VVDS updated BCVM047I All control statements processed, highest RC 0

7. The following example issues the SPLIT command remotely through CUU C122 and RDF group E0 to perform a multi-instant SPLIT to symdev#s 1FD-1FF.

SPLIT 1,RMT(C122,01FD-01FF,E0),INS(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,RMT(C122,01FD-01FF,E0),INS(Y) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I * MULTI INSTANT-SPLIT REMOTE BCV devices through C122: BCVM004I * 01FD-01FF(0001) BCVM047I All control statements processed, highest RC 0

8. The following example issues a SPLIT command locally through CUU C122 to perform a multi-instant SPLIT to symdev#s 18D-18F. The command also specifies that the BCV (M1) is synchronized from BCV mirror (M2).

SPLIT 1,LCL(C122,18D-018F),INS(Y),BCVREFRESH(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,LCL(C122,18D-018F),INS(Y),BCVREFRESH(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I * MULTI INSTANT-SPLIT LOCAL BCV devices through C122: BCVM004I * 018D-018F(0001) BCVM047I All control statements processed, highest RC 0

9. The following clone-emulation example issues a SPLIT command remotely through CUU DE20 and RDF group 06 to perform a remote multi-image Consistent SPLIT, setting the TIMEOUT value to 05 seconds on symdev# 01CC. I/O. In this example, TF/Mirror does not wait for the command to complete before continuing.

SPLIT 1,RMT(DE20,01CC,6),CONS(GLOBAL,TIMEOUT(5),STDCUU(DF60)),NOWAIT

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,RMT(DE20,01CC,6),CONS(GLOBAL,TIMEOUT(5),STDCUU(DF60)),NOWAITBCVI021I End of INPUT control statement(s) from SYSIN BCVI082I (0001) Symm 0001903-00097, ECA detected and enabled BCVM039I (0001) Process input statement BCVM004I CONSISTENT-SPLIT REMOTE BCV SYMDEV 01CC through DE20 BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0


Command Reference

10. The following clone-emulation example issues a SPLIT command locally through CUU DE22 to BCV symdev# 01D4. RDF is not resumed after the split.

SPLIT 1,LCL(DE22,01D4),R2SYNC(N)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,LCL(DE22,01D4),R2SYNC(N) BCVI021I End of INPUT control statement(s) from SYSIN

BCVM039I (0001) Process input statement BCVM004I INSTANT SPLIT LOCAL BCV SYMDEV 01D4 through DE22 BCVM140I Command processed via TF/Clone emulation BCVM047I All control statements processed, highest RC 0

11. The following example issues a multi-hop SPLIT command remotely through CUU 9A10 and RDF group 50. Then, the SPLIT command ‘hops’ through RDF group 13 and issues a multi-instant SPLIT to symdev# range EF8-EF9.

SPLIT 7,RMT(9A10,EF8-EFA,50.13),INS(Y)

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 7,RMT(9A10,EF8-EFA,50.13),INS(Y) BCVI021I End of INPUT control statement(s) from SYSIN BCVM039I (0001) Process input statement BCVM004I * MULTI INSTANT-SPLIT REMOTE BCV devices through 9A10: BCVM004I * 0EF8-0EFA(0001) BCVM047I All control statements processed, highest RC 0

12. This example issues a SPLIT command issued remotely through CUU DE20 and RDF group 50 to perform a remote, multi-image, Consistent SPLIT using ECA to hold the I/O symdev# range 16A-16C.

SPLIT 2,RMT(DE20,16A-16C,50),INS(Y),CONS(GLOBAL(ECA))

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 2,RMT(DE20,16A-16C,50),INS(Y),CONS(GLOBAL(ECA))BCVI021I End of INPUT control statement(s) from SYSIN BCVI082I (0001) Symm 0001903-00344, ECA detected and enabled BCVM039I (0001) Process input statement BCVM004I * CONSISTENT-SPLIT REMOTE BCV devices through DE20: BCVM004I * 016A-016C(0001) BCVM047I All control statements processed, highest RC 0

13. The following example issues a remote consistent split thru gatekeeper 8510 and RDF group F2 to perform a remote, multi-image, Consistent SPLIT using ECA to hold the I/O symdev# range 5F0-5FF. However, since SRDF/A was detected, it is suspended and resumed to ensure consistency.

SPLIT 1,RMT(8510,5F0-5FF,F2),INS(Y),CONS(GLOBAL(ECA))

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) SPLIT 1,RMT(8510,5F0-5FF,F2),INS(Y),CONS(GLOBAL(ECA)) BCVI021I End of INPUT control statement(s) from SYSIN BCVI082I (0001) Symm 0001926-00313, ECA detected and enabled BCVI121I ECA bypassed for SRDF/A Remote Consistent Split

SPLIT 131

Command Reference

BCVM039I (0001) Process input statement BCVM004I * CONSISTENT-SPLIT REMOTE BCV devices through 8510: BCVM004I * 05F0-05FF(0001) BCVM140I Command processed via TF/Clone emulation BCVM133I SRDFA Suspend successful for RA Group F2, CUU 8510, Symm 0001926-00313BCVM133I SRDFA Resume successful for RA Group F2, CUU 8510, Symm 0001926-00313 BCVM047I All control statements processed, highest RC 0

14. The following example issues a remote consistent split in a ConCurrent SRDF/A environment. (Supported in Enginuity 5x75 and above). It simultaneously splits symdev# range 5F0-5FF and 690-69F, using gatekeeper CUU 8510 and RDF groups F2 and 2F respectively to suspend / resume SRDF/A to ensure consistency. But, note the BCVM157W warning because MSC is not active, consistency cannot be guaranteed.

SPLIT 1,RMT(8510,5F0-5FF,F2),INS(Y),CONS(GLOBAL(ECA)) SPLIT 1,RMT(8510,690-69F,2F),INS(Y),CONS(GLOBAL(ECA))

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0002) SPLIT 1,RMT(8510,5F0-5FF,F2),INS(Y),CONS(GLOBAL(ECA)) BCVI018I (0003) SPLIT 1,RMT(8510,690-69F,2F),INS(Y),CONS(GLOBAL(ECA)) BCVI021I End of INPUT control statement(s) from SYSIN BCVI082I (0002) Symm 0001926-00313, ECA detected and enabled BCVI121I ECA bypassed for SRDF/A Remote Consistent Split BCVM039I (0002) Process input statement BCVM004I * CONSISTENT-SPLIT REMOTE BCV devices through 8510: BCVM004I * 05F0-05FF(0002) BCVM140I Command processed via TF/Clone emulation BCVM004I * CONSISTENT-SPLIT REMOTE BCV devices through 8510: BCVM004I * 0690-069F(0003) BCVM140I Command processed via TF/Clone emulation BCVM133I SRDFA Suspend successful for RA Group F2, CUU 8510, Symm 0001926-00313BCVM133I SRDFA Suspend successful for RA Group 2F, CUU 8510, Symm 0001926-00313BCVM133I SRDFA Resume successful for RA Group F2, CUU 8510, Symm 0001926-00313 BCVM133I SRDFA Resume successful for RA Group 2F, CUU 8510, Symm 0001926-00313 BCVM157W Consistent Split includes multiple SRDF/A groups without MSC, consistency cannot be assured BCVM047I All control statements processed, highest RC 4

15. The following example issues a remote consistent split in a cascaded R21 configuration. The command is being issued from the gatekeeper 8510, using multi-hop RDF groups F0 and 52 to consistently split symdev# range 4E0-4EF. Note, that since ECA is sent on the R21, that the GLOBAL parameter CONS(ALLOWNONSYNC) is required. The BCVM080I messages are issued because DEBUG(ECA) is also coded on the GLOBAL statement.

GLOBAL CONS(ALLOWNONSYNC),MAXRC(4,SETMAX),DEBUG(ECA) SPLIT 1,RMT(8510,4E0-4EF,F0.52),INS(Y),CONS(GLOBAL(ECA))

BCVI020I Start of INPUT control statement(s) from SYSIN BCVI018I (0001) GLOBAL CONS(ALLOWNONSYNC),MAXRC(4,SETMAX),DEBUG(ECA) BCVI018I (0002) SPLIT 1,RMT(8510,4E0-4EF,F0.52),INS(Y),CONS(GLOBAL(ECA)) BCVI021I End of INPUT control statement(s) from SYSIN BCVI133W (0002) BCV 04E0, Consistent Split allowed for (ADCOPY-Disk) BCVI082I (0002) Symm 0001926-00313, ECA detected and enabled BCVI133W (0002) BCV 04E1, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E2, Consistent Split allowed for (ADCOPY-Disk)


Command Reference

BCVI133W (0002) BCV 04E3, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E4, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E5, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E6, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E7, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E8, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04E9, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04EA, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04EB, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04EC, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04ED, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04EE, Consistent Split allowed for (ADCOPY-Disk) BCVI133W (0002) BCV 04EF, Consistent Split allowed for (ADCOPY-Disk) BCVM039I (0002) Process input statement BCVM004I * CONSISTENT-SPLIT REMOTE BCV devices through 8510: BCVM004I * 04E0-04EF(0002) BCVM140I Command processed via TF/Clone emulation BCVM080I Window Set, Symm 0001926-00313, Duration 0019, Interval 0001, Run# 0001, through 8510BCVM080I Start device 00B2, Last 00C1 BCVM080I Window Clr, Symm 0001926-00313, Run# 0001, through 8510 BCVM080I Start device 00B2, Last 00C1 BCVM047I All control statements processed, highest RC 4

USEREXIT

PurposeThe USEREXIT command allows you to pass control to a user written program during the processing of TF/Mirror actions.

Required syntaxUSEREXIT seq#,load-module-name,p1,p2



load-module-name

Specifies the user-written program to which control is to be passed during the processing of TF/Mirror actions.

p1

Four-digit (two-byte) hexadecimal value.

p2

Four-digit (two-byte) hexadecimal value.

seq#

Specifies a decimal number from one to 128 that indicates in what order the specified command is executed. All actions on the same sequence level are executed in parallel.

USEREXIT 133

Command Reference

Comments◆ The program specified is linked to using the LINK macro while passing the parameters

p1 and p2 which are four-digit hexadecimal values. The exits are executed on their sequence level in the order that you specified them in the SYSIN file. The exit routine must specify in R15 the exit return code when returning control. This return code is checked against the MAXRC specified in the GLOBAL command.

ExampleThe following example passes TF/Mirror control to a user written program called WAITBKUP.

USEREXIT 1,WAITBKUP,008A,C001


CHAPTER 5SRDF/AR

Invisible Body Tag

This chapter introduces the Symmetrix Automated Replication (SRDF/AR) feature. It provides information on the automated consistent resynchronization cycle provided by SRDF/AR and the commands used to control the cycle.

◆ Introduction to SRDF/AR processing ...................................................................... 136◆ Defining a SAR (Symmetrix Automated Replication) environment........................... 142◆ Using SRDF/AR...................................................................................................... 143◆ ADD ...................................................................................................................... 144◆ DELETE.................................................................................................................. 145◆ GLOBAL................................................................................................................. 145◆ MODIFY................................................................................................................. 145◆ SRDF/AR storage estimates ................................................................................... 153◆ Example................................................................................................................ 153◆ Performing restart in a SRDF/AR environment........................................................ 159◆ Testing SRDF/AR recovery procedures ................................................................... 161◆ Operational considerations ................................................................................... 166◆ Drive failure recovery procedures .......................................................................... 167◆ Documenting problems......................................................................................... 170

SRDF/AR 135

SRDF/AR

Introduction to SRDF/AR processingSRDF/AR is a feature that offers you data protection with consistency over a distance. This protection is achieved by using geographically separated replicas with hardware and software products and facilities from EMC Corporation.

The SRDF/AR feature allows you to automate data copies across SRDF links to provide a restartable image of the data at a remote site in the event of a disaster at the production site.

Note: SRDF/A is incompatible with SRDF/AR. For a single hop run, each R1-BCV is checked. For Automated Multi-hop Configuration (AMH), the source R1-STD devices are checked.

SRDF/AR ensures that a logically consistent, restartable image of the data is automatically propagated to the recovery site in a manner transparent to the host application or database. The result is a series of consecutive data save points that you can use as the basis for restarting host applications on the remote end of the link.

You can use SRDF/AR in single-hop and multi-hop configurations.

Note: “SRDF/AR in multi-hop configurations” on page 141 provides more information about multi-hop configurations.

Terms and concepts

Most of these terms and concepts have been introduced lower in this guide. However, it may be useful to review them here.

Symmetrix Remote Data Facility (SRDF)SRDF is business continuance software that provides an online, host-independent, mirrored data storage solution for duplicating production site data on one or more physically separated target Symmetrix systems. When your main systems are down for a planned or unplanned event, SRDF enables fast switchover from the source data to the target copy.

The following EMC publications provide more information about SRDF:

◆ EMC Symmetrix Remote Data Facility Product Manual

◆ EMC SRDF Host Component for z/OS Product Guide

Consistent copiesThe data copy created by SRDF/AR is a consistent copy. The term consistent is based on the concept of dependent write I/O. A dependent write is a write that is not issued by the application unless some prior write operation has successfully completed.

Most applications, and in particular database management systems (DBMSs), have dependent write logic imbedded in them to ensure data integrity if a failure occurs in the host processor, software, or storage system. An example is a database update.


SRDF/AR

When updating a database, a DBMS system takes the following steps:

◆ Writes to the disk containing the log

◆ Writes the data to the actual database dataset

◆ Writes again to the log volume to indicate that the database update was made

These three write I/Os (log, database, and log again) are related and each I/O is not issued until the prior I/O has successfully completed.

Consistent SPLITsA Consistent SPLIT prevents dependent I/O from being issued by the application during the split process, thus ensuring the integrity and consistency of the data at the BCV copy. This results in a copy of the data that is restartable.

Mainline SRDF/AR processing

The following are the main steps to the SRDF/AR cycle:

Note: You need to understand the steps in a SRDF/AR cycle because you can STOP a cycle at the end of a step and then later RESTART the cycle from that point.

0. Perform health check.

1. Validate devices:

2. Perform Consistent SPLIT on source BCVs.

3. Wait for source R1 BCVs to synchronize.

4. Check for source BCV readiness.

5. Reestablish source BCVs.

6. Wait for target BCV mirror synchronization.

7. Reestablish target BCVs.

8. Wait for target R2 device to synchronize with their BCVs.

9. Split the target BCVs.

10. Source wait and target check:

a. Wait for source BCV synchronization.

b. Perform target BCV mirror synchronization check (if TargetBcvMirrorSyncAtEnd(CYCLE) was specified).

11. Check status:

a. Perform mirror status check.

b. Perform target BCV mirror synchronization check (if TargetBcvMirrorSyncAtEnd(Process) was specified).

Each of these steps is explained further on the following pages. The command syntax is described in “Using SRDF/AR” on page 143.

Introduction to SRDF/AR processing 137

SRDF/AR

Step 0Perform health check. This step checks for any failed devices.

Step 1 Validate source devices. All source BCV pairs must be correctly established:

◆ Splits cannot be in progress◆ There must not be any invalid tracks◆ The BCV cannot be HELD◆ Source and target BCVs must be offline◆ No invalid tracks on the R2 owed to the R1◆ R2s are not RW◆ Mirrored R2s are valid

Note: Source device validation is performed only once in a SRDF/AR cycle.

Validate target devices. All target BCV pairs must be split and have a relationship to the STD device specified in the input.

Validate mirrored R2 devices. It is an error if both mirrors have invalid tracks. For unprotected R2 devices cannot have any invalid tracks.

R1BCV

R1BCV

R2

R2

BCV

BCVSTD

Production Site Secondary Site

Standard and BCV are fully established

STD

STD

R1BCV

R1BCV

R2

R2

BCV

BCV

STD


Verifies that the target (R2) BCVs are split


SRDF/AR

Step 2Perform Consistent SPLIT on source BCVs.

Steps 3 and 4Wait for the source R1 BCVs to synchronize with the target R2 STD devices.

Steps 5, 6, 7, and 8These steps are as follows:

◆ Reestablish source BCVs.◆ Wait for target BCV mirror synchronization.◆ Reestablish target BCVs.◆ Wait for target (R2) devices to synchronize with their BCVs.

STD

R1BCV

R1BCV

R2

R2

BCV

BCV

STD


Consistent split

STD

R1BCV

R1BCV

STD

Adaptive Copy Extended Distance

Production Site

R2

R2

BCV

BCV

Secondary Site

Resync in progress

Secondary Site

STD

R1BCV

R1BCV

STD

Production Site

R2

R2

BCV

BCV

Re-establish


SRDF/AR

Steps 9 and 10AThese steps are as follows:

◆ Split target BCVs.

◆ Ensure source BCVs are synchronized.

Get the current time and calculate the wait interval. If the specified cycle time is greater than the actual time for the previous cycle, wait for the start of the next cycle. If it is less, start the next cycle immediately if IMMED was specified for CYCLe_OverFlow, otherwise, wait for the start of the next cycle time.

Repeat the cycle starting with Step 1 until a STOP is issued or the number of specified cycles complete.

Step 10BIf TARGETBCVMIRRORSYNCATEND is set to CYCLE, step 10B is executed to perform target BCV mirror synchronization check. If TARGETBCVMIRRORSYNCATEND is not set to CYCLE, this step is bypassed.

Note: “TARGETBCVMIRRORSYNCATEND(action)” on page 152 provides more information about the TARGETBCVMIRRORSYNCATEND parameter.

Step 11A Perform mirror status check and target BCV mirror synchronization check. Query the SRDF/AR Process for Not Ready devices. This is a health check that is run at the end of each cycle.

STD

R1BCV

R1BCV

R2

R2

BCV

BCV

STD


Query status Instant split

STD

R1BCV

R1BCV

R2

R2

BCV

BCV

STD



SRDF/AR

Step 11BIf TARGETBCVMIRRORSYNCATEND is set to PROCESS, step 11B is executed perform target BCV mirror synchronization check. If TARGETBCVMIRRORSYNCATEND is not set to PROCESS, this step is bypassed.

Note: “TARGETBCVMIRRORSYNCATEND(action)” on page 152 provides more information about the TARGETBCVMIRRORSYNCATEND parameter.

SRDF/AR in multi-hop configurations

In a multi-hop configuration (Figure 23), EMC Consistency Groups (ConGroup) technology provides protection of the production site to an offsite secondary site.

Figure 23 SRDF/AR multi-hop configuration

This ensures the integrity of production data at the secondary site during a production site rolling disaster.

SRDF/AR is configured, controlled, and monitored by the production site but is operated between the secondary and target sites. This provides consistent, restartable copies at a remote restart site cyclically using SRDF adaptive copy technology plus splits of the remote BCVs. BCVs at the restart site provide protection during the adaptive copy session between the secondary and restart site.

Note: “Mainline SRDF/AR processing” on page 137 describes the SRDF/AR cycle in detail.

R2

R1BCV

R1BCV

R2

Production Site

R1

R1

R1

R1

Symmetrix 1 Symmetrix 2

R2

R1BCV

R1BCV

R2

R2

BCV

BCV

R2

R2

BCV

BCV

R2

ConGroup RollingDistaster Protection

Symmetrix AutomatedReplication Protection

Secondary Site


SRDF/AR

In the event of a ConGroup trip event, the secondary site contains a consistent, restartable image of the business continuance data of the production site. A final split of the secondary site R1BCVs followed by their resynchronization to the R2s at the restart site produces a restartable environment at long distances with data current to the point at which the disaster happened.

Defining a SAR (Symmetrix Automated Replication) environment To define a SAR environment, the Source R1 BCVs must be established and the Target BCVs must be Split. Before starting SAR for the first time, EMC recommends running a Consistent Split of the source R1 BCVs followed by a Re-establish.

Following are the steps to define a SAR process:

1. Use the SC VOL command CREATEPAIR between Source R1-BCVs and Target R2-STD.

Note: Refer to the Mainframe Enablers SRDF Host Component for z/OS Product Guide for more information on SC VOL CREATEPAIR and other host component commands.

2. ESTABLISH Source STD to Source R1 BCVs.

3. ESTABLISH Target R2 STD and Target BCVs

4. SPLIT Target R2 STD and Target BCVs

Note: For more information on TimeFinder/Mirror commands, refer to Chapter 4, “Command Reference,” in this product guide.

5. ADD a new process

6. Define the process using MODIFY command

Note: For more information on SRDF/AR commands, refer to “ADD” on page 144, and “MODIFY” on page 145 in this chapter.

Here is an example of ADD and Modify statement:

ADD seq#,process_name,HOP_TYPE(SINGLE),MAXMSG(1),MAXDEV(64),SYSTEM(GLOBAL)

MODIFY seq#, process_name,DEFINE, RESUME(0,30,5),REEST(0,3,1),REEST_TGT(0,5,1), MULTA(Y),BYPASSTARGETBCVNOTREADY(Y), CYCLE(00:00:00,2), CYCLE_OVERFLOW(IMMED),TIMEOUT(15,CONT), MSGOPT(SYSOUT(TFALOG1)),METAMAX(4), POLICY(P1,P4,P14), DEBUG(STATUSE,ITRK,ECA,IO)

MODIFY seq#,process_name,DEFINE,DEVICE_LIST(LCLSTD(AC-AD,07,3C00),

LCLR1BCV(786-787),TGTB(758-759)) Where:

Seq# Is the sequence in which command is executed.

process_nameIs the SAR process name.


SRDF/AR

Using SRDF/ARThe ability to produce consistent point-in-time copies of information spanning multiple volumes and multiple Symmetrix systems is important to business continuance. This capability is provided through the TF/Mirror Consistent SPLIT command. Creating a consistent copy of all necessary data objects provides the restartable image on the remote BCVs.

Note: “SPLIT” on page 121 describes the SPLIT command.

The current TF/Mirror batch interface can create consistent restartable images, one at a time. Continually creating consistent copies of business continuance information is not practical without automation support. The SRDF Automated Replication (SRDF/AR) feature provides the necessary automation support.

SRDF/AR commands perform the following steps:

◆ Define the volume(s) to be managed.

◆ Specify the cycle characteristics.

◆ Provide for cycle control and queries.

These SRDF/AR commands are described in the following sections.

Note: Before starting a defined SRDF/AR process, you need to define all device relationships,. You must establish the BCVs at the source site and at the secondary site with the associated standard device and currently split from the standard device. You must also complete installation customization with the TF/Mirror LINKLIB concatenated to the ResourcePak-Base EMCSCF STEPLIB.

Note: The GLOBAL command is also used in a SRDF/AR process definition. “GLOBAL” on page 145 describes the GLOBAL command.

Reading command syntax maps

“BCVGROUP and BCVLIST” on page 75 describes how to read the command syntax maps given with each of the following commands.

Using SRDF/AR 143

SRDF/AR

ADD

DescriptionThe ADD command defines the process-name to EMCSCF. The two long running processes defined today are the single and multi-hop modes of the SRDF Automated Replication (SRDF/AR) feature. If the process name is already defined then the ADD request statement is rejected.The ADD command does not start the process, it only defines the name and processing type to EMCSCF.

BATCH syntaxADD seq#,processname,parameters

Parameters

process-name

Specifies the name of the process (maximum of 20 characters). If this name is already defined the statement fails.

seq#


HOP_Type

Specifies the type of long running process to be defined to EMCSCF. The options are SINGLE and MULTI. The process descriptions provide the definitions.

MAXDev

Specifies the maximum SRDF/AR devices per controller (1-64000, default 8192).

MAXGrp

Specifies the maximum number of SRDF/AR groups (1-9999, default 64).

MAXMsg

Specifies the maximum SRDF/AR message buffers (1-9999, default 256).

SYSTEM(LOCAL[(ECA|IOSLEVEL)|GLOBAL[(ECA)])

Specifies whether a local or multi-LPAR SRDF/AR is defined and whether the Enginuity Consistency Assist (ECA) is used.


SRDF/AR

DELETEDescription

The DELETE command removes the process control blocks from the system. The process name must be in a stopped state for the command to function, otherwise the command is rejected.

BATCH syntaxDELETE seq#,processname

Parameters

seq#


process-name

Specifies the name of the process (maximum of 20 characters). If this name is not already defined, the statement fails.

GLOBALDescription

The GLOBAL command sets default values for all commands.

MODIFYDescription

The MODIFY command allows management of and parameter setting for a process. Multiple DEFINE and QUERY actions are allowed on a single sequence level. Only one START, RESTART, or STOP action is allowed on a single sequence.

Note: Make sure all ADD and DELETE commands are executed prior to issuing a MODIFY command.

BATCH syntaxMODIFY seq#,process-name,sub-command parameters,sub-parameters

The MODIFY syntax requires that after seq# and process-name, the following sub-command parameters, when used, must be placed before any sub-parameters:

◆ DEFine ◆ EXPort ◆ Query◆ MP_Resync ◆ RESTART◆ START ◆ STOP

DELETE 145

SRDF/AR

Parameters

seq#

Specifies a decimal number from 1 to 128 that indicates in what order the specified command is executed. All actions on the same sequence level are executed in parallel.

process-name

Specifies the name of the process (maximum of 20 characters). If this name is not already defined, the statement fails.

Sub-command parameters

DEFINE

Define the devices and attributes of the process. As many DEFINE actions may occur for a process as required to define the total set of devices to be operated upon by the process. Device lists may not span Symmetrix systems. If multiple Symmetrix systems are needed to create a restartable remote image, multiple DEFINE actions with device lists for each Symmetrix unit are needed.

To change the configuration, you need to delete and then redefine the desired configuration. The last setting for CYCle, CYCle_OverFlow, TIMEOUT on a DEFINE action is used.

EXPORT

EXPORT runs against a defined SRDF/AR process (the internal control blocks) and build a file containing SRDF/AR syntax that can be used to redefine the configuration. The form of the syntax statement is as follows:

EXPORT(SYNTAX(ddname[,RANGE|NORANGE])

Where:

ddname

Specifies the ddname of the file that can be used to redefine the configuration. The file referenced by ddname must be preallocated. The file can be either a SYSOUT file or a dataset (sequential, PDS member, or GDG). The resulting file is in syntax format, which you can submit to define the process. This works only at a source site.

Note: Because SRDF/AR does not have flags to track every option, the generated syntax in the syntax file has some differences from entered SRDF/AR syntax. For example, all device specifications are in the form of Symmetrix device numbers.

RANGE

(Default) specifies that, when creating the syntax file, device ranges are used whenever possible.

NORANGE

Specifies that, when creating the syntax file, individual MODIFY DEFINE statements are used for each set of devices.


SRDF/AR

QUERY

STATUS specifies to display the cycle step, cycles performed, changed track accumulation, current settings, etc. DEVices displays the list of devices defined to the process. MSG lists the message buffers associated with the process. After a MSG display, the message queue is emptied. The process specified may be active or stopped.

RESTART

Restart a stopped process. The restart point is determined by the STOP request. If the STOP actions specified FORCE restart may not be possible.

START

The START action begins the process at the beginning of the cycle.

STOP

The STOP action has the following options:

STOP without a parameter specifies stopping the cycle when the current cycle step completes.

STOP(NORMAL) (the default) specifies that the cycle continue until it reaches the normal end of cycle.

STOP(FORCE) specifies immediate stop no matter what the state of the cycle.

STOP(IMMEDiate) specifies an immediate stop. The process must be active for the STOP to take effect.

STOP(STEP(step#)) specifies which step to stop at, providing that the specified step has not yet occurred in the SRDF/AR cycle. Otherwise, the SRDF/AR cycle stops at the end of the then current cycle. For example:

• If you specify STOP(STEP 03)) and SRDF/AR is at step 2 in the SRDF/AR cycle, SRDF/AR stops at the end of step 3.

• If you specify STOP(STEP 03)) and SRDF/AR is at step 4 or higher in the SRDF/AR cycle, SRDF/AR stops at the end of the current cycle.

Note: The EMC ResourcePak Base for z/OS Product Guide describes the SCF STOP command.

Sub-parameters

BCVSTATE

When NR is specified, the device is left in NR_BCV state after the Consistent SPLIT. SRDF/AR step 4 then readies all of the source R1 BCVs. The default is READY.

BYPTBCV

Controls the use of the target BCV. Valid values include:

N — Normal or SRDF/AR operation to establish and split the target BCV.

Y — Bypass the establish and split of the target BCV.

MODIFY 147

SRDF/AR

Note: Specifying BYPTBCV(Y) in the initial definition of a SRDF/AR process means there are NO target BCVs in the SRDF/AR configuration. This is SRDF/AR configuration choice made by the installation. In this case, it not possible to START using BYPTBCV(N).

BYPTONL(Y|N)

An optional parameter that applies to DEFINE and START. This parameter allows you to bypass the online check for target BCVs. N (no) is the default.

cuu_gatekeeper

Optional parameter specifies an alternative device to issue the commands against.

cuu

Specifies a device address.

cuu-cuu

Specifies a range of device addresses. The first cuu value is the starting device address and the second cuu value is the ending device address. The range must be contained on the same physical control unit.

CYCle

An optional parameter that applies to the DEFINE and START sub-command parameters. This parameter defines the cycle time and optionally the number of cycles to perform. The cycle time specifies time frequency for starting each cycle of a process (for example, start the process every four hours). If the actual cycle time exceeds the cycle time the CYCle_OverFlow action specifies the desired behavior.

If the number of cycles to be performed is specified as zero (0) or not specified, then the cycle process runs until a STOP command is issued.

To run a SRDF/AR process indefinitely, code the following:

CYCLE(00:00:00,0),CYCLE_OVERFLOW(IMMED)

CYCle_OverFlow

Specifies processing behavior when a cycle takes longer than specified in the cycle time. NEXT specifies a wait until the next calculated cycle time to begin a new cycle. IMMED specifies that a new cycle start immediately after the conclusion of the current cycle. The start time of this new cycle is the basis for the next calculated cycle time.

[,DEBUG([STATus] [,STATusE] [,ITRks] [,IOSLevel] [,DISPCmd] [,ECA])]

Enables various debugging displays:

STATus SRDF/AR status information

STATusE Extended SRDF/AR status information

ITRks Invalid track display

IOSLevel Held IOS level information

DISPCmd Display the SRDF/AR statement used to define all current processes

ECA Enginuity Consistency Assist information


SRDF/AR

DEVice_List

SRCR1BCV specifies the source R1BCV devices. SRCSTD specifies the standard devices. TGTBCV specifies the target BCV Symmetrix devices. Depending on the HOP_TYPE, and the LCLR1BCV or LCLSTD parameter setting (GLOBAL statement), SRCR1BCV accepts either a CUU or a Symmetrix device number. When you specify LCLR1BCV or LCLSTD, Symmetrix device numbers are required regardless of the HOP_TYPE; otherwise, a CUU range is required.

ITRKSYNC

Controls the limit on the Invalid Track check before a pause is issued. The syntax is:

ITRKYNC([normal][,][residual])

Where:

normal

Specifies the number of times SRDF/AR is to perform invalid track checks. The default value is 60.

residual

Specifies the number of successive checks on which an invalid track is detected before issuing a Verify. If a Verify does not resolve the situation, SRDF/AR issues a pause.

Note: When the invalid track count is not one for each BCV with any invalid tracks, the value of the normal parameter is used.

MSGOPT

Specifies message handling options. BUFfered holds messages in the memory buffer. You can display the messages using the QUERY statement.

PAUSE

The command can be issued through TF/Mirror:

MODIFY nn,process_name,PAUSE

or as an SCF Modify command:

F scf_task,SAR,PAUSE,process_name

The PAUSE command causes a SRDF/AR process to pause and issue the following message:

*nn BCVA058A Process process_name, Paused in Step nn (reason)- reply CONTinue or CANcel

An immediate Pause occurs just before the next API call. A Step level Pause occurs before the next API call for the desired step.

Either type of Pause is deferred during the Consistent Split phase to prevent impacting the Consistent Split, possibly causing a loss of consistency for the affected cycle. For example, an immediate Pause issued during the Consistent Split phase of Step 02 is deferred until the Consistent Split processing has completed (Step 03).

MODIFY 149

SRDF/AR

You can schedule a PAUSE to take effect for a step in the SRDF/AR process by specifying that step number on the PAUSE. For example:

MODIFY nn,process_name,PAUSE(step#)

Where:

step#

The step number

The SCF PAUSE command also allows an optional step number.

Note: The EMC ResourcePak Base for z/OS Product Guide describes the SCF PAUSE command.

POLICY(Pn,…)

With a single-hop configuration, POLICY can be used on the RE-ESTABLISH of the Source BCVs if the STD devices are not RDF, (mm...) or if RDF, Static RDF and unprotected. In all other cases the STD is an RDF device, so it must be Static RDF and unprotected

Where n can be:

1 = Wait for drive replacement (Pause).

2 = Proceed with resiliency.

3 = Protected BCV always must be protected.

4 = Protected BCV can run unprotected (tolerate a mirror failure).

Note: P4 (tolerating a mirror failure for a Protected BCV) can make a huge difference in the resiliency of the SAR process.

5 = Wait for BCV mirror sync.

6 = Bypass (no wait for) BCV mirror synchronization wait.

7 = Bypass (skip) Step 3 (source R1 synchronization wait) if drive failure in Step 2.

8 = Use PBE (protected BCV ESTABLISH).

9 = No R2 replacement.

10 = Allow R2 replacement.

11 = Target BCVs only.

12 = N/A.

13 = Protected R2 must always be protected.

14 = Protected R2 can run unprotected. (Tolerate a mirror failure.)

15 = N/A

16 = N/A

The defaults are 1, 3, 5, 9 and 13.

rdfgroup

Specifies the RDF group. This must be a one or two-digit (hex) value representing the RDF group number. rdfgroup.rdfgroup specifies a multi-hop reference.


SRDF/AR

REEST(count,initial_wait,interval)

An optional parameter that applies to DEFINE and START. Can control the number of concurrent RE-ESTABLISH requests issued. After count RE-ESTABLISH commands have been issued, a wait for interval_wait occurs and the status of each of the devices just processed is checked. Once attached, the next group of count devices is processed in the same way until all of the devices have been processed successfully.

The default is REEST(8,5,1), with the values in seconds. A count of zero disables the option. count can range from zero through 65535. initial_wait times can range from zero through 999 seconds.

REEST_TGT(count,initial_wait,interval)

An optional parameter that applies to DEFINE and START. Can control the number of concurrent RE-ESTABLISH requests issued to the target Symmetrix unit. After count RE-ESTABLISH commands have been issued, a wait for interval_wait occurs and the status of each of the devices just processed is checked. Once attached, the next group of count devices is processed in the same way until all of the devices have been processed successfully.

The default is REEST_TGT(8,5,1), with the values in seconds. A count of 0 disables the option. count can range from zero through 65535. initial_wait times can range from zero through 999 seconds.

RESUME(count,initial_wait,interval)

An optional parameter that applies to DEFINE and START. Can control the number of concurrent RESUME requests issued. First, a Consistent SPLIT is performed without a request to propagate the data to the target R2. After all the SPLIT commands have been issued, a wait of initial_wait seconds occurs. The RESUMEs to propagate the data to the target R2s are then issued in groups of count with a wait of interval seconds between each group.

The default is RESUME(0,30,5), with the values in seconds. The maximum time waiting for the attached state is 10 times the interval_wait. If this is exceeded, the cycle stops with the appropriate messages. count can range from zero through 65535. initial_wait times can range from zero through 999 seconds.

Setting the FORCE option on the RESUME prevents RC 26 and RC 29 errors.

Note: The EMC Mainframe Enablers Message and Code Guide provides more information about RC errors.

symdv#

Specifies the Symmetrix device number. This can be a 12-digit value.

symdv#-symdv#

Specifies a range of Symmetrix device numbers. The first symdv# value is the starting device number, and the second symdv# is the ending device number. Both starting and ending range must be a four-digit value.

SYSOUT(ddname)

Optionally route messages to SYSOUT identified by ddname for this SRDF/AR process. You specify the ddname in the SCF PROC at startup.

MODIFY 151

SRDF/AR

You can specify both SYSOUT and WTO(nn) concurrently.

TARGETBCVMIRRORSYNCATEND(action)

Specifies running the target BCV mirror synchronization check at the end of the process at the end of the process at the end of the cycle or not at all. The purpose is to detect a drive failure affecting a BCV mirror before the end of a cycle or process.

Where:

action is one of the following:

PROCESS

Run check before termination of the SRDF/AR process (as step 11B).

CYCLE

Run as step 10B (target BCV mirror synchronization check) at the end of every cycle.

NO

Do not run at cycle or process end.

Additionally, the mirror status check is run as Step 0 when the first cycle starts executing.

Note: You can abbreviate this parameter as TGTBCVMSYNCATEND or TGTBCVMSE.

TIMEOUT

An optional parameter that applies to the DEFINE and START sub-command parameters. This parameter specifies the maximum time to hold I/O processing during Consistent SPLIT processing. The timeout is specified in seconds. The default TIMEOUT is 15 seconds.

As shown in the MODIFY syntax diagram, TIMEOUT has two primary keywords.

• CONTinue continues the process, based upon the setting of MAXRC.

• TERMinate ends the process, either IMMEDiately or at the end of the current cycle. (IMMEDiate and CYCLE are valid only when TERMinate is specified.)

If the maximum timeout specified is exceeded, no operations are performed on the target BCVs. The BCVs at the recovery site contain consistent images of the last successfully completed cycle. RESTART is not available under this condition. The process must have a new START action issued.

WAIT

The action specified is completed before the next sequence level is executed. In the case of a START/RESTART this may mean the current sequence level never completes. For QUERY, WAIT is implied. However, to avoid an issue with the potential completion of an ADD or DELETE command, make sure those commands are executed prior to issuing a MODIFY command.

WTO(nn)

Optionally issues the text as a Write To Operator with the optional route code nn. If WTO is specified without a route code, a default of 11 is used. You can specify both WTO(nn) and SYSOUT concurrently.


SRDF/AR

SRDF/AR storage estimatesTable 11 shows the defaults for the SRDF/AR control blocks:

ExampleExample 1 Use the following range of devices as a reference for example 1.

In a single hop implementation, you can use z/OS addresses or Symmetrix device numbers to define the source BCV device list. If you decide to customize the environment with Symmetrix device numbers, you do not need to define the group of R1BCV devices to the operating system.

The device list of the target BCV devices are always defined with the Symmetrix device numbers.

ADD 10,PROCESSONE,HOP_TYPE(SINGLE)MODIFY 11,PROCESSONE,DEFINE,DEVICE_LIST(SRCSTD(A000-A002),

SRCR1BCV(A100-A102),TGTBCV(0001-0003))

MODIFY 11,PROCESSONE,DEFINE,DEVICE_LIST(SRCSTD(B100-B102),SRCR1BCV(B180-B182),TGTBCV(0004-0006))

MODIFY 12,START,PROCESSONE,CYCLE(0),TIMEOUT(15)

The ADD statement at sequence level 10 creates a new process named PROCESSONE. Devices in Symmetrix system “Symm1” are specified in the device list of the first MODIFY statement at sequence level 11. The standard devices mounted on addresses A000

Table 11 SRDF/AR control block defaults

Control block DefaultOverride keyword Length @ defaults Location

TFACT 1 N/A 64 CSA

TFAGRP 64 MAXGrp 1024+(MaxMsg * 112)

ECSA

Message Buffers 256 MAXMsga

a. If storage becomes constrained, most of the SRDF/AR storage requirements can be eliminated by using the MSGOPT (WTO) option and MAXMSG(1).

TFASYM Unlimited N/A 256+(MaxDev * 128)

ECSA

Device Entries 4096 MAXDev

Type of devicez/OS control unit address Symmetrix dev number

Source Standard A000-A002B100-B102

Source R1BCV A100-A102B180-B802

0100-01020100-0102

Target BCV 0001-0006

SRDF/AR storage estimates 153

SRDF/AR

through A002 and their respective R1BCVs on addresses A100 through A002 are protected on the BCVs in the remote Symmetrix system “Symm3.” The Symmetrix device numbers identify these BCVs.

Similarly, the standard devices on Symmetrix system “Symm2” on addresses B100 through B102 and their respective R1BCVs on addresses B180 through B182 are also protected on the BCVs in the remote Symmetrix “Symm3.” Their Symmetrix device numbers identify these BCVs. Since the SRCR1BCV specifies R1BCV devices the RDF group is known. This provides the path information for the remote Symmetrix unit.

CYCLE(0) specifies that the process runs until an explicit STOP is issued for the process. Each subsequent cycle begins immediately after the previous one has completed. The timeout value of 15 seconds specifies the maximum time I/O is held waiting for the Consistent SPLIT to complete. The START statement at sequence level 12 begins the process PROCESSONE.

If the timeout value is exceeded, the process stops with an error. If this does occur the Consistent SPLITs did not complete within the allotted time. The consistency of the local BCVs data cannot be determined without user intervention. Valid data is at the remote BCVs from the previous successful SRDF/AR cycle.

In Figure 24 on page 154, one remote Symmetrix system is used to protect standard devices in two local Symmetrix systems.

Figure 24 Remote Symmetrix protection of local standard devices

Example 2 Submit a job to issue the following:

MODIFY 20,PROCESSONE,STOP

STD

A000

STD

A001

STD

A002

STD

B100

STD

B101

STD

B102

R1BCV

B180

R1BCV

B181

BCV

B182

R1BCV

A100

R1BCV

A101

R1BCV

A102

R2

R2

R2

R2

R2

R2

BCV

0004

BCV

0005

BCV

0006

BCV

0001

BCV

0002

BCV

0003

SYMM1

SYMM2

SYMM3

SRDF LinksAdaptive Copy Mode

SRDF Links Adaptive Copy Mode

dvtype dvtype

cuu cuu

Symmetrix device numbersmust be used on remote

systems


SRDF/AR

To determine if the process PROCESSONE is stopped, one or more jobs must be run issuing the following:

MODIFY 20,PROCESSONE,QUERY(STATUS)

After the process is stopped, the following may be issued in a separate job:

MODIFY 20,PROCESSONE,RESTART

In this example, the process is stopped and queried for its status. Then the process is RESTARTED.

Example 3 MODIFY 30,PROCESSONE,STOPMODIFY 31,PROCESSONE,DELETEADD 32,PROCESSONE,HOP_TYPE(SINGLE)MODIFY 33,PROCESSONE,DEFINE,DEVICE_LIST(SRCSTD(A000-A002),SRCR1BCV(A100-A102),TGTBCV(0001-0003))MODIFY 33,PROCESSONE,DEFINE,DEVICE_LIST(SRCSTD(B100-B102),SRCR1BCV(B180-B182),TGTBCV(0004-0006))MODIFY 33,PROCESSONE,DEFINE,DEVICE_LIST(SRCSTD(A003),SRCR1BCV(A103)TGTBCV(0007))MODIFY 34,PROCESSONE,START,PROCESSONE,CYCLE(0),TIMEOUT(15)MODIFY 35,PROCESSONE,QUERY(MSG)MODIFY 35,PROCESSONE,QUERY(STATUS)

Example 3 stops and deletes the PROCESSONE process. PROCESSONE is redefined the same as Example 1, but with one additional volume on local Symmetrix Symm1, identified as A003 (Figure 25 on page 156). After the process is started, queries are issued: one for any outstanding messages from the process and one for the status of the process.

Example 155

SRDF/AR

Figure 25 Remote Symmetrix protection with additional local devices

Example 4 Example 4 is a multi-hop SRDF/AR example

When building the device lists for a multi-hop configuration, the only host addressable devices are the R1 devices on the source side. These addresses are used to identify the source standard devices. SRDF/AR automatically identifies the partner R2 devices in the bunker site during the execution of the define action.

STD

A001

STD

STD

B100

STD

B101

STD

B102

R1BCV

B180

R1BCV

B181

BCV

B182

R1BCV

A101

R1BCV

R2

R2

R2

R2

R2

R2

BCV

0004

BCV

0005

BCV

0006

BCV

0001

BCV

0002

BCV

0003

SYMM1

SYMM2

SYMM3

SRDF LinksAdaptive Copy Mode

SRDF Links Adaptive Copy Mode

dvtype dvtype

cuu cuu

Symmetrix device numbersmust be used on remote

systems

A002 A102

STD

A003

R1BCV

A103

BCV

0007

R2

R1BCV

A100

STD

A000

Source

R1

SRCSTD

R2

SRCBCVVR

Bunker

R2

TGTBCV

Target


SRDF/AR

All the other devices are remote so Symmetrix device numbers must be used to identify the SRCR1BCV devices. SRDF/AR automatically identifies the RDF groups used in both the bunker Symmetrix system and target Symmetrix system.

EMC Consistency Groups for z/OS (ConGroup) protects the data between the source Symmetrix system and the middle, or bunker, Symmetrix system in the event of an unplanned disaster (rolling disaster).

In the event of a rolling disaster, ConGroup trips and a dependent write consistent copy (restartable image) of the data as it was at the beginning point of the rolling disaster is captured on the R2s in the bunker Symmetrix system. One final SRDF/AR cycle propagates the restartable image of the data to the target Symmetrix system.

SRDF/AR in multi-hop mode provides the automation to send the dependent write consistent copy of data from the bunker to the target site. No channel connectivity is required to the bunker site.

A restartable copy, with some data loss, still exists if the source and bunker site are both lost.

SRDF/AR performs remote Consistent SPLIT in order to create the restartable images by holding the I/O on the source site while issuing the remote Instant SPLIT to the bunker Symmetrix and releasing the I/O at the source site.

The following output is a sample SRDF/AR debug log.

14:01:47.95 BCVA002I Process TEST1, Beginning cycle 1, Version 7.0.0 (17) 14:01:48.64 BCVA086I Process TEST1, Source 0001901-01735, MCL 5773, GK 6BBF (Clone) 14:01:48.64 BCVA088I Process TEST1, Target 0001926-01812, MCL 5874, RAG 16 (Clone) 14:01:48.65 BCVA000I 00: Mirror Status Check 14:02:00.55 BCVA000I 01C: Target R2-R1 Invalid check 14:02:02.54 BCVA000I 01D: Target R2 Local Mirror Check 14:02:04.60 BCVA000I 01E: Source R1 Status check 14:02:07.50 BCVA000I 02: Consistent Split 14:02:07.55 BCVA065I Process TEST1, Consistent point at 2010.144 14:02:07.51 (cycle 1) saved for SBCV 14:02:07.55 BCVA000I Source Resume 14:02:12.56 BCVA000I 03: Source R1 sync wait 14:02:12.56 BCVA000I Check for Split-in-progress 14:02:12.73 BCVA000I Invalid Track Check 14:02:13.93 BCVA000I Symm 0001901-01735, Dev 0D97 00004137, Total 000104DC 14:03:15.22 BCVA000I Symm 0001901-01735, Dev 0D98 00003D27, Total 0000C7BE 14:04:16.44 BCVA000I Symm 0001901-01735, Dev 0D98 00001ED1, Total 00006839 14:04:47.66 BCVA000I Symm 0001901-01735, Dev 0D98 00001C88, Total 00005194 14:05:18.91 BCVA000I Symm 0001901-01735, Dev 0D99 00001468, Total 00003918

Type of deviceControl unit address CUU

Symmetrix dev number symmdev

Source Standard D010-D014

Source R1BCV 0140-0144

Target BCV 000A-00A4

ADD 01,SARTEST03,HOP_TYPE(MULTI)MODIFY 02,SARTEST03,DEFINE, DEVICE_LIST(SRCR1BCV(0140-0144), SRCSTD(D010-D014), TGTBCV(00A0-00A4))

Example 157

SRDF/AR

14:05:50.12 BCVA000I Symm 0001901-01735, Dev 0D9A 00000828, Total 00000D51 14:06:06.36 BCVA065I Process TEST1, Consistent point at 2010.144 14:02:07.51 (cycle 1) saved for TR2 14:06:06.36 BCVA000I 04: Source BCV Ready - Bypassed 14:06:06.36 BCVA000I 05: Re-Est Source volumes 14:06:21.36 BCVA000I Source BCV mirror sync check 14:06:24.26 BCVA066I Process TEST1, Consistent point at 2010.144 14:02:07.51 (cycle 1) expired for SBCV 14:06:24.26 BCVA000I Source Suspend 14:06:29.48 BCVA000I 06: Target BCV mirror sync check 14:06:31.51 BCVA000I 07: Re-Est Target volumes 14:06:31.51 BCVA000I Check for Split-in-progress 14:06:37.32 BCVA000I 08: Target R2 sync wait 14:06:38.74 BCVA000I Check for BCV Synchronization 14:06:38.90 BCVA000I 09: Split Target BCVs 14:06:39.08 BCVA065I Process TEST1, Consistent point at 2010.144 14:02:07.51 (cycle 1) saved for TBCV 14:06:39.08 BCVA000I 10: Source BCV sync wait 14:06:40.29 BCVA000I Check for BCV Synchronization 14:06:40.45 BCVA000I 11: Mirror Status Check 14:06:50.30 BCVA003I Process TEST1, Completed cycle 1


SRDF/AR

Performing restart in a SRDF/AR environment

Getting started

Before attempting any of the procedures outlined in the following sections, please review the following:

◆ cuu refers to the z/OS device number of the device and dev# refers to the Symmetrix device number.

◆ The following Symmetrix configuration parameters must be specified:

• Enable Links Domino: NO• Prevent auto links recovery after all links failure?: YES• Force RAs Links off-line after power-up?: YES

Note: Contact your EMC Customer Support Engineer to verify your parameter settings.

Your configuration, the specific nature of the outage, and any unique circumstances that may exist dictate the specific recovery steps that are required. ALWAYS contact the EMC Customer Support Center for assistance in a recovery situation. EMC personnel are trained for proper handling of these situations. An incorrect action during the recovery process can result in data corruption.

Recovering using operational host

This section describes examples of procedures to be performed in a SRDF/AR actual restart situation.

The following site definitions are used throughout these procedures:

◆ Production site: host and Symmetrix unit(s) containing standard (STD) volumes and source (R1BCV) devices that experienced an outage.

◆ Restart site: host and Symmetrix unit(s) containing target (R2) volumes and their associated BCV devices.

Making the SRDF/AR restart volumes available

The SRDF Host Component application must be running to make the restart site available. Before performing operations on the SRDF/AR controlled volumes, you need to have an operational z/OS image attached to the Symmetrix system containing the SRDF/AR target volumes.

Note: The SRDF Host Component for z/OS Product Guide provides additional information about making the operational site available.

TF/Mirror SRDF/AR process creates point-in-time, consistent copies of volumes. You must first decide whether the recovery and subsequent restart operations are to use the R2 devices or their partner BCV devices. Additionally, it is necessary to determine the current state of the R2 and their partner BCV devices.

Performing restart in a SRDF/AR environment 159

SRDF/AR

Note: EMC recommends that you restart the R2 devices. This allows BCV devices to be used for normal TF/Mirror operations at the restart site if desired. This also positions for using R1/R2 personality swap as part of the go-home process. The go-home process requires the use of the recovery Procedure 2 in the SRDF Host Component for z/OS Product Guide. The procedure deals with having used the R2 devices for operational use (read-write enabled) and later resynchronizing the R1-R2 pairs.

After the restart devices (R2 or BCV) are determined, the SRDF/AR configuration may be in one of three possible states. Each of the three possible states requires a different recovery procedure.

The three possible states are:

◆ All of the target (R2) devices are split from their partner BCV devices.

◆ None of the target (R2) devices are split from their partner BCV devices.

◆ Some of the target (R2) devices are split from their partner BCV devices.

Note: “Introduction to SRDF/AR processing” on page 136 lets you review the steps. The actions performed at each step determine the possible state of the SRDF/AR configuration at the time of recovery.

How device locks work

Several EMC products, both mainframe and open systems, use Device Lock (DEL) 9 to serialize operations to a Symmetrix device. For example, TF/Mirror obtains a lock on the BCV during any active operation (ESTABLISH, RE-ESTABLISH, SPLIT, and RESTORE).

During the course of processing, TF/Mirror monitors the duration of any held lock. If a device lock has been in effect for less than 15 minutes, any new request for a lock on that device fails. If a device lock has been in effect for 15 minutes or more, then TF/Mirror releases the existing lock and the new request for a lock on that device is honored.

SRDF/AR obtains a long-term lock on each BCV (source and target) and on each source STD device in the process during initialization (when the SRDF/AR process is first started). These locks are held until the process ends and they cannot be taken over by TF/Mirror.

You can use the ReleaseDeviceLock JCL parameter to release any SRDF/AR locks that were not freed due to an abnormal termination of the SRDF/AR process. The ReleaseDeviceLock JCL parameter is not allowed for an active process.

Note: The following section, “Clearing SRDF/AR locks”, provides information about ReleaseDeviceLock. “JCL parameters” on page 25 discusses of ReleaseDeviceLock.

If a process abnormally terminated without clearing the Active flag, you must delete the process with the FORCE option and re-define the process before you run the ReleaseDeviceLock procedure.


SRDF/AR

Clearing SRDF/AR locks

Because an SRDF/AR process can involve a large number of devices, a procedure is available to help clear up all the SRDF/AR locks in a single-hop or multi-hop environment immediately

Here is a sample jobstep that you can use after some customization. Note that PARM='RELEASEDEVICELOCK' is required. With the PARM= set and the keyword START on the MODIFY statement, all of the device external locks associated with the defined SRDF/AR process are RELEASED.

Executing a jobstep with PARM='RELEASEDEVICELOCK' results only in clearing the locks for the devices in the process that is specified in the MODIFY START statement; it does not execute the MODIFY START to start the process.

//RELEASE EXEC PGM=EMCTF,REGION=1M,PARM='RELEASEDEVICELOCK'//STEPLIB DD DSN=Your.TimeFinder.Library,DISP=SHR//SYSOUT DD SYSOUT=*//SYSABEND DD SYSOUT=*//SYSIN DD *GLOBAL WAIT,MAXRC=4**** RELEASE LOCKS FROM YOUR EXISTING SRDF/AR PROCESS.**MODIFY 03,Your_SRDF/AR _Process_Name,START/*

If, for some reason, the SRDF/AR process does not exist, you need to DEFINE the SRDF/AR process using TF/Mirror commands.

Note that the SRDF/AR process does not actually run. Although the START command is used, the only action that takes place when RELEASEDEVICELOCK is specified, is that the locks are cleared. After the locks are cleared, the SRDF/AR process ends. The named SRDF/AR process can then be started normally.

Testing SRDF/AR recovery proceduresNormal SRDF/AR processing consists of the following steps:

1. Synchronizing the primary site standard (STD) devices and their R1BCV devices.

2. Splitting both the standard devices and the recovery site R2 devices from their BCV devices.

3. Synchronizing the R1BCV and R2 devices across the SRDF link.

4. Re-establishing the STD and R2 with their respective BCV devices.

This processing creates the three possible states listed previously.

To test these procedures you can issue:

◆ MODIFY STOP(NORMAL) to the SRDF/AR process. This results in an ALL Split state on the target Symmetrix system since the SRDF/AR process continues to the start point for a new cycle.

◆ MODIFY STOP(STEP) to the SRDF/AR process. This results in either an ALL Split or NONE Split state on the target Symmetrix system depending on which step is executing at the time the command is issued.

Testing SRDF/AR recovery procedures 161

SRDF/AR

◆ To create the SOME Split state on the target Symmetrix system, you must take RDF links offline through the SRDF Host Component command: SC LINK,ALL,OFFLINE. This must occur during step 6 of the SRDF/AR process, while target (R2) volumes are being re-established with their BCV mirrors.

When performing the procedures described in this chapter, you are directed to issue commands either at the host with access to the source standard (STD) device or at the host with access to the target (R2) device. You can redirect commands across the link using the RMT(cuu[,rdfgroup#]) option. This gives you the option to enter all commands from the same host and redirect the commands to a remote Symmetrix system.

Note: Table 12 on page 167 presents information about what to do in device failure situations.

This section contains the following procedures:

◆ Procedure 0: Query and clear any existing Symmetrix device locks associated with SRDF/AR devices. Determining the state (INUSE vs. AVAIL) of all the BCV volumes at the restart site.

◆ Procedure 1: Performing SRDF/AR recovery when All of the target (R2) devices are split from their partner BCV devices.

◆ Procedure 2: Performing SRDF/AR recovery when None of the target (R2) devices are split from their partner BCV devices.

◆ Procedure 3: Performing SRDF/AR recovery when Some of the target (R2) devices are split from their partner BCV devices.

Procedure 0: BCV state and the restart environment

When RDF link failure has interrupted a SRDF/AR process, the devices at the restart site are still marked as belonging to the SRDF/AR process. Since the actual SRDF/AR process that created the restartable images on the R2 and BCV devices is not executing at the restart site, TF/Mirror needs to be made aware of the SRDF/AR configuration. This is accomplished by running the TF/Mirror jobs during the restart procedures with PARM=SAR_RESTART.

1. Issue the following TF query to all Symmetrix control storage systems:

QUERY seq#,LCL(cuu)

• If the value of the STATUS field for all BCV devices is AVAIL, the BCV devices are split. Go to “Procedure 1: All R2s are split from their BCVs” on page 163.

• If the value of the status field for all BCV devices is INUSE or INUSX, the BCVs are established or in the process of establishing. Go to “Procedure 2: No R2 is split from its BCV” on page 164.

• If some of the BCV devices show a value of INUSE or INUSEX and some of the BCVs show a value of AVAIL in the status field, go to “Procedure 3: Some R2s are split from their BCVs” on page 165.

2. Vary the LINKS offline at the restart site to protect the R2 volumes from inadvertent resynchronization from the R1BCV devices:

#SC LINK,ALL,OFFLINE


SRDF/AR

Procedure 1: All R2s are split from their BCVs

If all of the target (R2) devices are split from their partner BCV devices, the SRDF/AR step executing was synchronizing the production site R1BCVs with the restart site R2s. If the synchronization is complete (no invalid tracks owed to the R2 devices) the target (R2) devices hold the most recent point-in-time consistent copy. If any one of the target (R2) devices has invalid tracks owed to it, then their partner BCV devices hold the most recent point-in-time consistent copy.

Note: Before performing this procedure, you must determine whether to use the R2 devices or their partner BCV devices as the point-in-time copy for restart.

BCV device restartIf you are going to use the BCV devices, take the following steps from a host at the restart site:

1. Check for outstanding invalid tracks owed to Any R2 in the SRDF/AR configuration by issuing the Host Component command:

SQ VOL,LCL(cuu,rdfgroup_of_SAR_R2_Devices),INV_TRKS

Result: Information about invalid tracks owed to the R2 devices is displayed.

2. Take one of the following steps, based on whether there are invalid tracks:

• If there are no invalid tracks owed to the R2 devices, do the following:

a. Issue the TF/Mirror command:

RE-ESTABLISH seq#,LCL(cuu,sym#bcv-sym#bcv)

Result: This captures the most current data-image on the BCVs from fully synchronized R2 devices.

b. Wait for the synchronization to complete by issuing the TF/Mirror command:

QUERY seq#,LCL(cuu)

c. Wait for the remaining tracks to synchronize. Look for an invalid track count of zero and a status of INUSE.

d. Issue the TF/Mirror command:

SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv),HOLD

Result: The BCVs now contain a point-in-time copy of the R2 data image that can later be refreshed from the R2s if necessary.

The BCV devices are Ready for restart.

• If there are invalid tracks on any of the R2 devices, issue a RESTORE command with the WAIT option followed by a SPLIT command to the BCV devices: This saves a copy of the restartable image on the R2 devices.

RESTORE seq#,LCL(cuu,sym#bcv-sym#bcv),WAIT,R1SYNC(N)SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv),HOLD

The BCV devices are Ready for restart.


SRDF/AR

Note: R2 RESTORE is prohibited if R1SYNC(Y) is specified on Enginuity 5x68 and higher.

R2 device restartIf you are going to use the R2 devices, take the following steps from a host at the restart site:

1. Check for outstanding invalid tracks owed to any R2 in the SRDF/AR configuration by issuing the SRDF Host Component command:

SQ VOL,LCL(cuu,rdfgroup_of_SRDF/AR _R2_Devices),INV_TRKS

Result: Information about invalid tracks owed to the R2 devices is displayed.

2. Do one of the following, based on whether there are invalid tracks:

• If there are no invalid tracks, RE-ESTABLISH and then SPLIT the BCVs to preserve a copy of the restartable image on the BCVs by issuing the command:

RE-ESTABLISH seq#,LCL(cuu,sym#bcv-sym#bcv),WAITSPLIT seq#,LCL(cuu,sym#bcv-sym#bcv),HOLD

Result: The R2 devices are ready for restart.

• If there are invalid tracks on any of the R2 devices, issue a standard TF/Mirror RESTORE command:

RESTORE seq#,LCL(cuu,sym#bcv-sym#bcv),R1SYNC(N)SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv),HOLD

Result: After the R2 devices are read-write (R/W) enabled with the SRDF Host Component, the R2 devices are ready for restart.

Procedure 2: No R2 is split from its BCV

If none of the target (R2) devices are split from their partner BCV devices (status of INUSE or INUSX), the SRDF/AR step executing was synchronizing the target (R2) and their partner BCV devices. After the synchronization is complete (the devices are fully established), both R2 and their BCV devices hold the most recent point-in-time copy.

Note: Before performing this procedure, you must determine whether to use the R2 devices or their partner BCV devices as the point in time copy for restart.

BCV device restartIf you are going to use the BCV devices, take the following steps:

1. Wait for the synchronization to complete by issuing the TF/Mirror command:

QUERY seq#,LCL(cuu)

2. Wait for the remaining tracks to synchronize. Look for an invalid track count of zero and a status of INUSE.

3. Preserve the restartable image on the R2 devices by issuing the TF/Mirror command:

SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv)Result: The BCV devices are ready for restart.


SRDF/AR

R2 device restartIf you are going to use the R2 devices, take the following steps:


QUERY seq#,LCL(cuu)

2. Wait for the remaining tracks to synchronize. Look for an invalid track count of zero and a status of INUSE.

3. Preserve the restartable image on the BCV by issuing the TF/Mirror SPLIT command:

SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv)Result: The R2 devices are ready for restart.

Procedure 3: Some R2s are split from their BCVs

If some of the target (R2) devices are split from their partner BCV devices, the SRDF/AR step executing was splitting or reestablishing the target (R2) and their partner BCV devices. This command may have been issued to some control storage systems and was pending for others when the failure occurred.

SPLIT commands are issued to the remote BCVs by the SRDF/AR process to preserve a restartable copy that has been successfully propagated to the R2. Therefore, by definition, the most recent restartable copy of the data is on the R2s when only some of the BCVs are in an AVAIL status.

Note: Before performing this procedure, you must determine whether to use the R2 devices or their partner BCV devices as the point in time copy for restart.

BCV device restartIf you are going to use the BCV devices, you must synchronize the BCVs with AVAIL status with their R2 partners so they can be synchronized with the BCVs having a status of INUSE. To do this, take the following steps:

1. Re-establish BCV devices with AVAIL status by issuing the command:



QUERY seq#,LCL(cuu)

3. Wait for the remaining tracks to synchronize.

4. Issue the TF/Mirror command:

SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv)Result: The BCV devices are ready for restart.

R2 device restartIf you are going to use the R2 devices, take the following steps:

1. Re-establish BCV devices with AVAIL status by issuing the command:



SRDF/AR


QUERY seq#,LCL(cuu)

3. Wait for the remaining tracks to synchronize.

Result: The R2 devices are ready for restart.

Note: If you want to preserve a restartable image on the BCVs, issue the TF/Mirror command: SPLIT seq#,LCL(cuu,sym#bcv-sym#bcv).

Operational considerationsTF/Mirror has implemented a enhanced SRDF/AR Resiliency. TF/Mirror now pauses the SRDF/AR process after all API and SYSCALL errors. You no longer have to issue a SRDF/AR PAUSE command to pause the SRDF/AR process when a drive failure is detected.

Note: The EMC Mainframe Enablers Message and Code Guide describes the messages discussed in this section.

◆ When devices are Not-Ready as a result of a drive failure, SRDF/AR identifies the event and issues the following messages and WTOR:

BCVA012W Process process_name, API call failed, rc 00180060, RTGT, BCV 0A4B, Symm 0002874-00999, RAG 01

BCVA063E Process process_name, BCV 0183 is N/R, Mir 01(02b-C2), Symm 0001877-90034, RAG 02

*nn BCVA058A Process process_name, Paused (error) - reply CONTinue or CANcel

◆ When the EMC CE service action is performing the drive replacement, there are periods of configuration locking and dynamic drive replacements that can cause collisions with SRDF/AR. SRDF/AR recognizes this, and issues the following messages and a WTOR:

BCVA012W Process process_name, API call failed, rc 00180031, RTGT, BCV 0A4B, Symm 0001234-00999, RAG 01

*nn BCVA058A Process process_name, Paused (error) - reply CONTinue or CANcel

◆ Retry tables handle all identified transient error conditions, and issue the messages such as the following:

BCVA047W Process process_name, API call failed, RC 94, Retry issued, CUU 0051, Symm 0001877-00999, RAG 00

BCVA047W Process process_name, API call failed, RC 8C, Retry issued, CUU 005D, Symm 0001877-00999, RAG 01

◆ SRDF synchronization and mirror synchronization problems are automatically detected. SRDF/AR detects that the synchronization is stalled. The stalled condition continues to be seen by repetitive BCVA000I messages when DEBUG(ITRKS) is specified, each indicating the same invalid track count:

BCVA000I process_name, R1SYNC 0100 ITRK count = 00000001BCVA000I process_name, R2SYNC 0200 ITRK count = 00000001BCVA061I Process process_name, Pause due to Synchronization problem, Symm 0001877-90034, RAG 02


SRDF/AR

◆ SRDF/AR checks all R2s at top of cycle (STEP 1) for invalid tracks on the R2 local mirrors. SRDF/AR interrupts if an R2 is detected with invalid tracks on its single local mirror (unprotected R2) or both local mirrors (protected R2). This prevents the possibility of continuing with incomplete data at the target site.

BCVA067E Process process_name, R2 nnnn has Invalid Tracks, Symm Tnnnnnnn-nnnnn, RAG nnBCVA042E Process process_name interrupted

When paused, SRDF/AR holds logical locks (DEL – Device External Locks) for all the STD, R1BCV and target BCV defined to the process, These locks prevent other TimeFinder actions to the devices.

SRDF/AR Resiliency should eliminate actions that must be completed after a drive replace service action.

In the rare event an action utilizing TF/Mirror is required, run the TF/Mirror job specifying PARM=’SAR_PAUSED’ on the JCL EXEC statement. PARM=’SAR_PAUSED’ allows TF/Mirror actions only when SRDF/AR is paused. This prevents accidental bypassing of ENQ and device locks if the TF/Mirror actions are submitted when SRDF/AR is running, but not paused. This parameter replaces all previous ENQ and device lock bypass processes.

Drive failure recovery proceduresTable 12 is based on situations that impact the SRDF/AR Resiliency process or the consistent point in time that SRDF/AR preserves at the Target site.

◆ Table 12 assumes a process configuration with R1BCVs and Target BCVs on separate physicals from the STD or R2 devices they are associated with during SRDF/AR re-establish steps.

◆ Table 12 assumes protected R2 devices.

◆ Table 12 assumes hot spares are not active for R1BCV or Target BCV devices.

For all steps except 1, 8 and 9, message BCVA063E shows device type, symmetrix device number, physical drive information and Symmetrix serial number.

Note: The TimeFinder/Mirror for z/OS Message and Code Guide describes message BCVA063E.

Table 12 Customer action matrix (page 1 of 3)

Step Description Device failure SRDF/AR typeSRDF/AR status

Recommendedprocedure Notes

0. Check status STD All Paused a. Replace Drive.

b. CONTinue.

This step performs drive failure checks only.

Drive failure recovery procedures 167

SRDF/AR

R1BCV All Paused a. Replace Drive.

b. CONTinue.

R2 All Paused a. Replace Drive.

b. CONTinue.

TGTBCV All Paused a. Replace Drive.

b. CONTinue.

1. Check status R1BCV - not established

All STOPPED Re-establish and Start SRDF/AR.

This step checked only for device status, not drive failure.

TGTBCV - not split

All STOPPED Split and Start SRDF/AR.

Local R1 -TNR or LNR

Single Hop STOPPED Resume and Start SRDF/AR.

Multi Hop only.

2. Consistent SPLIT

R1BCV All PAUSED a. Replace Drive.

b. CONTinue.

If resume not used, R2’s may be out of sync. In this case, target actions are bypassed for this cycle to preserve last point of consistency.

3. Source R1 sync. wait


b. CONTinue.

1 If SRDF/AR paused again due to links or R1BCV with TNR status, correct and confirm decreasing ITRK. Then reply “CONTinue.” Otherwise, contact EMC Customer Service.2) If SRDF/AR paused again repeat 1.


b. CONTinue.

4. Source BCV ready

R1BCV All Bypassed No action. BCVSTATE(READY) in SRDF/AR definition.

Paused a. Replace Drive.

b. CONTinue.

BCVSTATE (NR) in SRDF/AR definition.

5. Re-establish source volumes

Bunker R2 Multi Hop Paused a. Replace Drive.

b. CONTinue.

Source re-establish resumed.


b. CONTinue.


Local STD Single Hop Paused a. Replace Drive.

b. CONTinue.


6. Target BCV mirror sync


b. CONTinue.

If no TGTBCV ITRKs this step.

TGTBCV M2 All Paused a. Replace Drive.

b. CONTinue.

Procedure is bypassed, otherwise follow the procedure for paused process.





SRDF/AR

7. Re-establish target volumes


b. CONTinue.

Target re-establish resumed.


b. CONTinue.

8. Target TGTBCV All Paused a. Replace Drive.

b. CONTinue.

1) If SRDF/AR is paused again, correct and confirm decreasing ITRK. Then reply CONTinue, otherwise, contact EMC Customer Support.2) If SRDF/AR is pause gain, repeat step 1.

Sync wait R2 All Paused a. Replace Drive.

b. CONTinue.

9. Split target BCVs


b. CONTinue.

Split resumed.

10. Source BCV sync wait

Bunker R2 Multi hop Paused a. Replace Drive.

b. CONTinue.

1) If SRDF/AR is paused again, correct and confirm decreasing ITRK. Then reply CONTinue, otherwise, contact EMC Customer Support.2) If SRDF/AR is paused again, repeat step 1.


b. CONTinue.

Local R1 Single hop Paused a. Replace Drive.

b. CONTinue.

11. Check status STD Single hop Paused a. Replace Drive.

b. CONTinue.

This step performs drive failure checks only.

R1BCV Single hop Paused a. Replace Drive.

b. CONTinue.

R2 Single hop Paused a. Replace Drive.

b. CONTinue.

TGTBCV Single hop Paused a. Replace Drive.

b. CONTinue.




Drive failure recovery procedures 169

SRDF/AR

Documenting problems This section describes the information required to diagnose SRDF/AR problems. When you provide the information defined in this document, EMC expects to reduce your phone time for reporting a problem, and speed up response time for Customer Support assistance with the problem.

Data collection reference

SRDF/AR has 11 steps in the process flow. The data collection focus depends on the step that fails. In addition, you should have the following baseline information always available:

◆ SRDF/AR definitions for all customer SRDF/AR processes.

This should be requested initially, and resent to us each time the customer changes their SRDF/AR environment.

This is baseline information to be retained by EMC C/S for repeat reference, to prevent having to ask for this every time.

◆ Serial number and Enginuity level for each Symmetrix system in the SRDF/AR configuration.

Save with baseline reference information.

◆ Host to Symmetrix device relationships, for each Symmetrix system in the SRDF/AR configuration.

Save with baseline reference information:

• For mainframe = UCB to Symmetrix system

• For open systems = device to Symmetrix system

◆ Current host SW levels for EMC products including maintenance levels updated as needed or on a regular basis.

Save with baseline reference information.

Failure information checklist

For a failure event, depending on what step it fails in, the following information should be captured and collected:

1. Check status:

• Source BCV offline check

• Target BCV offline check

• Target R2-R1 invalid check

• Ensure that the mirrored R2s are valid


SRDF/AR

Step 1 is designed to validate device states and device relationships. EMC does not see many issues in this step. If there are issues, they are usually setup relationship conflicts that cause SRDF/AR Process to fail in step 1. To assure that these types of failures do not happen, check SRDF/AR definitions, device statuses, bin files and device relationships for conflicts.

For step 1 data required is:

• TF/Mirror queries of all boxes SRDF/AR query to display SRDF/ARs knowledge of the relationships

• RDF query for each box pair

2. Consistent SPLIT

Step 2 splits the source BCVs in the source Symmetrix unit in a single-hop environment and the R2/R1BCV pair in the bunker Symmetrix unit in a multi-hop environment.

Data needed for Step 2 is:

• TF queries of all source/bunker Symmetrix units

• RDF queries of all Symmetrix units

• SCFLOG

• SYSLOG +/- 15 minutes

• GTF trace for con split time-outs/other con split errors

• Possibly EREP

3. Source R1 sync wait

Data needed for Step 3 is:


• RDF queries of all Symmetrix units

• SYSLOG +/- 1 hour

4. Source BCV ready

5. Re-establish source volumes

Data needed for Step 4 or 5 is:



• SCFLOG

6. Target BCV mirror sync

Documenting problems 171

SRDF/AR

7. Re-establish target volumes


• TF queries of all target Symmetrix units


• SCFLOG

8. Target R2 sync wait

9. Split Target BCVs


• TF/Mirror queries of all target Symmetrix units


• SCFLOG

10. Source BCV sync wait

11.Check status




• SCFLOG

To diagnose certain intermittent problems, EMC often requests a GTF trace of the gatekeeper devices for the SRDF/AR process. This would apply to Consistent SPLIT time-outs, elongation, other unknown causes. This allows EMC to further diagnose issues and to help identify areas of concern.


APPENDIX AError Codes

This appendix provides a comprehensive list of error codes that can be issued by TimeFinder/Mirror.

◆ User abend codes ................................................................................................. 174◆ DOIO error codes................................................................................................... 174◆ TimeFinder/Mirror reason codes............................................................................ 175◆ EXTENTS reason codes .......................................................................................... 179

Error Codes 173

Error Codes

User abend codesThe following user abend codes are issued in the event a error occurs before the message system is initialized.

DOIO error codesFigure 26 shows the format for DOIO error codes.

Figure 26 DOIO error code format

Table 13 Abend codes

Code Description

U0001 The SYSOUT DDNAME was not specified in the JCL.

U0002 The OPEN request failed for the SYSOUT DDNAME.

U0806 SCF Address space not found.

XX XX XX XX

Device status

Subchannel status

First 2 bytes of sense data


Error Codes

TimeFinder/Mirror reason codesThis reason code table only applies to TimeFinder/Mirror operations running with Enginuity levels 5773 and lower.

Note: For versions running with Enginuity levels 5874 or higher, the hexadecimal reason code (yy) is converted to a decimal number (xxx) and contained in the appropriate EQCAxxxE message, indicated by the BCVM144I message. For example:BCVM013E RESTORE failed on BCV xxxx, reason code yyBCVM144I - REFER TO EQCAxxxE JOBLOG MESSAGE

Table 14 TimeFinder/Mirror (EMCTF) reason codes (page 1 of 4)

Error code Description

01 The standard device does not exist.

02 The standard device is a BCV.

03 Attach operation: The standard device already has a BCV or a spare mirror Detach operation: The standard device does not have an active BCV mirror.

04 The standard device has four active mirrors.

05 The BCV is not the device which initiated the ESTABLISH command.

06 The device specified as a BCV in the call is not a BCV.

07 The BCV is already established to another standard device.

07A This version of TimeFinder/Mirror is not supported at the current Enginuity level.You need to use TimeFinder/Mirror 5.6 with Level Set 1 or a higher version of TimeFinder/Mirror.

09 The standard and BCV devices are not the same size.

0A Invalid request options.

0B The standard and BCV devices are not of the same emulation type.

0D The standard device is not ready or is write disabled.

0E The command attempted to establish a ready R2 BCV.

0F This BCV was not previously attached to this standard device, cannot reestablish.

10 ESTABLISH in progress. Poll later for ending status.

11 The standard device is busy, reissue the SPLIT/RESTORE command.

13 The standard and BCV devices are the same device.

14 Controller type invalid.

15 The standard device has open concurrent copy sessions.

16 The BCV has open concurrent copy sessions.

17 The BCV is not in a ready state or is write disabled, or (on a split) the BCV mirror is not ready.

TimeFinder/Mirror reason codes 175

Error Codes

1A The BCV does not have enough available dynamic mirrors to perform the requested ESTABLISH operation.

1B The standard device already has two attached dynamic mirrors (such as BCV, hot spare, or dynamic RDF mirror). Enginuity limits the number of dynamic mirrors to two.

1C Regular split not supported in Enginuity 5x68 or higher.

1D SYSTEM_TIME_OVERRUN - no resources to process request, try later.

20 Internal error.

21 The standard and BCV devices do not comprise a BCV pair.

22 Not enough resources (write pending slots) to execute the split process. Try again later.

23 The BCV mirror is not fully synchronized with the standard device mirror(s).

24 Rejected because standard device would become invalid.

25 The BCV has four mirrors.

26 SDDF is not enabled, therefore a differential split operation is not possible.

27 The standard and BCV devices have a different number of meta members.

28 One device in the pair is a meta device and the other is not.

2A The BCV device is in transient state and the requested operation is rejected. For a concurrent BCV feature, the first ESTABLISH may not have completed.

2B The standard device is in transient state and the requested operation is rejected.

2C Attempting a regular split on a meta volume where not all the members are established.

2D The pair has different RAD flag in flags 2.

30 Illegal TimeFinder/Mirror command.

31 Configuration upgrade in progress.

32 Cannot use internal BCV (DRVs) devices.

33 Cannot use standard device for internal BCV.

34 Cannot create GST record for DAS.

35 BCV device assigned to SNAP session or is held.

36 Moving the BCV mirror away would leave invalid tracks.

37 A reverse split was requested on a device with only one mirror.

38 BCV has write pendings (not in sync with its mirror).

39 The pair has different physical block sizes. Low level format difference.




Error Codes

3D Destination device not ready.

Note: This code comes from EMC TimeFinder/Mirror Mainframe SNAP facility. TimeFinder/Mirror invokes TimeFinder/Mirror Mainframe Snap facility syscalls through the TimeFinder/Mirror Base CONFIG command.

40 BCV is not on this host adapter.

41 A background split is in progress, BCV cannot be used.SR device is not a BCV device.

42 A background split is in progress, Standard device cannot be used.Device already set or released.


43 Not enough concurrent copy slots exist to keep track of yet another BCV.Device is an established BCV device.


44 Illegal to force an instant split.Device is an active EMCSNAP device.


45 SNAP session (File SMMF) exists for this BCV.Syscal 812C - illegal modifier.


46 The pair specified are metas with differing stripe sizes.Device has CCOPY (Protection Session) sessions established.

47 The standard device has an active file level SNAP session.

48 Timeout.

50 In SymmVault mode no SMMF operations are allowed.

51 SymmVault BCV cannot receive any data through an establish after a track was protected.

52 SymmVault STD cannot receive any data through a restore after a track was protected.

53 Standard device cannot be a virtual device or a log device.



TimeFinder/Mirror reason codes 177

Error Codes

55 If STD device is striped, SMMF operation are on the HEAD of the device.

56 If BCV device is striped, SMMF operation are on the HEAD of the device.

60 Moving mirror is not ready.

61 Moving mirror is not write enabled.

62 Moving mirror is not valid.

63 Syscall 813D: invalid number of entries.

65 Syscall 813D: instant split flag not set.

66 The standard device is assigned to a TimeFinder/Clone Mainframe Snap Facility session or is held.

67 Syscall 812D: some of the data mirrors of the RAID group have invalid tracks.

68 Syscall 8125: No SPLIT request exists for the other BCV concurrently established.

69 Syscall 8125: Restore not allowed against a PPRC R2 standard device.

70 Syscall 812D, some of the data mirrors of a RAID group have invalids.

71 Syscall 8125: Establish or restore not allowed for a PPRC BCV.

72 Syscall 8125: Establish or restore not allowed if SNOW is active and R1 is ready.

74 Syscall 8125: Restore is not allowed if R2 is STD and write enabled and if the R1 is ready.

76 A virtual restore has been aborted, leaving the BCV inconsistent and with aborted tracks.

77 BCV is a RAID protected Device.

78 Can’t split while STD is attach in progress.

79 Can’t perform Protected RESTORE while BCV has IVTOC tracks.

F0 Controller completed the request although the BCV shows not in use.

F1 Retry count was exceeded for code 22.

F2 I/O error on SPLIT.

F3 Retry count was exceeded for code 11.

F8 Clone session detected in error.




Error Codes

EXTENTS reason codesThe following table contains reason codes for the EXTENTS program.

Table 15 EXTENTS error codes

R15 Reason Explanation

0 Successful

4 1 Illegal mask specified

2 No matching datasets found

3 Unknown function code

4 Overflow, unable to return all matching datasets.

5 UCB not found

6 Dataset not found on volume

7 DSCB not type 1 or type 4

8 Tracks allocated = 0

9 Extents not available due to HSM migrate

A Caller not APF authorized

B Extents program logic error

C Entry type = GDG base

8 SVC26, - Catalog management return code

12 8 Dataset is not catalogued

? Locate failed - the reason code contains the locate return code

16 EXTWA Failed validation

EXTENTS reason codes 179

Error Codes


APPENDIX BEnhancements

Invisible Body Tag

This appendix provides a comprehensive list of enhancements for TF/Mirror.

◆ Enhancements by release ..................................................................................... 182

Enhancements 181

Enhancements

Enhancements by releaseTable 16 lists enhancements to TimeFinder and TF/Mirror by release:

Table 16 TimeFinder enhancements (page 1 of 7)

Release Enhancement

7.6.0 There are no specific feature enhancements to TF/Mirror for this release. This manual does contain corrections and updates from the previous publishing.



7.3.0 There are no specific feature enhancements to TF/Mirror for this release.

7.2.0 TF/Mirror allows a concurrent asynchronous leg configuration consisting of an R11 source device and two R2 devices with SRDF/A on each leg. This configuration allows a PiT Consistent Split, along with the option of a separate consistent split on each leg.

TF/Mirror now supports thin devices. Enginuity level 5874 or higher is required.

A new CONFIG parameter, MULTIDELINC allows you to remove multiple devices from BCV-standard device relationships using a single syscall to process the requests together in a multi-device list. MULTIDELINC is now the new default parameter.

The CONFIG DELINC command option now allows the user to terminate a Clone session after an error has occurred, when only the STD device number is available (not the BCV). This feature was implemented to terminate incomplete clone sessions that can occur on Enginuity levels 5773 and below, when an error occurs during the creation of a clone session.

The FBA Meta session clean-up feature detects Clone session errors during Establish or Restore, and internally terminates incomplete Clone sessions.In addition, if any members of an FBA Meta group had a Clone session error, then all Clone sessions in that group are terminated. This leaves the FBA Meta group in a consistent state, with no members in a Clone session.

When partial FBA Meta groups are specified, TF/Mirror allows the user to specify the META head device number of an FBA META group, and then TF/Mirror identifies the other group members, in order to process the entire group.

7.0.0 TF/Mirror 7.0 running with Enginuity 5874 and higher no longer uses the TF/Mirror Enginuity code. Instead, TF/Mirror uses clone emulation for all operations. Running with Enginuity 5773 and lower, TF/Mirror still uses TF/Mirror code.

TF/Mirror Version 7.0 running with Enginuity 5874 supports Cascaded Clone Emulation. Cascaded Clone is the ability for a clone operation to take place with a device that is already involved in a clone operation.Because the source device must to an STD device and the target device must be a BCV device, you cannot use Version 7.0 to cascade Clone Emulation. However, you can use Clone Emulation to cascade from a regular clone session. For example, you can clone device x to a STD device and use Clone Emulation to copy the STD device to a BCV.

Under Enginuity 5874, you can perform SRDF Host Component procedures 4 and 6 for R2 to R1 synchronization while a Clone Emulation operation to the R2 is in progress. (SRDF Host Component now forces TF/Clone protected tracks to become RDF Remote invalid tracks.)


Enhancements

TF/Mirror Version 7.0 running with Enginuity 5874 supports Extended Address Volumes (EAVs).

TimeFinder./Mirror Version 7.0 supports use of the FORCE parameter with the SPLIT command under clone emulation mode.

TF/Mirror 7.0 operates with Symmetrix systems that are at Enginuity revision level 5874 as well as the prior levels defined in the EMC Mainframe Enablers Installation and Customization Guide.

TF/Mirror 7.0 supports all currently supported versions of z/OS.

TF/Mirror 7.0 includes the application of accumulated maintenance.

5.6.0 TF/Mirror 5.6 recognizes the new R21 device type. The R21 device is the target of one SRDF relation ship and simultaneously the source of another SRDF relationship.

TF/Mirror 5.6 now allows for the multi-tasking of TimeFinder commands. This process, called Parallel Timefinder, allows you to specify subtasks through a new GLOBAL parameter, PARALLEL.

TF/Mirror 5.6 operates with Symmetrix systems that are at Enginuity revision level 5773 as well as the prior levels.

TF/Mirror 5.6 supports all currently supported versions of z/OS.

TF/Mirror 5.6 includes the application of accumulated maintenance.

5.5.0 TF/Mirror operates with Symmetrix systems that are at Enginuity revision level 5772 as well as the prior levels defined in Chapter 2 of the EMC TimeFinder/Mirror for z/OS Product Guide.

TF/Mirror supports all current versions of z/OS.

TF/Mirror has added support for RAID 6 protected devices.

TF/Mirror has a number of improvements in remote Consistent SPLITs:• TF/Mirror no longer requires that you have to submit remote Consistent SPLIT in a

multi-hop environment from the host attached to the array on which you want to obtain the point of consistency (site A). You can now initiate a Consistent SPLIT from site B or site C. TF/Mirror dynamically validates the location of the R1 device.

• The STDcuu parameter on the SPLIT command is now optional for an remote Consistent SPLIT. However, when you do specify STDcuu, TF/Mirror validates your specification. If the specification does not reference the correct R1, TF/Mirror substitutes the correct R1 and issues message BCVI120W (or E depending on the MAXRC value).

• When you issue a Consistent SPLIT for a BCV attached to an R2 (STD), TF/Mirror validates the RDF status. If the R2 is active (the R1 is not TNR), TimeFinder does not set ECA on the R2 and issues message BCVI119W (or E depending on the MAXRC value).

• With a remote Consistent SPLIT, the R1 must be in Synchronous mode. It cannot be in Semi-Synchronous mode or Adaptive Copy mode.

• TF/Mirror now handles remote Consistent SPLITs in mixed ECA/non ECA environments as follows: TF/Mirror examines the SRDF environment you specified. If the environment consists of mixed ECA and non ECA protected volumes, TF/Mirror uses non-ECA protection. If all the volumes are using ECA, then TF/Mirror uses ECA protection.

• ECA is disabled in SRDF/A remote Consistent SPLITs.• Multi-hop Consistent SPLITs are supported.


Release Enhancement

Enhancements by release 183

Enhancements

TF/Mirror 5.5 lets you use clone emulation with all types of RAID protection. You enable expanded clone emulation with the GLOBAL parameter CLONEemulation and a CLONEemulation parameter for the ESTABLISH or (Full) RESTORE commands.

TF/Mirror includes a new GLOBAL parameter, ATTach that implements a new multiple grouping function. ATTach allows multiple attach requests (on ESTABLISH or RESTORE commands) to be processed before the Symmetrix unit is queried to ensure that the BCVs are attached.

The CONFIG parameters, HOLD and RELEASE have changed. HOLD now obtains a device lock and RELEASE attempts to release the HOLD device lock and the TF/Clone Mainframe SNAP Facility (fsmmf) hold. The reason for this change is to provide a better method to hold a BCV. It overcomes the inter operability problems of the automatic TF/Clone Mainframe SNAP Facility hold and the CONFIG HOLD.

TimeFinder has the TolerateDesiredState GLOBAL parameter. Previously, if a device was not in the correct state, a SPLIT, ESTABLISH, or RESTORE operation would fail and stop execution unless you had specified a MAXRC value of 8. Now, the TolerateDesiredState parameter allows processing to proceed with a MAXRC value of 4 or higher.

TimeFinder has enhanced the AutoRelease GLOBAL parameter to include ESTABLISH and RE-ESTABLISH. Previously, an ESTABLISH or RE-ESTABLISH failed if the STD was the target of a SNAP. Now, if an ESTABLISH or RE-ESTABLISH failed because of a hold on the STD, TF/Mirror automatically issues a release and retries the command.

TF/Mirror includes performance improvements in internal checks, BCV clone emulation and other BCV operations, and in split operations.

TF/Mirror includes the application of accumulated maintenance.

5.4.0 The TimeFinder utility has been removed from TF/Mirror and is now shipped as a separate component: EMC TimeFinder Utility.

TF/Mirror supports Symmetrix systems that are at Enginuity revision level 5671 as well as the prior levels defined in Chapter 2 of the EMC TimeFinder/Mirror for z/OS Product Guide.

TF/Mirror supports RAID 5 protected BCVs, also known as “clone emulation.” This allows traditional TimeFinder commands and operations without having to use Symmetrix mirror positions.

TF/Mirror supports multi-attach with ESTABLISH and RE-ESTABLISH commands. Multi-attach allows multiple device pairs to be attached through one syscall. You can control multi-attach through the new parameters on the GLOBAL, ESTABLISH, and RE-ESTABLISH commands.

TF/Mirror supports several SRDF/AR resiliency enhancements, including:• SRDF/AR configuration persistence -- a hardening of SRDF/AR

configuration/cycle information to allow cross-IPL restarts.• Reaction to, management of, and recovery from hardware failures consistent with

user-selected policy choices.• Improved resiliency of SRDF/AR by enhancing retry processing so that it is more

efficient and take less time.

TF/Mirror includes SRDF/A awareness. SRDF/A (SRDF/Asynchronous) is a new mode of operation for SRDF. This feature ensures the integrity of each product while allowing their side-by-side interaction.

The Consistent SPLIT feature and the SRDF/AR feature are now activated by a license feature code.


Release Enhancement


Enhancements

TF/Mirror (including SRDF/AR) includes support for 12-digit Symmetrix serial numbers.

TF/Mirror includes the application of accumulated maintenance.

5.3.1 SNAP has been removed from TimeFinder and is now shipped as a separate product with the name TF/Mirror Mainframe SNAP Facility.

Protected RESTORE mode is now fully supported. The optional parameter PROTECTEDRESTORE for the RESTORE command protects the BCV against changes to the standard device until an ESTABLISH or RE-ESTABLISH operation. Protected RESTORE requires Enginuity 5670.50 or higher.

5.3.0 TimeFinder Base

A new Multi-Protection variation has been added to Multi-Hop SAR.

SAR now supports mixed CKD and FBA device configurations in addition to multi-image configurations. This is dependent on Enginuity Consistency Assist (ECA). Check the EMC Powerlink website for current information in the release notes for Enginuity information on ECA support.

Optional control of target re-establishes with REEST_TGT is now available for SAR.

Additional flexibility to define devices in a SAR configurations.


Multi-Image LPAR Support for Symmetrix Automated Replication (SAR). SAR can now be used across multiple mainframe logical partitions (LPARs). Multi-image SAR support is enabled by the capability known as Multi-Image Consistent SPLIT, first delivered in the base TimeFinder V5.1.

Performance improvement for Consistent SPLIT using an Enginuity assist.

New controls and general performance improvements for multi-host SAR using an Enginuity assist.

Samplib JCL, programs, and structures are now distributed in SCF SAMPLIB and have been removed from TF RIMLIB. SCF SAMPLIB is delivered with EMC ResourcePak Base for z/OS. For more information, refer to the EMC ResourcePak Base for z/OS Product Guide.


Normal Splits are converted to Instant on Enginuity level 5x68 and higher.

The FORCE option is allowed on an Instant SPLIT on Enginuity level 5x68 or higher.

Support has been added for Striped CKD Meta devices. The striped meta device is still presented as one CKD UNIT address.For an ESTABLISH or RESTORE, the devices must have the same configuration attributes. A striped device is not allowed to attach to a non-striped device. (Enginuity microcode level 5x68 and higher.)

Using Symmetrix device level locks in addition to the current software ENQUEUE on BCV devices enhances serialization.

Symmetrix Automated Replication syntax is extended to support HOP_TYPE(MULTI) for single image SAR.

1 or 2-digit (hex) RDF groups may now be specified.


Release Enhancement


Enhancements

Multi-Image Consistent SPLIT is supported.

TimeFinder Utility

The parameter SYSTEM_CATALOG is added to the CATALOG statement. If specified, a lookup is performed to determine the appropriate catalog to use. The dataset is then catalogued into the system catalog structure.


The optional parameter SBCV has been added to the extended format Query to show multi-BCV status. This parameter starts the display with the BCV entered on the Query command.

The optional wait parameter for ESTABLISH, RE-ESTABLISH, SPLIT, and RESTORE now allows the wait interval to be specified. The default wait times are 10 minutes for SPLIT and 120 minutes for ESTABLISH and RESTORE functions.

CONFIG DELINC errors have been changed to warnings (RC 4). The corresponding severity levels of messages BCVM075W, BCVM076W, and BCVM077W have been changed accordingly.

Support for remote commands has been extended to include multi-hop configurations. The ragrp field for a RMT command can be a single RDF group or a list of RAs describing the path of up to 8 hops to a remote Symmetrix system.

Protected BCV Establish.This feature involves locally mirrored BCVs only. When issued on an establish or a restore with Protected BCV Establish, both mirrors of the BCV are added as mirrors of the Standard. (Enginuity microcode level 5x68 and higher.)

Remote Consistent SPLIT is now supported. Consistent can be specified on a RMT command.

Concurrent BCV can now be configured using the CBCV optional parameter. This allows one standard device to have 2 established BCV devices. (Enginuity microcode level 5x67 and higher.)

An option for instant BCV mirror synchronization may be specified for ESTABLISH or RE-ESTABLISH. This feature involves locally mirrored BCVs only. (Enginuity microcode level 5x67 and higher.)


Single image Consistent SPLIT: New SPLIT parameter available that performs an Instant SPLIT across all devices requested in the same SPLIT command sequence level, halting all host I/O to the devices being SPLIT on the host image that the request is executing on (Enginuity microcode level 5x66 and higher).

CONFIG DELINC provides the ability to remove a BCV to STD (incremental) relationship (Enginuity microcode level 5x66 and higher).

Option to set the jobstep return code by using the SETMAX sub parameter.

New LCL parameter to support commands to a Symmetrix device number. This allows TimeFinder control of Symmetrix devices whether or not the device is available to the host.

TimeFinder Utility

Performance increase when processing many volumes: When processing multiple volumes and or a large number of datasets, EMCTFU automatically processes volumes in parallel for significant performance gains.


Release Enhancement


Enhancements

Performance increase: When the DIRECT=YES parameter is specified on the SOURCECATALOG statement, EMCTFU makes some catalog changes directly, to reduce the overhead of invoking the IDCAMS utility.


Instant SPLIT (Enginuity microcode level 5x66 and higher).

New extended query display (Enginuity microcode level 5x66 and higher).

Multiple splits in a single I/0 request (Enginuity microcode level 5x66 and higher).

Multiple differential data sessions for different BCVs paired with the same standard device allowing incremental establish to multiple BCVs or incremental restore from multiple point-in-time BCV copies (Enginuity microcode level 5x66 and higher).

RDF suspend R1 BCV before split.

New SAF security interface checks to allow bypassing WTORs and online checking.

Additional information passed to SAF exit to allow additional flexibility in customization.

Calculate RDF group for RMT requests if the ragrp parameter is not specified. Remote requests are allowed to continue if ragrp parameter is not specified and the R1 device is suspended.

Add range support to remote device RMT requests.

Check for R2-R1 invalid tracks on differential split on an R1 BCV.

TimeFinder Utility

Performance enhancement resolving VSAM cluster information.

3.3.0 New security interface to protect from unauthorized usage.

TimeFinder Base

Security Interface.

2K BCV device support.

WAITSYNC keyword on SPLIT command.

NOR1RESYNC now default on RESTORE command.

R1RESYNC keyword on RESTORE command.

4K action support.

TimeFinder Utility

GDG dataset support, GDG base is created if it does not exist.

Alternate index support, index is connected to the base cluster if the base cluster is also being processed.

Allow rename of dataset even if the original is allocated.

Performance enhancement to cleanup processing.

Processing of multivolume datasets allowed if source catalog is unavailable.


Release Enhancement


Enhancements

Logical check determines whether all dataset extents have been found.

3.2.1 Remote commands in an SRDF environment (with Enginuity microcode 5x65 and higher).

New CONFIG command (with Enginuity microcode 5x65 and higher):• HOLD• RELEASE• READY• NR

QUERY command enhancements:• Enginuity level• Controller type• Mirror indicator• Number of cylinders• BCV Hold and Not Ready status (with 5x65)• Last SPLIT type

New keywords on SPLIT command:• NR — make BCV Not Ready to the host• HOLD — mark BCV as not available for other TimeFinder operations• CHANGEDONLY — only synchronize changed tracks on the BCV mirrors• BCVREFRESH — Synchronize BCV (M1) from BCV mirror (M2)

BCVGROUP/DSN BCV selection • Check emulation type• Check cylinder size • Check BCV online status

Allow RESTORE from a BCV that was never ESTABLISHED.

New EMC SNAPTM Utility provides immediate dataset and volume copies without previous TimeFinder ESTABLISH.

Support for SRDF Multi-Hop with Differential BCV copies (with 5x65).

2.1.0 Enhanced BCV and standard device online checking with Enginuity microcode 5x64 and higher.

Enhanced syntax checking.

Restore command or Incremental Restore command disable feature.

Support of multiple DSN with the same sequence number and common volumes.

Sample jobs that provide examples of OS/390 Product Set usage are found in the SCF SAMPLIB dataset.

NOTYPE option on GLOBAL statement.


Release Enhancement


Documents

TimeFinder/Mirror for z/OS Version 7.6 Product Guide