Wrong density passed to VM:Tape from VM:Backup for RESERVE TAPE

Products

• VM:Backup for z/VM
• VM:Backup High-Speed Disaster Recovery Option (HiDRO)
• Mainframe VM Product Manager
• VM:Manager Suite for Linux on Mainframe
• VM:Manager Suite for z/VM
• VM SUITE
• VM:Tape for z/VM

Issue/Introduction

Started using new media, changed the TAPEPOOL record in VMBACKUP CONFIG file.

TAPEPOOL VTSINH MEDIA ENH DENSITY ENHXF ASKADD SCRATCH

In VM:Tape, the SERIES and POOL files refer to:

DSN=*,JOB=VMBACKUP,POOL=VTSINH        
SCRPOOL=VTSINH,RANGE=Q00000-Q99999 

SERIES  Q00000  100000  ENHA 

VMTAPE Q TA
VMTQRY191I 0170 3490E   36trk,38K/XF   FREE 

It appears that all looks okay with a SERIES record of ENHA and a VM:Backup TAPEPOOL record of ENH for MEDIA and ENHXF for DEN.

However, VM:Backup is sending over the mount as:
VMBACKUP 007 VMTVMB600I Beginning: 'RESERVE TAPE SCRATCH 310 DSN DAILY. PRIMARY (LABEL SL DEN EXF' for 00000001
End result is:

VMBACKUP 007 VMTAPK304E No VTSINH scratch CART volumes available; mount canceled.

So, it appears that VM:Backup is sending over EXF for density rather than ENHXF.

Resolution

The first recommendation is to change RESERVE ON to OFF in the VMBACKUP CONFIG file. It is not recommended that you have RESERVE ON when running with silos on VM:Tape.

When SCRATCH is included on the VM:Backup TAPEPOOL record, it tells VM:Tape to obtain tapes to use in VM:Backup backup and MPC jobs from general scratch tapes found in the VM:Tape TMC. SCRATCH is applicable only when the VM:Tape interface is enabled.

When SCRATCH is not on the TAPEPOOL record, the correct density is passed. SCRATCH would not be used when you are using POOLS on VM:Tape. Without SCRATCH, the MOUNT command going over to VM:Tape would contain the name of the POOL that VM:Backup is supposed to use.

Removing SCRATCH from the TAPEPOOL records in VM:Backup should resolve this type of problem.