ibm® virtualization engine ts7700 series

TS7700 Flash Copy for Disaster Recovery Testing October 2020

of 65 © Copyright IBM Corporation, 2015-2019

IBM® TS7700 Series

Best Practices

Flash Copy for Disaster Recovery Testing V1.6a

Katsuyoshi Katori, [email protected]

IBM Systems, Enterprise Storage Development, IBM Japan

Ltd.

Takeshi Nohta, [email protected]


Ltd.

Takahiro Tsuda, [email protected]


Ltd.

Shinsuke Mitsuma, [email protected]


Ltd.

Joseph Swingler, [email protected]

IBM Systems, Storage Systems Development, IBM USA

mailto:[email protected]






Contents 1 Change History ................................................................................................................................... 4

2 Flash Copy for Disaster Recovery (DR) Testing ................................................................................ 5

2.1 Configurations Supported ............................................................................................................. 5

2.2 Code Requirements ....................................................................................................................... 5

2.3 Restrictions ................................................................................................................................... 6

2.4 Flash Copy DR Testing Common Terms ...................................................................................... 6

3 Flash Copy for DR testing operation overview .................................................................................. 8

3.1 Basic steps for Using the Flash Copy for DR Testing Function ................................................... 8

3.2 General Considerations for the Flash Copy for DR Testing Function ........................................ 11

4 Operational Details ........................................................................................................................... 14

4.1 Preparation .................................................................................................................................. 14

4.2 Defining Write Protect Exclusion Categories ............................................................................. 14

4.3 Defining a Disaster Recovery Family ......................................................................................... 16

4.3.1 Create a DR family or add a cluster to an existing DR family ............................................ 16

4.3.2 Remove a cluster from a DR family .................................................................................... 17

4.3.3 View status of a DR family .................................................................................................. 18

4.4 Initiating the Flash Copy for DR Testing ................................................................................... 23

4.4.1 Enable the Write Protect Mode and the Flash Copy ............................................................ 23

4.4.2 Disable the Flash Copy and the Write Protect Mode ........................................................... 26

4.4.3 Check the asynchronous request status ................................................................................ 28

4.5 LIVECOPY Option ..................................................................................................................... 32

4.6 SELFLIVE Option ...................................................................................................................... 34

4.7 LIVEACC Option ....................................................................................................................... 36

4.8 Viewing flash delta data in cache from flash copies ................................................................... 38

5 Flash Copy and the Management Interface (MI) .............................................................................. 40

5.1 Viewing delta amount of data in cache from flash copies using the Management Interface (non-

tape attached TS7700 Flash Capable cluster only) ............................................................................... 40

5.2 Viewing delta amount of data in cache from flash copies using the Management Interface

(TS7700T/TS7700C cluster only) ......................................................................................................... 41

5.3 Viewing details of flash copy of logical volumes ....................................................................... 42

5.4 Virtual Tape Drives panel ........................................................................................................... 45

5.5 Write Protect mode panel ............................................................................................................ 46

6 Appendix A. Details of the format of data reported by “DRSETUP” library request command ..... 47

6.1 Supported keywords .................................................................................................................... 47

6.2 Format of the data reported by “DRSETUP, ADD” command .................................................. 48

6.3 Format of the data reported by “DRSETUP, REMOVE” command .......................................... 49

6.4 Format of the data reported by “DRSETUP, WP, ENABLE” command ................................... 50

6.5 Format of the data reported by “DRSETUP, WP, DISABLE” command .................................. 50

6.6 Format of the data reported by “DRSETUP, FLASH, ENABLE” command ............................ 51

6.7 Format of the data reported by “DRSETUP, FLASH, DISABLE” command ........................... 52

6.8 Format of the data reported by “DRSETUP, DOALL, ENABLE” command ........................... 53

6.9 Format of the data reported by “DRSETUP, DOALL, DISABLE” command .......................... 54

6.10 Format of the data reported by “DRSETUP, LIVECOPY, FAMLIY” command .................. 55

6.11 Format of the data reported by “DRSETUP, SELFLIVE, ENABLE” command ................... 56



6.12 Format of the data reported by “DRSETUP, SELFLIVE, DISABLE” command .................. 57

6.13 Format of the data reported by “DRSETUP, LIVEACC, <volser>, <category>” command . 57

6.14 Format of the data reported by “DRSETUP, SHOW” command ........................................... 58

6.15 RETURN CODE error description of “DRSETUP” command .............................................. 65



1 Change History

Version 1.0 – Original version

Version 1.1 – Updates for TS7700 Release 3.2

Version 1.1.1 – Update the description on the automatic removal and Flash Copy on TS7720T



Version 1.4 – Updates for TS7700 Release 4.1.1. Add the new LI REQ LIVEACC.

Version 1.5 – Updates for TS7700 Release 4.1.2 (8.41.200.113) and 4.2.

• Add description about the asynchronous operation and TS7700C (cloud enablement).

Version 1.6 – Updates for TS7700 Release 5.0.

• Add description that LI REQ DRSETUP,SHOW,dr_family may show ‘MORE WRITE PROTECT

EXCLUDED CATEGORIES TO DISPLAY EXIST.’.

• Add description to support up to 128 write protect excluded categories.

• Add description about the DR test volume eject prior to shutting down DR test LPAR.

• Add new TS7770 model descriptions.

Version 1.6a – Updates to correct typo (“reject” -> “eject”).



2 Flash Copy for Disaster Recovery (DR) Testing With release 3.1, concurrent disaster recovery testing is improved with the Flash Copy for Disaster

Recovery Testing function. This enables a Disaster Recovery host to perform testing against a point in

time consistency snapshot while production operations and replication continues. With Flash Copy,

production data continues to replicate during the entire DR test and the same logical volume can be

mounted at the same time by a DR host and a production host. Used in conjunction with Selective Write

Protect for DR testing, DR test volumes can be written to and read from while production volumes are

protected from modification by the DR host. All access by a DR host to write protected production

volumes will be provided via a snapshot in time, or flash, of the logical volumes. In addition, a DR host

will continue to have read access to production original content that has since been returned to scratch.

In a real world outage, the point in time when the production environment becomes unavailable is not

predictable, thus the state of the DR cluster or clusters is unpredictable with respect to volume

consistency. Volumes may have not completed replication to a DR site or the replication for certain

volumes may not have even started. Prior to the addition of Flash Copy for DR Testing, ongoing

replication and remote grid access functionality could provide misleading DR test results. For example,

if copies are not available, a DR host mount will simply access remote content through the grid. Also, a

production volume which is modified via the production host has that modification carried over to the

DR cluster or clusters. The Flash Copy capability mimics the consistency of one or more clusters at the

DR site at time zero of a simulated disaster. Only the data consistent within the DR site at time zero is

accessible to a DR test host. Some accounts accomplish this by pulling grid links. However, most

customers require the production data to continue to replicate during the DR test so that in the event of a

true disaster, all data is replicated as designed.

During a DR test, volumes may need to be mounted from both the DR and production hosts. Prior to

Flash Copy for DR Testing, these mounts were serialized such that one host access received an IN USE

exception. This was especially painful when the true production host was the instance which fails the

mount. Flash copy allows logical volumes to be mounted in parallel to a production host and a DR host.

Production hosts may scratch volumes, reuse volumes or modify volumes but the DR TS7700 will

provide a snapshot of the logical volumes from time zero of the simulated disaster event or the start of

the DR test.

2.1 Configurations Supported

The Flash Copy for DR testing function is supported on TS7700 Grid configurations where at least one

TS7700 Flash Capable cluster exists within the DR location. The function cannot be supported under

TS7740 only grids or where a TS7740 is the only applicable DR cluster. A TS7740 may be present and

used as part of the DR test so long as at least one TS7700 Flash Capable is also present in the DR site.

2.2 Code Requirements

The Flash Copy for DR testing function was introduced with TS7700 code level release 3.1. All clusters

in the grid must be running with R3.1 or higher microcode level to enable this function.



2.3 Restrictions

There are a few restrictions for the FlashCopy function as following.

• Do not perform the DR testing using the Flash Copy function when a cluster in the grid is

currently unavailable. An attempt to enable a flash copy in this situation will result in a failure.

You can perform the DR testing using the Flash Copy function as long as all clusters in the grid

are powered on (they can be in service/offline state as long as they are powered on).

• Do not perform the DR testing using the Flash Copy function when a cluster of which grid links

are disconnected exists in the grid. Otherwise library request commands to enable write protect

mode/flash copy will fail with an internal error.

2.4 Flash Copy DR Testing Common Terms

The following terms are used throughout the document.

• Live Copy - A real time instance of a virtual tape within a Grid that can be modified and

replicated to peer clusters. This is the live instance of a volume in a cluster which is the latest

version of the volume on that cluster. If the Live Copy is also consistent relative to the grid, it

can be altered via a production host or from a DR host when it’s in the exclusion list of write

protect.

• Flash Copy - A snapshot of a live copy at time zero (see below). The content in the flash copy is

fixed and does not change even if the original copy is modified or if replication events occur. A

flash copy may not exist at a particular cluster if a live volume was not present within that cluster

at time zero. In addition, a flash copy does not imply consistency as the live copy may have been

down level with respect to the grid or simply incomplete at time zero.

• DR Family -A set of TS7700 clusters (most likely those at the DR site) which serve the purpose

of disaster recovery. One to seven clusters can be assigned to a DR family. The DR family is

used to determine which clusters should be affected by a flash request and/or write-protect

request via a Library Request (LI REQ) command. A DR Family of one TS7700 Flash Capable

cluster is supported.

• Write Protect Mode (existing function) - When Write Protect Mode is enabled on a cluster, host

commands fail if they are issued to logical devices in that cluster and attempt to modify a

volume's data or attributes and that volume is not excluded from write protect. The flash copy is

created on a cluster when it is in the write protect mode only. Also, only write protected virtual

tapes are flashed. Virtual tapes assigned to the excluded categories are not flashed.

• Time Zero - The time when the flash copy is taken within a DR family. The time zero mimics

the time when a real disaster happens. Customers can establish the time zero using a LI REQ

command.

• TS7700D - TS7720/TS7760/TS7770 Disk only (without tape)

• TS7700T - TS7720/TS7760/TS7770 Tape Attach



• TS7700C – TS7760/TS7770 Cloud Attach

• TS7700 Flash Capable - TS7700D or TS7700T or TS7700C



3 Flash Copy for DR testing operation overview This chapter provides basic steps and general considerations for using the Flash Copy function. Details

of the usage of library request (LI REQ) commands are provided later within this document.

3.1 Basic steps for Using the Flash Copy for DR Testing Function

1. Set up the write protection exclusion categories on each cluster to be added to a DR family using

the TS7700 management interface (MI). Each cluster in the DR family must have identical

exclusion categories defined. Do not enable write protect at this time from within the MI panel.

If already enabled, it must first be disabled before moving to the next step. This step can be

completed in advance of any DR test.

2. Define a DR family using a library request command. Note that the DR family is independent

from cluster families for grid replication. A DR family is viewed as the cluster or clusters that

make up a customer’s DR site or sites. Essentially, the DR family is the group of clusters

expected to be left running in the event of a production outage. This step can be completed in

advance of any DR test.

3. Enable write protection for the defined DR family via an LI REQ command. This results in all

clusters within the DR family enabling their pre-configured write protection state. This can be

completed in advance of any DR test given many accounts prefer write protect be enabled

indefinitely. Write protection enablement against a DR family must occur through the LI REQ

command which is why any previously enabled write protection from within the MI must first be

disabled as part of step 1.

4. To truly start the test or initiate a time zero snapshot, perform the Volume Flash of the volume

repository within all TS7700 Flash Capable clusters in the DR family via an LI REQ command.

When a Volume Flash occurs, all content in the TS7700 Flash Capable cluster cache repositories

within the DR Family perform snapshots creating an instant cloned point of isolation of the state

of all volumes within TS7700 Flash Capable clusters in the DR location. Any changes to

volumes from that point forward will be updated in the live file systems of the TS7700 Flash

Capable clusters, while the original at time zero volumes remain unchanged. This function is

carried out among all TS7700 Flash Capable clusters in a DR Family at the same time and is

referred to as time zero.

a. Note that only logical volumes which are in the cache repository are flashed when the LI

REQ command was issued. Even on a TS7700T/TS7700C cluster this is true. Logical

volumes are not in the cache repository but in a physical tape/cloud (a.k.a., “migrated”

logical volumes) are not flashed.

