We have a new wrinkle in this problem: a Firewall.
There is a firewall that issues a kill or disconnect after one hour of inactivity but TCP/IP does not get the notification and still holds the session until it's TCP/IP timers kick in--the default TIMEMARK value of 10,800 seconds (3 hrs)--and finally kills the session.
This explains the behavior:
TCP/IP timeout settings need to be less than the firewall timeout.
You need to ensure that TCP/IP kills the session before the Firewall timer removes the session from its STATE list. Otherwise, TCP/IP does not know that the session has been terminated by the firewall and you will see errors similar to what is described here.
Check with your TCP/IP vendor's recommendations for configuring timeout when there is a firewall in place.