Kelli -

The ANS1809E messages suggest that your server IDLETimeout value is
much too low.  The ANR0481W messages suggest that the COMMTimeout
value is also too low.  Those become factors when the client is slow,
which seems the issue which needs to be pursued.

Assuming that, beyond verifying settings, that you have empirically
tested the actual network throughput between client and server (FTP
or other), you might also want to perform a traceroute or the
equivalent, to assure that you're not suffering a transcontinental
misrouting or the like.  You might want to perform Query SEssion in
the server, or examine TSM accounting records, to discern the nature
of the delay as seen from the server.  I would also review the
timestamps in the full client backup log to see if that is
inordinately slow, which may be induced by some issues in the file
system, or possibly induced by a kernel patch.  And, of course, look
for lots or retries.  If the transfer of a given file seems slow, try
doing a cp of it to /dev/null to perceive file system performance.
Beyond that, run a client trace and find out where the slowness is.
It may well point to some common element in the networking.  If you
are backing up over a WAN or LAN, you are at the mercy of other
traffic (including DoS attacks).

You can also try isolated Incremental or Selective backups of certain
files, as test-case examinations of what's happening.  Also, if TSM
is having trouble getting data out of those systems, then maybe other
applications are as well: check for manifestations in their logs.

The messages you pasted into the posting are truncated, so we don't
have all the details.  The ANS8010E message seems very new, and
undocumented: try 'dsmc help' to get info on that.

   Richard Sims