b. The new LI REQ third keyword “SELFLIVE” (refer to the chapter 6 in detail) is provided

to access the volume with the read-only mode whose volume is created by the DR host

after the time zero although the volume was not in the cache repository at the time zero.

This feature was provided by the IBM support only with R3.2 but LI REQ command

starts being available from R3.3. This feature may be especially used under the zVSE DR

test environment whose specific private category xFFFF is used in the DR test but the

category cannot be included in the write protect excluded categories because it’s shared

with the production host.



5. Now, you can bring up your DR host environment and start DR test jobs accessing the clusters

within the DR family.

• All host access will either reference the live version of the volume or the snapshot (flash

copy) version based on the volume’s category and the selective write protect exclusion

definitions. This means host mounts to write protected volumes will access the snapshot

(flashed instance) while write-protect excluded volumes will access live data. TVC selection

of snapshot data will be limited only to those clusters in the DR family. If a TS7740 cluster or

a TS7700T/TS7700C cluster exists in the DR family, its live content can be accessed only if

no TS7700 Flash Capable cluster has a snapshot instance and either the TS7740 or the

TS7700T/TS7700C is shown to have had a copy prior to time zero *and* the LI REQ

LIVECOPY usage option is set to "FAMILY" (the default is NONE). Customers will need to

activate the LIVECOPY option explicitly using a LI REQ command. If no cluster has a valid

copy at time zero within the DR family, the DR host mount will fail.

• All mounts to a write protected volume at the DR cluster will result in a DR instance of

ownership to be exchanged among peer clusters in a DR family. This will allow DR host

mounts and live production mounts to occur in parallel. The parallel DR-Host ownership

moves only among DR Family clusters and does not support advanced features such as

Ownership Takeover.

• The second keyword “LIVEACC” (refer to the chapter 6 in detail) is provided as a method to

allow a DR host to bypass the point in time write protected flash instance of a volume and

instead access the volume's live data within the grid. The override is achieved by allowing a

volume to be moved from a write protected category to a write protected excluded category.

Customers will need to issue the LI REQ LIVEACC, <volser>, <category> (<volser> is the

volser which requires Live Copy access. <category> is the category defined as “excluded

from write protect” on MI “Write Protect Mode” panel) to any cluster in the DR Family.

Using this LI REQ option, a DR host can access production data created after the flash was

initiated or before a valid copy could be made to the DR site.

• An attempt to modify a volume from a DR host which is in a write protected state will be

denied. All flash copies are read only.

• TS7700 Flash Capable clusters in the DR family will see an increase in capacity requirements

when snapshot volumes are reused in the production environment and then replicated to the

DR site. These volumes will retain two instances (one at time zero and the latest production

instance). Flash volumes which did not change throughout the DR test process do not utilize

any additional capacity within a DR TS7700 Flash Capable cluster. Customers can check

how much disk space is used for production modified flash copies via the management

interface (cache utilization page) or the LI REQ command "CACHE" response.

• Customers can check whether a virtual tape device is mounting a flash copy or a consistent

live copy via the management interface (virtual tape drives page).

6. Once the DR test completes, cleaning up the DR environment is required prior to dissolving the

flash copy. You should delete the data from the DR clusters that was written by the DR host,

otherwise the unneeded data will continue to occupy cache or tape space. The DR volumes that

are written to during the DR test, be sure to return them to scratch and ensure that the used

scratch category has an expiration time. If the DR test volumes should be ejected, they have to be

ejected prior to shutting down the DR host LPAR. The DR volumes cannot be ejected while

Flash Copy is still enabled. To eject the DR test volumes from the DR host LPAR, you need to

disable Flash Copy while Write Protect Mode is still enabled, then the volumes can be ejected

from the DR host LPAR.



7. Dissolve the flash copy of virtual tapes through a LI REQ command. Any additional flash copy

capacity is freed and given back to the TS7700 Flash Capable cluster at this time.



3.2 General Considerations for the Flash Copy for DR Testing Function

1. The set of exclusion categories must be equal across clusters within a DR family. Otherwise, the

LI REQ commands to enable write protect / enable flash copy will fail. The exclusion categories

can be defined only using the management interface. No LI REQ command to define write

protect categories is provided.

2. Be sure to add the write protection exclusion scratch categories to the list of fast ready categories

on the DR clusters. If two scratch categories are defined on the DR host, both should be included

in the write protect exclusion categories. z/OS customers should add PRIVATE/ERROR

category used by the DR host as well to the list of excluded categories (here it is required that the

production host and the DR host use different categories for output volumes.)

3. A DR family is defined using an LI REQ command. The setting is persistent.

4. There must be at least one TS7700 Flash Capable cluster in a DR family. The TS7700 Flash

Capable cluster may be tape attached. A TS7740 can be a member of a DR family. However, you

cannot create a DR family without at least one TS7700 Flash Capable cluster being present.

5. All clusters within a DR family must be online to enable flash copy within the family. Other

clusters in the grid can be offline or service state as long as they are powered on, grid links are

working.

6. Volumes belonging to a TS7740 Cluster are not flash copied. Also, volumes in migrated state on

a TS7700T/TS7700C cluster are not flash copied.

7. If the production host has connectivity to virtual tape devices on clusters included within the DR

family, the tape devices must be varied offline from the production host.

8. Category mounts, category changes (including EJECT category) and construct changes initiated

by a DR host to flash copies are not currently supported. They are failed with ERA29 mod X'10'

or function incompatible.

9. All DR host activity must be issued to device ranges contained within the TS7700 Flash Capable

clusters which are members of the defined DR family. Device ranges to any TS7740 within a

DR family must be varied offline.

10. If no cluster has a valid copy at time zero within the DR family, the DR host mount fails.

11. All volume consistency points or recovery point objective testing against emulated outages or

disasters is relative to when flash copy is enabled. All volumes not yet fully replicated to the DR

site will not be accessible by the DR host as would be in a true outage. Any remote updates to

DR site volumes will retain all updates up to that point in time. For example, if writes are

occurring to a volume contained within a DR clusters tape volume cache and this FLASH

command is issued, writes up to the point on tape in which the FLASH was issued will be

accessible to the DR host and all records on tape from that point forward will not as would be

true in an actual outage.

12. Tape Volume Cache selection of snapshot data is limited only to those TS7700 Flash Capable

clusters in the DR family.

13. Flash copies within a DR family are not replicated to peer DR family clusters, though any real

production instances or live copies will continue to replicate as configured.

14. If a TS7740 Cluster and/or a TS7700T/TS7700C Cluster exists in the DR family, its live content

can be accessed only if no TS7700 Flash Capable cluster in the DR family has a consistent

snapshot instance and the TS7740 Cluster is shown to have had a copy prior to time zero. You

must invoke an LI REQ command to enable the use of the live copy prior to starting the mount

operation. This step permits the microcode to access live content on the TS7740 Cluster and/or

the TS7700T/TS7700C Cluster in the DR family when automatic removal is expected to have



moved much of the oldest content into the TS7740. Or, when specific workloads are designed to

bypass the TS7700 Flash Capable.

15. Automatic removal processing of TS7700D won’t work on all clusters which are members of a

DR family that is currently in a snapshot state even if the setting of automatic removal is enabled.

This automatic removal behavior is same for CP0 (resident only partition) of a TS7700T cluster

whose code level is R3.2 or later. However, this has no application to CP0 of a TS7700T cluster

whose code level is at R3.2 and below and the automatic removal will or will not work

depending on its setting. Automatic removal behavior on the flash enabled DR family cluster for

each model and code level is described in the Table below. This is because removal of volume

content has no effect on the actual disk cache capacity given all content at time zero is retained.

Temporary pre-removal is suggested prior to a DR test being initiated where automatic removal

is required. Or, the lowering of automatic removal threshold on TS7700D and TS7700T clusters

is suggested to accommodate the entire test. As for how much the temporary removal should

remove or how low the threshold should be lowered, it should account for all content that will

replicate to the DR TS7700D and TS7700T clusters during the entire duration of a DR test and

for all content which will be created by the DR host during the entire DR test. The value should

also take compression into account given all content in disk cache is compressed.

TS7700D and TS7700T Automatic Removal Behavior on Flash Copy Enabled DR

Family Cluster

Code level

R3.1 R3.2 R3.3 or later

TS7700D Automatic removal does not work.

TS7700T CP0

(resident only

partition)

N/A Automatic removal

works by default. It

can be disabled by

LI REQ setting.

Automatic removal does not work.

(Note) Automatic removal does not work on TS7700C CP0 contents.

16. As described in the previous paragraph, the automatic removal policy is enabled by default for

the CP0 (resident only partition) of a TS7700T cluster whose code level is at R3.2 or below. If

the CP0 is active and Flash Copy retained content crosses the auto removal threshold, auto

removal can result in excessive removal when FlashCopy is enabled, so it is highly

recommended that auto removal be disabled during a FlashCopy DR test. It can be disabled and

then optionally re-enabled through the “SETTING,CACHE,REMOVE” LI REQ command.

Refer to the “IBM TS7700 Series z/OS Host Command Line Request User’s Guide” on IBM

techdocs website (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101091)

for general information for the library request command. 17. The amount of Tape Volume Cache (TVC) used will increase within the DR family TS7700

Flash Capable clusters during the DR testing using the Flash Copy function. The increase will be

limited to those production volumes which are reused given the reuse will result in two or more

instances of the same volume within the TS7700 Flash Capable DR family clusters. Those

volumes which are not modified during the test will require no additional disk cache capacity. A

TS7700 Flash Capable cluster within a DR location will require additional capacity to

accommodate the reuse of volumes as well as any DR test data which is created within an

excluded category. This extra capacity requirement must be considered when planning the size of

the disk cache on TS7700 Flash Capable clusters. In addition, if temporary pre-removal must

take place, additional capacity can be purchased to accommodate a higher temporary removal

threshold.



18. ‘Return to scratch’ job may take longer to complete when flash copy is enabled somewhere in

the grid. This is because a category change on a write protected logical volume after flash

creation generates token snapshot of the logical volume on clusters within the DR family where

flash copy is enabled.

19. Several issues have been reported that disabling flash copy operation failed because it took

longer than expected. This can occur when the snapshots of a large amount of virtual volumes

need to be deleted while disabling flash copy. When this occurs, the LI REQ command to disable

the flash will time out. To avoid the issue, enabling/disabling write protect/flash copy operations

(WP/FLASH/DOALL, ENABLE/DISABLE) are now executed asynchronously in the

background. The asynchronous operation is supported once all clusters in the grid are at R4.1.2

(8.41.200.113)/R4.2 (8.42.x.x) or above.

20. At the code level of 8.50.x.x or above, up to 128 write protect excluded categories can be defined.

It is applicable only when all clusters in the Grid are at 8.50.x.x or above. Otherwise, up to 32

write protect excluded categories are still only usable.

21. Once the DR test completes, Flash Copy needs to be disabled while Write Protect Mode is still

enabled to eject the unneeded DR test volumes if required. The volume eject is ejected while

Flash Copy is still enabled.



4 Operational Details

4.1 Preparation

Before setting up the actual DR testing environment with FlashCopy, make sure that all preparatory

activities have been completed. These activities can be completed far in advance of an actual test and in

many cases left in a configured state.

1. Determine the name of the DR family which you’re going to create for the DR test. Only one DR

family can be defined in a grid. Only alphanumeric characters can be acceptable as the name. No

space must be included in the name. The maximum length of the name is 8 characters.

2. Determine what clusters in the grid are to be included in the DR family. IDs of clusters to be

included in the DR family are required when you define the DR family in the grid (described in

details in later within this document)

3. Determine write protect excluded categories to be defined for the DR test. For each z/OS system

plex attached to the DR Family clusters, the recommendation is to have each system plex's unique

set of MEDIA1, MEDIA2, PRIVATE and ERROR categories defined within each DR cluster's

exclusion category list. The PRIVATE, MEDIA2 and MEDIA1 (if used) are most important. Not

adding ERROR will only prevent hosts' ability to move a volume from ERROR back to

PRIVATE. Excluding both MEDIA1 and MEDIA2 is required to accommodate workloads that

can target either SCRATCH category. It's also recommended to include both MEDIA1 and

MEDIA2 even if only one of the scratch categories are used within your environment. This is

because any workload that does not explicitly use a defined data class with a defined scratch

media type will result in mount requests that target both scratch categories. In this case, the

TS7700 will fail the mount request if both category definitions are not excluded. The exclusion

of the ERROR category can be optional. A volume can be moved to the ERROR category by

