Gretchen [and anyone else],

Does the 5.1.6.1 upgrade require new client code?

How do you handle distribution/installation/maintenance of the client?
I by no means have the volume (500GB/night and growing with 250 clients
and growing) you have, but with the 5.x release of TSM, there seems to
be a new "release" of the client every other day (I'm exagerating, of
course).  My sysadmins on the client side are having a tough time
keeping up with the client version and patches.  Just wanted to know how
a big install like your handles this.

TIA.

Mahesh


>>> [email protected] 02/10/03 09:02AM >>>
The two situations where I could force a core dump in v5.1.6.0 have
been resolved, but I think there is now a different problem in
v5.1.6.1.

Granted, my servers run flat out all the time with sessions
constantly,
but I rarely pin the 13 GB log with dirty pages (at least not over
60 to 70%). It's happening all the time now. I've had to cut back
on my workload by two thirds in order to get the log to settle down.
Not good. It took out two of my servers a couple of times over the
weekend until I severely limited the number of sessions and scheduled
sessions.

The log would creep up and I'd get the 'log is pinned by a dirty
page' from 'show logpin'. When the log started to cool off, but not
drop in utilization, this message would alternate with the 'log
not pinned, will be cleared at next commit'. It took one server
over 5 hours last night to 'calm down' - I disabled sessions when
it hit 40% and it climbed to over 80% before it started to wane.

Also, when it's a client that has the log throttled, it's almost
impossible to cancel the session before the log fills and core
dumps the server. A 'cancel session force=yes' would be really
nice about now. It's about a wash whether or not to allow the
log to fill and core dump or just halt the server and let it
come up again and 'figure' things out.

It'd be nice to know if we can force a commit or if it's time
based, just when does it happen?

Gretchen Thiele
Princeton University