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: Jan.Norback AT Atosorigin DOT com
Tel: +31 (0)40-2780289
Mobile: +31 (0)6-12994492
Fax     : +31 40 2783962