Management Classes

View the management classes that define the IBM® TS7700 copy policy for volume redundancy.

The Current Copy Policy table displays the copy policy in force for each cluster in the grid. If no management class is selected, this table is not visible. You must select a management class from the Management Classes table to view copy policy details.

The Management Classes table displays defined management class copy policies that can be applied to a cluster. You can use the Select Action drop-down menu on the Management Classes table to

Create a management class
Modify an existing management class
Copy an existing management class
Copy one or more existing management classes from the accessing cluster to another cluster in the grid
Delete one or more existing management classes

The default management class can be modified, but cannot be deleted. The default management class has a name that is "- - - - - - - -".

Status information that is displayed in the Management Classes table includes

Name

The name of the management class. The value in this field must be 1 - 8 characters in length. Each management class within a cluster or cluster pair must have a unique name. Valid characters for this field are

A-Z, 0-9, $, @, and #

The first character of this field cannot be a number. This field is the only field that cannot be modified once added.

Secondary Pool

The target pool in the volume duplication. If a secondary pool is defined (the pool number is set to a non-zero value), a second copy of the virtual volume is made on a separate physical volume during premigration. This column is visible only if the cluster possesses a physical library. If the cluster does not possess a physical library, the management interface categorizes newly created management classes using pool 0.

Note: Refer to the Storage Groups page to define the primary pool. If the Copy Export function is used, set the secondary pool to a pool other than the primary pool of a defined storage group. For the TS7700 Tape Attach, the secondary pool is applied only to logical volumes that do not reside in cache partition 0.

Description

A description of the management class.

Scratch Mount Candidate

Clusters that are listed under Scratch Mount Candidate are selected first for scratch mounts of the volumes that are associated with the management class. If no clusters are displayed, the scratch mount process remains a random selection routine that includes all available clusters.

This function is available only when all clusters in the grid operate at microcode level 8.20.0.xx or later and the Setting Assist Scratch library request option is enabled across the grid.

Before this function is operational, all of the following must be true:

SAA is enabled with the host Library Request command by using the following LIBRARY REQUEST command:
```
LIBRARY REQUEST,library-name,SETTING,DEVALLOC,SCRATCH,[ENABLE|DISABLE]
where library-name = composite-library-name
```
Disabled is the default setting.
An adequate number of devices connected to the scratch mount candidate clusters are online at the host.
Note: If the clusters are online, but too few or no devices are online at the host, jobs that use SAA can go into allocation recovery. In allocation recovery, the existing MVS allocation options for device allocation recovery (WTOR|WAITHOLD|WAITNOH|CANCEL) are used. If all or many devices associated with the candidate clusters need to be taken offline, as when servicing a cluster, then SAA should first be disabled by using the host Library Request command. Thus, other clusters in the grid can be used for SAA during the outage. Alternatively, you can extend the list of candidate clusters to include clusters that have devices remaining online at the host during the outage. Use the management class construct to extend the list of candidate clusters.

Retain Copy Mode

Whether previous copy policy settings on non-fast-ready virtual volume mounts are retained. Possible values are

Yes: Previous copy policy settings on non-fast-ready virtual volume mounts are retained.
No: Previous copy policy settings on non-fast-ready virtual volume mounts are NOT retained.

Table 1. Management class settings for each cluster
Clusters	The nickname and ID of the cluster to which the settings apply.
Copy Mode	Copy Mode The copy mode that is used in the volume duplication. Deferred Volume duplication occurs later based on the internal schedule of the copy engine. Rewind Unload (RUN) Volume duplication occurs when the RUN command is received. The command only returns after the volume duplication completes successfully. Synchronous Copy Volume duplication occurs upon any synchronous mode copy operation. Refer to the topic Synchronous mode copy in the Related information section for more information. Time Delayed Volume duplication occurs after the user-specified delay period passes. The option is only available if all clusters in the grid operate at microcode level 8.31.0.xx or later. Delay Queuing Copies for [`X`] Hours The number of hours copy queuing is delayed if Time Delayed Mode Copy is selected. This value is a number in the range of 1 to 65,535. Start Delay After The trigger that initiates the delayed start time if Time Delayed Mode Copy is selected. Possible values include Volume Create The time-delayed start occurs when the volume is created. Volume Last Accessed The time-delayed start occurs when the volume was last accessed. No Copy No volume duplication occurs if this action is selected. Pair Copy Volume duplication occurs when the entire volume is stored successfully on the primary pool. The write operation is committed when both primary and secondary pools possess the volume copy. This field is only visible when the cluster is a cluster pair.

