A MPC (Merge Purge Copy) job has run and completed successfully. The REINIT job runs and fails... Not all tapes that are in the MPC job are removed from the database. What needs to be done?
There are several reasons why a REINIT job may fail. Several unique reasons that have been encountered over the years are documented below.
Reason #1. VM:Backup is not interfaced with VM:Tape. This means that VM:Backup has a 1C0 disk, with tapepool files, where at least one of them contains the volsers that VM:Archiver uses for tapes. If the volsers were manually deleted from the tapepool file before REINIT runs, the process would not be able to delete them, which leads to failure.
Solution #1. Either restore the tapepool file back to it's original state before the volsers were manually removed and then run REINIT again. Or, manually add back into the tapepool file the volsers and the information necessary to complete a tapepool record, then run REINIT.
Notes to this solution:
The create and expir can be any date, jobname can be any 8 characters, as can be the vmbackup ident any 16 char. The volser and machine name must be correct.
Once REINIT has run, these records should no longer be in the tapepool file or in the VM:Archiver database.
Reason #2. VM:Backup is interfaced with VM:Tape. The volser in the TMC is in SCRATCH status, yet REINIT fails on this volser.
Solution #2. Most often this is due to the fact that even though the tape is SCRATCH, the OWNER field is populated with something other than VMARCH. Use the VMTAPE EDIT command and change the OWNERID to VMARCH (the name of the VM:Archiver service virtual machine) and then run REINIT.
Reason #3. VM:Backup is interfaced with VM:Tape. The volser in the TMC has been reused and no longer has an OWNERID of VMARCH (the name of your VM:Archiver service virtual machine).
Solution #3. This requires the interface between the VM:Backup service virtual machine and VM:Tape to be severed, and creation of a TAPEPOOL file on VM:Backup's 1C0 disk.
- End VMBACKUP
- Make the following changes in the VMBACKUP CONFIG on the 191 disk of VMBACKUP:
Comment out the PRODUCT VMTAPE record
Add a TAPEPOOL record for VMARCH:
TAPEPOOL VMARCH MEDIA CART DENSITY 38K ASKOPER
To ensure that NO VM:Backup jobs run while the VM:Tape interface is severed, comment out the MULT record and create a new one:
MULT JOBS 1 BACKUPS 0 RESTORES 0 TRESTORE 0 URESTORE 0 MPC 0 REINIT 1
Verify that there is a TAPEDISK record and that the VADDR is valid. This may require the addition of a 1C0 mdisk of 1 cylinder to the VM:Backup directory entry.
- Create a VMARCH TAPEPOOL file on the TAPEDISK mdisk specified in the VMBACKUP CONFIG file.
- In that file, create a record for each volser. Use the same layout as described in Solution #1.
- Initialize VM:Backup and run the REINIT job.
Once the REINIT job runs to completion without errors, END VM:Backup:
- Put back the VM:Tape interface
- Put back the original MULT record
- Comment out or remove the TAPEPOOL record for VMARCH
- Either remove the 1C0 disk (TAPEDISK) or leave alone.
Reason #4. VM:Backup is interfaced with VM:Tape. The VOLSER is no longer in the TMC.
Solution #4. It makes no sense to add the VOLSER back into the TMC. Follow the steps outlined in Solution #3.
In one case, after the correct solution was followed, the volser did not appear in the VMTAPE LIST SCRATCH. Upon research, it was determined that the volser OUTCODE field was populated. Once that OUTCODE was set to NULL and REFRESH was run, the volser appeared in the LIST.
If you have a REINIT job that failed for other reasons, contact CA Technical Support at 703-709-4980.