Yes, we saw your first posting...  We can't always reply immediately.
If you're unsure that a posting got distributed, inspect the List
archives to see if your posting made it into circulation.

First and foremost, if your TSM server is being jeopardized by a
client's behavior, you need to protect the server.  You can do 'SHow
LOGPINned Cancel' to terminate sessions or processes which are pinning
the Recovery Log, as described in the TSM Problem Determination Guide
- or simply cancel the session outright.

Beyond that, someone needs to take a good look at what that client is
doing, relative to healthy transaction processing.  Someone could have
set up something unreasonable, perhaps in ignorance of best practices;
or there could be an odd condition causing the client to get stuck
somewhere in the file system.  Check back in your Activity Log for ANE
session conclusion messages for that client, to see if it's performing
B/A client work (rather than TDP) and check past session statistics
for a sense of sizes, rates, and duration.  This can reveal if what
the client has been doing has been getting more outrageous over time,
or whether the current session is anomalous.  If the networking seems
ploddingly slow from the stats, that can get fixed.  It needs
analysis.  Talk to the client admin and see if they made recent
changes, or are aware of unusual data activity.

   Richard Sims   http://people.bu.edu/rbs/