At a client company I work at, we were experiencing horrific ADSM performance 
(backing up remote servers to a home office mainframe) and lots of lost 
sessions (ANS1809W messages). The problem was corrected by a reboot of the home 
office ATM WAN  switch and changing packetshaper, to treat backup as straight 
low priority, rather than trying to manipulate sessions directly. These actions 
resulted in a dramatic improvement of performance and eliminated the lost 
sessions. You might want to closely look at your network environment.



>>> rbs AT BU DOT EDU 03/29/07 8:44 AM >>>
On Mar 29, 2007, at 8:26 AM, Ibán Bernaldo de Quirós Márquez wrote:

> Thanks for your reply Richard... sorry for not giving specific  
> details !!
> We are backin up directly to disk. At the moment three of the dsmc  
> have finished. Only one stills !! but very slow comparing to others...
> We have check network performance and the net is freely at 80 %, so  
> we are only using 20 % of our throughput.
> Does the TSM client do it best to get the better throughput  
> independly of how the network is ¿?

TSM doesn't have a lot of self-optimization, and what there is exists  
almost wholly in the server.  See "Backup performance" in ADSM  
QuickFacts for all the usual things to check.  Do a bunch of 'Query  
SEssion' commands on the server to get a sense of where slowness is,  
as revealed in the State report field.  Check the ANR0406I session  
start messages to see if all came via the same network path.   
(Routing can affect speed.)  The file system or directory branch  
involved can have a great impact on client throughput (fragmentation,  
contention, virus checking, search time, media weakness resulting in  
time-consuming read retries, etc.).  Check your OS error log for any  
issues.  Run an OS analyzer ('top', or the like) to see what the  
process and disk subsystem are doing.  If the problem area is not  
apparent, run the backup with client tracing activated, per the TSM  
Problem Determination Guide.

   Richard Sims