On Thu, 14 Aug 2003, Bill Fitzgerald wrote: > does anyone have this information for converting from 3590B to the 3590E drives? I > know I am behind the tech curve, but that's life.
The process below is the same no matter what the conversion is from and to. B-->E B-->H E-->H > > Bill > > >>> [EMAIL PROTECTED] 08/14/03 09:27AM >>> > > >and I will be free to start running some movedata commands to start > > >consolidating tapes (using the new higher compression). > > ... > > > > 3590H upgrading is fully covered in the server README file. > > > > > > I must apologise for being a bit thick here, but exactly which README is > > this. I can find no reference to necessary steps when upgrading from B1A to > > the H1A 3590 drives in the manuals or the the README file in > > /opt/tivoli/tsm/server etc �(I'm running TSM on Solaris by the way). > > you should have: > > /opt/tivoli/tsm/server/README > > and this section goes into conversion strategies in detail: > > ********************************************************************************* > * $$6 Support for IBM 3590 Model Hxx Tape Drives * > ********************************************************************************* > > TSM now supports the IBM 3590H Tape drive. > > The 3590H tape drive writes data in a new 384 track data tape format. > 3590H drives can not write in 3590 128 track format or 3590E 256 track > format however, they can read data from the tapes previously written in > 128 track format on 3590 drives or 256 track format on 3590E drives. > > With new 3590H drives available, the existing 3494 libraries with 3590/3590E > drives may either be completely upgraded with 3590H drives or they may > have an intermix configuration (3590, 3590E and 3590H drives). > > TSM administrators must follow certain rules to transition from old > 3590/3590E drives to new 3590H drives and/or maintain both kinds of > drives within the same physical library. > > Minimum Configurations: > > Device Driver level: Atape.7.1.1.0 (ftp://service.boulder.ibm.com/storage/devdrvr/A > IX) > > Tape formats for 3590H: > - 3590H-B - uncompressed mode (similar to 3590E-B) > - 3590H-C - compressed mode (similar to 3590E-C) > - DRIVE - the most advanced available format > Note: For 3590E and 3590H tape drives the most > advanced formats are respectively 3590E-C and 3590H-C > > 1. All 3590/3590E drives within physical library are upgraded > with 3590H drives at the same time. > > Consider an example with one 3590/3590E drive physically > defined as /dev/rmt0. Assume that there were originally > defined devclass, logical library, and > storage pool for 3590 drive. > There were also some volumes (tape cartridges) checked > in the library with data written on that drive. > Replaced 3590/3590E drive with 3590H drive. > > Steps below will allow you to use the new 3590H drives > with minimum changes to TSM server: > > - Using SMIT utility or manually, remove /dev/rmt0 device > example: rmdev -l 'rmt0' '-d; > - Using SMIT utility or manually, define the 3590H device > example: mkdev -c tape -t '3590' -s 'scsi' -p 'scsi0' > -w '0,0' -l 'rmt0'; > - Run TSM server (dsmserv); > - Issue TSM command: UPDate DEVclass devclassname FORMAT=DRIVE > update devclass devclass_3590 FORMAT=DRIVE; > - Issue TSM command: DELete DRive libname drivename > delete drive lib_3590 drive_3590; > - Issue TSM command: > DEFine DRive libname drivename DEVIce=devicename > define drive lib_3590 drive_3590 device=/dev/rmt0; > - Users must update storage pool volumes to have ACCESS=READONLY > under the following conditions. Users do not have to follow > this procedure for database backup, dump or export volumes. > > For storage pool volumes: > 1) The volume currently has READWRITE access. > 2) The volume was previously written on 3590 drive. > For example, > UDPATE VOLUME volname ACCESS=READONLY WHEREACCESS=READWRITE > > This also applies to DRM-managed copy storage pool volumes that > are in the MOUNTABLE state. > > For DRM-managed volumes that are not available to the TSM server > (i.e., the volumes are not in MOUNTABLE state), the user does > not need to take any action. If copy storage pool volumes are > brought back on-site to recover the ADSM server, the COPYSTGPOOL > VOLUMES AVAILABLE macro will update the access of the copy > storage pool volumes to READONLY. > > For any other off-site volume (ACCESS=OFFSITE), the user must > update the access to READONLY after the volumes are brought > back on-site. > > 2. Intermix of 3590/3590E and 3590H drives in a single 3494 library > environment. > > Consider an example of a physical library with > one 3590/3590E drive defined on /dev/rmt0 and > a new 3590H drive defined on /dev/rmt1. > Assume that there were originally defined devclass, > logical library, and storage pool for 3590/3590E drives. > With addition of a new 3590H drive to the > library that already has 3590/3590E drives in it, new DEVCLASS, > new logical LIBRARY, and new STORAGE pool MUST be defined. > > Defining new devclass, logical library, and storage pool > for 3590H drive: > > DEFINE LOGICAL LIBRARY > define library lib_3590H libtype=3494 device=/dev/lmcp0 > scratchcategory=lib_3590_scratch > > privatecategory=lib_3590_scratch+3 > > DEFINE DEVCLASS > define devclass devclass_3590H devtype=3590 format=3590H-C > library=lib_3590H > format=3590H-B > format=DRIVE > > DEFINE STORAGE POOL > define stgpool stg_3590H devclass_3590H other parameters > > Defining separate devclass for each type of drives will > allow the user to specify the format for the drive and insure > that 3590/3590E volumes will not be mounted on 3590H drives > and that 3590H volumes will not be mounted on 3590/3590E drives. > > Defining a logical library for each type of drives will allow > to define two separate storage pools of scratch volumes. > It is necessary to allow write the label for the volume > in the appropriate format. > > Moving a scratch volume from 3590/3590E scratch pool > to 3590H scratch pool: > > - TSM command: CHECKOut LIBVolume libraryname volname REMove=No > - TSM command: CHECKIn LIBVolume libraryname SEARCH=Yes > Note: In order to move volume from 3590/3590E scratch pool to 3590H > scratch pool issue above commands and RELABEL the volume > after it has been checked in the 3590/3590E library. > > IN ORDER TO READ THE VOLUME PREVIOUSLY WRITTEN IN 3590/3590E FORMAT > ON 3590H DRIVE (THE STORAGE POOL THAT OWNS THE VOLUME POINTS > TO A DEVCLASS THAT USES 3590H drive): > - UPDATE ACCESS MODE TO THAT VOLUME TO READONLY > update volume volumename access=readonly whereaccess=readwrite > - CHECKOUT THE VOLUME FROM THE LOGICAL 3590/3590E LIBRARY > (THE DEVCLASS' OLD LIBRARY THAT HAD 3590/3590E DRIVES);lename > define drive l > - CHECKIN THE VOLUME TO THE LOGICAL 3590H LIBRARY > (THE DEVCLASS' NEW LIBRARY THAT CONTAINS 3590H DRIVES). > > Private volumes defined in private categories: > > The volumes defined in private category have to be marked READONLY in > order to read data from them on 3590H drives. After data is expired > and volume becomes empty its access type is still READONLY because > this volume was directly defined in the private category. In order > to reuse volumes with expired data on 3590H drives the access type of > these volumes must be updated to READWRITE type. The user may update > all volumes to READWRITE type with the following TSM command: > update volume volumename/ *(all of them) access=readwrite > whereaccess=readonly wherestatus=empty > There are also SQL scripts that will allow the user to query all volumes > with above mentioned attributes. > > Next time the empty volume is mounted on 3590H drive for writing, > it will be AUTOMATICALLY relabeled using 3590H format. This volume > can be used neither for reading nor for writing on 3590/3590E drives. > > Scratch volumes: > > Next time the empty volume is mounted on 3590H drive for writing, > it will be AUTOMATICALLY relabeled using 3590H format. This volume > can be used neither for reading nor for writing on 3590/3590E drives. > > Steve Roder, University at Buffalo > HOD Service Coordinator > VM Systems Programmer > UNIX Systems Administrator (Solaris and AIX) > TSM/ADSM Administrator > ([EMAIL PROTECTED] | (716)645-3564) > > Steve Roder, University at Buffalo HOD Service Coordinator VM Systems Programmer UNIX Systems Administrator (Solaris and AIX) TSM/ADSM Administrator ([EMAIL PROTECTED] | (716)645-3564)
