SVTS Reserve

CA Vtape keeps its control information in a dataspace and writes it out to the Global VCAT and BSDS data sets. To ensure the integrity of these updates, a hardware reserve is issued with QNAME=SVTS against the volume the Global VCAT resides on.

The RNAME value used is determined by setting the GlobalReserve attribute located in the Dynamic Options Section of the OSPARMS parmlib member.

If Enhanced is coded, the RNAME value includes part of the Global VCAT and BSDS data set names. This allows multiple CA Vtape Complexes to reserve their own control data sets with a unique RNAME value. Complex A can update its own control data sets without having to wait on Complex B while it is updating its control data sets.

If COMPATIBILITY is coded, the RNAME value is GLOBAL. In a multiple CA Vtape Complex environment, a reserve issued with the generic RNAME of GLOBAL will force one complex to wait before updating its control data sets while another complex is updating its own control data sets.

Enhanced is the recommended setting.

When CA Vtape is running with GlobalReserve=Enhanced a scan is performed for the QNAME=SVTS, RNAME=GLOBAL reserve. If the Compatibility reserve is detected, the detecting CA Vtape will dynamically change to GlobalReserve=Compatibility to prevent possible control data set corruption. Corruption could occur if two Subsystems sharing the same Global VCAT and BSDS are started with different GlobalReserve settings.

You can also dynamically switch between values by updating the GlobalReserve attribute and issuing the SVTn REFRESH=OPTIONS console command. If you change to Compatibility, any other subsystem in the complex that is running with Enhanced automatically switches to Compatibility as soon as your change is detected. If you change to Enhanced and any other subsystem is running with Compatibility, the subsystem you just changed will switch back to Compatibility.

If you have a DASD resource serialization manager such as CA MIM or IBM Global Resource Serialization (GRS), you may want to convert QNAME=SVTS hardware reserves to SCOPE=SYSTEMS enqueues. However, in some cases this approach can lead to integrity exposures and corruption of the Global VCAT and the BSDS.

Note: The F MIM, DISPLAY INIT command can be used to determine your GDIF PROCESS=SELECT/ALLSYSTEMS operating mode value.

Important! All instances of the QNAME=SVTS hardware reserve, regardless of the RNAME value, must be managed the same way on all systems. Converting some QNAME=SVTS reserves and not others will create an integrity exposure that could result in data loss.

Also, if the QNAME=SVTS reserve is converted to an enqueue for a CA Vtape Complex that is running in multiple sysplexes and you do not use IBM's GDPS/PPRC HyperSwap, the resulting integrity exposure could cause a data loss.

The following sections describe two different implementations, the recommended implementation and the required implementation for sites using IBM's GDPS/PPRC HyperSwap product.

Recommended Implementation, IBM’s GDPS/PPRC HyperSwap Product Not Used

Note: If you are not using IBM's GDPS/PPRC HyperSwap product, do not convert the QNAME=SVTS hardware reserve with CA MIM or IBM GRS to an enqueue.

If CA MIM is in ALLSYSTEMS mode, add the following statement to the MIM MIMQNAME parmlib member to tell CA MIM not to convert the QNAME=SVTS hardware reserves:
```
SVTS GDIF=NO
```
If CA MIM is in SELECT mode, you do not need any MIM MIMQNAME or GDIEXMPT parmlib member updates. By default hardware reserves are not automatically converted.
For IBM GRS, you do not need any GRSRNL00 parmlib member updates. By default hardware reserves are not automatically converted.

Required Implementation, IBM’s GDPS/PPRC HyperSwap Product in Use

Note: If you are using IBM's GDPS/PPRC HyperSwap or you are sure you will never share a Global VCAT and BSDS between more than one sysplex, you can safely have CA MIM or IBM GRS convert all instances of QNAME=SVTS hardware reserves to a SCOPE=SYSTEMS enqueue.

If CA MIM is in ALLSYSTEMS mode, you do not need any MIMQNAME or GDIEXMPT parmlib member updates, because all hardware reserves are automatically converted in this mode.
If CA MIM is in SELECT mode, add the following statement to the MIMQNAME parmlib member to convert all QNAME=SVTS hardware reserves to a SCOPE=SYSTEMS enqueue:
```
SVTS GDIF=YES,
SCOPE=RESERVES,
EXEMPT=NO,
ECMF=YES,
RPTAFTER=30,
RPTCYCLE=60
```
For IBM GRS, add the following statement to the GRSRNL00 parmlib member to convert the QNAME=SVTS hardware reserves to a SCOPE=SYSTEMS enqueue:
```
RNLDEF RNL(CON)  TYPE(GENERIC)  QNAME(SVTS)
```