Lawrence, I guess you are talking about 3590 drives in a 3494 library? For that there are some good info in the README file for the server (see below). We upgraded all the drives to E drives at the same, if you only got 2 then it makes sense to do both at the same time. Just remember to put all existing none-scratch tapes into readonly, they can't be written to until they have gone back to scratch through expire (and move data). (Read is no problem from the upgraded drives). Make sure you are upto date with all SW including TSM/library/drives.
================================= README.SRV=================== .... 1. All 3590 drives within physical library are upgraded with 3590E drives at the same time. Consider an example with one 3590 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 drive with 3590E drive. Steps below will allow you to use the new 3590E 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 3590E 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. ... Regards, Jan Norback Tivoli Certified Consultant: ADSM/TSM IBM Cert. Adv. Technical Expert RS/6000 AIX Atos Origin-IT (MS/DS/OSS Unix) VA-106, PO-box 218, 5600 MD Eindhoven, The Netherlands Groenewoudseweg 1 5621 BA Eindhoven, The Netherlands Email: [EMAIL PROTECTED] Tel: +31 (0)40-2780289 Mobile: +31 (0)6-12994492 Fax : +31 40 2783962 -----Original Message----- From: Lawrence Clark [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 3:43 PM To: [EMAIL PROTECTED] Subject: Upgradeing 3494 drives We are upgradeing the drives in our 3494 library to: -double the storage capacity of the J cartridges -convert from SCSI to fibre There seems to be a question of if we need to convert just one drive and move the data to the newly defined lib / drive or can we simply convert both drives, as long as the drives remain in the same library defined to TSM. Has anyone done this? The existing cartridges can be read by the upgraded drives ( but noit written to ). I guess the question is will TSM use the newly defined drives when a call for a cartridge with existing data is made.