Scratch Mount Requested by a Remote Virtual Tape Unit

When scratch mount is requested by a remote Virtual Tape unit the following occurs:

Initially, the remote VTU will request a connection with the remote system based on the name defined within the remote group definition.
When a connection request is accepted, the remote system will allocate a Client Drive. The Client Drive will be used to mirror data sent to it by the local system.
The local system then creates a list of valid Virtual Volser ranges as defined in the Virtual Volume pool which was assigned by the remote group definition. The Virtual Volser range list is then transmitted to the remote system where it will be used to select a scratch volser.
The remote system uses its own Virtual Volume POOL8 and attempts to select an appropriate volser based on the list provided by the local system.
If no compatible scratch volser is available, the remote system will then attempt to dynamically assign one hundred available scratch volsers to its own POOL8 from within one of the volser ranges as originally requested by the local system.
Once a scratch volser has been selected, the remote system will simulate the mount on the Client Drive. The scratch volser is then transmitted back to remote VTU running on the local system.
After receiving information about the selected Virtual Volume, the local system completes the mount which then signals the application that it can begin writing data.

Important! At this point the same Virtual Volser is mounted on remote Virtual Tape units on both the local and remote system.

As the application writes data onto the Virtual Volume, the remote VTU running on the local system records that data to DASD cache and simultaneously transmits that data to the Client Drive running on the remote system. There, the data is recorded separately onto the DASD cache of the remote system.
This effectively allows both systems to record the same application data to their respective Virtual Volume cache data sets at the same time, thereby duplexing the content of the Virtual Volume.
When the volume is unloaded, the remote connection is closed and both systems will then contain their own copy of the Virtual Volume in their respective caches.
Finally because the Externalization processes on these systems are autonomous, each will then process the Virtual Volume cache data set based on their own respective group definition. Group definitions have a comprehensive set of attributes which may be used to control where and how many externalized copies of the Virtual Volume are created.