How P2P Works

CA Vtape P2P is a true peer-to-peer implementation utilizing TCP/IP to provide communication across SVTS subsystems. Today, separate SVTS subsystems running autonomously can each have their own set of Virtual Volser ranges, Virtual Devices, and control files. CA Vtape P2P allows these SVTS subsystems to further define remote subsystems, remote Virtual Drives, remote Virtual Volumes, remote groups, and remote data filters. This gives the SVTS subsystems the added ability to share a common overlapping subset of Virtual Volumes without the need of shared DASD or control data sets.

CA Vtape P2P introduces several new concepts which would be useful to review here. For purposes of this discussion, consider what happens when an application requests a scratch tape be mounted on a remote tape drive. Further, consider calling the system where that application is running the local system and the remotely connected system the remote system. Observe the following:

CA Vtape P2P uses the concept of local versus remote Virtual Tape Units (VTU) or drives. From CA Vtape you are already familiar with local Virtual Tape Units, these are the same Virtual Devices you should already be accustomed to using without the need of utilizing CA Vtape P2P. These devices do not communicate with remote systems. In contrast to a local VTU, a remote VTU has all of the same features along with the added capability of being able to establish a TCP/IP connection with a remote system.
Just as local VTUs are assigned by data class or data set filters defined within the parmlib, so too are remote VTUs assigned in a similar manner utilizing remote data set or data class filters.
Remote data set or data class filters point to a remote group definition. The remote group definition contains the name of the remote system with whom to communicate. Further, the remote group definition also contains a Virtual Volume pool name which describes Virtual Volser ranges from which to assign a remote Virtual Volume.