Question & Answer
Question
Answer
Description:
Normally, it takes two runs of Expiration processing (EDGHSKP EXPROC) to scratch a virtual volume. During the first EXPROC run, if both the virtual volume Retention Date (calculated by VRSEL) and the virtual volume Expiration Date (set during data set open) have passed, the virtual volume Status remains MASTER but the Availability is set to Pending Release (in case you want to reclaim the volume). During the second EXPROC run, if there are no pending actions (for example, INIT, ERASE, REPLACE, RETURN, and so on.) and/or pending moves that need to be confirmed, then the virtual volume Status is set to SCRATCH.
If EXPROC fails to release the virtual volume, perform the following checks.
Note: If you have any additional question or concerns regarding the resolutions that are outlined, open a Q&A/Usage Service Request. The resolution section does not consider all possible variations of potential causes for virtual volumes not being scratched and should be regarded as a series of preliminary steps to take prior to opening up a Q&A/Usage Service Request.
Resolution:
Use the ' RMM LISTVOLUME volser ALL' subcommand or the RMM panels to display RMM virtual volume information.
1) Check the Status field. If Status = SCRATCH, then RMM already released the virtual volume. If Status = MASTER, continue to Step 2.
2) Check the Availability field.
If Availability = Vital Record:
EDGHSKP Vital Record SELection processing (VRSEL) is retaining this virtual volume because a data set on the virtual volume is retained by a vital record specification (VRS). Search for the volser in the Vital Records Retention Report (REPORT DD) produced by VRSEL processing to determine which data set and data set-type VRS are involved. Remember, a virtual volume with multiple data sets might be covered by more than one VRS definition. (A virtual volume might also be retained by a volume-type VRS.)
If Availability = Pending Release:
A) Check the Actions Pending section of the LISTVOLUME output. If any actions are pending -- Init = Y, Erase = Y, Notify = Y, then the virtual volume cannot be scratched. Use the CHANGEVOLUME subcommand with the CONFIRMRELEASE (or CRLSE) operand to confirm that the pending action is completed. For example, specify CONFIRMRELEASE(INIT) to confirm that the volume is initialized. Once confirmed, another inventory management run is required to scratch the virtual volume. If the actions pending are either Replace = Y or Return = Y, then use CHANGEVOLUME subcommand with the EXPDT(future_date) RELEASEACTION(SCRATCH) to reset the replace and return flags (note that it is recommended to set the expiration date to a future date – hence the EXPDT parameter set to future_date in the provided example). After resetting the replace and/or return flag, release the virtual volume with the DELETEVOLUME subcommand (for example, RMM DV volser RELEASE) and then another inventory management run will scratch the virtual volumes. See below, for example, steps to follow. If you do not see any of the following flags, but the volume is "Pending Release", then refer to the following section to check the "In transit" flag and whether the CATSYSID parmlib member option is specified.
i. If Init = Y, then
a. RMM CV volser CRLSE(INIT)
b. run EXPROC
ii. Else if Erase = Y, then
a. RMM CV volser CRLSE(ERASE)
b. run EXPROC
iii. Else if Replace = Y, then
a. RMM CV volser EXPDT(future_date) RELEASEACTION(SCRATCH)
b. RMM DV volser RELEASE
c. run EXPROC
iv. Else if Return = Y, then
a. RMM CV volser EXPDT(future_date) RELEASEACTION(SCRATCH)
b. RMM DV volser RELEASE
c. run EXPROC
v. Else if Notify = Y, then
a. RMM CV volser CRLSE(NOTIFY)
b. run EXPROC
B) If In transit = Y (under the Store Information section), then a “move” is in-progress – however, because the volume is a virtual volume, it is not moving but rather being assigned to a different location. Given that the volume is virtual and cannot move, it results in the In transit flag remaining on indefinitely. Regardless of the type of volume, RMM interprets this In transit flag as a tape volume moving locations. To cancel the move, use the RMM CHANGEVOLUME subcommand with LOCATION - to set the virtual volume location back to its Current location - for example, RMM CV volser LOCATION(current_location). Note that the CURRENT location should match the HOME location (typically a library name) for virtual volumes. To prevent automatic volume movement (which results in the In transit flag being set on) for any type of volume (typically utilized to prevent virtual volumes from having In transit = Y) in a particular library, specify LOCDEF LOCATION(library_name) TYPE(LIBRARY) AUTOMOVE(NO) option in the EDGRMMxx parmlib member - where library_name is the name of the virtual tape library where the virtual volumes reside.
C) If In transit = N, the Destination field is blank, the volume is in its Home location, and there are no pending actions, then the volume should return to scratch during the next EDGHSKP EXPROC run.
If the virtual volume is system-managed, in order to prevent the RMM CDS and the VOLCAT from getting out-of-sync, RMM will not change the status of the virtual volume in the RMM CDS from MASTER to SCRATCH if the update to the TCDB fails. The system running Inventory Management processing must have access to the TCDB. Check for errors in the RMM EDGHSKP Message file (MESSAGE DD).
Additionally - when the In transit flag is off - check whether the CATSYSID parmlib member option is specified within your EDGRMMxx parmlib member. Specifying this parameter with anything other than "CATSYSID(*)" indicates to RMM that you are not fully sharing catalogs across all the systems that share the RMM CDS. When catalogs are not fully shared, the volume must be returned to scratch on a system with access to the catalogs where the first file was created. In other words, if the EDGRMMxx parmlib member has a value other than * for CATSYSID, then EXPROC has to run on the LPAR that assigned the first data set to the virtual tape volume. For example, tape volume A00000 has a data set written/assigned to it from system SYSA, the EDGRMMxx parmlib member has CATSYSID(SYSB) specified, and RMM housekeeping (EDGHSKP) is regularly done on SYSB, then the volser A00000 will be set to "Pending Release", and it stays in that availability (instead of scratching the tape volume) until EXPROC runs on SYSA. Reference the ASSIGN field on an RMM LISTVOLUME volser display to see what LPAR wrote the first file on the volume and compare this value to the CATSYSID value in EDGRMMxx (or in the MESSAGE file of EDGHSKP run), if they are different then EXPROC must be run on the system specified in the ASSIGN field.
If Availability is blank:
A) Check when the RMM EDGHSKP inventory management utility was last run. For virtual volumes managed by the VRSEL retention method, RMM does not mark a virtual volume pending release if the virtual volume's last change date is more recent than the time of the last VRSEL processing run. The last change date might have changed for one of these reasons:
i. The virtual volume is used or updated outside of EDGHSKP processing
ii. A move is confirmed since the last VRSEL processing
B) Check the virtual volume's Expiration Date, the virtual volume's Retention Method, and if you have specified that RMM should ignore the expiration date for the virtual volume. Look at the virtual volume's Action on Release: Expiry date ignore setting. If the expiration date is not ignored based on the retention policies you defined, RMM keeps the volume until the expiration date is reached, even though the volume is no longer covered by a vital record specification.
The default expiration date set by RMM is the creation date plus the EDGRMMxx PARMLIB member RETPD value. You can override the default by using the RMM CHANGEVOLUME subcommand with the EXPDT or RETPD operands. A common error occurs when you are using expiration dates that have special meaning ("special dates"). Examples of these dates include EXPDT= 99000. RMM requires the use of the RMM EDG_EXIT100 exit or the Default Table (EDGDEFxx parmlib member) to clear the expiration date field in the JFCB (JFCBXPDT) and assign a vital record specification management value for these dates. With the RMM EDG_EXIT100 exit or Default Table, the virtual volume's expiration date is set to the creation date plus the EDGRMMxx parmlib member RETPD operand value. If EDG_EXIT100 or Default Table does not clear JFCBXPDT, the EXPDT date is passed to RMM. RMM translates EXPDT=99000 to an expiration date of 1999/000 (a past Julian date), which causes RMM to consider the virtual volume to be already expired. To avoid premature expiration of virtual volumes, check the EDG_EXIT100 exit or Default Table to ensure that the correct management value is being assigned and also verify that the VRS (by that name) is also defined. If you did not intend to use an expiration date that has a special meaning, use the RMM CHANGEVOLUME subcommand to specify the correct expiration date.
When using VRSEL as the retention method for virtual volumes [that is, RM(VRSEL) is specified in your EDGRMMxx parmlib member] and the RETAINBY(SET) parmlib option is also specified within your EDGRMMxx parmlib member, then a virtual volume can still be retained past its expiration date (if the virtual volume is not VRS retained) because another volume within the set is still being retained, and therefore the entire set is still being retained. Check the latest expiration date within the set of volumes to see when the set expires.
You can use the RMM Dialog to view the vital record status for virtual volumes and data sets. Volume search-results lists include 'VRS' in the ' Status' column and Set Retention state in the ' S R' column. Data set search-results lists show the vital record state in the ' V R' column. Select/display the data set details to view the matching VRS information and the VRS retention date. Move the cursor to the 'VRS name' and press enter to see a list of the VRSs, enabling you to look at the matching VRS details. You can also use the RMM LISTDATASET subcommand or the Vital Records Retention Report produced by EDGHSKP VRSEL processing to determine which data set and vital record specification are involved.
If Availability = OPEN:
When a data set on a virtual volume is open for a write operation, RMM sets a flag in the volume record. When Availability = OPEN, either a write operation is still in-progress, or the open flag did not get reset because of a system error (for example, an abend). When the open flag is ON during VRSEL processing, RMM assigns the virtual volume to the OPEN VRS definition (if one exists), otherwise, VRSEL tries to match the data set to a dsname mask VRS. For more information regarding how to add VRS definitions, refer to the ADDVRS information in the "Using RMM TSO subcommands" section of the "z/OS DFSMSrmm Managing and Using Removable Media" manual. To resolve virtual volumes held by the open flag, use the CHANGEVOLUME subcommand with the CLOSE operand to reset the indicator, so that during the subsequent run of VRSEL processing, the tape is released from the OPEN VRS and possibly reassigned to a matching VRS.
If Availability = On Loan:
The virtual volume (or any other type of volume) is in a loan location (that is, unavailable) and cannot return to scratch until it returns to its home location. RMM cannot manage virtual volumes that are on-loan. To resolve this unavailability, reset the loan location with the following RMM CHANGEVOLUME subcommand: RMM CHANGEVOLUME volser LOANLOC(''). After issuing the CHANGEVOLUME subcommand, then try running EXPROC again to see whether the virtual volume goes to scratch status (that is, Status = SCRATCH within the LISTVOLUME output).
3) If above does not apply; check your PRTITION commands in EDGRMMxx parmlib member or by issuing RMM LC ALL. PRTITION commands with TYPE(RMM) and IGNORE for volume or volume range will affect return to scratch processing by EXPROC.
For additional information regarding these procedures, see the current version of the following manuals:
SC23-6874-30 z/OS DFSMSrmm Implementation and Customization Guide
SC23-6873-30 z/OS DFSMSrmm Managing and Using Removable Media
Related Information
Was this topic helpful?
Document Information
Modified date:
29 June 2021
UID
ibm10871118