Recover virtual tape - scratched
search cancel

Recover virtual tape - scratched


Article ID: 214040


Updated On:


Vtape Virtual Tape System


Virtual tape shows in scratch status but has not been written over.  The virtual tape does not show to be on the VTAPE primary and duplex backups.  The backstore primary tape is also in scratch status but has not  been written over.   Can I recover this virtual tape ?


Release : 12.6

Component : CA VTAPE


The general method for recovering a scratched virtual volume, as outlined in the 'CA Vtape Virtual Tape System Administration Guide' is as follows: 

You can reactivate a Virtual Volume that has been scratched if its Backstore Primary or Duplex Tape is still available.  

To reactivate a Virtual Volume:

1. Look up the Virtual Volume in the tape management system. If the VOLSER has been reused, copy the new data set to another Virtual Volume to free up the VOLSER.
2. After Externalizing the new Virtual Volume, scratch the needed VOLSER in the tape management system and in the Global VCAT. To scratch the VOLSER in the Global VCAT, execute the SVTSUTIL batch command VVE_SCRATCH=volser where volser is the Virtual Volume VOLSER.
3. Look up the physical tape in the tape management system. If the tape has been scratched, return it to active status.
4. Look up the data set records for this physical tape and return the expired Virtual Volume data set to active status.
5. Using the information from the tape management system, customize and execute the sample JCL found in HLQ.CCUUJCL(CATBKSTR) to recatalog the Virtual Volume Backstore Entry:
Update the tape management system to return the Virtual Volume to active status with the correct application data set name and other information. Ensure that the expiration date is extended to prevent the Virtual Volume from being scratched too soon.
6. Issue the SVTn START RECALL=volser console command to manually Recall the Virtual Volume.
The Recall reactivates the Virtual Volume in the Global VCAT and allows the application to read it. 

Now, in this case the backstore PRIMARY (physical) volume was in scratch status.  To recover the virtual volume from this physical volume, the following additional notes apply:  

1. To remove both the virtual and physical volumes from scratch status, the user can go into the CA1 ISPF panels and for each volume enter 'U' to update the TMC volume records by setting the EXPDT for each tape to a future date.  This will turn off the 'scratch bit' for the volume. 

2. If the tape volume is in the physical ATL, a CTSSYNC should be run to synchronize the CA1 TMC with the TCDB (VOLCAT) and the LM (Library Manager) of the ATL.   

3. If a Vtape RECALL is performed, and the message "SVTnPR108W  VVVVVV RECALL ON VOL PPPPPP,VOL/DARC/SMSINFO FOLLOW:" is issued, and the SVC 99 Error Code is 02700000, then this is likely caused by the physical volume not being available in the ATL.  To verify existence of the physical volume in the ATL, the command "DISPLAY SMS,VOLUME(PPPPPP)" can be issued.  For the volume to be properly located in the ATL, the output fields LIBRARY CATEGORY should show 'PRIVATE' (and not 'NONE'), and the LIBRARY NAME should show a valid library name (and not 'SHELF',  which means the tape is external to the library). The physical tape will need to be checked into the ATL before Vtape RECALL can be performed, and a CTSSYNC can be run to re-verify that all DB's are in sync with each other.  

4. Another way to verify that the physical volume is properly located in the ATL is to run a Copycat or CTS tapemap.  If the CTS message CA$F062E  SVC 99 ERROR - DDNAME ‘cccccccc‘ - ERROR CODE ‘0270‘ - REASON CODE ‘0000’ is issued, then this indicates that the volume is not in the ATL.  If an SVC 99 error code of '0484' is received during tapemap, this indicates an 'environmental' type of error which could also be caused by the tape not being in the ATL.  If the user receives the error IEC147I  613-60, then the tapemap job will need to be run with the proper Jobclass which uses BLP=YES. 

5.  The DSNBs for the target virtual volume do NOT need to be re-created via TMSAGGR, as it should be possible to read the virtual volume files without having these control blocks available (however, if updates or MODing onto the virtual is needed, then these DSNBs will need to be present). 




Additional Information

See the manual "CA Vtape Virtual Tape System Administration" for details on virtual volume (and other) data recovery procedures. 

See the manual "OSMVS Programming: Authorized Assembler Services Guide" for details on decoding SVC 99 (Dynalloc) error codes.