I think the answer can be "it depends", or "yes it has always worked that way for SCSI libraries", or "maybe", depending on exactly the situation. I don't believe there is any difference between what happens in TSM 6.any and 5.5.
* For 3494 libraries, TSM doesn't manage the slot locations, the 3494 does. TSM just tells the 3494 what cartridge it wants mounted in which drive, and the 3494 software is responsible for locating the cartridge via its on-board data base and moving it around. * TSM has a much more intimate relationship with SCSI libraries. TSM has to actually know the slot locations and pass them to the library when it wants something done. What it sends down the wire to the robot is the equivalent of "go to slot 1428, grab cartridge, move to the drive in position 256, load cartridge". It maintains the cartridge slot locations and drive positions (called element numbers) in the TSM DB. You can also see them if you look at your devconfig file. They get updated by checkin/checkout, or a library audit. TSM gets the available slot locations from the SCSI library at start up time, when you see the "library bubba is ready for operations" message in the activity log. Even the mid-sized libraries like the TS3310/ADIC 500/Quantum I500 come with different configurations with different numbers of drawers/frames/drives/slots/IO ports, so the only way TSM can know what's actually out there, and what drive is in which physical position, is to ask the library. Thus, if you are deleting/defining drives and paths, or replacing a failed drive - things that change just from TSM's point of view - you can do that in a SCSI library without restarting TSM. (Although in a Windows environment, if you are recabling stuff it also isn't too hard to get yourself in a situation where you have to reboot Windows to clear a hung or error condition on the bus, which really isn't TSM's fault but it gets restarted anyway. Oh, for the days I had an AIX TSM server...) But if you make a change to the actual hardware configuration of the tape library ( adding a new frame/drawer, licensed slots, adding a physically new drive in a library position where there was no drive before), certainly anything that requires a library reboot/rescan, you have to restart TSM so it will pick up the new config from the robot's point of view. * Change what the 3494 sees - no restart * Change what TSM and the OS see - no restart needed from TSM's point of view * Change what the SCSI tape robot sees inside the library - gotta restart TSM There are other situations that vary a lot. You can usually update drive firmware without a TSM restart. You can sometimes update library firmware without a TSM restart, but if you have a problem the first thing you'll need to try is a TSM restart (and a host reboot on Windows) so just plan on it anyway. There are some libraries - the TS3500 I know in particular - that will let you force a drive reset from the library panel, without a host/TSM restart. I'm sure there are other cases I've missed. But this may help explain why you get different answers, depending on the context and the situation. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Roger Deschner Sent: Thursday, January 19, 2012 1:38 AM To: [email protected] Subject: Re: [ADSM-L] Drive and Path Definition I used to believe in all sorts of hokus-pokus in this regard, but I have found that if you do things in an organized way in the correct order, everything just works, without restarting dsmserv, on both TSM 5.5 and 6.2. See the TSM for AIX Administrator's Guide. I recently moved a library from a simple configuration with one server, to a Library Manager configuration with multiple server clients, which involved a lot of undefining and redefining of paths and drives, and it all just worked. The Library Manager is TSM 6.2, and it has a 5.5 client and a 6.2 client. There were surprisingly few surprises. Add the drive, run AIX cfgmgr, go into smit and add Tivoli Storage Manager devices, define the drive and path in TSM, and it just works. Pay attention to the fact that typically rmtN, mtN, and TSM driveN device numbers will be different. Make sure the serial numbers in TSM Q DRIVE F=D are correct. Do things in the wrong order, and sometimes restarting dsmserv or even AIX can make up for your disorganization, making it appear that those restarts were necessary. In my experience, this is an area that has become a lot more stable and predictable in recent releases of TSM 5.5 and 6.2. Roger Deschner University of Illinois at Chicago [email protected]<mailto:[email protected]> ========== "You will finish your project ahead of schedule." =========== ================= (Best fortune-cookie fortune ever.) ================== On Wed, 18 Jan 2012, David Bronder wrote: >Richard Rhodes wrote: >> >> > In the past we've never had to restart TSM to add a new drive. As >> > long as the drive was discovered and available at the AIX layer, we >> > could define the new drive. Has this changed with v6.2.x? >> >> It's my experience that any change to the library (adding slots or >> drives) requires cycling TSM before it can access the new resource. > >Seriously? Is this behavior due to changes in TSM 6.x, or has it >always been this way for SCSI-style (smcX) libraries? > >I've never had this issue with my 3494 library and any TSM version from >ADSM 2.1 through TSM 5.5. > >If it's a 6.x change, it makes me nervous about the upgrade from 5.5. >If a SCSI library limitation, it makes me hesitant to give up my 3494 >(looking at dedupe VTL appliances and/or newer physical libraries). >Getting TSM downtime is like pulling teeth, as our DBAs run log backups >for Oracle and MS-SQL servers almost continuously, 24x7. > >-- >Hello World. David Bronder - Systems Architect >Segmentation Fault ITS-EI, Univ. of Iowa >Core dumped, disk trashed, quota filled, soda warm. >[email protected]<mailto:[email protected]> >
