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
========== "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
>
|