z/OS, but any user attempt to move it out of the ERROR category from a DR attached host will

fail unless the ERROR category is also defined.

4.2 Defining Write Protect Exclusion Categories

The Management Interface (MI) is used to define the logical volume categories that are excluded from

write protection and thus can be created, modified or have their attributes changed from a DR host.

Logical Volumes whose categories are not listed cannot be altered by the DR host(s). The Write Protect

Exclusion categories need to be set up prior to starting the DR test. The MI panel for defining these

categories is accessed by selecting (Settings) => Cluster Settings => Write Protect Mode. In the

example below categories 0012, 001E, and 001F have been defined as the categories that will be used by

the DR host. Be sure to set up the same excluded from write protect categories on all clusters in the DR

family. The enabling of the DR test will fail when all clusters in the DR family do not have the same

exclusion categories defined.

Once the write protection command is executed, you are not able to change the settings of the write

exclusion categories. If this is needed, the write protection (and the flash copy if enabled) needs to be

disabled first.

The “Ignore fast ready characteristics of write protected categories” option informs the DR cluster that

production logical volumes defined as fast-ready (scratch) should be treated as private volumes. This

means they will be presented to the DR host in their entirety in spite of them being set to a scratch

category. This is only applicable to non-flash instances of the data such as when a TS7740 live copy

must be accessed, which was previously returned to scratch and remains there. Any flash instances



returned to scratch after time zero will always be accessible even when the production host reuses those

volumes. Any fast-ready categories that are included in the “Write Protect Mode Exclusion Categories”

list will always be treated as scratch categories even when this option is enabled.

The MI panel below also allows you to enable or disable Write Protect Mode. With Release 3.1 a new

Library Request command (DRSETUP) is added that provides an alternate method to enable and disable

the Write Protect mode. The MI panel can only enable or disable the standard write protect mode which

is incompatible with the flash copy capability provided in the R3.1 release. It is required that the

Library Request command be used to enable and disable write protect mode when used for the purpose

of flash copy for DR testing. When flash copy for DR testing isn’t going to be used, the LI REQ method

can be used as an alternative to using the MI panel method as the resulting write protection behavior is

the same. It’s only when flash copy is going to be used where the two enablement methods have

underlying differences in which the LI REQ enabled method is a pre-requisite to flash copy. This is

discussed in a subsequent section.

Figure 1 - Write Protect Mode Exclusion Categories

Be sure to add the scratch categories to be used by the DR host, (0012 in the example above) to the list

of scratch categories on all of the DR clusters. This panel is accessed on the MI by selecting

(Virtual) => Categories.

Notice that the Write Protect Mode is currently left disabled given it will be enabled via the LI REQ

operation in a later step.

Figure 2 - Scratch Categories



4.3 Defining a Disaster Recovery Family

The Library Request Command “DRSETUP” is used to define which clusters are in a Disaster Recovery

(DR) family. Only one DR family can be set up in a grid. The DR families must be set up prior to the

actual DR testing using the Flash Copy function. Those clusters within a grid which are expected to

remain running in the event of a production site outage should be defined within the DR family. There

are three Library Request variants of the DRSETUP command used to manage DR families which are

shown below.

Refer to Appendix A for detailed format of the data reported by all the DRSETUP variants.

Refer to the “IBM® TS7700 Series z/OS Host Command Line Request User's Guide” on techdocs for

general information for the library request command.

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101091

4.3.1 Create a DR family or add a cluster to an existing DR family

You can create a DR family or add a cluster to an existing DR family using the “ADD” keyword. The

syntax of the command is: LI REQ, <clib_name>, DRSETUP, <family_name>, ADD, <cluster id>

Where:

⚫ <clib_name> is the composite library name of the TS7700 grid

⚫ <family_name> is the eight character alphanumeric name for this family

⚫ <cluster id> is the cluster index number 0-7

Note:

⚫ The DR family is created the first time the DRSETUP, ADD command is issued when no family

name of any value already exists.

⚫ The DR family must be created using a TS7700 Flash Capable cluster. A family cannot be

created using the ID of a TS7740 cluster. A TS7740 cluster can be added to an existing family

once at least one TS7700 Flash Capable cluster exists in the existing family definition. The

TS7700 Flash Capable cluster may be tape attached.

• You cannot add a cluster to a DR family when Write Protect is enabled.

• You cannot add a cluster to a DR family when Flash Copy is enabled.

• You cannot add a cluster to a DR family which is not in an online state.

Following is an example of the command response when a DR family is newly created:

CBR1280I Library VTSCOMP1 request.

Keywords: DRSETUP,DRFAM001,ADD,1

----------------------------------------------------------------------

DRSETUP V1 .0

DR FAMILY DRFAM001 WAS NEWLY CREATED

CLUSTER 1 WAS ADDED TO DR FAMILY DRFAM001 SUCCESSFULLY

Following is an example of the command response when a cluster is added to an existing DR family





Keywords: DRSETUP,DRFAM001,ADD,3

----------------------------------------------------------------------

DRSETUP V1 .0

CLUSTER 3 WAS ADDED TO DR FAMILY DRFAM001 SUCCESSFULLY

4.3.2 Remove a cluster from a DR family

You can remove a cluster from a DR family using the “REMOVE” keyword. The syntax of the

command is: LI REQ, <clib_name>, DRSETUP, <family_name>, REMOVE, <cluster id>

Where:



⚫ <cluster id> is the cluster index number 0-7

Note:

⚫ The DR family definition is automatically deleted when the last member cluster is removed from

the DR family. You cannot keep a DR family definition with no member cluster. Once the

family is completely removed, a new family definition with the same or different name can be

generated with the ADD keyword.

⚫ The DR family must always include a TS7700 Flash Capable cluster. The last cluster to be

removed from the family must be a TS7700 Flash Capable cluster. The TS7700 Flash Capable

cluster may be tape attached. You cannot have a DR family which includes only a TS7740

cluster.

⚫ You cannot remove a cluster from a DR family where Write Protect is enabled.

⚫ You cannot remove a cluster from a DR family where Flash Copy is enabled.

Following is an example of the command response when a cluster is removed from a DR family:


Keywords: DRSETUP,DRFAM001,REMOVE,2

----------------------------------------------------------------------

DRSETUP V1 .0

CLUSTER 1 WAS REMOVED FROM DR FAMILY DRFAM001 SUCCESSFULLY

Following is an example of the command response when the last member cluster is removed from a DR

family:


Keywords: DRSETUP,DRFAM001,REMOVE,1

----------------------------------------------------------------------

DRSETUP V1 .0

CLUSTER 1 WAS REMOVED FROM DR FAMILY DRFAM001 SUCCESSFULLY

DR FAMILY DRFAM001 WAS DELETED BECAUSE NO MEMBER EXISTS



4.3.3 View status of a DR family

You can view the current status of a DR family using the “SHOW” keyword. The syntax of the

command is: LI REQ, <clib_name>, DRSETUP, SHOW [,<family_name>]

Where:


⚫ <family_name> is the eight character alphanumeric name for the family to be shown. This is

optional. If no family name is specified, then the summary view is displayed instead (currently

only one DR family is supported).

Following is an example of the command response when the SHOW command is issued to R4.1.1 or

below cluster to display the status of a DR family which includes two clusters:


Keywords: DRSETUP,SHOW,DRFAM001

----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW

ID FAM NAME FLASH FLASH TIME (UTC) LCOPY MEMBER CLUSTERS

1 DRFAM001 INACTIVE N/A NONE 0 1 - - - - - -

----------------------------------------------------------------------

FAMILY MEMBER WRITE PROTECT STATUS VIEW

CLUSTER WRT-PROTECT EXCATS-NUM IGNORE-FR ENABLED-BY SELFLIVE

CLUSTER0 DISABLED 4 TRUE N/A N


----------------------------------------------------------------------

CATEGORIES EXCLUDED FROM WRITE PROTECTION WITHIN DR FAMILY DRFAM001

CLUSTER ACTIVE EXCLUDED CATEGORIES

CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E

If R4.1.2 or R4.2 cluster receives the request, following is an example of the command response:



----------------------------------------------------------------------

DRSETUP V2 .1

DR FAMILY VIEW



----------------------------------------------------------------------





----------------------------------------------------------------------



CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E

----------------------------------------------------------------------

DRSETUP CURRENT ACTIVE OPERATION STATUS

NO ACTIVE DRSETUP FLC/WP OP IS RUNNING



If R5.0 cluster receives the request, the following is an example of the command response:



----------------------------------------------------------------------

DRSETUP V3 .0

DR FAMILY VIEW


1 DRFAM INACTIVE N/A FAMILY 0 - 2 - - - - 7

----------------------------------------------------------------------



CLUSTER0 DISABLED 111 FALSE N/A N

CLUSTER2 DISABLED 128 FALSE N/A N


----------------------------------------------------------------------

CATEGORIES EXCLUDED FROM WRITE PROTECTION WITHIN DR FAMILY DRFAM


CLUSTER0 0002 0003 0004 0005 0006 0007 0008 0009 1001 1002 1003

1004 1005 1006 1007 1008 1009 2001 2002 2003 2004 2005

2006 2007 2008 D0FF 1000 2000 3000 100A 100B 100C 100D

100F 100E 2009 200A 200B 200D 200C 200E 200F 7000 7001

7002 7003 7004 7005 7006 7007 7008 7009 700B 700C 700D

700E 700F 8000 8001 8002 8003 8004 8005 8006 8007 8008

8009 800A 800B 800C 800D 800E 800F 9000 9001 9002 9003

9005 9006 9007 9008 9009 900A 900B 900C 900D 900E 900F

A000 A001 A002 A003 A004 A005 A006 A007 A008 A009 A00A

A00B A00C A00D A00E A00F B000 B001 B002 B003 B004 B005

B006

CLUSTER2 A000 A001 A002 A003 A004 A005 A006 A007 A008 A009 A00A

A00B A00C A00D A00E A00F 1000 1001 1002 1003 1004 1005

1006 1007 1008 1009 100A 100B 100C 100D 100E 100F E000

E001 E002 E003 E004 E005 E006 E007 E008 E009 E00A E00B

E00C E00D E00E E00F 7000 7001 7002 7003 7004 7005 7006

7007 7008 7009 700A 700B 700C 700D 700E 700F 8000 8001

8002 8003 8004 8005 8006 8007 8008 8009 800A 800B 800C

800D 800E 800F 2000 2001 2002 2003 2004 2005 2006 2007

2008 2009 200A 200B 200C 200D 200E 200F C000 C001 C002

C003 C004 C005 C006 C007 C008 C009 C00A C00B C00C C00D

C00E C00F D000 D001 D002 D003 D004 D005 D006 D007 D008

D009 D00A D00B D00C D00D D00E D00F

CLUSTER7 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A

100B 100C 100D 100E 100F 2000 2001 2002 2003 2004 2005

2006 2007 2008 2009 200A 200B 200C 200D 200E 200F 7000

7001 7002 7003 7004 7005 7006 7007 7008 7009 700A 700B

700C 700D 700E 700F 8000 8001 8002 8003 8004 8005 8006

8007 8008 8009 800A 800B 800C 800D 800E 800F A000 A001

A002 A003 A004 A005 A006 A007 A008 A009 A00A A00B A00C

A00D A00E A00F C000 C001 C002 C003 C004 C005 C006 C007

C008 C009 C00A C00B C00C C00D C00E C00F D000 D001 D002

D003 D004 D005 D006 D007 D008 D009 D00A D00B D00C D00D

MORE WRITE PROTECT EXCLUDED CATEGORIES TO DISPLAY EXIST.

----------------------------------------------------------------------



The “DR FAMILY VIEW” displays the summary status of the specified DR family. The fields

displayed in the line are as follows:



ID: The ID of the DR family. Currently only one DR family can be defined in a grid. Therefore, the

ID of the DR family is always “1”.

FAM NAME: The name of the DR Family

FLASH: “ACTIVE” when FlashCopy is enabled within the DR family. “INACTIVE” when

FlashCopy is not enabled.

FLASH TIME: The UTC timestamp when the FlashCopy was enabled. “N/A” when the FlashCopy is

not enabled.

LCOPY: “FAMILY” when live copy usage is allowed within the DR family. “NONE” when live copy

usage allowed.

MEMBER CLUSTERS: IDs of clusters which are included in the DR family. Clusters not included in

the DR family or non-existing clusters are displayed with ‘-‘.

The “DR FAMILY MEMBER WRITE PROTECT STATUS VIEW” displays write protect status of

each cluster in the DR Family. The fields displayed in each line are as follows:

