Out of order..

==> On Thu, 25 Aug 2005 14:03:20 -0400, Tae Kim <Tae_Kim AT MCKINSEY DOT COM> 
said:

> 3. Less experienced Admins might do something funky to the directory or
> files that TSM instance is running off of.

Not to be too brutal here, but anyone whom you fear will

rm -rf /usr/tivoli/tsm/server

ought to have root privileges taken away. :)

And further, what's to prevent them from

rm -rf /some/other/path/TSM-server/5.3.1/

?


> 2. Down time can be managed more efficiently. It is hard to coordinate
> shutdown of TSM server for a extended amount of time because of TDP domino
> and oracle backs ups (backing up archive and recovery logs).

I absolutely agree that server splits help reduce downtime.  I've got 9 TSM
servers on my main hardware, and am contemplating two additional ones to
accomodate new customers.   It's the manual moving around of code directories
that makes me shudder.


> 1. Upgrade of the TSM binary will not upgrade all of TSM servers at Once.
> If I want to apply a patch I can try it on one TSM server that is less
> critical and run it for couple of days before applying it to other servers
> (don't have QA box with 100's of clients and a separate .

The problem is not with the theory of this, it's with the practice.  If you
manage to get everything right, that'll be fine.  But if you get something
wrong, the first you will understand of it is that your running TSM servers
just had some resource they care about yanked from under them.  You -thought-
you were only affecting the to-be-upgraded one, but instead you zapped (for
instance) the device package that a running instance was using.

Further, TSM's packages are intertwined with low-level device packages all
across AIX.  Heck, the HSM product even has kernel modules rattling around.
What happens when you need two or three different versions of Atape?  Eugh.


So, my point is that when you use SMITTY to apply the new codelevels, you are
not in fact isolating the other instances, no matter what you think.  I
suggest buying a B50 (cheep cheep) and doing your test installs there.



> but its not IBM supported so I guess I have no choice

Well, another list denizen has reported long-term success with the strategy
you describe, so clearly "It doesn't work" is too strong a case.  You may meet
with the same success as did he.   Write about it if you do, and I'll cheer.

>From waaay over here. ;)


- Allen S. Rout