We found some tapes defined as 'SCRATCH' in the TMC, but defined as 'VOLSPECIFIC' in the VTS.
To fix this we ran 'VMTAPE REFRESH POINTER' (both without and with the SYNC option) and although it said 'done' the VTS still shows the volume as 'VOLSPECIFIC'.
Running VM:Tape with an IBM VTS.
Running REFRESH with the POINTER option only updates VMTAPE's PICK and SCRATCH List files and resets the scratch pick pointer back to the beginning of the list. It does not synchronize with the robot and updates the PICK/SCRATCH files based on the current information in the TMC only. The SYNC/NOSYNC option, when used with the POINTER option is essentially ignored.
The customer stated that this anomaly where some tapes were not scratched correctly in the VTS was the result of an intermediate condition during a DR test where some of the drives were temporarily set to READ/ONLY mode. When SCRATCH was run, the internal RMS processing picked one of the R/O drives and as a result when VMTAPE SCRATCH was run the commands sent by VMTAPE to RMS to SCRATCH the tapes in the VTS were rejected because of the R/O condition.
They said since, and normally, the VMTAPE SCRATCH processing works correctly so this was a one-time occurrence that he has to somehow correct.
It's also not a good option to just let REFRESH (without the POINTER option) run as that will interfere with normal tape processing, predominantly due to the console noise it will create on the VMTAPE and RMS consoles, and potential overhead in the VTS due to thousands of query commands.
You may also want to consider setting up a
"VMTSYNC" vmtape server to do this.