Tapes are not being UNCATALOGUED/SCRATCHED after executing a successful SARPAC

Products

• View

Issue/Introduction

I ran tape consolidation against our smallest database, and it all worked well. The tapes that were consolidated however, are still cataloged and therefore according to a Tape Retention rule, it won't be returned to the RMM scratch pool until its un-cataloged. Is that something that we have to account for and take care of?  I would have thought SAR would have removed them somehow... Is there a utility to do this ?

Environment

Release : 14.0, View, SARPAC, RMM, NOT, SCRATCHED, AFTER

Resolution

Regarding your SARPAC'd tapes not being uncatalogued...

The SARPAC utility itself does not issue MVS UNCATALOG requests. All SARPAC is doing is moving the "active" data from the old tapes to the new tapes.

The OLD SARPAC tapes should be uncatalogued after the next standard View BACKUP process runs. The BACKUP will determine that there are no longer any "active" reports on those OLD tapes and consequently, will issue the MVS UNCATALOG request for them.

* Note - Be aware that any tapes that show "INDEX ONLY" in the Remarks Field of the SARPAC REPORT will not be uncatalogued until such time as when the value defined for the SARINIT "NGENI=" parameter has been exceeded. ((Or NGENT= if NGENI is not specified)).

* Also, please review Knowledge "Article Id: 28228 - How to Protect Your CA View Tapes with CA Tape Management Systems" and  discuss this with your storage group. Make sure your Tape Management System does not automatically uncatalog any View tapes that were created as the result of a failed BACKUP or SARPAC execution.

Additional Information

- Support generally recommends that a LOW value such as 2 or 3 be specified for the NGENI parameter so that tapes that ONLY have a backup of the master index on them, (No actual report data), will be freed for scratch sooner rather than later.

- To avoid possible loss of report data, the most CURRENT master index backup should always be used for any type of restore/recovery scenario.