Tape drives and tapes
Starting with Independent Software Vendor (ISV) IBM Z Program Development Tool
(IBM zPDT) (ISV zPDT) GA10, general SCSI tape drives are no longer “officially” supported. Only Fibre Channel-connected 3590 drives are supported. However, the awsscsi device manager from earlier ISV zPDT releases continues to be distributed as is. You can continue to use it, but IBM cannot address problems with general SCSI tape drives. The awstape device manager remains a standard part of ISV zPDT.
14.1 ISV zPDT 359x tape support
Information Technology Company (ITC)1 works with ISV zPDT development by testing changes to the awsscsi device manager that are designed to more fully support Fibre Channel Protocol (FCP)-attached IBM 3590/3592 tape units. Although these devices can be physically attached to an ISV zPDT system before these awsscsi enhancements, they function only in basic mode by emulating a 3490 device. With updated support, these units can operate in full 359x mode, with minor exceptions.2
The FCP adapters
ITC tested several FCP adapters, from both Emulex and QLogic, including older 2 Mb adapters such as the Emulex LPe1150-E, up to the current FCP adapters that are offered with Lenovo System x, such as the 8 Mb Emulex, IBM part number 42D0485. Although most testing was with Emulex adapters because they were more available, we did test with at least one QLogic adapter (dual-core 8 Mb, IBM part number 42D0510). In all cases, the FCP driver that was included in openSUSE 12.2 functioned correctly and newer or different drivers were unnecessary.3 Firmware-related issues, even on the oldest adapters, did not occur, so the firmware levels of the various adapters are not documented here. All adapters that were tested were PCIe format adapters.
14.1.1 3590/3592 tape drives
Testing was performed with 3592-J1A and 3592-E05 tape units, and the 3590-H11 with a 10-cartridge autoloader.4 There are no configuration options for 3590 devices. These drives are also known as TS1120 models.
All 3592 drives must be configured5 for RACK installation, and not for LIBRARY installation. Each drive has two ports. The port that you intend to use must be configured as PORT SPEED=Auto Negotiate, TOPOLOGY=L-Port. As a best practice, set HARD ADDRESS to x88, although it is not required.
Performance is limited by the x86 architecture of the underlying hardware platform and the configuration of the Linux operating system. Therefore, performance numbers cannot be expressed in meaningful terms. Our experience showed that the performance is acceptable for development users, and allows fully compatible interchange of media with other mainframe data centers.
 
Important: Although you might have a 3592 physical SCSI drive, it should be defined as a 3590 in the device map (devmap) to match a z/OS input/output definition file (IODF) entry, as in this example:
device 590 3590 3590 /dev/sg3
14.2 Discontinued support
 
