Volume replacement policies

DFSMSrmm supports policies for volume replacement. You define them in the MEDINF commands in parmlib. This enables you to define different replacement policies based on media type and recording format. The replacement policies are implemented for all types of volumes, other than logical volumes, and for both private and scratch volumes, but not for those volumes pending release. Until you define one or more MEDINF commands in parmlib with the REPLACE operand, DFSMSrmm processing uses a hard-coded value of PERM(1).

Volume replacement policies are implemented during inventory management expiration processing for stacked and physical volumes. This enables the release action for private volumes that meet or exceed one or more of the threshold values to be changed from SCRATCH to REPLACE (and from RETURN to REPLACE for WORM volumes) so that the volumes are identified for replacement. Later, if and when the data expires and the volume is released, the volume pending actions are set from the release actions. It also enables scratch volumes to be processed by the replacement policies and if any threshold is met, the release action is set to REPLACE, and the scratch volume is changed to master status pending release.

When inventory management sets the release action, the volume last change user ID is set to '*HKP' and if the volume is scratch, the volume owner is set to 'REPLACE'. Any other subcommand processing sets the last change user ID as normal and any other fields based on the subcommand operands and the command issuers ID.

DFSMSrmm open-time volume validation checks if a volume opened for output processing has the REPLACE release action and rejects the volume. This prevents volumes that need to be replaced from being used for new data sets. Existing processing rejects volumes pending release.

You can report on volumes that need to be replaced:

Use the RMM SEARCHVOLUME subcommand with the ACTION(REPLACE) operand. This lists the volumes that are ready to be replaced. You can physically replace them and confirm the replace action with the command:
```
RMM CV volser CRLSE(REPLACE)
```
or, you can delete them from DFSMSrmm with the command:
```
RMM DV volser REPLACE
```
and destroy the volumes.
Alternatively, if you do not want to replace or destroy a volume marked for replacement, you can turn off the replace action with the command:
```
RMM CV volser REPLACE(NO)
```
To have the replacement policy re-applied, you can reclaim the volume from pending release with the command:
```
RMM CV volser RETPD(1) RELEASEACTION(SCRATCH)
```
When the volume is next processed by EXPROC, the REPLACE policy is used to determine if the REPLACE action is required.
Use the SEARCHVOLUME subcommand with the RELEASEACTION(REPLACE) operand. This lists the volumes that should be replaced, but contain data that has not yet expired.
- For physical volumes, if the data does not expire soon, you should consider copying the data to a new volume and then release the volume so that it can be replaced or destroyed. You can use a product such as IBM Tivoli Tape Optimizer to copy the data to a newer volume.
- For stacked volumes, check how the stacked volumes is being used by the virtual tape system. For exported volumes, consider importing the logical volumes back to a library enabling the stacked volume to be removed from service. For stacked volumes in use inside a virtual tape system, consult the appropriate documentation for how to remove a volume from service.
DFSMSrmm also provides sample reports in the Report Generator.

EREP and the IBM Service Agent provide reporting capability based on LOGREC and SMF records and can generate a report of volumes that should be replaced. There is no current link between this report and DFSMSrmm. DFSMSrmm tracks volume usage and I/O errors and now provides support for volume replacement policies. You could manually use EREP or Service Agent (with IBM Service support) reports as a base for setting the REPLACE release action.

IBM also has a function called Statistical Analysis & Recording System (SARS) that is used by current IBM tape drives for tracking media statistics to determine or predict media failure. DFSMSrmm now uses the alerts from SARS Media Information Messages (MIM) to drive the setting of the REPLACE release action. This ensures that the best decisions about replacement are taken because the IBM tape hardware uses many different factors in considering whether a tape volume is still in good shape. MIM alerts occur at the time a volume is used and are intercepted and handled on z/OS by device services and an eventual action message issued to the console. The message number is IEA486E. WTO message ID IEA486E is now intercepted by the DFSMSrmm subsystem and the MIM message code used to determine the action that needs to be taken. Any message code (mc) that is one of 60-62 or 64 is used to drive volume replacement.

An example of message IEA486E:

IEA486E dddd, TVOL, severity ALERT, VOLUME=volid, S=s, MC=F0, E=e,REF=mcee-mmmm-tt, REPEATED.

Where:

severity

Is one of the following:

ACUTE: indicates that tape directory errors occurred
MODERATE: indicates that high temporary read or write errors occurred
SERIOUS: indicates that permanent read or write errors occurred
SERVICE: indicates cleaner cartridge

mc

MIM message code. Values DFSMSrmm cares about are 60, 61, 62, and 64; these cause the REPLACE release action to be set in place of the SCRATCH release action (and from RETURN to REPLACE for WORM volumes), if not already set.

SARS driven actions override DFSMSrmm policies by causing the volume release action to be set to REPLACE when the existing release action is SCRATCH. For scratch volumes, the release action is set to REPLACE, the volume is changed to master status, and then released.

When interception of a SARS MIM message sets the release action, the volume last change user ID is set to *mim and, if the volume is scratch at the time the SARS MIM message driven processing occurs, the volume owner is set to 'SARSMIM'. Any other subcommand or subsystem processing sets the last change user ID as normal and any other fields based on the subcommand operands and the command issuers ID, therefore the last change user ID is likely to change. However, you can use the EDGAUD audit report with a SYSIN command of SELECT USERS(*mim) to report on volumes updated as a result of SARS MIM driven processing even if the volume has later been updated.

For active volumes (those that are used regularly), the SARS functionality is the best way to identify volumes that need to be replaced based on problems that SARS detects with the media. For volumes that are not used regularly, perhaps because they are scratch or are subject to long term retention, either on-site or off-site, the DFSMSrmm replacement policies provide a good way to manage the life of the volume because the policies are used regularly by expiration processing. For IBM virtual tape libraries, the SARS alerts for stacked volumes are handled internally to the library and volumes removed from use as required. There is no automatic way for the DFSMSrmm policies to be used other than for AGE.