Is there anything in the CA Vtape VTS PARMLIB that could increase Virtual Volume usage?

Document ID : KB000048298
Last Modified Date : 14/02/2018
Show Technical Document Details


We are using a lot more Virtual VOLSERs than I anticipated. Could the CA Vtape VTS PARMLIB be configured incorrectly?


Not really. The number of VOLSERs used is determined by the amount of data being written, the retention period of the Virtual Volumes, and the size of the Virtual Volumes.

Typically the reason for an increase in Virtual Volume usage is:

  1. An increase in the size of the data sets being written to Virtual Volumes.
  2. An application being changed to use CA Vtape VTS.
  3. An increase in the retention of the Virtual Volumes.
  4. An increase in the frequency that backup or archive jobs are being run.
  5. A combination of the above items.

There are only two parameters in the PARMLIB that might have an impact on the number of Virtual Volumes being used.

The first parameter is VolumeSize in the Volume Pools Section in the VTPOOLS member. If the increase in VOLSER usage is due to an increase in the size of the data sets being written, than increasing the size of the Virtual Volumes being written to would reduce the number of VOLSERs used.

For example, if the average size of the data sets being written to Virtual Volumes increases from 1800 MBs to 2300 MBs and your Virtual Volume Size is 2000 MBs, the average data set will now require two Virtual Volumes. If the VTPOOLS member is updated with VolumeSize=4G, the average data set of 2300 MBs will now only require a single VOLSER.

If someone accidentally changed this parameter to a lower size, this could explain the increase in Virtual Volume usage.

The second parameter is the HardwareCompressionOption in the Dynamic Options Section in the VTPARMS member and the Group Sections in the VTGROUP member.

If the HardwareCompressionOption was turned on and your Virtual Volumes were getting 50% compression when written to DASD, turning off the option could double your Virtual Volume usage.

If the VolumeSize and HardrwareCompressionOption parameters were not accidentally changed, then you need to run tape management system reports to determine the source of the increase in usage.

An application like IBMs DB2 which is writing image copies to separate Virtual Volumes for small table spaces, can use a lot of tapes in a short period of time if the backup is changed from running daily to running twice a day. If the retention of these backups is also doubled, the Virtual Volume usage by this one backup job could increase by a factor of four.

Changing these backups to stack their small table spaces on Virtual Volumes will have a positive effect on Virtual Volume usage.

Researching tape usage and modifying JCL can take a considerable amount of time. Virtual Volumes are not like real volumes in that they do not take up rack space or slots or have to be physically handled. A Virtual VOLSER is just an index entry in the CA Vtape VTS and tape management system control data sets that corresponds to catalog entries for a data set on DASD and potentially a Backstore Tape.

The amount of time spent researching tape usage and modifying JCL has to be balanced against the time spent increasing the size of the CA Vtape VTS and tape management system control data sets to expand the Virtual Volume Ranges and the increase in catalog space. Often times it is more cost effective to expand the Virtual Volume Ranges.