>     Look at "Cache Hit Pct." and "Cache Wait Pct." in the q db f=d
>output.  You want to see cache hit % in the 98-99 range and Wait% to be
>zero.  If these numbers are not in these ranges, then your performance
>suffers.  Increasing BUFPOOLSIZE in dsmserv.opt is the knob to turn, but
>if you turn it up to far, your system will page if you are short of real
>memory.

Good qualification, Steve.  There is the tendency to crank the BUFPOOLSIZE
value, achieve a Cache Wait Pct. around 98, and go home happy.  But that's
illusory if you don't have enough real memory, because the buffer space
will be paged (unless buffers are page-locked in memory, which I doubt).
Looking at TSM performance from the standpoint of TSM is rather make-believe,
because TSM is an application, and as such runs in a virtual environment
under the operating system.  TSM server admins need to be well versed not
only in TSM, but also in the operating system, in order to be able to deal
effectively with performance issues.  That's why we all get paid so much,
ayuh.
       Richard Sims, BU