Important: The remainder of this chapter describes SCSI usage that is untested and without formal support, starting with ISV zPDT GA10. This text is included for customers who might still be using SCSI tape drives.
SCSI tape drives might be used in two ways:
•With the awsscsi device manager, SCSI tape drives may be used by IBM zSystems programs.
•Several Linux utilities that directly use SCSI tape drives are provided with ISV zPDT. These utilities can be used when ISV zPDT is not active. These utilities are not associated with devmaps or a device manager.
However, not all SCSI tape drives are usable. Their usability depends on the exact tape drive model, the firmware level, the firmware options that are selected, the exact SCSI adapter (and firmware level), and the exact cable characteristics. Several different tape drives were tested in previous years, but we cannot guarantee that your tape drive will work. As a best practice, work with your ISV zPDT supplier to understand your SCSI tape drive environment.
This chapter describes three categories of SCSI tape drives:
•Tape drives that use traditional SCSI cables. These drives are emulated as 3420, 3480, or 3490 drives, regardless of the actual nature of the tape drive.
•IBM 359x tape drives that are connected with fiber cables that are defined as 3420, 3480, or 3490 drives in the devmap. These drives are subject to the same comments as when using parallel SCSI cables.
•IBM 359x tape drives that are connected with fiber cables that are defined as 3590 drives in the devmap.
The awsscsi device manager
Selected SCSI tape drives can be used as “real” tape drives during ISV zPDT operation. The awsscsi device manager is used so that the SCSI tape drive can appear as a 3420, 3480, 3490, or 35906 devices.
A typical devmap definition might be as follows:
[manager]
name awsscsi 7000
device 581 3490 3490 /dev/sg5
The 7000 in this example is the CUNUMBR operand. This example defines a tape drive at address (device number) 581. If z/OS is used, then the z/OS IODF must have a corresponding device (IBM 3490) that is defined for this address. (z/VM detects devices dynamically and finds a 3490 at this address.)
The appearance to software (as a 3490 in the example above) has no direct relationship to the SCSI device type. In this case, /dev/sg5 might be a digital linear tape (DLT) drive, for example, that has no physical characteristics of a 3490 drive.7
As shown in Figure 14-1, Linux SCSI devices can be addressed through two interfaces. The relationship between the st and the sg interfaces can be complicated because the sequence number that is used for a drive is typically not the same number.
Figure 14-1 SCSI driver interfaces
The Linux device for the SCSI tape drive can be changed with the awsmount command, as shown in this example:
$ awsmount 580 -u /dev/sg5 (Disassociate sg5.)
$ awsmount 580 -m /dev/sg3 (Mount a different drive.)
The last operand of the device statement (/dev/sg5 in the example) denotes the SCSI device that is used. Determining this operand is a bit complicated. Linux can address a SCSI tape drive in three ways:
•/dev/stN (Where N starts at 0 and is incremented as needed.)
•/dev/nstN
•/dev/sgN
The /dev/stN and /dev/nstN interfaces are for sequential tape devices. The first tape drive on a Linux system is /dev/st0; a second tape drive would be /dev/st1; and so forth. The two forms, /dev/stN and /dev/nstN, differ only in whether a rewind is performed when the device is closed.8 The /dev/stN and /dev/nstN interfaces are used with the ISV zPDT stand-alone tape utility functions, such as scsi2tape and tape2scsi, and also by Linux utilities such as tar and mt. The /dev/stN and /dev/nstN interfaces are not used with the awsscsi device manager.
The /dev/sgN devices are general SCSI devices, and the awsscsi device manager uses the /dev/sgN interfaces.9 Unfortunately, the N value for a device is typically not the same in the stN and the sgN forms. All Linux SCSI devices are assigned sgN numbers, and Linux treats many of its normal devices as SCSI (even if they are not really hardware SCSI devices).10 The first (and only) tape drive on a Linux system would be /dev/st0, but it might be /dev/sg7, for example.
Determining the st and sg numbers
To manually determine these interfaces, list /proc/scsi/scsi, as in this example:
$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00 (this is sg0)
Vendor: IBM Model: root Rev: V1.0
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00 (this is sg1)
Vendor: IBM Model: 03592E05 Rev: 1C91
Type: Sequential-Access ANSI SCSI revision: 03
This example shows two SCSI devices (a disk and a tape) that correspond to /dev/sg0 and /dev/sg1. In this case, /dev/sg1 is the device that you specify for the awsscsi device manager, but any Linux utility uses /dev/st0 or /dev/nst0 for the same tape drive. The devices that are listed in /proc/scsi/scsi are in sgN order: sg0, sg1, sg2, and so forth.
You can list both the st and sg interface numbers for all SCSI tape drives that are connected to your system with the aws_findlinuxtape command:
$ aws_findlinuxtape
Vendor: FUJITSU Model: M2488E M2488 Rev: 7 C <===> /dev/st0 /dev/sg10
Vendor: IBM Model: 03592E05 Rev 1C91 <===> /dev/st1 /dev/sg11
The sg number can change from one Linux start to another one if there are any configuration changes.
Permissions
There is another issue with both /dev/stN and /dev/sgN devices: The permission bits must able to be used by ISV zPDT. Some Linux systems allow general user access to /dev/stN devices by default, but no Linux systems allow general access to /dev/sgN devices by default. You must change the permissions to allow general access to your device, as in this example:
$ ls -al /dev/sg*
crw-r----- 1 root disk 21, 0 2008-09-03 14:44 /dev/sg0
crw-rw---- 1 root tape 23, 0,2008-99-03 14:44 /dev/sg1
$ su
(Enter root password.)
# chmod 666 /dev/sg1
# exit
$ ls -al /dev/sg*
crw-r----- 1 root disk 21, 0 2008-09-03 14:44 /dev/sg0
crw-rw-rw-+1 root tape 23, 0,2008-99-03 14:44 /dev/sg1
In this example, we changed the permissions for /dev/sg1 so that everyone (including
ISV zPDT) can read/write to it. This change (by using chmod) is lost when Linux restarts, but it is suitable for many situations. Always verify the correct sgN number first by listing /proc/scsi/scsi.
A persistent change can be made by modifying Linux start functions. Unfortunately, there are two problems with this approach:
•The method of modifying Linux start functions differs with different Linux distributions. For example, you might change /etc/rc.local, /etc/rc.d/rc.local, /etc/init.d/boot.local, or another file depending on the exact Linux distribution.
•You can easily make a general change for stN and nstN devices, but you cannot easily make a general change for sgN devices. You should not change the permissions to allow universal access to all /dev/sgN devices because of security reasons.
You could place the following lines in /etc/init.d/boot.local (assuming that your particular Linux distribution uses this file):
chmod 666 /dev/st[0-9] Change all tape devices.
chmod 666 /dev/nst[0-9] Change all tape devices.
chmod 666 /dev/sg7 Change a particular SCSI device.
Do not use chmod 666 /dev/sg[0-9] because this command provides direct access to anyone to all the SCSI devices on your system. Unless you always have the same devices that are turned on when you start Linux, you cannot safely predict the sgN number of a device.
Block counts
There is confusion about ISV zPDT that uses SCSI-attached tape drives that are defined as 3490 devices. This definition means that the actual device controls and sense information are transformed (by the awstape device manager) to appear as a 3490.
IBM 3490 tape drives provide a block counter. This counter is 22 bits, and the largest count that it can hold is approximately 4 million. If you write to a SCSI-attached tape drive that is defined as a 3490 (under zPDT), you receive an end-of-media indication after writing approximately 4 million blocks. z/OS performs EOV functions and calls for a new tape cartridge (depending on your JCL). The remaining tape media in the first cartridge is not used, but the system works correctly otherwise.
This situation is likely to arise only when using a SCSI 359x tape drive that is defined as a 3490 unit in the devmap. If you read a cartridge that is written by another system (that was not emulating a 3490 drive), the cartridge might contain more than 4 million blocks. This situation should work correctly if the IBM zSystems program does not read the block count. If it does, and if the tape position is past the 4 million block point, the IBM zSystems program indicates a block count error. What happens then depends on the design of the application program. A tape cartridge with more than approximately 4 million blocks is not fully compatible with 3490 emulation.
Parallel SCSI adapters
At the time of writing, the most recent Lenovo System x servers do not list parallel SCSI adapters for their standard configurations.
•IBM did not formally test any of the existing SCSI adapters with these servers.
•There is no known reason why they should not work if the appropriate adapter slots are available.
•We informally11 used the Ultra SCSI 320 series of adapters with xServer 3650 M2 and 3500 M2 machines without problems with our older SCSI tape drives.
For some of our systems, we used openSUSE 11.2 or later for this operation. Other and earlier distribution with Linux kernels below the level that is used in openSUSE 11.2 did not work with these SCSI adapters on some of our systems. This condition is likely to change with future Linux distributions. If parallel SCSI operation is important to you, discuss your ISV zPDT configuration with your ISV zPDT provider.
•There is no defined IBM Support for these configurations.
•Parallel SCSI adapters, cables, and devices can be complex. There are different data path widths, single-ended and with differential circuits, low-voltage and high-voltage versions, and various terminators. If you are not familiar with this area, obtain expert help in configuring your system.
•The newest SCSI devices use fiber connections instead of parallel (wire) connections.
Testing specific hardware
 
