back to the general informations of XTF:

XTF - Extended Tape Facility
Detailed Information
Mode of Operation
XTF is started after VSE IPL in a partition in which it is permanently running. Different options, such as blocksize of container files (=physical files written by XTF), number of blocks, number of virtual cartridge units, etc., may be specified.

When XTF recognizes an I/O to a virtual tape unit, the I/O is simulated by XTF.


(XTF physical view of e.g. 4 Programmen)

While writing to a virtual cartridge (on a virtual unit), those blocks are captured - possibly together with blocks, written to other virtual units - and are written to a real cartridge, without storing the data to an intermediate dasd.

When a virtual cartridge is to be read, XTF opens the real file (container file), in which the virtual cartridge was stored.

Additionally, there is an option to store a virtual cartridge - either while writing or explicitly after the creation - in a data space (a dataspace is virtual storage maintained by the operating system). At the time, the virtual cartridge is to be read, XTF can present the data directly out of the data space. This allows the same cartridge to be read by multiple programms simultaneously.

The number of cartridges to be held concurrently in the data space is only limited by the size of the data space. This size may be defined by the user.

Synergy with BVS
XTF only recognizes mount and demount commands for virtual cartridges. Thus, it is in effect a "virtual" tape robot system.

BVS support for real robot systems was extended to the "virtual" robot system XTF. Of course, BVS permits the coexistence of real and virtual robot systems.

For output data sets the volser field in the TLBL statement must only be coded with VAULTx or AUTOx to force the output to be written to an XTF container file.

For input data sets, BVS searches its catalog for the appropriate generation/version of the data set about to be read. If the cartridge holding the data set is served by a robot system, BVS sends - by means of its robot interface - a mount command to the robot system (in this case XTF). This mount forces the open of the appropriate container file.

Opening of a container file by XTF is considered by BVS to be an opening of a regular tape data set. If necessary, a real robot system is engaged.

Synergy with other tape management sytems
For other tape management systems, XTF provides an appropriate exit. So, for tape opens and close the exit can pass the necessary command to XTF to mount or demount the appropriate virtual cartridge on the virtual unit. For the tape management system XTF is totally transparent, which means, that the tms handles real and virtual cartridges the same way.

Advantages

1. Gain of a robot system or virtual tape server (VTS) as the capacity of the cartridges may be completely used
   
   
2. Gain of real cartridge units by combining output data sets to one unit
   
   
3. Gain of cartridges
   a) lower prime-costs
   b) smaller file
   
   
4. increased multiprogramming by relieving the bottleneck of cartridge units
   
   
5. Gain in performance by shortened mount processing
   
   
6. dramatic reduction of real tape I/O's by
   a) buffering the data up to 64K
   b) writing multiple blocks per I/O
   
   
7. utilization of data in memory (without any program changes) by spooling of tape data sets into data spaces
   
   
8. multiple read of virtual cartridges via input data spaces at the same time by different programs
   
   
9. effortless implementation under a tape management system, such as BVS, since XTF appears as (virtual) robot system
   
   
10. user friendly, as XTF only needs 4 system commands
    

click here to go back to the general informations:

to download the flyer of XTF in PDF format point to the icon, klick right mouse button and select "store destination"; to display the flyer click left mouse button