CLUSTER: The cluster included in the DR family.

WRT-PROTECT: “ENABLED” when Write Protect is enabled on the cluster. “DISABLED” when

Write Protect is not enabled.

EXCATS-NUM: The number of write protect exclusion categories defined on the cluster.

IGNORE-FR: “TRUE” when the “Ignore fast ready characteristics of write protected categories”

option is enabled. “FALSE” when the option is not enabled. This option can be modified only through

the Management Interface when write protection is disabled.

ENABLED-BY: “LIREQ” when Write Protect is enabled via the DRSETUP LI REQ command. “MI”

when Write Protect is enabled via the Management Interface.

You’ll see the write protect exclusion categories defined on clusters included in the DR family. If the set

of excluded categories does not match across clusters within the DR family and flash copy for DR

testing is going to be used, you should utilize the MI and modify the appropriate clusters so that all

clusters in the DR family are in agreement. If R5.0 cluster receives the request and there are too many

write protect exclusion categories to be shown within 50 lines of whole output, it shows “MORE

WRITE PROTECT EXCLUDED CATEGORIES TO DISPLAY EXIST.” at end of the write protect

exclusion categories list. In that case, you need to check all defined write protect exclusion categories

from MI “Write Protect Mode” page on each cluster if you would like to check all of them.

At the end of the “DRSETUP, SHOW” command response, the “DRSETUP CURRENT ACTIVE

OPERATION STATUS” displays the active asynchronous DRSETUP command status if R4.1.2 or

above cluster receives the request. If the grid is a mixed code configuration with R4.1.2or above and

8.4.1 or below code levels, R4.1.2 or above cluster still returns the asynchronous DRSETUP command

status but it always shows “ASYNC DRSETUP OP IS NOT SUPPORTED”.

The third keyword for the SHOW command is optional. You can issue the “DRSETUP, SHOW”

command without family name.



Following is an example of the command response when the SHOW command is issued to R4.1.1 or

below cluster without family name.


Keywords: DRSETUP,SHOW

----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW


1 DRFAM001 INACTIVE N/A FAMILY - 1 2 - - - - -

NA N/A INACTIVE N/A NONE - - - - - - - -







----------------------------------------------------------------------

FAMILY MEMBER WRITE PROTECT STATUS SUMMARY VIEW

CLUSTER STATUS

ID FAM NAME C0 C1 C2 C3 C4 C5 C6 C7

1 DRFAM001 -- WP WP -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

If R4.1.2/4.2 cluster receives the request, following is an example of the command response:



----------------------------------------------------------------------

DRSETUP V2 .1

DR FAMILY VIEW










----------------------------------------------------------------------


CLUSTER STATUS


1 DRFAM001 -- WP WP -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

----------------------------------------------------------------------





If R5.0 cluster receives the request, following is an example of the command response:



----------------------------------------------------------------------

DRSETUP V3 .0

DR FAMILY VIEW










----------------------------------------------------------------------


CLUSTER STATUS


1 DRFAM001 -- WP WP -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

----------------------------------------------------------------------



The “DR FAMILY VIEW” displays the summary status of the specified DR family as described in

previous page. Although the response provides a total of eight rows only the first row will contain valid

information. The other rows are reserved for future use.

The “FAMILY MEMBER WRITE PROTECT STATUS SUMMARY VIEW” displays the summary of

write protect status of clusters included in each family. Although this response also provides a total of

eight rows only the first row will contain valid information. The other rows are reserved for future use.

If the cluster is in write protect mode, it is shown as “WR” in the view.

At the end of the “DRSETUP, SHOW” command response, the “DRSETUP CURRENT ACTIVE

OPERATION STATUS” displays the active asynchronous DRSETUP command status if R4.1.2/4.2

cluster receives the request. If the grid is a mixed code configuration with R4.1.2/4.2 and R4.1.1 or

below code levels, R4.1.2/4.2 cluster still returns the asynchronous DRSETUP command status but it

always shows “ASYNC DRSETUP OP IS NOT SUPPORTED”.



4.4 Initiating the Flash Copy for DR Testing

With the addition of Flash Copy for DR testing, there are now two main steps when initiating or

concluding a DR test. This is enabling/disabling Write Protect mode and enabling/disabling the Flash

Copy. The Write Protect mode prevents a DR host from modifying production volumes. This capability

existed before R3.1. The Flash Copy defines a time-zero where any changes to logical volumes after that

time are not seen by the DR host.

4.4.1 Enable the Write Protect Mode and the Flash Copy

You can enable the Write Protect and Flash Copy using the LI REQ command either separately or in one

command.

The two operations must be issued sequentially where the “WP” keyword to enable the Write Protect

Mode must be used before “FLASH” keyword to enable the Flash Copy. The “write protection can be

enabled ahead of any testing. As many accounts do, it can be left enabled indefinitely. One fact of

leaving write protection enabled indefinitely is that any true outage where production actually fails over

to the DR location would first require the write protection mode be disabled through the LI REQ

command. This disablement would need to occur prior to running production at the DR location

allowing true production volumes and their associated attributes to be modified.

The syntax of the command using “WP” keyword is following: LI REQ, <clib_name>, DRSETUP, <family_name>, WP, ENABLE

Where:



Note:

• You cannot enable the Write Protect Mode if it is already enabled on a cluster included in the

DR family via MI or a previous LI REQ invocation.

• You cannot enable the write protect mode if the write protect exclusion categories don’t match

across all clusters included in the DR family definition.

• Write Protection can be enabled far in advance to the actual DR test.

Following is an example of the command response from R8.41 or below cluster when the Write Protect

Mode is enabled:


Keywords: DRSETUP,DRFAM001,WP,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .0

WRITE PROTECT STATUS HAS BEEN ENABLED SUCCESSFULLY

If the request is received by R4.1.2/4.2 cluster and the entire Grid is at R4.1.2/4.2, it is handled

asynchronously and following is an example of the command response:


Keywords: DRSETUP,DRFAM001,WP,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .0

DRSETUP DRFAM WP ENABLE HAS STARTED SUCCESSFULLY



The “DRSETUP, SHOW, <family>” command now provides a response like following:



----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW



----------------------------------------------------------------------



CLUSTER0 ENABLED 4 TRUE LIREQ N


----------------------------------------------------------------------



CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E

Now that write protection is enabled through the LI REQ command or was previously enabled, you can

issue the command to enable the Flash Copy which will mimic the time zero of a production site outage.

The syntax of the command using “FLASH,ENABLE” keyword is following: LI REQ, <clib_name>, DRSETUP, <family_name>, FLASH, ENABLE

Where:



Note:

• You cannot enable the FlashCopy if the Write Protect Mode is not yet enabled via the LI REQ

enablement method within the DR family.

• All volume consistency points or recovery point objective testing against emulated outages or

disasters is relative to when this command is issued. All volumes not yet fully replicated to the

DR site will not be accessible by the DR host as would be in a true outage. Any remote updates

to DR site volumes will retain all updates up to that point in time. For example, if writes are

occurring to a volume contained within a DR clusters tape volume cache and this FLASH

command is issued, writes up to the point on tape in which the FLASH was issued will be

accessible to the DR host and all records on tape from that point forward will not as would be

true in an actual outage.

• The command may take a few minutes to complete. You should verify the command response

described below is recorded in the SYSLOG before you proceed to next step.

Following is an example of the command response from R4.1.1 or below cluster when the Flash Copy is

enabled:


Keywords: DRSETUP,DRFAM001,FLASH,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .0

FLASH COPY HAS BEEN ENABLED SUCCESSFULLY






Keywords: DRSETUP,DRFAM001,FLASH,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .0

DRSETUP DRFAM FLASH ENABLE HAS STARTED SUCCESSFULLY

You can verify if the Flash Copy and/or the Write Protect mode are enabled using the “DRSETUP,

SHOW” command. The “DRSETUP, SHOW, <family>” command now provides a response like

following:



----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW


1 DRFAM001 ACTIVE 2013-09-18-05.32.55 NONE 0 1 - - - - - -

----------------------------------------------------------------------





----------------------------------------------------------------------



CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E

An alternative option is to enable both the Write Protect Mode and the Flash Copy at the same time

using the “DOALL” keyword. This method is provided for those accounts which do not require write

protection be enabled in advance of the time zero snapshot. The syntax of the command using the

“DOALL” keyword is as following: LI REQ, <clib_name>, DRSETUP, <family_name>, DOALL, ENABLE

Where:



Following is an example of the command response from R4.1.1 or below cluster when the Write Protect

Mode and the Flash Copy are enabled with one command:


Keywords: DRSETUP,DRFAM001,DOALL,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .0

WRITE PROTECT STATUS HAS BEEN ENABLED SUCCESSFULLY

FLASH COPY HAS BEEN CREATED SUCCESSFULLY






Keywords: DRSETUP,DRFAM001,DOALL,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .0

DRSETUP DRFAM DOALL ENABLE HAS STARTED SUCCESSFULLY

4.4.2 Disable the Flash Copy and the Write Protect Mode

When DR testing has completed and the snapshot is no longer needed, the disabling of Flash Copy and

optionally the Write Protect mode can occur. The Flash Copy can be disabled by itself using the FLASH

and DISABLE keywords. The Write Protect mode, which can be left enabled, is disabled using the WP

and DISABLE keywords. If DOALL was used to enable both write protect and the flash copy, the two

modes can be disabled independently.

If the DR host shares a tape management database or control data set with other hosts attached to the

Grid, take care not to disable the Write Protect on the DR cluster until after the DR host has completely

finished the return to scratch processing (with DFSMSrmm this takes two consecutive invocations of

EXPROC). Otherwise if the Write Protect is disabled before return to scratch is complete, it is possible

that the DR host may return volumes to scratch that belong to other hosts.

If the DR test volumes need to be ejected prior to shutting down the DR LPARs, they have to be done

after disabling Flash Copy while Write Protect Mode is still enabled. Ejecting the volumes while Flash

Copy is enabled is not allowed.

The syntax of the command using “FLASH,DISABLE” keywords is following: LI REQ, <clib_name>, DRSETUP, <family_name>, FLASH, DISABLE

Where:



Note:

• You cannot disable the Flash Copy while a virtual tape device is mounting a flash copy volume.

You need to demount the volume before disabling the Flash Copy. If the DR host is no longer

available and therefore a demount is not possible, the virtual drives page of the MI can be used

to force a demount of the mounted volume.

Following is an example of the command response from R8.41 or below cluster when the Flash Copy is

disabled.


Keywords: DRSETUP,DRFAM001,FLASH,DISABLE

----------------------------------------------------------------------

DRSETUP V1 .0

FLASH COPY HAS BEEN DELETED SUCCESSFULLY





----------------------------------------------------------------------

DRSETUP V1 .0

DRSETUP DRFAM FLASH DISABLE HAS STARTED SUCCESSFULLY



The syntax of the command using “WP,DISABLE” keywords is following: LI REQ, <clib_name>, DRSETUP, <family_name>, WP, DISABLE

Where:



Note:

• You cannot disable the Write Protect Mode while the Flash Copy is enabled in the DR family.

You must disable the Flash Copy first.

Following is an example of the command response from R4.1.1 or below cluster when the Flash Copy is

disabled.



----------------------------------------------------------------------

DRSETUP V1 .0

WRITE PROTECT STATUS HAS BEEN DISABLED SUCCESSFULLY





----------------------------------------------------------------------

DRSETUP V1 .0

DRSETUP DRFAM WP DISABLE HAS STARTED SUCCESSFULLY

You can verify if the Flash Copy and/or the Write Protect mode are disabled using the “DRSETUP,

SHOW” command. The SHOW command will provide an output like following when both the Flash

Copy and the Write Protect Mode are disabled.



----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW



----------------------------------------------------------------------





----------------------------------------------------------------------



CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E

Both the Write Protect Mode and the Flash Copy can be disabled simultaneously using the DOALL and

DISABLE keywords. The syntax of the command using these two keywords is following: LI REQ, <clib_name>, DRSETUP, <family_name>, DOALL, DISABLE



Where:



Note:

⚫ The command will disable write protect mode within the family and complete successfully if

Flash Copy is not enabled yet with the family.

Following is an example of the command response from R4.1.1 or below cluster when the Write Protect

Mode and the Flash Copy are disabled with one command:


Keywords: DRSETUP,DRFAM001,DOALL,DISABLE

----------------------------------------------------------------------

DRSETUP V1 .0

WRITE PROTECT STATUS HAS BEEN DISABLED SUCCESSFULLY