Tip: Older SCSI drives might require interfaces that are not available with current servers. For example, some older drives require SCSI Fast/Wide High-Voltage Differential adapters. The last generation of these adapters used PCI (not PCIe) adapter slots in servers but many current servers no longer have these slots. The details that are involved in SCSI tape drive usage can be complex. Talk with a knowledgeable ISV zPDT provider about your SCSI tape drive requirements.
IBM testing (a few years ago) involved the following SCSI drives:
•IBM 3592-E05 TS1120 Fibre Channel-attached SCSI tape drive. The drive was at firmware level 1C91, as determined by the itdtinst1.2LinuxX86 and itdtinst4.1.0.026LinuxX86_64 tools from IBM.
•Fujitsu M2488E parallel SCSI tape drives with media cartridges that are compatible with IBM 3480 and 3490 drives. These drives were at firmware level 7.C.01 or 7.xG.01, as determined through the drives control panel.
•IBM LTO-3 3580 parallel SCSI tape drive. This drive was at firmware level 5BG4, as determined by the itdtinst1.2LinuxX86 tool from IBM.
These drives were tested with Lenovo System x servers x3650-M1 (7979), x3650-M2 (7947), and x3500-M2 (7939). The following adapters were used:
•Emulex Corporation Zephyr-X LightPulse Fibre Channel Host Adapter (rev 02). This adapter was at Emulex LightPulse x86 BIOS Version 1.71A0 and firmware ZS2.50A, as displayed during the BIOS startup.
The Linux device drivers (provided in the Linux distribution) were determined by using the command dmesg | grep Emulex:
 – Red Hat Enterprise Linux (RHEL) 5.3 (64-bit): Emulex LightPluse Fibre Channel SCSI driver 8.2.0.33.3p
 – openSUSE 11.1 (64-bit): Emulex LightPluse Fibre Channel SCSI driver 8.2.8.7
 – SUSE Linux Enterprise Server 11 (64-bit): Emulex LightPluse Fibre Channel SCSI driver 8.2.8.14
