These release notes support ptx®/SPDRIVERS (Storage Products Drivers) V3.2.2 for systems running DYNIX/ptx® V4.5.3. ptx/SPDRIVERS enables NUMA and Symmetry® systems to communicate with various storage devices. Read this document before you install or run this release of ptx/SPDRIVERS.
ptx/SPDRIVERS V3.2.2 contains the following changes since ptx/SPDRIVERS V3.2.1:
The tl driver now supports the DLT7000E and DLT8000 tape drives.
The tl and mw device drivers and the mc are now supported when their associated tape and robotics devices are connected to an IBM 2108 R03 SAN Data Gateway Router.
ptx/SPDRIVERS V3.2.1 contains the following changes since ptx/SPDRIVERS V3.2.0:
ptx/SPDRIVERS V3.2.1 supports Fibre Channel-ported IBM Magstar® 3590 Tape Subsystems. Earlier versions of ptx/SPDRIVERS only provided support for SCSI-attached IBM Magstar 3590 Tape Subsystems through special support contracts. The device driver for FC-ported IBM Magstar 3590 Tape Subsystems is the tc device driver. Additionally, ptx/SPDRIVERS commands and utilities like cfwdl, infodev, and scsilog have been enhanced to support the FC-ported IBM Magstar 3590 Tape Subsystem.
For more information, refer to "Tape Drive and Media Type Support in ptx/SPDRIVERS" later in these release notes.
ptx/SPDRIVERS V3.2.0 contains the following changes since ptx/SPDRIVERS V3.1.0:
ptx/SPDRIVERS V3.2.0 is supported for use on DYNIX/ptx V4.5.2. Previous versions of ptx/SPDRIVERS are not.
ptx/SPDRIVERS is now selected by ptx/INSTALL for automatic installation on DYNIX/ptx. This enhancement helps to ensure that device drivers and utilities are available on a host.
The mw driver in ptx/SPDRIVERS V3.2.0 supports the new generation L700 library from Storage Tek (STK) in addition to the STK 9710 and 9730 libraries previously supported in ptx/SPDRIVERS V3.1.0. This library can contain up to 20 DLT7000 tape drives and, depending on the number of tape drives and the cartridge storage capacity selected, from 154 to 678 storage slots for cartridges. This support was previously provided in a patch to ptx/SPDRIVERS V3.1.0 on the "Software Patches for DYNIX/ptx V4.5.1 and Layered Products" CD.
Some of the device drivers in ptx/SPDRIVERS V3.2.0 have been enhanced in anticipation of future support for new fabric devices. Specifically, the tl, mw, and mc device drivers have been enhanced. However, no additional fabric devices have been qualified at this time.
ptx/SPDRIVERS V3.1.0 contains the following changes since ptx/SPDRIVERS V3.0.0:
ptx/SPDRIVERS V3.1.0 is supported for use on DYNIX/ptx V4.5.1. Previous versions of ptx/SPDRIVERS are not.
ptx/SPDRIVERS V3.1.0 contains a new utility, cfwdl, which is a common firmware downloader. This utility downloads firmware to Fibre Channel Host Adapters, FC Bridges, JBOD disk drives, and SCSI devices like tape drives and libraries. The cfwdl utility also can be used to audit SCSI and FC devices and firmware files, and to list the devices that need firmware upgrades. For more information, refer to "ptx/SPDRIVERS Commands and Utilities" later in this chapter.
ptx/SPDRIVERS V3.0.0 contains the following changes since ptx/SPDRIVERS V2.3.0:
ptx/SPDRIVERS V3.0.0 is supported for use on DYNIX/ptx V4.5.0. Previous versions of ptx/SPDRIVERS are not.
ptx/SPDRIVERS now logs errors to the Error and Event Subsystem (EES). EES provides a uniform set of interfaces to report, log, and retrieve system errors and events on DYNIX/ptx systems. For more information, refer to the EES User's Guide.
Support for the SCSI-attached IBM Magstar 3590 Tape Subsystems is no longer covered by the standard support model for ptx/SPDRIVERS V3.0.0. However, special support contracts can be obtained for this support. Contact your IBM Sales Representative for more information.
Several problems have been fixed in ptx/SPDRIVERS V3.0.0. Refer to Fixed Problems in ptx/SPDRIVERS V3.0.0 at the end of this chapter for more information.
ptx/SPDRIVERS V3.2.2 runs on DYNIX/ptx V4.5.3.
Installing ptx/SPDRIVERS requires approximately 3.5 MB in the root filesystem. No run-time disk space is required for ptx/SPDRIVERS.
ptx/SPDRIVERS V3.x.x designates that the /etc/mctab file, the mc command, the mcbuild command, and the rc2 script that executes mcbuild at boot time be placed on the custom miniroot on a DYNIX/ptx V4.5.x system. (The device drivers are part of the kernel and do not have to be explicitly placed on the custom miniroot.) Additionally, for SAMS:Alexandria® and Backup Toolkit users, the Backup Toolkit systeminfo script, which is run during daily SAMS:Alexandria housekeeping, copies the /etc/mctab file under the name mctab in the /usr/alexbkup/disaster_recovery directory.
Hosts running DYNIX/ptx V4.5.x and a backup application, like SAMS:Alexandria server, must install ptx/SPDRIVERS. ptx/SPDRIVERS includes all the tape and library device drivers required for the devices supported by DYNIX/ptx for use with backup applications like SAMS:Alexandria. If you are upgrading a host from DYNIX/ptx V4.4.1 or later, no changes are required in the SAMS:Alexandria hardware configuration as the device names will remain the same after the upgrade to DYNIX/ptx V4.5.x and ptx/SPDRIVERS V3.x.x.
If the host is running DYNIX/ptx V4.5.x, ensure that ptx/SPDRIVERS is already installed before you install SAMS:Alexandria.
ATTENTION Backup Toolkit V4.4.3, SAMS:Alexandria V4.50.70 and earlier versions, and NetBackup V3.4 and earlier versions do not support the FC-ported IBM Magstar 3590 Tape Subsystem.
Before you install the ptx/SPDRIVERS software, you should familiarize yourself with the hardware installation requirements for the tape drives and libraries you plan to use. For more information, refer to the applicable hardware documentation. You should also determine the hardware connections you plan to use for each library before software installation.
Use ptx/INSTALL to install ptx/SPDRIVERS V3.2.2 from the "DYNIX/ptx V4.5.3 and Layered Products Software, Volume 1" CD. The DYNIX/ptx V4.5.3 and Layered Products Software Installation Release Notes tell how to use this process to install all DYNIX/ptx software. This document also describes how to use the mcbuild utility to associate tape drives with media changers and how to verify hardware detection of configured devices.
ATTENTION If you are upgrading from a host running DYNIX/ptx V4.4.7, V4.4.8, or V4.5.1, a change in the way DYNIX/ptx V4.5.2 and DYNIX/ptx 4.5.3 generate UUIDs for tape drives causes device name slippage for tc and tl devices that are attached at the time of the upgrade. When the system reboots, these devices will have temporary names in the device naming database. Any applications, such as backup applications, that physically configure these device names will be unable to locate the associated devices.
This scenario occurs because DYNIX/ptx V4.5.1 and V4.4.x do not use device serial numbers to generate the UUID for a tape device, but DYNIX/ptx V4.5.2 and DYNIX/ptx 4.5.3 do. These modifications to DYNIX/ptx V4.5.2 and DYNIX/ptx 4.5.3 resulted in a change in the unit number which caused the device number to be recalculated by the device naming database.
Before upgrading to DYNIX/ptx V4.5.2 or DYNIX/ptx 4.5.3 and ptx/SPDRIVERS V3.2.x, note the names of all tc and tl devices that are attached to the system. Then, after the upgrade, delete the previous device names from the device naming database (devctl -D) and rename the newly named devices to the previous names (devctl -n).
Since ptx/SPDRIVERS contains kernel components, you must compile the kernel and reboot with that new kernel before you can use ptx/SPDRIVERS. If you try to compile the kernel and ptx/SPDRIVERS is not installed, DYNIX/ptx will output a warning message during the compile. Note, however, that the kernel can be built without ptx/SPDRIVERS.
The default system configuration file for ptx/SPDRIVERS is called /etc/conf/uts/symmetry/spd.std.
You can deinstall ptx/SPDRIVERS by using the Software Management option on the System Administration menu in the ptx/ADMIN menu system. If you are not familiar with the steps to deinstall a product, refer to the ptx/INSTALL Software Installation Guide. The deinstallation of ptx/SPDRIVERS does not delete the /etc/mctab file since this file was not created by the installation of ptx/SPDRIVERS.
ATTENTION ptx/SPDRIVERS is tightly coupled with DYNIX/ptx and must not be deinstalled unless you no longer need to use the devices supported by ptx/SPDRIVERS. Once you deinstall ptx/SPDRIVERS, those devices are no longer accessible. Refer to "Media and Driver Support for ptx/SPDRIVERS Devices" later in this release note for the supported devices.
Once ptx/SPDRIVERS is deinstalled, you must rebuild the kernel and reboot the operating system.
Table 1-1 summarizes the tape drives, media types, capacities, and device files that are supported by ptx/SPDRIVERS V3.2.2.
|
|
Native Mode |
Compressed Mode |
||
Tape Drive |
Media Type |
Capacity |
Device Filea |
Capacity |
Device Filea |
DDS-2TM tape drive |
4-mm DAT |
4 GB |
/dev/rmt/td0 |
8 GBb |
/dev/rmt/td0c |
DDS-3 tape drive |
4-mm DAT |
12 GB |
/dev/rmt/td0 |
24 GBb |
/dev/rmt/td0c |
DLT4000 tape drive |
DLTtape IIIxt |
15 GB |
/dev/rmt/tl0d15 |
30 GBb |
/dev/rmt/tl0d15c |
DLTtape IV |
20 GB |
/dev/rmt/tl0d20 |
40 GBb |
/dev/rmt/tl0d20c |
|
DLTtape IIIxt or IV |
variablec |
/dev/rmt/tl0 |
variablec |
/dev/rmt/tl0c |
|
DLT7000, DLT7000E, DLT8000 tape drivesd |
DLTtape IIIxt |
15 GB |
/dev/rmt/tl0d15 |
30 GBb |
/dev/rmt/tl0d15c |
DLTtape IV |
20 GB |
/dev/rmt/tl0d20 |
40 GB |
/dev/rmt/tl0d20c
|
|
DLTtape IV |
35 GB |
/dev/rmt/tl0d35 |
70 GBb |
/dev/rmt/tl0d35c |
|
DLTtape IIIxt or IV |
variablec |
/dev/rmt/tl0 |
variablec |
/dev/rmt/tl0c |
|
DLT8000 tape drive |
DLTtape IV |
40 GB |
/dev/rmt/tl0d40 |
80 GBb |
/dev/rmt/tl0d40c |
IBM Magstar 3590 Tape Subsystem (E11 and E1A)e |
IBM 3590 High Performance Tape Cartridge |
20 GBf 40 GBg |
/dev/rmt/tc0 |
/dev/rmt/tc0c |
a. The device file names shown in this table are for devices assigned a unit number of zero, for example, /dev/rmt/tl0d15. Devices assigned a unit number of one are named /dev/rmt/tl1d15, and so on.
b. The compression amounts listed are based on a 2:1 compression rate. The actual capacity of a tape when used with hardware compression format varies with the type of data being backed up.
c. See the notes following this table for information about the capacity.
d. DLT8000 tape drives are supported only when directly connected to a single-ended SCSI host adapter in IBM xSeries 430 and NUMA-Q systems. Connection via a Fibre Channel Bridge or a SAN Data Gateway (SDG) Router is not supported.
e. ptx/SPDRIVERS V3.2.2 supports only an FC-ported IBM Magstar 3590 Tape Subsystem. SCSI-attachment of this tape drive to a NUMA system requires a special support contract. Contact your IBM Sales Representative for more information.
f. Capacity of a Standard 3590 Cartridge.
g. Capacity of an Extended Length 3590 Cartridge
h. The E11 and E1A models of the 3590 tape drive use a new compaction algorithm, which typically uses a 3:1 compression rate.
Note the following additional information:
The DLT7000 and DLT7000E tape drives are functionally the same. The DLT7000E tape drive is a DLT8000 tape drive with DLT7000 Emulation enabled.
The tl drivers do not support writes to tape densities other than those listed in Table 1-1. If you attempt to write to a media type or density that is not supported by a given driver, the driver will report an error.
You can read data from a DLTtape with unknown density or media type; use the /dev/rmt/tln device file with no suffix for this (where n equals the drive number). With this device file, all drive defaults will be in effect. For example, data compression will be on, writes to a blank tape will occur at the highest supported density, and when not at the beginning of a tape (BOT), writes to a previously written tape will occur at the media density.
If you insert a type-IV cartridge that contains data written at a density of 20 GB into a DLT7000, DLT7000E or DLT8000 tape drive, the drive behaves slightly differently depending on whether you use the tl driver without a density specification or use the tld35 driver. The behavior is as follows:
When using either the tl or tld35 drivers, the tape will be written at a density of 35 GB only when the tape is positioned at the beginning of the tape (BOT) and the tape has not been read before you to try to write to it.
If you use the tl driver and either the tape was read before the write or the tape is not at BOT, the write will occur at a density of 20 GB.
If you use the tld35 driver and either the tape was read before the write or the tape is not at BOT, an error is returned and the write will not occur. You can clear this condition by unloading and reloading the tape without doing any read operations after the load operation.
There are special considerations when using type-IV cartridges that previously contained data written at a density of 20 GB and that will now be used in DLT7000, DLT7000E or DLT8000 tape drives configured for use with SAMS:Alexandria. In this scenario, if you want to write to these tapes at a density of 35 GB you must reset the density manually. For more information, refer to the Backup Toolkit V4.4.4 Release Notes for SAMS:Alexandria.
Note the following additional information specific to NUMA systems and ptx/SPDRIVERS V3.2.2:
Only FC-ported IBM Magstar 3590 Tape Subsystems are supported. SCSI-attachment of this tape drive to a NUMA system requires a special support contract. Contact your IBM Sales Representative for more information.
Only the models E11 (autoloader/stacker) and E1A (tape drive without the autoloader/stacker) are supported.
ptx/SPDRIVERS V3.2.2 supports dual porting of the tape drive. DYNIX/ptx V4.5.3 supports dual-port connection but not dual access. The second connection simply provides failover protection.
Connection of IBM 3590 tape drives to the IBM 3494 library is not supported at this time.
NetBackup V3.4 and earlier versions do not support the FC-ported IBM Magstar 3590 Tape Subsystem.
SAMS:Alexandria requires a fastpatch in order to support the FC-ported IBM Magstar 3590 Tape Subsystem. For information on the fastpatch, refer to Backup Toolkit V4.4.4 Release Notes for SAMS:Alexandria.
The tc device driver does not support pre-written IBM tape labels. On a pre-labeled tape, the first file is the tape label. Before writing to a pre-labeled tape, you must issue an mt command to skip the first file, then perform the write. If you do not issue the mt command to skip the first file, the tape label will be overwritten.
DYNIX/ptx V4.5.x supports a maximum transfer block size of 128K bytes.
For details on other limitations and caveats specific to NUMA systems, refer to the online document Supplement for IBM Tape Devices on NUMA Systems that is available at this URL:
To locate this document from the NUMA Customer Documentation web page, you can use the left pane to select the topic "Hardware" and then the subtopic "Tape Operation."
For further information about the IBM Magstar 3590 Tape Subsystem, refer to the publications at the following URL:
http://www.storage.ibm.com/hardsoft/tape/pubs/pubs3590.html
Table 1-2 describes the libraries that are supported by the drivers in this release of ptx/SPDRIVERS. Table 1-3 describes the libraries that are supported by DYNIX/ptx and do not require device drivers in ptx/SPDRIVERS.
Library |
Internal Tape Drive |
Number of Tape Drives |
Number of Tape Slots |
Device Filea |
EXB®-10h Autoloader/ Stacker |
EXB-8505XL tape driveb |
1 |
10-cartridge magazine |
/dev/mch/mx0 |
DDS-2 Library |
DDS-2 tape drive |
2 4 |
22 or 60 20 or 58 |
/dev/mch/ms0 |
DDS-3 Library |
DDS-3 tape drive |
2 4 |
20 60 |
/dev/mch/ms0 |
HP® DLT4000 Library |
DLT4000 tape drive |
2 4 |
48 48 |
/dev/mch/ml0 |
STK L700 Library Storage Module (directly-connected)c |
DLT7000 and DLT7000E tape drives |
1 to 20 |
154-678 |
/dev/mch/mw0 |
STK 9710 Library Storage Module (directly-connected) |
DLT4000 tape drive DLT7000 and DLT7000E tape drives |
1 to 10 |
252 or 420 or 588 |
/dev/mch/mw0 |
STK 9730 Library Storage Module (directly-connected) |
DLT4000 tape drive DLT7000 and DLT7000E tape drives |
1 to 4 |
18 or 30 |
/dev/mch/mw0 |
a. The device file names shown in this table are for devices assigned a unit number of zero, for example, /dev/rmt/mx0. Devices assigned a unit number of one are named /dev/rmt/mx0, and so on.
b. The EXB-8505XL tape drive uses 8-mm tapes and uses the tx device driver, which is provided by DYNIX/ptx, not ptx/SPDRIVERS.
c. This library is supported as a directly-connected library on NUMA hosts running DYNIX/ptx V4.5.x or V4.6.x and as an ACSLS-connected library on Symmetry hosts running DYNIX/ptx V4.5.x and all hosts running DYNIX/ptx V4.4.4 or later maintenance releases.
Library |
Internal Tape Drive |
Number of Tape Drives |
Number of Tape Slots |
Device Filea |
DLT7000 and DLT7000E tape drives |
1 to 20 |
154-678 |
not applicable |
|
DLT4000 tape drive DLT7000 and DLT7000E tape drives |
1 to 10 |
252 or 420 or 588 |
not applicable |
|
STK 9740 Library Storage Module (ACSLS-connected) c |
DLT7000 and DLT7000E tape drives |
1 to 10 |
318-486 per LSM |
not applicable |
IBM Magstar 3494 Tape Libraryd |
IBM Magstar 3590 Tape Drive (E1A)e |
1 to 7f |
variableg |
not applicable |
a. The device file names shown in this table are for devices assigned a unit number of zero, for example, /dev/rmt/mx0. Devices assigned a unit number of one are named /dev/rmt/mx0, and so on.
b. This library is supported as a directly-connected library on NUMA hosts running DYNIX/ptx V4.5.x or V4.6.x and as an ACSLS-connected library on Symmetry hosts running DYNIX/ptx V4.5.x and all hosts running DYNIX/ptx V4.4.4 or later maintenance releases.
c. The library robotics of an ACSLS-connected library are controlled by STK's Automated Cartridge System Library Software (ACSLS) and not a device driver.
d. For connection to a NUMA system, you must obtain the IBM Automated Tape Library Software, which contains the lmcpd daemon and some additional files. For details, refer to Backup Toolkit V4.4.4 Release Notes for SAMS:Alexandria, "Configure IBM 3494 Tape Libraries."
e. Support is only for an FC-ported IBM Magstar 3590 tape drive model E1A when internal to an IBM 3494 tape library attached to a NUMA system running DYNIX/ptx V4.5.3 and ptx/SPDRIVERS v3.2.2. Model E11 (autoloader/stacker) of the IBM Magstar 3590 tape drive and the Automated Cartridge Facility (ACF) functionality is not supported for use with SAMS:Alexandria.
f. This is a DYNIX/ptx system limitation, not an IBM Magstar 3494 library limitation.
g. The number of slots supported is determined by the lmcpd daemon and not by the NUMA system to which it is attached.
Note the following additional information:
All tape drives within one HP DLT4000 library, one direct-connect STK library, or one logical library of an ACSLS-connected STK library must use the same tape densities and the same type of tapes. In other words, do not use both DLTtape IV and DLTtape III tapes in the same library or configure one tape drive with the d20 density and another tape drive in the same library with the d15 density.
Do not mix DLT4000 with DLT7000 or DLT7000E tape drives within one directly-connected STK library; all tape drives within one of these libraries must be the same type.
You can mix DLT4000 and DLT7000 or DLT7000E tape drives in an ACSLS-connected STK 9710 library as long as only one type of tape drive is used per logical library. (ACSLS-connected STK L700 and STK 9740 libraries are only supported for use with DLT7000 and DLT7000E tape drives.)
ptx/SPDRIVERS includes the following commands and utilities:
The cfwdl utility, which is a common firmware downloader. This utility downloads firmware to FC Host Adapters, FC Bridges, JBOD disk drives, SCSI devices like tape drives and libraries, and the FC-ported IBM 3590 Tape Subsystem. The cfwdl utility also can be used to audit SCSI and FC devices and firmware files and to list the devices that need firmware upgrades.
The cfwdl utility replaces the ffutil, dltutil, and fwdl utilities previously provided by ptx/SPDRIVERS. The cfwdl utility also replaces the fcdl utility previously provided by DYNIX/ptx.
Note that the cfwdl utility does not download firmware to FC Switches, EMC® Symmetrix® storage subsystems, IBM Enterprise Storage Servers (ESS), IBM FAStT200TM Storage Servers, or HDSTM disk arrays from Hitachi Data Systems.
For information about using the cfwdl utility, refer to the DYNIX/ptx V4.5.3 and Layered Products Software Installation Release Notes and go to Chapter 13, "Download Firmware with cfwdl." Additionally, you can refer to the cfwdl(1) man page, which describes the syntax options of this utility.
The fcinfo utility, which uses a combination of mode and log sense commands to obtain and display statistical information obtained from Fibre Channel Bridge(s) installed in a NUMA system. fcinfo is a service utility intended for use only by customer support personnel. For more information, refer to the fcinfo(1) man page.
The mc utility, which manipulates media changer devices and displays their status.
The mc command can also display volume tag information (also referred to as barcode information). Note, however, that the mc command cannot manipulate media based on its barcode-you can use only the element addresses to identify media to the mc command.
ATTENTION When using the mc command to manipulate tapes in a direct-connect STK library, you must issue the mc command once for each media element you wish to move from or to the CAP. There is no option to the mc command that enables you to move multiple media elements from or to the CAP. For more information on using the mc command with STK libraries, refer to the mw(1) man page.
For more information, refer to the mc(1) man page.
The mcbuild utility, which associates tape drives in the system with a specific media-changer (library). For more information, refer to "Associate Tape Drives with Media Changers with the mcbuild Utility" later in these release notes, or refer to the mcbuild(1) man page.
The scsilog utility, which displays statistical information obtained from SCSI devices. scsilog returns information about compression rates, error rates, and the amount of data transferred. For more information, refer to the scsilog(1) man page. For a detailed explanation of the information returned by scsilog, refer to Appendix C, "Log Sense Codes," of the NUMA-Q Supplement to the DLT Tape Library User's Guide.
When using directly-connected libraries, you should use the mcbuild utility to associate tape drives with each media changer or library device. You can create or update these associations at any time-a system reboot is not required. This task is not applicable to ACSLS-connected libraries.
When mcbuild is not used, a media changer driver tries to determine the names of its connected tape drives the first time the media changer device is opened. The media changer driver then keeps those tape drive names until the system is rebooted. This method works most of the time, especially when there is only one media changer on the host and all the tape drives connected to the host are in the media changer. However, because the media changer device cannot return unique identifiers for the tape drives connected to it, the media changer driver has no way of positively associating a tape drive with that media changer device.
To prevent these problems, you should use the mcbuild utility to explicitly associate tape drives with every media changer on the host. Even if you only have one media changer on the host, it is a good system administration practice to use the mcbuild utility.
Complete the following steps to use the mcbuild utility to associate tape drives to directly-connected media changer devices:
Create or edit the /etc/mctab file to contain one line for each media changer device and its associated tape drives.
ATTENTION Any time you add, remove, or rename a tape device that is associated with a media changer or library device, you must first delete the library configuration from the host (devctl -d), next reprobe the host (devctl -c), then update the /etc/mctab file appropriately, and lastly run the mcbuild command. These actions remove the reference pointers established in the kernel by the previous mcbuild command. A system reboot is not required.
Each line in the /etc/mctab file should be of the following format:
mc_device_name drive1 drive2 drive3 ...
The order given for the tape drives must correspond to their order as storage elements in the library. This is important because the naming order of tape drives may not correspond directly to their order in a library. For example, a library may have four tape drives with SCSI ID's 0, 1, 2, and 3. Because of the way they are cabled to the system, the system may probe them in a different order (such as 2, 3, 0, 1). The system will assign drive names in probe order, but mc(1) will erroneously assume that the drive name sequence follows its own ordering. mcbuild must be used to rectify this situation by listing the drive names in the correct order with respect to the library.
For example, to associate the tape drives tl0 through tl3 with the HP DLT4000 library /dev/mch/ml0 and to associate the tape drives tl4 through tl8 with the STK 9710 library /dev/mch/mw0, you would add the following lines to the /etc/mctab file:
/dev/mch/ml0 tl0 tl1 tl2 tl3 tl4
/dev/mch/mw0 tl5 tl6 tl7 tl8 tl9
If you do not know which tape drives belong to which library, you can determine this information as follows:
To determine a tape drive that belongs to a specific DDS-2 or DDS-3 library, identify the SCSI bus ID for the library (ms device) and then locate the tape drives (td devices) that are located on the same SCSI bus.
Use the same method to determine the first two tape drives that belong to a specific HP DLT4000 library. Identify the SCSI bus ID for the library (ml device) and then locate the two tape drives (tl devices) that are located on the same SCSI bus. If the HP DLT4000 library contains four tape drives, the third and fourth tape drives will be the next two tl devices, typically located on the next SCSI bus.
For a directly-connected STK library, first identify the SCSI bus ID for the library (mw device). If drives were installed according to the recommended procedure, they will be in the following locations:
On a STK 9710 library, DLT4000 drives (tl devices) will be at SCSI IDs 0-4. DLT7000 and DLT7000E drives (tl devices) will be at SCSI IDs 0-4 and 10-14. If the library contains both DLT4000 and DLT7000 or DLT7000E drives, the DLT4000 drives will be at the lower SCSI IDs.
For the STK 9730 library, DLT4000, DLT7000, and DLT7000E will be at SCSI IDs 0-3 or 1-4.
For the STK L700 library, refer to your site-specific library configuration scheme. Although it is not required, the DLT7000 and DLT7000E drives (tl devices) could be at SCSI IDs 0-4 and 10-14 for the first 10 drives and SCSI IDs 0-4 and 10-14 for the second 10 drives.
The lowest ID is typically in the lowest position in the library. For example, drive tl5 will be at SCSI ID 0. In dumpconf output, the unit number corresponds to the SCSI ID.
Run the mcbuild utility to associate the tape drives and media changers that are defined in the /etc/mctab file.
# mcbuild
ptx/SPDRIVERS includes online man pages that describe various components of this product. To view the ml(7) man page, for example, enter the following command:
# man 7 ml
The following man pages are included with ptx/SPDRIVERS:
This section describes the following subjects:
Note that no problems have been explicitly fixed in ptx/SPDRIVERS V3.1.0, V3.2.0, or V3.2.1.
The numbers in parentheses identify the problems in the problem-tracking system.
The following problems were fixed in ptx/SPDRIVERS V3.2.2:
(246748) The fcinfo failed to provide interactive searching through the configuration tree as its default behavior when no Fibre Channel bridge devices we specified.
(253586) When upgrading to an SuperFly 3.x firmware level from an SuperFly 2.x level, the SF 3.x firmware changed the way the LP7000 FC Host Adapter reported its name. This change caused the naming database of the operating system to assign a new name to the upgraded device when it was probed following the upgrade from an SF2.x level. There was a manual workaround to this problem. The cfwdl utility performs the manual workaround automatically, so this is no longer a problem.
(255531) The dltutil -e DLT drive utility paniced the machine. This utility is primarily used by Customer Support.
(255367) The STK9730 media changer (devctl -d mw0) paniced the machine when the media changer was connected off a QLC card.
(255211) The Request Sense length defined for all IBM Magstar 3590 Tape Subsystem tc devices was too long for the Fibre Channel Bridge so tc devices connected to the bridge would not come up.
(254022) Running two mc commands concurrently caused MMU faults in scsimc_reread_device().
The following problems were fixed in ptx/SPDRIVERS V3.0.0:
(23793) The mcbuild command failed after using OLI to add DAT drives to an existing DDS-3 library.
(237851) The tl device driver incorrectly requested log page 2 when it should have called log page 3.
(239809) When a drive was removed and replaced in a library, the mc command did not pick up the new device configuration.
(241210) The fcinfo utility always prompted for confirmation before clearing the log page data. Now, you can use the -C option to clear the log page data without any query.
(241428) When the dltutil fw download option was run, the command line prompt reappeared immediately, even though the command was still running.
(242201) When a move media command failed, the mc command did not report a reasonable error message when the device in question was in the "unit attention" state.
(243218) The ffutil man page did not describe what happens when the firmware file revision does not match the FC Host Adaptor device revision.
(248540) fwdl program was not reporting valid sense key.
The media changer drivers all invoke the same code (scsimc) to handle request sense data; this code tries to interpret the sense data and return in text what the problem is. However, when an error occurs, scsimc does not return the raw sense data, so none of the media changer drivers can output this information to /usr/adm/ktlog. The raw sense data should be output because it frequently contains diagnostic information that can help isolate the source of the error.
Workaround: None.
The mcbuild(1) man page should explain that the order given for the drives corresponds to their order as storage elements in the library.
This is important, because the naming order of tape drives may not correspond directly to their order in a library. For example, a library may have four tape drives with SCSI ID's 0, 1, 2, and 3. Because of the way they are cabled to the system, the system may probe them in a different order (such as 2, 3, 0, 1). The system will assign drive names in probe order, but mc(1) will erroneously assume that the drive name sequence follows its own ordering. mcbuild must be used to rectify this situation by listing the drive names in the correct order with respect to the library.
Also, the man page does not describe the output of the mcbuild command.
Workaround: None.
When the cfwdl utility cannot download a firmware file to a device or cannot access a device, a vague error message is displayed about the situation:
cfwdl: Unable to create a download object for tl1
Workaround: If you receive this error message, take the following actions as appropriate:
Ensure that you execute cfwdl from the /usr/ssw/fw directory or include the full pathname to the firmware file with the -f option. For example, -f /usr/ssw/fw/esq25.sqfw.
Ensure that you are downloading the correct firmware file for the type of target device. For example, if you are downloading to a DLT7000 table top tape drive, ensure that you are designating a firmware file intended for it, and not a firmware file intended for a DLT7000 tape drive in an STK library. Refer to the appropriate version of the cfwdl-Compatible Firmware Bundle Release Notes for descriptions of the cfwdl-compatible firmware files that are installed on your host.
Ensure that there are no typographical errors in the pathname or firmware filename and that the file actually exists in /usr/ssw/fw. If the firmware file exists in a different directory, use the -p option to designate the pathname of the directory.
Clear any influx conditions that occur after downloading firmware to DLT tape drives in STK libraries. Refer to problem report 251162 for information about how to clear influx conditions.
In an STK library, each tape drive has an individual door that is generally left open between tape drive operations. When the tape drive door is open during a reset operation, the tape drive cannot determine whether it contains a tape, which then causes an influx condition to occur for that tape drive. This scenario occurs when the following events happen:
Tape drive firmware is downloaded to a DLT tape drive in an STK library.
Robotics firmware is downloaded to a directly-connected or ACSLS-connected STK library. (The onsite service personnel that are downloading robotics firmware to ACSLS-connected libraries will clear the influx condition - no user action is required for that situation.)
The tape drive is power-cycled while the tape drive door is open.
The influx condition prevents cfwdl from successfully downloading or auditing the firmware versions of the DLT tape drives. For example, if a tape drive is in the influx condition, the cfwdl -a command will fail with messages similar to the following:
# /usr/service/bin/cfwdl -a -d tl3
cfwdl: scsibus18 (target 2, lun 0): command 0x12: adapter unable to initiate command cfwdl: Could not open the passthru device for tl3 to get the revision cfwdl: Unable to create a download object for tl3
Workaround: To prevent influx conditions from occurring during firmware downloads, closely follow the recommended steps for downloading tape drive and library firmware that are provided in the DYNIX/ptx V4.5.3 and Layered Products Software Installation Release Notes. Specifically, refer to Chapter 13, "Download Firmware with cfwdl," and review the section "DLT Tape Drive and STK Library Firmware Download Procedures." This section also describes how to clear an influx condition that has occurred. Note that the recovery from this condition is different based on whether the library is directly-connected or ACSLS-connected.
When you use cfwdl -u to determine which devices require firmware upgrades, messages similar to the following are returned for devices that require updates:
Device tl0 needs to be updated: Old Firmware XXXX New firmware 245FFirmware file /usr/ssw/fw/DLT7K_STK_V95.sqfw
The problem is that the message is missing a blank space between the phrase about the new firmware version that is required (in this example, New firmware 245F) and the text about the firmware file required (Firmware File...). The result is that the firmware version looks like it is 245FFirmware.
Workaround: None.
The cfwdl(1) man page is confusing in some sections and omits some important usage information in other sections. For example, the syntax shown in the SYNOPSIS section does not accurately reflect the usage information provided in the DESCRIPTION section. Also, the WARNINGS section needs additional information in the "For DLT Drives and STK Libraries" section and the "For SD scsi and FCP devices" section.
Workaround: For detailed cfwdl usage information, refer to the DYNIX/ptx V4.5.3 and Layered Products Software Installation Release Notes and go to Chapter 13, "Download Firmware with cfwdl."