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
>
> >>> spr AT REXX.ACSU.BUFFALO DOT EDU 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
> (spr AT buffalo DOT edu | (716)645-3564)
>
>
Steve Roder, University at Buffalo
HOD Service Coordinator
VM Systems Programmer
UNIX Systems Administrator (Solaris and AIX)
TSM/ADSM Administrator
(spr AT buffalo DOT edu | (716)645-3564)
|