•QLogic Corporation ISP2432-based 4 Gb Fibre Channel to PCI Express HBA (rev 03). This HBA was at BIOS revision 1.28, as displayed during BIOS startup. The firmware level was 4.04.05 [IP][Multi-ID][84XX], as determined by the ql-hba-snapshot.sh tool from QLogic.
The Linux device drivers (provided in the Linux distribution) were determined by using the command dmesg | grep Qlogic:
 – RHEL 5.3 (64-bit): QLogic Fibre Channel HBA Driver 8.02.00.06.05.03-k
 – openSUSE 11.1 (64-bit): QLogic Fibre Channel HBA Driver 8.02.01.02.11.0-k9
•Adaptec ASC-29320ALP U320 (rev 10) parallel SCSI adapter at Adaptec SCSI Card 29320LPE Flash BIOS v4.31.2S1, as displayed during BIOS startup.
Block size
You probably want to use variable block sizes with SCSI tape drives. You can check for them with these commands:
$ su (Switch to root. Might not be necessary.)
# mt -f/dev/st0 status
If the indicated tape block size is 0 bytes, the drive is set for variable block sizes. If not, enter the following command:
# mt -f/dev/st0 setblk 0
In our example, we use the /dev/stN devices rather than the /dev/sgN devices for these commands. Also, the Linux must have the mt command installed.
With our older drives and adapters, the Linux drivers for Emulex and QLogic both default to a maximum block size of 32 K. Block sizes larger than 32 K are typically not used by application programs, but large block sizes might be used by backup programs (such as ADRDSSU for z/OS) or by virtual tape managers. (The newer drivers that are used with the IBM 359x drives default to a 64 K maximum block size.)
The following Linux commands were used to set def_reserved_size to 65536:
$ su (Changes to root.)
# rmmod sg (Removes the sg module.)
# /sbin/modprobe sg def_reserved_size=65536
(Loads the sg module with the default reserved size up to 64 K.)
# cat /proc/scsi/sg/def_reserved_size
(Displays the current setting for def_reserved_size.)
# exit (leave root)
This change allowed both cards to use 64 KB reserved buffer size for data transfers. These commands do not make a permanent change. A Linux restart puts the default size back to 32768.
Recent Linux releases might have changed these interfaces.
ISV zPDT SCSI utilities
Two ISV zPDT utilities can work directly with SCSI tape drives assuming that the Linux system has access to the SCSI adapter. Standard awstape-format files (in Linux) can be moved to and from SCSI tape devices by using the scsi2tape and tape2scsi commands:
$ scsi2tape /dev/st0 /z/my/TAPE23 (Copy SCSI tape to awstape file.)
$ tape2scsi /my/tapes/111111 /dev/st0 (Write SCSI tape from the awstape file.)
$ scsi2tape -c /dev/st0 /z/mytape2 (Compress the awstape file.)
These two commands are typically used when ISV zPDT is not active.12
Linux SCSI tape utilities
Linux can provide basic tape utility functions through the mt package. This package is not required for ISV zPDT, but it might be useful in other ways. The package is not normally installed by default. In some cases, the mt function is part of the cpio function.
Practical advice
Most SCSI tape drives do not use vacuum columns to help manage tape start and stop times. Instead, they use slower mechanical methods to manage physical tape movement, which means that starting and stopping the tape cannot be done in typical “tape gap” intervals.
For older types of drives, the net effect is usually as follows:
•If the program (including the operating system elements) issues tape read/write commands quickly enough, the tape drive runs the tape at full speed.
•If the program (including the operating system elements) does not issue reads/writes quickly enough, the tape drive stops after the current data block. The next read/write might cause the tape drive to “backhitch” (that is, back up the tape for a distance) and then restart forward movement. This action is done to ensure that the tape is “up to speed” for the next read/write operation.
This backhitch movement can greatly reduce the effective data speed of the drive. Not all drives encounter this situation because other factors such as internal buffering on newer types of drives can help avoid it. You can typically hear the effects of a tape drive doing a backhitch for every data block.
If you encounter this situation, an alternative approach is to use the ISV zPDT SCSI utilities such as scsi2tape to copy the SCSI tape to an awstape emulated tape volume. The SCSI utilities are fast and should not encounter any backhitching. Your application can process the emulated tape volume copy instead of the real SCSI tape volume, which might result in much faster processing of your tape data.
The SCSI adapters that are needed to use older SCSI tape drives might not be compatible with newer servers. One solution is to acquire an older server with appropriate adapters and use it to convert older tapes into awstape format files. This format can be readily moved to newer servers running ISV zPDT.
 
