On Dec 14, 2007, at 10:55 AM, Fred Johanson wrote:
This sounds like PMR#64846-122, which is still open after months of work. The last thing in the traces we ran is a TCPFLUSH. After that things hang forever.
That reminds me of the trivial but helpful diagnostic of running the 'netstat' command with no operands, to see the dynamics of the Recv-Q and Send-Q packet counts. Running it on both ends of the session can be illuminating. Where you consistently see a Recv-Q on the TSM server system, for the client's incoming work, it suggests that the TSM server is not keeping up with the flow, where 'select * from sessions' will reveal the detail of byte counts, to verify progress numerically, and some state sense of it by last verb recorded. Certainly, the great variable in session progress is the intervening networking, which can be tested concurrently, from the OS, as the TSM session prevails. Richard Sims tired of the snow, and it's not even winter yet