This document provides configuration Information for IBM TS1140 (IBM 3592 Generation 4) drives.
Support for TS1140 (3592 generation 4) drives on AIX, HP-UX, Oracle Solaris, Linux, and Windows starts at Tivoli Storage Manager levels 5.5.6, 6.1.5, 6.2.3, and 6.3.0. Support for TS1140 (3592 generation 4) drives on z/OS starts at Tivoli Storage Manager level 18.104.22.168.
The following table lists capacities, compressed and uncompressed for IBM TS1140 or 3592 generation 4 drives. Two of the media types, JB and JC, are also used by generation 3 drives, but the generation 4 capacities are larger.
IBM 3592 generation 4 capacities for UNIX, Linux, and Windows
|NOTE: Tivoli Storage Manager for z/OS does not adjust estimated capacity based on the format of the volume.|
The same ratio also applies to short-tape capacity and WORM (write-once, read-many) volumes. For details, see the 3592 generation 4 hardware specifications.
IBM 3592 generation 4 drives support:
- Tivoli Storage Manager Application Managed Encryption on all open platforms
- Re-writeable and write-once, read-many (WORM) media formats.
- Append-only mode
Device Class Information:
To use the new hardware through Tivoli Storage Manager, define a device class that specifies the 3592 device type:
DEVTYPE=3592 FORMAT=< DRIVE, 3592-4, 3592-4C>
where 3592-4 is the uncompressed format and 3592-4C is the compressed format
NOTE: If you have an existing device class that specifies one of the other formats (for example, 3592-3C), you can continue to use that device class and substitute generation 4 drives by updating the device class definition (UPDATE DEVCLASS) or specifying a new FORMAT value of DRIVE, 3592-4 or 3592-4C.
For optimal performance, do not mix generations of 3592 drives in a single logical library. Media problems can result when different drive generations are mixed. For example, Tivoli Storage Manager might not be able to read a volume's label. The following table shows read-and-write interoperability for the four generations.
Generation 1 format
Generation 2 format
Generation 3 format
|Generation 4 format|
|Generation 1||Read and write||Not compatible||
|Generation 2||Read and write||Read and write||
|Generation 3||Read only||Read and write||
|Generation 4||Not compatible||Read only||
||Read and write|
If mixing generations of drives within the same library partition, use one of the following methods to prevent or minimize the potential for problems:
Open systems and Windows:
- If your library contains two drive generations, force all drives to use the format of the earlier generation. For example, if your library contains generation 3 and generation 4 drives, force all the generation 4 drives to use the generation 3 format. The result is that all the drives can read and write to all the media.
Remember: If you force a drive generation to write in the format of an earlier drive generation, both drive generations can verify labels and read media written in the format of the earlier drive generation. For example, if your library contains generation 3 and generation 4 drives, both drive generations can verify labels and read media written in the generation 3 format. However, this configuration does not allow the generation 4 drives to read or write in their optimal format.
If your library contains three drive generations, the latest drive generation in your library can only read media from the earliest format, but cannot write with it. For example, if your library contains generation 2, generation 3, and generation 4 drives, the generation 4 drives can only read the generation 2 format. In this configuration, mark all media previously written in generation 2 format to read-only.
- (349X and ACSLS libraries only) This method is a simple way to logically partition the generations without partitioning the hardware. Define two or three new library objects for each drive generation that the physical library contains. For example, if you have a physical library with 3592-3 drives and 3592-4 drives, define two new library objects.
Specify a path with the same special file name for each new library object. In addition, for 349X libraries, specify disjoint scratch categories (including WORMSCRATCH category, if applicable) for each library object. Specify a new device class and a new storage pool that points to each new library object.
Example for the new 349X library object with a set of 3592-3 drives:
DEFINE LIBRARY libgen3 LIBTYPE=349X SCRATCHCAT=300 PRIVATECAT=301
DEFINE PATH server1 libgen3 SRCT=SERVER DESTT=LIBR DEVI=devlib
DEFEINE DRIVE libgen3 dr1
DEFINE PATH server1 dr1 SRCT=SERVER DESTT=DRIVE LIBR=libgen3 DEVI=deva
DEFEINE DRIVE libgen3 dr2
DEFINE PATH server1 dr2 SRCT=SERVER DESTT=DRIVE LIBR=libgen3 DEVI=devb
Example for the new 349X library object with a set of 3592-4 drives:
DEFINE LIBRARY libgen4 LIBTYPE=349X SCRATCHCAT=400 PRIVATECAT=401
DEFINE PATH server1 libgen4 SRCT=SERVER DESTT=LIBR DEVI=devlib
DEFEINE DRIVE libgen4 dr1
DEFINE PATH server1 dr1 SRCT=SERVER DESTT=DRIVE LIBR=libgen4 DEVI=devc
DEFEINE DRIVE libgen4 dr2
DEFINE PATH server1 dr2 SRCT=SERVER DESTT=DRIVE LIBR=libgen4 DEVI=devd
NOTE: The DEVICE value for the path definition in both library objects is the same because both library objects refer to the same physical library. However, drives should be unique to each library. Thus, in the example, all 3592-3 drives would be defined to libgen3 and all 3592-4 drives would be defined to libgen4.
- (SCSI only) Define a new storage pool and device class for the generation 4 drives. Set the FORMAT parameter to 3592-4 or 3592-4C (not DRIVE). The original device class will have a FORMAT parameter set to 3592, 3592C, 3952-2, 3592-2C, 3592-3, or 3592-3C (not DRIVE). Update the MAXSCRATCH parameter to 0 for the storage pool that will contain all the media written in generation 1, generation 2, or generation 3 formats, for example:
UPDATE STGPOOL <gen2pool> MAXSCRatch=0
This method allows both generations to use their optimal format and minimizes potential media problems that can result from mixing generations. However, it does not resolve all media issues. For example, competition for mount points and mount failures could result. The following known media issues also remain:
1. CHECKIN LIBVOL: The problem resides with using the CHECKLABEL=YES option. If the label is currently written in a generation 4 format, drives of previous generations will fail this command for this particular media. As a best practice, use CHECKLABEL=BARCODE to circumvent this issue for CHECKIN.
2. LABEL LIBVOL: The problem also results when the server tries to use drives of a previous generation to read the label written in a generation 4 format. In this case, the LABEL LIBVOL command will fail unless OVERWRITE=YES is specified. Verify that the media being labeled with OVERWRITE=YES does not have any active data.
3. CHECKOUT LIBVOL: As with the previous two commands, the same problem arises when Tivoli Storage Manager verifies the label (CHECKLABEL=YES) if it is written in a generation 4 format and the operation uses drives of previous generations to read the label. Thus, Tivoli Storage Manager recommends using CHECKLABEL=NO to circumvent this issue for CHECKOUT.
If your library has generation 2 drives or uses generation 2 media with generation 3 drives. and if you want to add generation 4 drives, complete the following steps:
1. Ensure that you have ACS routines to restrict generation 4 drives to generation 3 format.
2. Remove the generation 2 drives.
3. Make generation 2 media read-only.
4. Update ACS routines, if available, to write in the generation 3 format only
5. Define a new storage pool and device class for the generation 4 drives. The original device class will have a UNIT parameter that resolves only to the generation 2 or generation 3 drives, and a value for the FORMAT parameter of DRIVE, 3592-2, 3592-2C, 3592-3, or 3592-3C. The new device class will have a UNIT parameter that resolves only to generation 4 drives, and a value for the FORMAT parameter of DRIVE, 3592-4, or 3592-4C.