FLASH COPY HAS BEEN DELETED SUCCESSFULLY




Keywords: DRSETUP,DRFAM001,DOALL,DISABLE

----------------------------------------------------------------------

DRSETUP V1 .0

DRSETUP DRFAM DOALL DISABLE HAS STARTED SUCCESSFULLY

4.4.3 Check the asynchronous request status

When the asynchronous request has been issued successfully, the progress and status can be checked by

LI REQ, DRSETUP, SHOW command as well as the operator message.

4.4.3.1 DRSETUP, SHOW output

When an asynchronous request is issued successfully, and the operation is still running in the

background, following is an example of LI REQ, DRSETUP, SHOW response:



----------------------------------------------------------------------

DRSETUP V2 .1

DR FAMILY VIEW










----------------------------------------------------------------------


CLUSTER STATUS




1 DRFAM001 -- WP WP -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

NA N/A -- -- -- -- -- -- -- --

----------------------------------------------------------------------


DOALL ENABLE STARTED AT 03/12 06:41:40 IS RUNNING

While the operation is still running in the background, the last line should show the current status with

the following format:

[Asynchronous operation] STARTED AT [Started time] IS RUNNING

[Asynchronous operation] could be either:

⚫ “WP ENABLE”

⚫ “WP DISABLE”

⚫ “FLASH ENABLE”

⚫ “FLASH DISABLE”

⚫ “DOALL ENABLE”

⚫ “DOALL DISABLE”

[Started time] provides the timestamp when that active asynchronous operation started in CUT.

Once the asynchronous request has succeeded or failed, it’s change to:


If an unexpected error occurs internally and the current active asynchronous operation status can’t be

checked, the text below is provided and IBM support personnel should be called:

ACTIVE DRSETUP OP CANNOT BE DETERMINED

4.4.3.2 Operator messages

The operator message is surfaced when the asynchronous request has completed (either succeeded or

failed). To identify if the asynchronous request has succeeded or failed, the operator message needs to

be monitored. The following operator message texts are used to report the final asynchronous operation

status:

[The asynchronous operation has successfully completed]

➢ G0062 DRSETUP %s HAS SUCCESSFULLY COMPLETED

%s: The submitted asynchronous request:

⚫ “WP ENABLE”

⚫ “WP DISABLE”

⚫ “FLASH ENABLE”

⚫ “FLASH DISABLE”

⚫ “DOALL ENABLE”

⚫ “DOALL DISABLE”

[The asynchronous operation has failed]

➢ G0063 DRSETUP FAILED. DR FAMILY %s IS EMPTY, CAN NOT PROCEED

%s: DR family name specified in the failed request.



This message is surfaced when the request specified a DR family name which does not exist.

➢ G0064 DRSETUP FAILED. CANNOT PERFORM THE REQUEST. A CLUSTER IN THE DR

FAMILY IS NOT ONLINE

This message is surfaced when some of the DR family member are not online.

➢ G0065 DRSETUP FAILED. WRITE PROTECT IS ALREADY ENABLED FROM THE

MANAGEMENT INTERFACE

This message is surfaced when the Write Protect mode was already enabled from Management

Interface (MI) but it’s attempted to enable the Write Protect mode from LI REQ.

➢ G0066 DRSETUP FAILED. WRITE PROTECT IS ALREADY ENABLED

This message is surfaced when the Write Protect mode is already enabled from LI REQ but it’s

attempted to enable the Write Protect mode from LI REQ again.

➢ G0067 DRSETUP FAILED. WRITE PROTECT IS NOT ENABLED"

This message is surfaced when the Write Protect mode is not enabled but LI REQ has been issued

to disable the Write Protect mode by WP/DOALL,DISABLE request or enable the Flash copy by

FLASH/DOALL,ENABLE request.

➢ G0068 DRSETUP FAILED. WRITE PROTECT EXCLUDED CATEGORIES NOT IN SYNC

WITHIN THE DR FAMILY

This message is surfaced when the Write Protect excluded categories are not synchronized in the

DR family.

➢ G0069 DRSETUP FAILED. CANNOT DISABLE WRITE PROTECT MODE. FLASH COPY

EXISTS.

This message is surfaced when the Flash copy is already enabled but LI REQ has been issued to

enable the Flash copy again by FLASH/DOALL,ENABLE request.

➢ G0070 DRSETUP FAILED. AN ERROR OCCURED PROCESSING THE HOST REQUEST.

RETURN CODE = %s

%s: Internal error code

This message is surfaced when an unexpected internal error has occurred. Please call IBM support

when this message is surfaced to investigate the failure reason by IBM support personnel.

➢ G0071 DRSETUP FAILED. VPD UPDATE FAILED

This message is surfaced when the vital product data (VPD) related to DRSETUP operation has

failed to be updated.

➢ G0072 DRSETUP FAILED. VPD SYNCHRONIZATION FAILED

This message is surfaced when the vital product data (VPD) related to DRSETUP operation has

failed to be synchronized among the grid.

➢ G0073 DRSETUP FAILED. NO FLASH COPY EXISTS IN DR FAMILY %s

%s: DR family name specified in the failed request

This message is surfaced when LI REQ, DRSETUP,FLASH,DISABLE has been issued but the

Flash Copy is no longer enabled.

➢ G0074 DRSETUP FAILED. CANNOT DISABLE FLASH COPY. FLASH COPY VOLUME IS

STILL MOUNTED

This message is surfaced when any flash copy volume is still mounted but LI REQ,

FLASH/DOALL,DISABLE has been issued.

➢ G0075 DRSETUP FAILED. FLASH COPY OPERATION FAILED

This message is surfaced when deleting/creating the snapshots has failed.

➢ G0076 DRSETUP RESETTING ASYNCHRONOUS OPERATION FLAG HAS FAILED

This message is surfaced when an internal error occurs and the asynchronous operation status is not

reset properly after the asynchronous operation has successfully completed.

➢ G0077 DRSETUP FAILED. CANNOT ENABLE DOALL/FLASH. FLASH COPY ALREADY

EXISTS



This message is surfaced when Flash Copy is already enabled but LI REQ, FLASH/DOALL,

ENABLE has been issued.



4.5 LIVECOPY Option

If a TS7740 cluster or a TS7700T/TS7700C cluster is present within a DR family, an option is available

allowing the “live” copy on the TS7740/TS7700T cluster to be accessed so long as it completed

replication or was otherwise consistent within the TS7740/TS7700T/TS7700C prior to time zero of the

DR test. This is applicable if the TS7700 Flash Capable cluster removed its copy or if the

TS7740/TS7700T/TS7700C was the only target of a volume.

The option is disabled by default. You must explicitly enable the option using the library request

command with “LIVECOPY” keyword as needed.

The syntax of the command is following: LI REQ, <clib_name>, DRSETUP, <family_name>, LIVECOPY, FAMILY

Where:



Note:

• You can use the option only if TS7740 cluster or TS7700T/TS7700C cluster is included in the

DR family. You cannot use the option if the DR family consists of only TS7700D clusters.

• Live copies contained outside of the DR family are not accessible as part of this option.

Following is an example of the command response when the live copy usage is allowed.


Keywords: DRSETUP,DRFAM001,LIVECOPY,FAMILY

----------------------------------------------------------------------

DRSETUP V1 .0

LIVE COPY USAGE HAS BEEN UPDATED TO FAMILY SUCCESSFULLY

You can verify if the current LIVECOPY setting using the “DRSETUP, SHOW” command. The SHOW

command will provide an output like following when the live copy usage is allowed.



----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW


1 DRFAM001 INACTIVE N/A FAMILY 0 1 - - - - - -

----------------------------------------------------------------------





----------------------------------------------------------------------



CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E



You can disable the live copy option using the library request command with “LIVECOPY,NONE”

keywords. The syntax of the command using the keywords is following: LI REQ, <clib_name>, DRSETUP, <family_name>, LIVECOPY, NONE

Where:



Following is an example of the command response when the live copy usage is disabled.


Keywords: DRSETUP,DRFAM001,LIVECOPY,FAMILY

----------------------------------------------------------------------

DRSETUP V1 .0

LIVE COPY USAGE HAS BEEN UPDATED TO NONE SUCCESSFULLY



4.6 SELFLIVE Option

Under zVSE host environment, the specific private category xFFFF is used from the zVSE DR host in

the DR test job. The category may be shared with the production host and it cannot be included in the

write protect excluded categories with the DR host. When the zVSE DR host attempts a scratch mount

whose scratch category is in the write protect excluded categories, writes DR test data, changes the

category to xFFFF and demount the volume during the DR test with Flash Copy, the volume is no longer

accessible because no time zero snapshot of the volume exists and the category is not in the write protect

excluded categories. This option allows the access to the live copy volume as read-only which was

created by the DR host after the time zero. Thus, the zVSE DR host is able to mount and read the

volume described above by using this option. This feature was used to be provided by the IBM support

with R3.2 code level (R3.2 PGA1 or above) but LI REQ command option is available from R3.3. When

the code of the machine is updated from R3.2 PGA1 to R3.3, the feature set by the IBM support will be

automatically inherited.

The option is set for the each distributed library in the DR family and the command may need to be

issued to the clusters in the DR family based off of the DR host configuration.

The option is disabled by default. You must explicitly enable the option using the library request

command with “SELFLIVE” keyword as needed.

The syntax of the command to enable SELFLVE option is following: LI REQ, <dlib_name>, DRSETUP, <family_name>, SELFLIVE, ENABLE

Where:


⚫ <dlib_name> is the distributed library name of the cluster for this DR family

Note:

• If the DR family consists of the multiple clusters and the DR host may issue the mount requests

to the clusters, this option needs to be set to all clusters in the DR family.

Following is an example of the command response when the SELFLIVE usage is enabled.

CBR1280I Library VTSDIST1 request.

Keywords: DRSETUP,DRFAM001,SELFLIVE,ENABLE

----------------------------------------------------------------------

DRSETUP V1 .1

SELFLIVE USAGE HAS BEEN ENABLED

You can verify if the current SELFLIVE setting using the “DRSETUP, SHOW” command. The SHOW

command will provide an output like following when the SELFLIVE usage is allowed.



----------------------------------------------------------------------

DRSETUP V1 .1

DR FAMILY VIEW


1 DRFAM001 INACTIVE N/A FAMILY 0 1 - - - - - -

----------------------------------------------------------------------






CLUSTER1 DISABLED 4 TRUE N/A R

----------------------------------------------------------------------



CLUSTER0 0011 0012 001F 001E

CLUSTER1 0011 0012 001F 001E

In SELFLIVE column:

‘N’ means SELFLIVE setting is disabled.

‘R’ means SELFLIVE setting is enabled.

Note: ‘Y’ has been used to indicate SELFLIVE setting is enabled at R4.1 or below and it’s changed

from ‘Y’ to ‘R’ (Read-Only) at R4.12 or above.

You can disable the SELFLIVE option using the library request command with “SELFLIVE,

DISABLE” keywords. The syntax of the command using the keywords is following: LI REQ, <dlib_name>, DRSETUP, <family_name>, SELFLIVE, DISABLE

Where:


⚫ <dlib_name> is the distributed library name of the cluster for this DR family

Following is an example of the command response when the live copy usage is disabled.


Keywords: DRSETUP,DRFAM001,SELFLIVE,DISABLE

----------------------------------------------------------------------

DRSETUP V1 .1

SELFLIVE USAGE HAS BEEN DISABLED



4.7 LIVEACC Option

When Flash Copy is enabled within a DR Family, any volume access from a DR host through the

devices attached to the DR family is considered as Flash Copy read only volume access if the volume’s

category is not excluded from the Write Protect mode. There may be a use case where a production host

creates new data after time zero (Flash Copy is enabled). This data is then copied to the cluster(s) in a

DR family and a need exists for the DR host to read the newly created Live Data versus the data that

may have existed when the DR Flash point was initiated. When the volume is in the write protect

category at time zero, the DR host has no way to access its Live Copy data created by the production

host after time zero and it can only access its time zero Flash Copy read only data.

This new option allows a DR host to change a write-protected volume to a category excluded from Write

Protect mode. Once its category is changed and it’s in non-write-protected category, the DR host starts

accessing the volume's Live Copy data created by a production host after time zero.

The category which the volume is moved to should be a unique private category that doesn't conflict

with any currently defined connected hosts. Even though the volume is moved into a unique category,

it's still accessible from both the DR host and the production hosts. Eventually, when return to scratch

processing occurs within the production host tape management system, the volumes will be moved back

