The customer is planning to move to a new site and is asking to move all the physical tapes to DASD to be faster. The tapes are managed by CA-Vtape and CA-1.
The Vtape DASD cache will be increased such that all of the tape data will reside on DASD, and the data will then be replicated to the new site using some kind of P2P connection. How could this be accomplished with Vtape?
Release : 12.6
Component : VTAPE
There are a couple of methods that could be used here.
The Vtape data can be replicated on a target (remote) system using the Vtape P2P option (extra license is needed for this feature). After the P2P option is configured, the local system data can be copied to new volumes which would then cause the data to be replicated onto the remote system. This process does NOT, however, catalog the data on the remote system. This will need to be done outside of Vtape processing (if there is shared DASD between these systems, and the data sets are cataloged to specific user catalogs, this may help with getting this catalog information onto the remote system).
The Vtape data could be copied into Vtape cache (using a utility such as CA Copycat with the FILECOPY option, and processing only the *primary* volumes of any volume sets) and assigned to a Vtape group with the 'CACHONLY' attribute set. This will prevent this new, copied data from being 'overlaid' with other Vtape data as it will be marked internally as 'not backstored', and thus not eligible to be overlaid with other Vtape data. Depending upon how the backstored data/volumes are managed in CA1, and what FILECOPY processing options are used, it is possible that when this data is copied to new volumes into the CACHONLY groups, the original virtual volumes on physical tape may become uncataloged, thus not easily accessed again should a need arise to do this. To avoid this possible exposure, the Vtape USS feature could be implemented so that when the volumes are copied into the CACHONLY groups, a 'triplex' copy of the same data could be made to USS DASD storage, and this data could also be migrated to the target site along with the CACHONLY data.
Some notes to be aware of:
1) The Vtape DASD cache that is allocated should be large enough to recall all of the virtual volumes from physical tape PLUS have enough for any NEW or COPIED data that is written to the CACHONLY groups.
2) When you initially recall virtual volumes from the physical backstore tapes, this data will NOT be fully protected from being overlaid with other data. In order to copy the data to the CACHONLY groups, the data will need to be recalled into cache first (either implicitly, by being referenced in a job which triggers backstore recall processing, or explicitly via a 'SVTn START RECALL=xxxxxx' command, or the Vtape 'mass recall' job found in the **.CCTUJCL data set).
3) When the data is copied to new volumes of the CACHONLY groups via FILECOPY, the data sets may be re-cataloged to the new virtual volumes. The prior catalog entries (for the files and Vtape VVE virtual volume entries) may be altered/deleted.
4) Several FILECOPY parameters which involve cataloging of the target data sets or updating of the TMC with catalog info, or involving file selection are:
INDISP/OUTDISP - Determines the retention for the input/output files.
FILES - Determines which files are copied. This parameter can take values such as: ALL / SPECIFIC / ACTIVE.
RECATLG - Determines the MVS catalog action to be performed for the output volumes created on OUTUNIT. This parameter takes values such as: ALL / PREV / NONE.
5) It is recommended to run a Vtape LIST=BACKSTORE report before moving the data to the new virtual volumes, in case data recovery is needed from the physical tapes (this will help to identify the physical volumes from which that data resides, along with file seq numbers). Also, the Vtape LIST=CACHE report can be used to determine what volumes are currently in Vtape DASD cache.