Synchronous Mode Copy settings specify how the library or virtual tape drive behaves when the Copy Mode value is Synchronous Copy and synchronization between the two synchronized ("S") locations is not satisfied. Synchronous Mode Copy settings determine whether the library opens the volume on both TVC clusters when a private mount occurs. These options are only visible when synchronous mode copy is enabled and all clusters in the grid operate at microcode level 8.21.0.xx or later.

Default Settings

By default, the synchronous-mode-copy clusters fail mount and tape operations if two copies of a volume cannot be maintained during an update (synchronous failure). When the synchronous failure setting is used, a zero RPO is provided for the target workload, independent of failures. Consider the following circumstances when using the default strict synchronization behavior include:

If the failure to synchronize is detected after the mount has already occurred, then tape operations fail to the targeted volume until a RUN occurs and a demount command is issued.
If content was written prior to the synchronization failure, then previous content on the emulated volume up to the last successful tape synchronization operation point is considered persistently synchronized and can be accessed later from either "S" consistency point.
If either "S" consistency point is unavailable, then scratch mount operations fail.

Synchronous Deferred On Write Failure

Enable this option to permit update operations to continue to any valid consistency point in the grid. If there is a write failure the failed "S" locations are set to a state of "synchronous-deferred". After the volume is closed, any synchronous-deferred locations are updated to an equivalent consistency point through asynchronous replication. If the Synchronous Deferred On Write Failure option is not checked and a write failure occurs at either of the "S" locations, then host operations fail.

Note: An "R", "D," or "T" site is chosen as the primary consistency point only when both "S" locations are unavailable.

On Private Mount: Always open single copy

By default, synchronous mode copy opens only one TVC during a private mount. The best TVC choice is used to satisfy the mount. The best TVC choice selection is made with location preferences in this order: synchronized ["S"], RUN ["R"], deferred ["D"], and time-delayed ["T"]. If a write operation occurs, the job enters the synchronous-deferred state regardless of whether the Synchronous Deferred On Write Failure option is enabled.

On Private Mount: Always open both copies

Enable this option to open both previously written "S" locations when a private mount occurs. If one or both "S" locations are on back end tape, the tape copies are first recalled into disk cache within those locations. The Always open both copies option is useful for applications that require synchronous updates during appends. Private mounts can be affected by cache misses when this option is used. Other circumstances to consider include:

If a private mount on both locations is successfully opened, then all read operations use the primary location. If any read fails, then the host read also fails and no failover to the secondary source occurs unless a z/OS DDR swap is initiated.
If a write operation occurs, both locations receive write data and must synchronize it to TVC disk during each implicit or explicit synchronization command.
If either location fails to synchronize, the host job either fails or enters the synchronous-deferred state, depending on whether the Synchronous Deferred On Write Failure option is enabled.

On Private Mount: Open both copies on z/OS implied update

Open both previously written "S" locations only when requested by the host to do so. This takes place when the mount request from the host has either write from BOT or update intent specified.

Table 2. Synchronous Mode Copy settings
Synchronous Deferred on Write Failure	The copy that is deferred on the unavailable cluster in a synchronous copy pair. By default, synchronous deferred on write failure is disabled and only visible when synchronous copy mode is used.
On Private Mount	When a private mount occurs, these options determine whether one or both tape volume cache (TVC) synchronized ('S') locations are opened. Always open single copies Only one TVC location is opened during a private mount. The best TVC choice is used to satisfy the mount in the following order: 'S', RUN ('R'), and deferred ('D'). Always open both copies Both previously written "S" locations are opened when a private mount occurs. Open both copies on z/OS implied update Both previously written 'S' locations are opened when a private mount occurs unless the host implies an update to the last updated mount. An update is implied when the host sets either the intend-to-update flag or the write-from-beginning-of-tape flag on the last updated mount. If an update is implied but does not occur, then the mount either enters the synchronous-deferred state or fails.

Use the drop-down menu on the Management Classes table to add a management class, modify or copy an existing management class, or delete one or more existing management classes.