AW: TSM Upgrade frequency

Hello Todd

we have the same problem and open a requestby ibm. the reason for the
requirement in time is that the server and sta 
are talking over database-records (segments) (like db-io over TCP/IP) ! 
In time we have 16 W2K STA and 8 STA at HP and that is not the end ...

Helge van de Kraan
IS-Rechnersysteme

Volkswagen AG 
Brieffach 1883
38436 Wolfsburg

Telefon +49 (5361)9-73711
Telefax +49 (5361)9-29289
http://www.volkswagen.de

 
-----Ursprüngliche Nachricht-----
Von: Todd Lundstedt [mailto:Todd_Lundstedt AT VIA-CHRISTI DOT ORG]
Gesendet: Dienstag, 18. Februar 2003 17:47
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: TSM Upgrade frequency


For you folks that patch your TSM server frequently (like the individual
from Oxford University who upgraded from some version to 5.1.6.0 on Feb3,
then to 5.1.6.1 on Feb7, and now planning to upgrade to 5.1.6.2 within a
couple weeks), how many of you have Storage Agent nodes?
I am still on 4.2.1.7 simply because of the Storage Agent issue.  We have a
problem with TSM server crashes that is supposed to be fixed in 4.2.1.9+,
but I find it hard to justify upgrading to 4.2.1.9+ when I know I will have
to upgrade to 5.x soon after.  According to the documentation I have read,
the TSM Server version and the Storage Agent version must be at the same
level.
We have several Storage Agent nodes, and all of them are considered 24x7
servers, mission critical.  It is like pulling teeth to get downtime for
any one of them just for normal OS or Application type maint.  I dread the
time where I have to take them all down at once.  Even more so, I dread
having to take all of them down at the same time several times a month just
to keep updating TSM Storage Agent versions because the TSM Server needed a
patch.
How do you folks with several mission critical, 24x7 servers go about doing
TSM Server upgrades and TSM Storage Agent upgrades?  Especially considering
that TSM Server outages are best done during the day when no backups are
occurring, and TSM Client Node outages are done during the night to reduce
impact on the users of those Client Nodes.