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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Roger Deschner
Sent: Thursday, January 19, 2012 1:38 AM
To: ADSM-L AT VM.MARIST DOT EDU
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 rogerd AT uic DOT
edu<mailto:rogerd AT uic DOT edu>
========== "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. david-bronder AT uiowa
>DOT edu<mailto:david-bronder AT uiowa DOT edu>
>
|