into the correct scratch category assigned to the owning system plex. There is no need to return such

volumes to a "different" private category when the tests complete.

An example is given below to provide how to use this LI REQ option:

1. C0 (cluster 0) and C1 (cluster 1) are the production clusters which the production host is attached.

C2 (cluster 2) and C3 (cluster 3) are the DR clusters which the DR host is attached.

2. The write-protect excluded category “0x001F” is defined on the DR family.

3. A volume “Z00000” is in a scratch category (0x0001) at time zero and Flash Copy is enabled.

4. After time zero, the production host creates new data on “Z00000” and its category is moved to

“0x000F” (production host private category), then it’s copied to DR Family (C2 and C3).

5. The DR host attempts to access the volume “Z00000”. Because it’s assigned to the category

“0x000F” which is not in write-protect excluded category, Flash Copy volume data whose snapshot

was taken when the volume was in a scratch category is provided. The provided data is not usable

for the DR host and DR host job may fail.

6. Issue this new LI REQ option “LI REQ, <distributed library (C2/C3)>, LIVEACC, Z00000, 001F”.

It changes the category of the volume (Z00000) from 0x000F to 0x001F. Because 0x001F is a write-

protect excluded category, DR host can access its Live Copy data which was created by the

production host after time zero (step #4), then DR host job may work expectedly.

The syntax of the command to use LIVEACC option is as follows: LI REQ, <dlib_name>, DRSETUP, LIVEACC, <volser>, <category>

Where:

⚫ <dlib_name> is the distributed library name of the cluster in the DR family

⚫ <volser> is the volser which requires Live Copy access

⚫ <category> is the target category defined as excluded from write protect in the DR family

Following is an example of the command response when the LIVEACC command successfully

completes.




Keywords: DRSETUP,DRFAM001,Z00000,001F

----------------------------------------------------------------------

DRSETUP V1 .1

Z00000 WAS SUCCESSFULLY ASSIGNED TO CATEGORY 001F

You can verify if the volume’s category is changed using “LI REQ, LVOL, <volser>” or MI Virtual Volume Details and so

on.



4.8 Viewing flash delta data in cache from flash copies

The amount of Tape Volume Cache (TVC) used beyond normal day to day operations may increase

within a DR family TS7700 Flash Capable cluster when the Flash Copy is enabled. One reason for this

increase is because those TS7700 Flash Capable clusters must retain the snapshot image of virtual tapes

at the time zero while allowing the live copy of the volumes to be modified. When a new copy arrives

into the DR site, it will replace an existing live copy and thus the previous live copy is retained within

the snapshot. This can result in up to a 2x increase per volume that is replicated where the volume had

some previous version present at the time of the snapshot.

You can check the amount of this retained delta data in cache from flash copies using a LI REQ

command or the Management Interface. Refer to section 8.1 for viewing amount of data in cache from

flash copies using the Management Interface.

Starting with R3.1, the LI REQ “CACHE” response provides amount of data in cache from flash copies.

An example of the “CACHE” response when the Flash Copy is enabled is as follows:

Refer to the “IBM® TS7700 Series z/OS Host Command Line Request User's Guide” on techdocs for

details of the “CACHE” response.

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101091 CBR1280I Library VTSDIST1 request.

Keywords: CACHE

----------------------------------------------------------------------

TAPE VOLUME CACHE STATE V4 .0

TS7700 VIRTUALIZATION ENGINE MODEL: TS7720 TAPE ATTACH

TOTAL INSTALLED/ENABLED GBS: 47850 / 47850

TOTAL ADJUSTED CACHE USED GBS: 9968

CACHE ENCRYPTION STATUS: CAPABLE

OVERCOMMITTED CACHE PARTITIONS: NONE

PRIMARY CACHE RESIDENT ONLY INFORMATION

PRIVATE CACHE USED GBS: 7974

SCRATCH CACHE USED GBS: 1

CP ALLOC USED PIN PKP PRM COPY CPYT

0 22850 7692 2077 3953 1661 0 0

FLASH COPY INFORMATION

INDEX ENABLED SIZE

1 YES 1988

2 NO 0

3 NO 0

4 NO 0

5 NO 0

6 NO 0

7 NO 0

8 NO 0

PRIMARY TAPE MANAGED PARTITIONS

CP ALLOC USED PG0 PG1 PMIGR D_PMIGR COPY PMT CPYT

1 3000 0 0 0 0 0 0 0 0

2 1000 0 0 0 0 0 0 0 0

3 2000 0 0 0 0 0 0 0 0

4 2000 0 0 0 0 0 0 0 0

5 4000 0 0 0 0 0 0 0 0

6 10000 0 0 0 0 0 0 0 0

7 3000 0 0 0 0 0 0 0 0

"




5 Flash Copy and the Management Interface (MI) Starting with R3.1, some management interface panels have changed to accommodate the introduction

of the Flash Copy for DR testing function.

5.1 Viewing delta amount of data in cache from flash copies using the Management Interface (non-tape attached TS7700 Flash Capable cluster only)

Starting with R3.1, the “Cache Utilization” panel of the Management Interface provides amount of data

in cache retained due to flash copies. The MI panel for viewing the data is accessed by selecting

(Monitor) => Performance => Cache Utilization => Total amount of data in cache.

The following figure 3 shows an example of the cache utilization panel opened when the Flash Copy is

enabled on the cluster.

Figure 3: Total amount of data in cache from flash copies



5.2 Viewing delta amount of data in cache from flash copies using the Management Interface (TS7700T/TS7700C cluster only)

Starting with R3.2, the “Cache Partitions” panel of the Management Interface provides amount of data in

cache retained due to flash copies on TS7700T/TS770C cluster. The MI panel for viewing the data is

accessed by selecting (Monitor) => Performance => Cache Partitions => “Properties for Resident

Partition”.



5.3 Viewing details of flash copy of logical volumes

Starting with R3.1, the Management Interface “Virtual Volume Details” panel provides methods to view

details about a volume’s flash copy instance as well as a live copy of a logical volume. The MI panel for

viewing details of a volume’s flash copy is accessed by selecting (Virtual) => Virtual Volumes =>

Virtual Volume Details.

If a flash copy for the volume exists, the “Flash Copy” field in the “Virtual Volume Details” table will

have either “Active” or “Created”. If no flash copy for the volume exists, the “Flash Copy” field has

“Not Active”.

The “Active” state means that a flash copy for the volume exists and the volume properties have not

been changed since flash copy was created. Following figure 4 shows an example of the volume details

panel for a logical volume where a flash copy exists (but volume properties or volume content has not

changed within the grid since the flash copy was created).

Figure 4: Virtual volume details page (flash “active”)



If a flash copy for the specified logical volume exists and the volume properties or content has been

changed within the grid, the “Flash Copy” field of the “Virtual volume details” will have “Created”. The

“Created” is a link to the Flash Copy Detail page which was newly introduced in R3.1. When you click

on the “Created” link, you will be able to see the volume state at time zero. If only “Active”, the live

and time zero properties are identical. Only when changes have occurred will the “Created” state

surface which provides the ability to differentiate between the live copy and flash copy instance.

Figure 5 shows an example of the volume details panel for a logical volume where a flash copy exists

and the volume’s properties have changed since the flash copy was created. Figure 5 shows volume

properties of the live copy of the specified logical volume. Note that the live copy is now assigned to

category 0001 (the “Category” field) which is a scratch category.

When you click the “Created” link to view volume properties of the flash copy, you’ll be redirected to

the Flash Copy Detail page as shown in Figure 6.

Figure 5: Virtual volume details page (flash “created”)



The Flash Copy Details page shown in Figure 6 shows volume properties of the flash copy of the

specified logical volume. Also the page provides information about the DR family which the flash copy

belongs to and when the flash copy was created. Note that the flash copy is assigned to a private

category 0x000F (see the “Category” field) although the live copy is now assigned to a scratch category

as shown in the figure 5 in the previous page. Also note that only two clusters are included in the

“Cluster-specific Flash Copy Properties” in figure 6 while all four clusters are shown in figure 5. This is

because only two clusters are included in the DR family “DRFAM001” in this example.

Figure 6: Flash Copy Details panel



5.4 Virtual Tape Drives panel

Starting with R3.1, the “Virtual Tape Drives” panel shows whether the mounted volume on a virtual

tape drive is accessing a flash copy or live copy in the “Mount Type” column. Figure 7 shows an

example of the Virtual Tape Drives page in R3.1. You can see a total of ten volumes are mounted and

eight of those ten volumes are accessing a flash copy. Also, you can see all the flash copies are mounted

as “write protect” (see the “state” field).

Figure 7: Virtual Tape Drives panel



5.5 Write Protect mode panel

If the flash copy function is active within a grid or the LI REQ method is used to enable write protect,

write protect for flash copy information is displayed in the Write Protect Mode Panel as shown in Figure

8. The remainder of the page is grayed out (disabled) until a user disables the LI REQ enabled write

protection. If any LI REQ enabled write protect is also not enabled, the page works as it originally did in

R3.0 or prior code levels. This disablement is an enforcement of write protection needing to be

exclusively enabled and disabled through the LI REQ mechanism when the intended purpose is assumed

to be on behalf of flash copy for DR testing. If the LI REQ method is used to simply enable write

protection and no intention of using flash copy is expected, the same disablement within the MI panel

will remain under the assumption a flash copy may be enabled.

Starting with R3.1, up to 32 excluded categories are supported for both MI and LI REQ enabled

variations of write protection.

At the code level of 8.50.x.x (R5.0), up to 128 excluded categories are supported (note: all clusters in the

Grid must be at 8.50.x.x or above to use 128 excluded categories).

Figure 8: Write Protect Mode Panel



6 Appendix A. Details of the format of data reported by “DRSETUP” library request command

6.1 Supported keywords Keyword

1

Keyword 2 Keyword 3 Keyword 4 Description Comp Dist 7740 7700D 7700T 7700C

DRSETUP

CCCCCCCC(*) ADD

REMOVE

0-7 Add/remove a

cluster

to/from the

DR family

Y N/A N/A N/A N/A N/A

WP ENABLE

DISABLE

Enable/disable

write protect

mode within

the DR family


FLASH ENABLE

DISABLE

Enable/disable

FlashCopy

within the DR

family


DOALL ENABLE

DISABLE

Enable/disable

write protect

mode and

flash copy

with a single

command


LIVECOPY FAMILY

NONE

Allow or

disallow

usage of a live

copy within

the DR

family.


SELFLIVE ENABLE

DISABLE

Enable/disable

accessing live

copy created

after time zero

N Y Y Y Y Y

DRSETUP SHOW CCCCCC (*) View

information

about the DR

family


DRSETUP LIVEACC <volser> <category> Change

category and

allow live

copy volume

access from

DR host

N Y Y Y Y Y

(*) DR family name



6.2 Format of the data reported by “DRSETUP, ADD” command

Following table details the format of the data reported.

Line Bytes Name Description

1 0:8 Header Info ‘DRSETUP V’

9:10 Version The version number for the response. The number if left justified and padded with blanks.

Starts with 1.

11:11 Dot ‘.’

12:12 Revision The revision number for the response. The number is left justified and padded with blanks.

The revision is introduced at 8.31.x.x and starts with 0.

When the response is updated in a compatible way, the revision is increased but the

version remains the same.

13:69 Blanks

If no DR family is defined in the grid and the specified cluster is a TS7700 Flash Capable cluster, the following lines are

returned. ‘CCCCCCCC’ is the name of the DR family. ‘N’ is ID of the cluster added to the DR family.

2 0:35 ‘DR FAMILY CCCCCCCC WAS NEWLY CREATED’

36:69 Blanks

3 0:53 ‘CLUSTER N WAS ADDED TO DR FAMILY CCCCCCCC SUCCESSFULLY’

54:69 Blanks

If the specified DR family already exists, the following lines are returned

1 0:53 ‘CLUSTER N WAS ADDED TO DR FAMILY CCCCCCCC SUCCESSFULLY’

54:69 Blanks

If another DR family is already defined in the grid, the following line is returned

1 0:57 ‘MAXIMUM NUMBER OF DR FAMILIES HAVE BEEN REACHED, ALLOWED 1’

58:69 Blanks

If no DR family is defined in the grid and the specified cluster is a TS7740 cluster, the following line is returned.

1 0:54 ‘A FLASH CAPABLE CLUSTER MUST BE INCLUDED IN A DR FAMILY’

55:69 Blanks

If the specified cluster is already a member of the DR family, following line is returned.

1 0:50 ‘CLUSTER N IS ALREADY A MEMBER OF DR FAMILY CCCCCCCC’

51:69 Blanks

If write protect mode is already enabled within the DR family, following line is returned.

1 0:57 ‘CANNOT ADD CLUSTER N AS WP IS ALREADY ENABLED AT CLUSTER 1’

58:69 Blanks

If flash copy is already enabled within the DR family, following line is returned.

1 0:55 ‘CANNOT ADD THE CLUSTER TO THE FAMILY. FLASH COPY EXISTS.’

56:69 Blanks



6.3 Format of the data reported by “DRSETUP, REMOVE” command Following table details the format of the data reported.




Starts with 1.

11:11 Dot ‘.’





13:69 Blanks

If the specified cluster is not the last member of the DR family, the following line is returned. ‘CCCCCCCC’ is the name

of the DR family. ‘N’ is ID of the cluster added to the DR family.

2 0:57 ‘CLUSTER N WAS REMOVED FROM DR FAMILY CCCCCCCC SUCCESSFULLY’

58:69 Blanks

If the specified cluster is the last member of the DR family, the following lines are returned.

2 0:53 ‘CLUSTER N WAS REMOVED FROM DR FAMILY CCCCCCCC SUCCESSFULLY’

54:69 Blanks

3 0:54 ‘DR FAMILY CCCCCCCC WAS DELETED BECAUSE NO MEMBER EXISTS’

55:69 Blanks

If non-existing DR family is specified, following line is returned.

1 0:33 ‘DR FAMILY CCCCCCCC DOES NOT EXIST’

34:69 Blanks

If the specified cluster is a 7720 cluster and all other clusters in the DR family are a 7740 cluster, the following line is

returned.

1 0:54 ‘A FLASH CAPABLE CLUSTER MUST BE INCLUDED IN A DR FAMILY’

55:69 Blanks

If the specified cluster is not a member of the DR family, following line is returned.

1 0:51 ‘CLUSTER N IS NOT A MEMBER OF DR FAMILY CCCCCCCC’

52:69 Blanks

If write protect mode is already enabled within the DR family, following line is returned.

1 0:67 ‘CANNOT REMOVE CLUSTER N AS WP IS STILL ENABLED AT DR FAMILY

CCCCCCCC’

68:69 Blanks

If flash copy is already enabled within the DR family, following line is returned.

1 0:60 ‘CANNOT REMOVE THE CLUSTER FROM THE FAMILY. FLASH COPY

EXISTS.’

61:69 Blanks



6.4 Format of the data reported by “DRSETUP, WP, ENABLE” command





Starts with 1.

11:11 Dot ‘.’



The revision is incremented to 1 at 8.41.100.x.

When asynchronous operation is supported in R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid,

the revision 0 is used so “V 1.0” is used.



13:69 Blanks

If the microcode successfully enabled write protect mode in the specified DR family, the following line is returned.

2 0:49 At R4.1.1 or below, or in the mixed code Grid (R4.1.2/R4.2 + R4.1.1 or below):

‘WRITE PROTECT STATUS HAS BEEN ENABLED SUCCESSFULLY’

At R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid:

‘DRSETUP DRFAM WP ENABLE HAS STARTED SUCCESSFULLY’

50:69 Blanks

If write protect mode is already enabled in the specified DR family, the following line is returned.

2 0:31 ‘WRITE PROTECT IS ALREADY ENABLED’

32:69 Blanks



34:69 Blanks

If there are two or more clusters in the DR family and the write protect exclusion categories don’t match across clusters,

following line is returned.

1 0:65 ‘WRITE PROTECT EXCLUDED CATEGORIES NOT IN SYNC WITHIN THE DR

FAMILY’

66:69 Blanks

If there is a cluster which is not online in the DR family, following line is returned.

1 0:68 ‘CANNOT PERFORM THE REQUEST. A CLUSTER IN THE DR FAMILY IS

NOT ONLINE.’

69 Blank

6.5 Format of the data reported by “DRSETUP, WP, DISABLE” command







Starts with 1.

11:11 Dot ‘.’








13:69 Blanks

If the microcode successfully disabled write protect mode in the specified DR family, the following line is returned.


‘WRITE PROTECT STATUS HAS BEEN DISABLED SUCCESSFULLY’

At R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid:

‘DRSETUP DRFAM WP DISABLE HAS STARTED SUCCESSFULLY’

51:69 Blanks

If write protect mode is not enabled in the specified DR family, the following lines are returned.

2 0:32 ‘WRITE PROTECT IS NOT ENABLED’

33:69 Blanks



34:69 Blanks



NOT ONLINE.’

69 Blank

6.6 Format of the data reported by “DRSETUP, FLASH, ENABLE” command





Starts with 1.

11:11 Dot ‘.’











13:69 Blanks

If the microcode successfully enabled flash copy in the specified DR family, the following line is returned.


‘FLASH COPY HAS BEEN CREATED SUCCESSFULLY’

At R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid:

‘DRSETUP DRFAM FLASH ENABLE HAS STARTED SUCCESSFULLY’

40:69 Blanks

If one or more clusters in the DR family are not in write protect mode, the following line is returned.

1 0:63 ‘A CLUSTER IN THE DR FAMILY CCCCCCCC IS NOT IN WRITE PROTECT

MODE’

64:69 Blanks

If flash copy is already enabled in the specified DR family, the following lines are returned.

1 0:46 ‘FLASH COPY ALREADY EXISTS IN DR FAMILY DRFAM001’

47:69 Blanks



34:69 Blanks



NOT ONLINE.’

69 Blank

6.7 Format of the data reported by “DRSETUP, FLASH, DISABLE” command





Starts with 1.

11:11 Dot ‘.’











13:69 Blanks

If the microcode successfully disabled flash copy in the specified DR family, the following line is returned.


‘FLASH COPY HAS BEEN DELETED SUCCESSFULLY’

At R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid:

‘DRSETUP DRFAM FLASH DISABLE HAS STARTED SUCCESSFULLY’

40:69 Blanks

If flash copy is not enabled in the specified DR family, the following line is returned.

1 0:41 ‘NO FLASH COPY EXISTS IN DR FAMILY DRFAM001’

42:69 Blanks



34:69 Blanks

If there is one or more flash copy volumes are mounted, following line is returned.

1 0:60 ‘CANNOT DISABLE FLASH COPY. FLASH COPY VOLUME IS STILL

MOUNTED’

61:69 Blanks



NOT ONLINE.’

69 Blank

6.8 Format of the data reported by “DRSETUP, DOALL, ENABLE” command




9:10 Version The version number for the response. The number if left justified and padded with

blanks. Starts with 1.

11:11 Dot ‘.’

12:12 Revision The revision number for the response. The number is left justified and padded with

blanks. The revision is introduced at 8.31.x.x and starts with 0.


When asynchronous operation is supported in R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x)




