Craig - You need to perform analysis to identify problem cause, where the TSM Problem Determination Guide and Performance Tuning Guide will help.
Log pinning is due to prolonged transactions, and is aggravated by sluggish networking and sluggish TSM servicing of transactions (often due to underlying disk/tape issues). You can quickly see if your TSM server is "behind" in its rate of servicing incoming client data by inspecting the TCP receive queue packets backlog. In AIX that can be done via the command: netstat | head -2 ; netstat | grep -vi dns | grep tcp If the various entries show a large receive queue value, then it is likely that your networking is good, but that TSM is not keeping up with the incoming, as may be caused by the underlying disk, tape, and I/O path technology that it is using. If your clients have recently started backing up very large files (digital movies is a stereotypical case), then that would certainly contribute to what you're seeing. A quick look at TSM accounting data or ANE Activity Log messages would give a sense of that, and Query CONTent with a negative Count value on the collocated tape volumes that the clients are doing will show biggies. Query SESSion during client activity will also help identify consumptive sessions. Before you gave TSM the new LTO 3 and SATA hardware, I would hope that you benchmarked it first, to assure that it was providing the performance you would need in production, and thus uncover any issues with it beforehand. A bad RAID choice in disk implementation will also slow throughput. Old microcode may have performance-impairing defects. A mismatched device driver can cause operational delays. Don't waste your time or jeopardize your server in doing a TSM db unload/reload. You may want to confer with your operating system people to have them help narrow down the problem area, where they are familiar with all the specifics of your environment. Richard Sims