Overview

CA Vtape builds Virtual Devices in the operating system. Although the devices do not physically exist, they appear to the operating system as if they do. The CA Vtape Virtual Device Engine responds as if a real device is attached. The Virtual Device Engine has functionality equivalent to the microcode that normally controls a hardware tape device.

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

These devices are defined to one or more Virtual Device Controller address spaces within a CA Vtape Subsystem. A CA Vtape Subsystem consists of between four and eleven address spaces. These address spaces are:

Primary address space – SVTS
1-8 Virtual Device Controllers – SVTSAS.SVTnVm.
Backstore Engine – SVTSAS.SVTnPT.
Utility address space – SVTSAS.SVTnUT.
Where n is the subsystem number of 1-8 and m is the controller number of 1-8.

The Virtual Device Engine supports up to eight Virtual Control Units, each one running in a separate address space. Because the Virtual Device tasks and service routines are in separate subaddress spaces, CA Vtape closely resembles a multiple control unit implementation. Just as physical device problems are localized to a single control unit, Virtual Device internal bottlenecks and outages will be isolated to those drives within a single subaddress space.

Individual devices or an entire controller and all of its devices can be restarted just like physical tape drives.

The Virtual Device Engine uses buffers, dataspaces, and VSAM Linear Data Sets (LDS) to provide data movement. When an application issues reads or writes to a Virtual Volume, data movement occurs between buffers used by the application and those of the Virtual Device. Data movement between the Virtual Device buffer and the Virtual Volume data set occurs asynchronously and independently of the I/O process running in the application. This provides high throughput for applications reading or writing to a Virtual Volume because the block size used by the application has very little impact on the asynchronous logic used to perform physical I/O to DASD.

When the Virtual Volume is dismounted, a process called Externalization, managed by the Backstore Engine, will automatically copy the Virtual Volume to a tape in stacked format. After the Virtual Volume has been Externalized, its space in the DASD buffer can be automatically reclaimed when needed.

When an application dismounts a Virtual Volume and releases a Virtual Device, the Virtual Volume and Virtual Device are immediately available for other requests. Subsequent requests made for this Virtual Volume are satisfied from the DASD buffer unless the Virtual Volume's space has been reused. If the Virtual Volume is no longer in the DASD buffer, the Backstore Engine will automatically start a process called Recall to move the data back into the DASD buffer.