1 Information Technology Company LLC, 7389 Lee Highway, Falls Church, VA 22042. For more information, contact [email protected].
2 One exception is that automated tape library functions are not supported.
3 This situation might not be true for other or older Linux distributions or for FCP adapters that are not widely used.
4 ITC also has single and dual drive models (E05, E06, and E07) that are available and complete ready-to-run units with power supplies, an IBM FICON adapter, a FICON cable, a CE panel, and a warranty.
5 Configuration changes are entered through an optional CE panel. The drives that are obtained by the ISV zPDT developers did not require configuration changes. You might discuss the need for a CE panel with your 359x provider.
6 Usage as a 3590 drive requires a fibre adapter and a “real” 359x drive.
7 IBM did not formally test DLT drives.
8 The /dev/stN device automatically rewinds when the device is closed. The /dev/nstN devices do not provide an automatic rewind.
9 The reason is that the /dev/stN interface does not accept the full SCSI command set that is necessary for some tape operations. The /dev/sgN interface allows all SCSI tape commands to be passed to the tape drive.
10 The sg numbers are assigned in ascending order by the bus and by the device on the bus. However, because Linux treats a number of non-SCSI devices as though they were SCSI, these bus and device numbers are difficult to predict in advance.
11 This statement was for ISV zPDT releases before GA10.
12 If the SCSI devices are not in the active devmap, these utilities can be safely used while ISV zPDT is active.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.116.85.72