CA Vtape P2P Option › Set up a SVTS Subsystem in a Separate CA Vtape Complex

Set up a SVTS Subsystem in a Separate CA Vtape Complex

In order to create remote Virtual Volumes you need at least two SVTS subsystems which do not share the same cache or control data sets. If necessary, these subsystems can run on the same LPAR but must use different high level qualifiers.

If you do not have one already you can create a separate SVTS subsystem by following the normal CA Vtape installation procedures.

Once you have a separate SVTS subsystem, you can configure CA Vtape P2P for the additional SVTS subsystem in the same manner as defined in the section Set Up a Simple P2P Configuration to Test TCP/IP Connectivity. Assuming that both of these subsystems can then communicate through TCP/IP the next step is to define these two subsystems as remote systems to each other.

Note: In the following example the first SVTS subsystem is defined as SVT1 and the second subsystem is SVT2.

To define two subsystems as remote systems to each other

1. Modify the VTP2PRMT members of each SVTS subsystem so that they can communicate with each other.

   In the VTP2PRMT of the first subsystem place a remote system definition which describes the second subsystem.

   Assuming P2P Listener for SVT2 is using port 11002 and that TCP/IP stack uses IP address 41.202.65.61, you can modify the VTP2PRMT member of SVT1 to contain a remote definition for SVT2, that is:

   <PeerToPeerRemotes>
       RemoteSystem=LocalHost
       RemoteSystem=SYS61.SVT2
   
   <LocalHost>                            
      Port = 1100&SVTS(-1:1)
      IPAddress = 127.0.0.1
      ConsoleSuffix = LCL&SVTS(-1:1)
    
   <SYS61.SVT2>
      Port=11002
      IPAddress=41.202.65.61
      ConsoleSuffix=S261
   

   Observe the following:

   • The combination of IP address and port for each P2P Listener must be unique. In this example different subsystems running on the same LPAR and TCP stack use the same IP address, however notice that the port numbers used by their respective P2P Listeners is in fact different SVT1 is using port 11001 while SVT2 uses 11002.
   • Setting up a unique ConsoleSuffix takes a certain amount of preplanning. This user defined, four character field must uniquely identify the remote system and also be meaningful and easy to remember. In our examples we are using a naming convention which consist of SxNN where x identifies the SVTS subsystem number (that is, from 1 to 8) and NN identifies the LPAR where that subsystem is running, which in this case is SYS61.

   Then assuming that the P2P Listener for SVT1 uses port 11001 and the TCP/IP stack it uses is at IP address 41.202.65.61, you can modify the VTP2PRMT member of SVT2 to contain a remote definition for SVT1, as follows:

   <PeerToPeerRemotes>
       RemoteSystem=LocalHost
       RemoteSystem=SYS61.SVT1
   
   <LocalHost>                            
      Port = 1100&SVTS(-1:1)
      IPAddress = 127.0.0.1
      ConsoleSuffix = LCL&SVTS(-1:1)
    
   <SYS61.SVT1>
     Port=11001
     IPAddress=41.202.65.61
     ConsoleSuffix=S161
   

2. Refresh the remote system definitions of each SVTS subsystem by issuing the operator command SVTn REFRESH=REMOTES. This command will cause each subsystem to reload its PeerToPeerRemotes (VTP2PRMT) member.
3. After about 30 seconds issue a SVT1 D R (display remotes) command. If the two systems are able to communicate, the display will show the status of that communication, for example:

   SVT1 D R
   SVT1TP403I Display Remote Statistics
   Rmt  Status       AsOf   #Receive     #MB Files #Transmit     #MB Files
   ---- ------------ ----- --------- ------- ----- --------- ------- -----
   LCL1 Active       17:06         5       1     0         5       1     0
   S261 Active       17:08         5       1     0         5       1     0
   ----------------------- --------- ------- ----- --------- ------- -----
   2 Remote System(s)             10       2     0        10       2     0
   SVT1X0100I Command Complete
   

   In the example above, S261 (SVT2) shows up as active and is able to communicate with SVT1.

   In addition, SVT1 should be able to transmit remote SVTS commands and receive responses from SVT2 by simply using the S161 console suffix, for example:

   SVT1.S261 D S
   SVT1TP204I Command for S261, TSO61.SVT2 scheduled
   S261X0224I Subsystem Status Display
   
        Field               Current State   
        ------------------- ----------------
        Release             r11.5           
        Subsystem           Active          
        …
        Recall Order        Duplex          
        Console             Local           
   S261X0100I Command Complete
   

   Try issuing SVT1.S261 D R (display remotes). You should then be able to see the status remote connections from the point of view of SVT2.

By following this procedure you have been able to configure two SVTS subsystems for basic P2P communication.