Grid, the revision 0 is used so “V 1.0” is used.



13:69 Blanks

If the microcode successfully enabled both write protect mode and flash copy in the specified DR family, the following lines

are returned.


‘WRITE PROTECT STATUS HAS BEEN ENABLED SUCCESSFULLY’

At R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid:

‘DRSETUP DRFAM DOALL ENABLE HAS STARTED SUCCESSFULLY’

50:69 Blanks

3 0:39 At 8.412 or below, or at 8.42 in mixed code Grid:

‘FLASH COPY HAS BEEN CREATED SUCCESSFULLY’

40:69 Blanks

If flash copy is already enabled in the specified DR family, the following line is returned.

1 0:46 ‘FLASH COPY ALREADY EXISTS IN DR FAMILY DRFAM001’

47:69 Blanks



34:69 Blanks

If there are two or more clusters in the DR family and the write protect exclusion categories don’t match across clusters,


1 0:65 ‘WRITE PROTECT EXCLUDED CATEGORIES NOT IN SYNC WITHIN THE

DR FAMILY’

66:69 Blanks



NOT ONLINE.’

69 Blank

6.9 Format of the data reported by “DRSETUP, DOALL, DISABLE” command




9:10 Version The version number for the response. The number if left justified and padded with

blanks. Starts with 1.

11:11 Dot ‘.’

12:12 Revision The revision number for the response. The number is left justified and padded with




blanks. The revision is introduced at 8.31.x.x and starts with 0.


When asynchronous operation is supported in R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x)

Grid, the revision 0 is used so “V 1.0” is used.



13:69 Blanks

If the microcode successfully disabled both write protect mode and flash copy in the specified DR family, the following lines

are returned.


‘WRITE PROTECT STATUS HAS BEEN DISABLED SUCCESSFULLY’

At R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid:

‘DRSETUP DRFAM DOALL DISABLE HAS STARTED SUCCESSFULLY’

51:69 Blanks


‘FLASH COPY HAS BEEN DELETED SUCCESSFULLY’

40:69 Blanks

If there is one or more flash copy volumes are mounted, following line is returned.

1 0:60 ‘CANNOT DISABLE FLASH COPY. FLASH COPY VOLUME IS STILL

MOUNTED’

61:69 Blanks



34:69 Blanks



NOT ONLINE.’

69 Blank

6.10 Format of the data reported by “DRSETUP, LIVECOPY, FAMLIY” command





Starts with 1.

11:11 Dot ‘.’








13:69 Blanks

If the microcode successfully changed the live copy usage setting in the specified DR family, the following line is

returned.

2 0:56 ‘LIVE COPY USAGE HAS BEEN UPDATED TO FAMILY SUCCESSFULLY’

57:69 Blanks

If there is no 7740 cluster in the DR family, following line is returned.

1 0:54 ‘LIVECOPY OPTION IS NOT SUPPORTED IN DISK-ONLY DR FAMILY’

55:69 Blanks

If the live copy usage setting is already set to ‘FAMILY’, the following line is returned.

1 0:33 ‘LIVE COPY USAGE WAS ALREADY FAMILY’

34:69 Blanks



34:69 Blanks



NOT ONLINE.’

69 Blank

6.11 Format of the data reported by “DRSETUP, SELFLIVE, ENABLE” command





Starts with 1.

11:11 Dot ‘.’


The revision starts from 1 at 8.33.x.x.



13:69 Blanks


returned.

2 0:30 ‘SELFLIVE USAGE HAS BEEN ENABLED’

31:69 Blanks






34:69 Blanks


1 0:30 ‘DISTRIBUTED LIBRARY UNAVAILABLE’

31:69 Blank

6.12 Format of the data reported by “DRSETUP, SELFLIVE, DISABLE” command





Starts with 1.

11:11 Dot ‘.’





13:69 Blanks


returned.

2 0:31 ‘SELFLIVE USAGE HAS BEEN DISABLED’

32:69 Blanks



34:69 Blanks


1 0:30 ‘DISTRIBUTED LIBRARY UNAVAILABLE’

31:69 Blank

6.13 Format of the data reported by “DRSETUP, LIVEACC, <volser>, <category>” command







Starts with 1.

11:11 Dot ‘.’





13:69 Blanks

If the microcode successfully changed the volume’s category, the following line is returned.

2 0:50 ‘<volser> WAS SUCCESSFULLY ASSIGNED TO CATEGORY

<category>’

The <volser> is the specified volser in the request.

The <category> is the specified category in the request.

51:69 Blanks

If the distributed library which receives the LI REQ does not belong to any DR family or no Flash Copy is enabled,


1 0:N ‘FLASH COPY IS NOT YET ENABLED ON DISTRIBUTED LIBRARY DDDD’

DDDD is the distributed library nick name and sequence number.

N:69 Blanks

If the specified category is not excluded from Write Protect, following line is returned.

1 0:47 ‘CATEGORY <category> IS NOT EXCLUDED FROM WRITE-PROTECT’

The <category> is the specified category in the request.

48:69 Blank

If the specified volser does not exist in the target Grid, following line is returned.

1 0:41 ‘VOLSER <volser> DOES NOT EXIST IN THE GRID’


42:69 Blank

If the category change fails due to unknown reason, following line is returned.

1 0:38 ‘CATEGORY CHANGE FAILED ON VOLSER <volser>’


39:69 Blank

6.14 Format of the data reported by “DRSETUP, SHOW” command Following table details the format of the data reported when the DR family name is specified in the third keyword:



9:10 Version The version number for the response. The number if left justified and padded

with blanks. Starts with 1.

The version is incremented to 2 at R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x). The




revision is reset to 0 at the same time.

The version is incremented to 3 at R5.0 (8.50.x.x).

11:11 Dot ‘.’

12:12 Revision The revision number for the response. The number is left justified and

