Identifying WORM tapes ready for destruction or reuse

Because physical WORM tapes cannot be reused, you cannot return the volumes to the scratch pool when the data has expired. Normally, you would expect the volumes to be destroyed once all the data has expired. Logical WORM tapes can be returned to the scratch pool, allowing the volumes to be reused either as WORM or R/W logical volumes. You can use the volume release actions to control how DFSMSrmm manages this process.

By default, DFSMSrmm sets the volume release action as follows:

For physical WORM, the return to owner release action is set, but you can use the replace release action instead, by changing the release action at any time during the volume's life.
DFSMSrmm REPLACE policy implementation for physical WORM tapes results in the REPLACE release action for tapes that meet the replacement criteria. IBM® recommends that you use the return to owner release action, so that any WORM volume with the replace release action is known to need replacement based on the REPLACE policy.
For logical WORM, the replace release action is set.

You can use the release actions for the volumes to determine the processing required. For physical WORM:

You can list all the WORM tapes that are pending return to their owner. Pick the volumes from the list and destroy them. After the volumes are destroyed, use the RMM CHANGEVOLUME * CRLSE(RETURN) or RMM CHANGEVOLUME volser CRLSE(RETURN) command to confirm the release action, which deletes the volume information from the DFSMSrmm control data set.
You can list all the WORM tapes that are pending replacement. Pick the volumes from the list and destroy them. Create new WORM tapes that use the same set of volume serial numbers. After the volumes are destroyed, use the RMM CHANGEVOLUME * CRLSE(REPLACE) or RMM CHANGEVOLUME volser CRLSE(REPLACE) command to confirm the release action, which resets the volume information to reflect that the volume has been replaced. Alternatively, if you do not want to replace the volumes, but would rather delete them from the DFSMSrmm control data set, use the RMM DELETEVOLUME volser REPLACE subcommand.
When the REPLACE release action is set based on the REPLACE policies, but is not yet pending, you should consider whether to copy the data to a newer WORM volume and destroy the WORM volume that has now matched your replacement policies. Use the DFSMSrmm VRS retention information for the data sets on the volume and the volume expiration date to determine how much longer the data needs to be retained.

You do not need to take any action to have logical volumes (whether WORM or R/W) automatically returned to scratch and available for reuse as either logical WORM or as R/W logical volumes.

To prevent logical WORM volumes returning to scratch automatically, use VLPOOL with RELEASEACTION(NOTIFY). This forces the NOTIFY release action for all volumes in the pool and requires you to issue RMM CV volser CRLSE(NOTIFY) to confirm the action before the REPLACE is handled automatically. Refer to z/OS DFSMSrmm Implementation and Customization Guide, SC23-6874 for information about how to use NOTIFY and ensure that it requires a manual action.