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