padded with blanks. The revision is introduced at 8.31.x.x and starts with 0.

The revision is incremented to 1 at 8.33.x.x.

The revision is reset to 0 at R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) when the

version is incremented to 2 at the same time.

The revision is incremented to 1 at R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x).

When the response is updated in a compatible way, the revision is increased

but the version remains the same.

The revision is reset to 0 at R5.0 (8.50.x.x) when the version is incremented

to 3 at the same time.

13:69 Blanks

2 0 Blank

1:14 Header Info ‘DR FAMILY VIEW’

15:69 Blanks

3 0:1 Blanks

2:3 Header Info ‘ID’

4:5 Blanks

6:13 Header Info ‘FAM NAME’

14:18 Blanks

19:23 Header Info ‘FLASH’

24:28 Blanks

29:44 Header Info ‘FLASH TIME (UTC)’

45:47 Blanks

48:52 Header Info ‘LCOPY’

53:54 Blanks

55:69 Header Info ‘MEMBER CLUSTERS’

4 0:2 Blanks

3 Family ID

(ID)

ID of the DR family. Only 1 DR family can be defined in a grid currently.

4:5 Blanks

6:13 Family Name

(FAM NAME)

The name of the DR family. Only alphabets/digits can be acceptable as the

name. No space must be included in the name. The maximum length of the

name is 8 characters.

14:15 Blanks

16:23 Flash State

(FLASH)

The state of the flash copy within the DR family. The following are the

values can be indicated:

‘ACTIVE’ Flash copy is enabled within the family.

‘INACTIVE’ Flash copy is not enabled within the family.




24:25 Blanks

26:44 Flash Time

(FLASH TIME)

The timestamp when the flash copy was enabled within the DR family. The

timestamp is formatted as follows:

‘YYYY-MM-DD HH:MM:SS’ for example:

‘2013-12-06-06.53.19’

If flash copy is not enabled within the DR family, this field is set to:

‘N/A’

45:46 Blanks

47:52 Live copy usage

(LCOPY)

Live copy usage setting within the family. The following are the values can

be indicated:

‘FAMILY’ Live copy can be used to satisfy a mount request for flash copy

volume.

‘NONE’ Live copy is never used to satisfy a mount request for flash

copy volume.

53:54 Blanks

55:69 Member clusters

(MEMBER CLUSTERS)

IDs of TS7700 clusters belonging to the DR family. Clusters not belonging to

the DR family or non-existing clusters are shown as ‘-‘

5 0:69 Separator All dash ‘-‘ caracsters

6 0 Blank

1:39 Header Info ‘FAMILY MEMBER WRITE PROTECT STATUS VIEW’

7 0:1 Blanks

2:8 Header Info ‘CLUSTER’

9:11 Blanks

12:22 Header Info ‘WRT-PROTECT’

23:24 Blanks

25:34 Header Info ‘EXCATS-NUM’

35:36 Blanks

37:45 Header Info ‘IGNORE-FR’

46:47 Blanks

48:57 Header Info ‘ENABLED-BY’

58:59 Blanks

60:67 ‘SELFLIVE’

68:69

For each cluster in the DR family a line is formatted as follows:

N 0:2 Blanks

3:9 Cluster Cluster belonging to the DR family

10:14 Blanks

15:22 Write Protect Status Write protect status for the cluster. The following are the values can be

indicated:

‘ENABLED’ Write protect mode is enabled on the cluster.




‘DISABLED’ Write protect mode is disabled on the cluster.

23:32 Blanks

33:34 Number of write protect

exclusion categories

Number of write protect exclusion categories defined on the cluster. Up to 32

categories can be defined.

At 8.50.x.x or above, up to 128 categories can be defined.

35:40 Blanks

41:45 Ignore fastReady

attributed setting

The status of the “Ignore fastReady characteristics of write protected

categories” setting on the cluster. The following are the values can be

indicated:

‘TRUE’ the setting is set to enabled.

‘FALSE’ the setting is set to disabled.

46:52 Blanks

53:57 Method used to enable

write protect mode

The method used to enable write protect mode. The following are the values

can be indicated:

‘LIREQ’ Write protect mode is enabled by library request command.

‘MI’ Write protect mode is enabled by Management Interface.

‘N/A’ Write protect mode is not enabled.

58:66 Blanks

67 ‘Y’ or ‘R’ SELFLIVE is enabled (‘R’ is used at R4.1.2 or above)

‘N’ SELFLIVE is not enabled

68:69 Blank

N+1 0:69 Separator All dash ‘-‘ characters

N+2 0 Blank

1:67 Header Info ‘CATEGORIES EXCLUDED FROM WRITE PROTECTION WITHIN

DR FAMILY CCCCCCCC’

N+3 0:1 Blanks

2:8 Header Info ‘CLUSTER’

9:11 Blanks

12:37 Header Info ‘ACTIVE EXCLUDED CATEGORIES’

N+4 0:1 Blanks

2:9 Cluster Cluster belonging to the DR family

10:11 Blanks

12:66 Write protect exclusion

categories

Write protect exclusion categories defined on the cluster. Up to 11 categories

can be shown in each line. Multiple lines will be used when more than 11

categories are defined on the cluster.

67:69 Blanks

M-1 0:6 Blanks

7:62 More write protect

excluded categories exist

indicator

‘MORE WRITE PROTECT EXCLUDED CATEGORIES TO DISPLAY

EXIST.’

This line is shown only when the request is received by the cluster with R5.0

or above code level and there are too may write protect excluded categories




to be shown within 50 lines of whole output.

63:69 Blanks

M 0:69 Separator All dash ‘-‘ characters.

From the Mth to (M+2)th lines, they’re provided only when the request is

received by the cluster with R8.42 or above code level.

M+1 0 Blank

1:39 Header Info ‘DRSETUP CURRENT ACTIVE OPERATION STATUS’

40:69 Blanks

M+2 0:1 Blanks

2:69 Current active

asynchronous request

status

[At R4.1.1 or below, or in the mixed code Grid (R4.1.2/R4.2 + R4.1.1 or

below)]

‘ASYNC DRSETUP OP IS NOT SUPPORTED’

[R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x)]

➢ No active asynchronous operation is running:

‘NO ACTIVE DRSETUP FLC/WP OP IS RUNNING’

➢ Active asynchronous operation is still running:

‘[Async op] STARTED AT [started time] IS RUNNING’

➢ Active asynchronous operation status can’t be determined:

‘ACTIVE DRSETUP OP CANNOT BE DETERMINED’

(*) Please refer to the section 4.4.3 for the details.

Following table details the format of the data reported when no DR family name is specified in the third keyword:



9:10 Version The version number for the response. The number if left justified and padded

with blanks. Starts with 1.

The version is incremented to 2 at R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x). The

revision is reset to 0 at the same time.

11:11 Dot ‘.’

12:12 Revision The revision number for the response. The number is left justified and

padded with blanks. The revision is introduced at 8.31.x.x and starts with 0.

The revision is incremented to 1 at 8.33.x.x.

The revision is reset to 0 at R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) when the

version is incremented to 2 at the same time.

The revision is incremented to 1 at R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x).

When the response is updated in a compatible way, the revision is increased

but the version remains the same.

13:69 Blanks

2 0 Blank

1:14 Header Info ‘DR FAMILY VIEW’

15:69 Blanks




3 0 Blank

1:69 Header Info ‘ID FAM NAME FLASH FLASH TIME (UTC)

LCOPY MEMBER CLUSTERS’

For each DR family a line is formatted as follows (currently only 1 DR family is supported in the Grid):

4:11 0:1 Blanks

2:3 Family ID

(ID)


If no DR family is configured, this field is set to:

‘N/A’

4:5 Blanks

6:13 Family Name

(FAM NAME)





‘N/A’

14:15 Blanks

16:23 Flash State

(FLASH)

The state of the flash copy within the DR family. The following are the

values can be indicated:

‘ ACTIVE’ Flash copy is enabled within the family.

‘INACTIVE’ Flash copy is not enabled within the family.

24:25 Blanks

29:44 Flash Time

(FLASH TIME)

The timestamp when the flash copy was enabled within the DR family. The

timestamp is formatted as follows:

‘YYYY-MM-DD HH:MM:SS’ for example:

‘2013-12-06-06.53.19’

If flash copy is not enabled within the DR family, this field is set to:

‘N/A’

45:46 Blanks

47:52 Live copy usage

(LCOPY)

Live copy usage setting within the family. The following are the values can

be indicated:

‘FAMILY’ Live copy can be used to satisfy a mount request for flash copy

volume.

‘NONE’ Live copy is never used to satisfy a mount request for flash

copy volume.

53:54 Blanks

55:69 Member clusters

(MEMBER CLUSTERS)

IDs of TS7700 clusters belonging to the DR family. Clusters not belonging to

the DR family or non-existing clusters are shown as ‘-‘

12 0:69 Separator All dash ‘-‘ caracsters

13 0 Blank

1:69 Header Info ‘FAMILY MEMBER WRITE PROTECT STATUS SUMMARY

VIEW ’

14 0:20 Blanks

21:34 Header Info ‘CLUSTER STATUS’




35:69 Blanks

15 0:1 Blanks

2:38 Header Info ‘ID FAM NAME C0 C1 C2 C3 C4 C5 C6 C7’

39:69 Blanks

For each DR family a line is formatted as follows (currently only 1 DR family is supported in the Grid):

16:23 0:1 Blanks

2:3 Family ID

(ID)



‘N/A’

4:5 Blanks

6:13 Family Name

(FAM NAME)





‘N/A’

14:15 Blanks

16:38 Write Protect Status The write protect status of TS7700 clusters belonging to the DR family.

When the cluster is in write-protect status, ‘WP‘ is provided.

Clusters not belonging to the DR family, non-existing clusters or clusters not

in write-protect status are shown as ‘--‘.

39:69 Blanks

24 0:69 Separator All dash ‘-‘ characters.

From 24th line and blow, they’re provided only when the request is received

by the cluster with R8.42 or above code level.

25 0 Blank

1:39 Header Info ‘DRSETUP CURRENT ACTIVE OPERATION STATUS’

40:69 Blanks

26 2:69 Current active

asynchronous request

status

[At R4.1.1 or below, or in the mixed code Grid (R4.1.2/R4.2 + R4.1.1 or

below)]

‘ASYNC DRSETUP OP IS NOT SUPPORTED’

[R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x)]

➢ No active asynchronous operation is running:

‘NO ACTIVE DRSETUP FLC/WP OP IS RUNNING’

➢ Active asynchronous operation is still running:

‘[Async op] STARTED AT [started time] IS RUNNING’

➢ Active asynchronous operation status can’t be determined:

‘ACTIVE DRSETUP OP CANNOT BE DETERMINED’

(*) Please refer to the section 4.4.3 for the details.



6.15 RETURN CODE error description of “DRSETUP” command When an internal error condition occurs while “DRSETUP” command is executed, the following error text message may be

reported.

AN ERROR OCCURED PROCESSING THE HOST REQUEST. RETURN CODE = XXXXX

The following return code (XXXXX) may be used:

RETURN CODE Description

-1 ~ -13 General VPD (Vital Product Data such as Write Protect Excluded Category, DR Family configuration

etc.) update/read/initialize error which may occur in the specified DRSETUP command.

32776 Deleting the previously created Flash Copy volumes metadata failed. (*) Not used if asynchronous

operation is supported.

32865 Another Flash Copy Operation is still in progress and the current operation was rejected. (*) Not used

if asynchronous operation is supported.

32868 Enabling Flash Copy failed. (*) Not used if asynchronous operation is supported.

32870 Deleting the previously created snapshot volumes failed. (*) Not used if asynchronous operation is

supported.

32871 Write Protect Status synchronization failed in the DR family. (*) Not used if asynchronous operation is

supported.

32872/ 32873 Write Protect Status update failed on the local/remote cluster in the DR family. (*) Not used if

asynchronous operation is supported.

If “DRSETUP” command failed with any of the RETURN CODE in the above table, retrying the command may help.

Contact your IBM service representative if the problem persists.

In R4.1.2 (8.41.200.113)/R4.2 (8.42.x.x) Grid, the following return codes are replaced to the error text message and they’re

no longer used:

• 32776/32865/32868/32870 are replaced to “FLASH COPY OPERATION FAILED”.

• 32871 is replaced to “VPD SYNCHRONIZATION FAILED”.

• 32872/ 32873 are replaced to “VPD UPDATE FAILED”.

ibm® virtualization engine ts7700 series

Documents