Bill, You are right : the change has to be made at devclass level, not at storage pool level !!!
Sorry for my mistake, I was in a rush when I wrote the mail :-( Cheers. Arnaud ************************************************************************ ****** Panalpina Management Ltd., Basle, Switzerland, CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 Direct: +41 (61) 226 19 78 e-mail: [EMAIL PROTECTED] ************************************************************************ ****** -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of William Boyer Sent: Friday, 13 October, 2006 15:48 To: ADSM-L@VM.MARIST.EDU Subject: Re: SUSPECT: I'm pretty sure that you cannot update/change the devclass of a stgpool. I would just: - Define the the new 3584 hardware - Take all the tapes out of the 3583 and put them in the 3584. - Update the devclass(es) to point to the 3584 library - Update the devclass(es)if needed...MOUNTLIMIT,FORMAT,... - Delete the old 3583 library/drive/path definitions. - Run a checkin for STATUS=SCRATCH on the 3584, then repeat for STATUS=PRIVATE - Check your paths if doing LAN free or NDMP backups for the new tape drive(s). Bill Boyer -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of PAC Brion Arnaud Sent: Friday, October 13, 2006 3:16 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: SUSPECT: Nicholas, As both libraries are using the same type of media, this should not be very difficult. What I would do : - define the new 3584 library + drives + path to the drives - define new device class pointing to 3584 - stop any operation accessing tapes (reclamation, client schedules, migrations) - store the output of "q libv name_of_3583_libary" to know which volumes were private and which one were scratch - checkout all volumes from 3583 library (checkout libv ... remove=bulk) - checking of the volumes in 3584 library, taking care of specifying if they're private or scratch - update the storage pools previously pointing to the 3583 library, to assign them the newly created 3584 device class (do not forget database backups devclass !). - if performing LAN free backups, review the storage agents configuration (same for possible library client TSM servers) - enable tape operations again ... This should do the trick ! Cheers. Arnaud ************************************************************************ ****** Panalpina Management Ltd., Basle, Switzerland, CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 Direct: +41 (61) 226 19 78 e-mail: [EMAIL PROTECTED] ************************************************************************ ****** -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of RODOLFICH, NICHOLAS Sent: Thursday, 12 October, 2006 23:14 To: ADSM-L@VM.MARIST.EDU Subject: SUSPECT: Hello All, We are using a 3583(LTO1) that is not very reliable. We also have a 3584(LTO1) that was freed up from elsewhere in the company and I will be replacing the 3583 with the 3584. TSM version 5.3.0 on AIX 5.3.4 What is the safest way to transition the data from the 3583 to the 3584. Both libraries will be online at one pint and I am trying to devise a way to do this with TSM safely! Any assistance will be appreciated!! Nicholas This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.