Previous Topic: Set up a SVTS Subsystem in a Separate CA Vtape ComplexNext Topic: CA Vtape P2P Advanced Configurations

CA Vtape P2P Option › Test Remote Virtual Volumes Access

Test Remote Virtual Volumes Access

The next logical step is to test your remote Virtual Volume access. Having systems which can communicate, you can now begin configuring one of these SVTS subsystems for remote Virtual Tape processing. This entails setting up remote drives, Virtual Volume pools, remote groups, and finally remote data filters.

To configure a SVTS subsystem for remote Virtual Tape processing

  1. Logically, SVTS treats local Virtual Tape units (VTU) and remote VTUs as two different device types. Local VTUs are assigned for local Virtual Volumes while remote VTUs are only assigned for remote Virtual Volumes.

    In order to mount or create both types of tapes, you must define both types of devices in the VTDRIVE parmlib member.

    If you already have a sufficient number of Virtual Devices addresses, you may want to reserve some for use as local VTUs and others as remote VTUs.

    Note: If you need additional device addresses you can define them using IBM's Hardware Configuration and Definition Dialogs (HCD) as described in Precustomization Planning. If your shop is running JES3, you cannot split your local and remote Virtual Volumes into separate pools. Under JES3 you can only define one volume pool.

    Defining local versus remote VTUs is simply a matter of coding the VTDRIVE parmlib member accordingly. The VTDRIVE member of CCUUPARM library includes several examples of how local and remote virtual devices are defined.

    Note: In this example we are only going to define remote Virtual Tape units to one subsystem (SVT2). This is the subsystem that we will refer to as the local system later in this document.

    Begin by modifying the VTDRIVE member of the local system (SVT2) to include at least two remote Virtual Units and at least two local Virtual Tape units. For example:

    ;***************************************
; SVT2 Drive List
;***************************************
 <VirtualDeviceList>
; Local VTUs
  VirtualControlUnit = 1
             Offline = 3500-3501
;Remote VTUs

  VirtualControlUnit = 2
       OfflineRemote = 3510-3511
                                       
  2. Restart the SVT2 subsystem. Modifying the Virtual Device definitions of VTDRIVES requires that we restart the subsystem in order for those definitions to be loaded.
  3. Issue the SVT2 D U (display unit) command to ensure that the Virtual Devices are properly defined to SVT2.
  4. Vary the Virtual Devices both offline and online to ensure that they are reacting properly.
  5. CA Vtape P2P allows separate SVTS subsystems utilizing remote VTUs to logically share an overlapping subset of Virtual Volser ranges. Using Virtual Volume Pooling we can logically isolate Virtual Volser ranges for use with remote mounts versus those that are used for local mounts.

    In this simple example, we configure the volume pools of SVT1 using its VTPOOLS member:

    Note: When you do this be sure to use volser ranges that are appropriate for testing within your own shop.

    ; SVT1

<VolumePoolDefinitions>
  Pool1=Pool1           ; Local volsers
  Pool4=Pool4           ; Remote volsers

<Pool1>
        Range=100000-100999
<Pool4>
        Range=300000-300999

While the VTPOOLS member used by SVT2 is configured as:
; SVT2

<VolumePoolDefinitions>
  Pool1=Pool1           ; Local volsers
  Pool4=Pool4           ; Remote volsers

<Pool1>
        Range=200000-200999
<Pool4>
        Range=300000-300999

    In this example the intent is to use POOL4 as the overlapping volser range used for remote Virtual Volumes.

  6. Once the VTPOOLS members are properly defined you can issue a SVTS REFRESH=POOLS on both subsystems. This command will load the new pool definitions onto both subsystems.

    Once the VTPOOLS member has been refreshed you can then confirm that they are properly enabled by issuing the SVTS D P (display parmlib) or SVTS D U (display unit) operator commands.

    Important! Although these subsystems now have an overlapping range of volsers in POOL4, neither system will assign scratch volumes from that range because there is currently no GROUP definition assigned to POOL4.

  7. Modify the VTGROUP member used by SVT2 to establish a remote group definition.

    A remote group definition identifies the name of the remote system with whom to communicate and where the remote Virtual Volume will be created. In addition the group definition must specify the Virtual Volume Pool from which to allocate scratch Virtual Volumes. For this example SVT1 is the remote system with whom to communicate and POOl4 is the Virtual Volume Pool to be used:

    <SVT2.GROUP71>
       Description                 = '&SVTS GROUP71'
       Primary                     = TEMPONLY
       VolumePool                  = Pool4
       RemoteSystemPrimary         = /S161

<SVT2.GROUP72>
       Description                 = '&SVTS GROUP72'
       Primary                     = TEMPONLY
       VolumePool                  = Pool4
       RemoteSystemPrimary         = SYS61.SVT1

    Note: The RemoteSystemPrimary and RemoteSystemSecondary can either be the name of the remote system (that is, SYS61.SVT1) or the remote ConsoleSuffix proceeded with a slash character (that is, /S161).

    One important aspect to remember about remote Virtual Volumes is that the group number assigned by the local system (SVT2) is the same group number used by the remote system (SVT1) for purposes of Externalization. The point is that the group definitions of these SVTS subsystems may be different allowing the Externalization processes of these systems to behave differently.

    In the example above, the Primary attribute is assigned to TEMPONLY for both GROUP71 and GROUP72. In this case, the local system (SVT2) will not externalize the Virtual Volume locally. Once they are created they are immediately placed on the freeable queue. Later, if these remote Virtual Volumes are deleted from local DASD cache of SVT2 they can be recalled from cache on the remote system, SVT1.

