This document provides configuration Information for IBM TS1150 (IBM 3592 Generation 5) drives.
Support for TS1150 (3592 generation 5) drives on AIX, Oracle Solaris, Linux, and Windows starts at Tivoli Storage Manager levels 6.3.5, and 7.1.1.
The following table lists capacities, uncompressed for IBM TS1150 or 3592 generation 5 drives. Two of the media types, JC and JK, are also used by generation 4 drives, but the generation 5 capacities are larger.
IBM 3592 generation 5 capacities for UNIX, Linux, and Windows
| NOTE: Compressed capacity is not estimated for 3592 generation 5 format tapes. Use the ESTCAPACITY option when defining or updating the device class to tune the compressed capacity to match actual data compression ratio.|
IBM 3592 generation 5 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-5, 3592-5C>
where 3592-5 is the uncompressed format and 3592-5C 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 5 drives by updating the device class definition (UPDATE DEVCLASS) or specifying a new FORMAT value of DRIVE, 3592-5 or 3592-5C.
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 5 format|
|Generation 1||Read and write||Not compatible||
||Not compatible||Not compatible|
|Generation 2||Read and write||Read and write||
||Not compatible||Not compatible|
|Generation 3||Read only||Read and write||
||Not compatible||Not compatible|
|Generation 4||Read only||Read only||
||Read and write||Not compatible|
|Generation 5||Not Compatible||Not Compatible||Not Compatible||Read and write||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 4 and generation 5 drives, force all the generation 5 drives to use the generation 4 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 4 and generation 5 drives, both drive generations can verify labels and read media written in the generation 4 format. However, this configuration does not allow the generation 5 drives to read or write in their optimal format.
(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-4 drives and 3592-5 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-4 drives:
DEFINE LIBRARY libgen4 LIBTYPE=349X SCRATCHCAT=300 PRIVATECAT=301
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=deva
DEFEINE DRIVE libgen4 dr2
DEFINE PATH server1 dr2 SRCT=SERVER DESTT=DRIVE LIBR=libgen4 DEVI=devb
Example for the new 349X library object with a set of 3592-5 drives:
DEFINE LIBRARY libgen5 LIBTYPE=349X SCRATCHCAT=400 PRIVATECAT=401
DEFINE PATH server1 libgen5 SRCT=SERVER DESTT=LIBR DEVI=devlib
DEFEINE DRIVE libgen5 dr1
DEFINE PATH server1 dr1 SRCT=SERVER DESTT=DRIVE LIBR=libgen5 DEVI=devc
DEFEINE DRIVE libgen5 dr2
DEFINE PATH server1 dr2 SRCT=SERVER DESTT=DRIVE LIBR=libgen5 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-4 drives would be defined to libgen4 and all 3592-5 drives would be defined to libgen5.
- (SCSI only) Define a new storage pool and device class for the generation 4 drives. Set the FORMAT parameter to 3592-5 or 3592-5C (not DRIVE). The original device class will have a FORMAT parameter set to 3592-4, or 3592-34 (not DRIVE). Update the MAXSCRATCH parameter to 0 for the storage pool that will contain all the media written in generation 4 format, for example:
UPDATE STGPOOL <gen4pool> 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 5 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 5 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 5 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.
Was this topic helpful?
17 June 2018