Understanding the Basic Components › CA Vtape

CA Vtape

CA Vtape simulates tape devices within the operating system. Although these devices do not physically exist, they appear to the operating system as if they do. A CA Vtape Virtual Device responds as if a real device is attached. It has functionality equivalent to the microcode that normally controls a hardware tape device.

Virtual Devices are defined to the operating system as a part of the CA Vtape installation. You use the IBM Hardware Configuration and Definition (HCD) software to create the definitions. These are software, not hardware, definitions requiring only an HCD activation to use. An IPL is not necessary.

The CA Vtape subsystem uses between two and nine address spaces on MVS that communicate with the CA Cloud Storage for System z server running on Linux.

The MVS address spaces are:

• The Primary address space – SVTS, which manages the control data sets, queues, resources, startup, shutdown, and operator communications.
• 1-8 Virtual Device Controllers – SVTSAS.SVTnVm. These are sub address spaces that act as Virtual Device controllers. These controllers provide subtasks that emulate Virtual Tape Drives attached to MVS. Individual Virtual Devices or the entire Virtual Controller and all of its devices can be restarted just like physical tape drives.

On Linux, the CA Cloud Storage for System z Server provides services to read and write Virtual Volume files as standard Network File System (NFS) files.

Virtual Devices use buffers and dataspaces to simulate tape devices. When an application issues reads or writes to a Virtual Volume, data movement occurs between the buffers used by the application and those of the Virtual Device. This movement occurs asynchronously and independently of the I/O process running in the application.

When an application dismounts a Virtual Volume and releases a Virtual Device, the Virtual Volume and Virtual Device are immediately available for other requests.