Important! If both the local system and the remote system define Primary=TEMPONLY for the same respective Group, then a condition will exist where neither the local system nor the remote system will externalize the Virtual Volume. As soon as the Virtual Volume is freed from cache the volume is lost. Therefore only use such a combination of TEMPONLY for temporary data sets.

GROUP71 and GROUP72 as defined on the remote system (SVT1) are not remote groups. For our example the group definitions used by the remote system will be:

<SVT1.GROUP71>
       Description                 = '&SVTS GROUP71'
       MB_Threshold                = 13000
       ShortRetention              = 0
       MediumRetention             = 7
       Primary                     = P3590
       BackstoreBlockSize          = 256K
       VolumePool                  = Pool1
<SVT1.GROUP72>
       Description                 = '&SVTS GROUP72'
       MB_Threshold                = 13000
       ShortRetention              = 0
       MediumRetention             = 7
       Primary                     = P3590
       Duplex                      = P3590
       BackstoreBlockSize          = 256K
       VolumePool                  = Pool1

As a remote Virtual Volume is created on SVT2 it will be transmitted to SVT1. After it is dismounted, it externalized on SVT1 according to the rules defined above. A primary backup will be created for remote volumes created in GROUP71. Likewise SVT1 will create a primary and duplex backup for those created in GROUP72.

  1. Activate the modified VTGROUP definitions of both systems by using the SVTn REFRESH=GROUPS command. Then verify that the remote group definition is in effect by issuing a SVTS D P,M (display parmlib) command.
  2. Modify the VTFILTR member defining a set of remote data filters on the local system (SVT2). Create remote data class or remote data sets filters for data sets that you intend to assign to the remote group definitions created in step 7 above.

    Note: Remote groups can only be referenced by remote data filters.

    Also note that local data filters take precedence over remote data filters. If a scratch mount for the same data set can be selected for processing by both a local and a remote data filter then that data set will be mounted on a local drive rather than a remote drive.

    A good example of the parmlib attributes describing remote data filters can be found in the VTFILTR member of the CCUUPARM library.

    A simple example of a set of local and remote DataSetFilters:

    <DataSetFilters>
       IncludeDC       = &SVTS..IncludeDC
       IncludeDS       = &SVTS..IncludeDS
       ExcludeDS       = &SVTS..ExcludeDS
       IncludeDCRemote = &SVTS..Rmt.IncludeDC
       IncludeDSRemote = &SVTS..Rmt.IncludeDS
       ExcludeDSRemote = &SVTS..Rmt.ExcludeDS
;*********************************************
;* Filters for SYS61.SVT1
;*********************************************
 <SVT1.IncludeDC>
<SVT1.ExcludeDS>
<SVT1.IncludeDS>
       GROUP21 = 'hlq.VTAPE21/'
<SVT1.Rmt.IncludeDC>
<SVT1.Rmt.ExcludeDS>
<SVT1.Rmt.IncludeDS>
;*********************************************
;* Filters for SYS61.SVT2
;*********************************************
 <SVT2.IncludeDC>
<SVT2.ExcludeDS>
<SVT2.IncludeDS>
       GROUP01 = 'hlq.VTAPE01/'
       GROUP11 = 'hlq.VTAPE11/'
<SVT2.Rmt.IncludeDC>
<SVT2.Rmt.ExcludeDS>
<SVT2.Rmt.IncludeDS>
       GROUP71 = 'hlq.VTAPE71/'
       GROUP72 = 'hlq.VTAPE72/'
  3. Once the appropriate remote data filters have been defined, activate them on the local system (SVT2) by issuing a SVTn REFRESH=FILTERS operator command.

    You can then confirm that the new remote data filters are in effect by issuing a SVTn D P,L (display parmlib) command.

    At this point the systems should be configured to begin testing access to remote Virtual Volumes through CA Vtape P2P.

    Note: If both the group definitions and the filter definitions have been changed, then after editing is complete for both, either a REFRESH=GRouP,E or a REFRESH=FiLTers,E command will activate both the changes to the groups and filters in the correct order.

  4. The next logical step is to attempt to create a remote Virtual Tape on the active system.

    If you have not done so already vary online the Virtual Vtape Units created in step 1 above.

    Next, create JCL for a simple job that will copy a data set to tape. Ensure that the output data set matches the criteria of a remote data filter defined in step 9 above, that is:

    //STEP1   EXEC PGM=IEBGENER
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=hlq.data.set
//SYSUT2   DD  DSN=hlq.VTAPE71.data.set,
 // DCB=(DSORG=PS,RECFM=F,BLKSIZE=64536),
 // UNIT=(3490,,DEFER),DISP=(NEW,DELETE)
 //SYSIN   DD  DUMMY,DCB=BLKSIZE=80

    Submit the job on the local system (SVT2 in our example). If the remote data set filters are correctly coded on the local system then the output DD should be assigned to a remote VTU, a remote virtual volser from POOL4 will be assigned and the mount should complete.

    While the job is running a SVTn D U (display units) will show the activity of the remote and local drives.

    After the job completes the same Virtual Volume data set should be present on both subsystems. You can check that the Virtual Volume is defined to both systems using the CA Vtape ISPF panels.

By following this procedure you should have been able to configure and write remote Virtual Volumes using two CA Vtape complexes.