Ich hab ja nicht gesagt, dass die Probleme mit der iSeries zu tun haben.
Beispiel (hat nichts mit diesem Problem zu tun):

TCP/IP ist eine sog. offene Verbindung ohne Polling o.ä.

Beim ODBC-Zugriff werden die Daten ja per Fetch abgeholt.
Durch das Blocken dauert der Fetch ggf. etwas länger, da die iSeries eben erst mal sammelt.
Bricht nun das Netz kurzfristig zusammen, kann die iSeries nicht senden und trennt den Job.
Der Empfänger bekommt von dem gar nichts mit, da TCP/IP glaubt, die Daten kommen schon noch irgendwann.
Komischerweise schlägt hier kein Timeout auf. Der ODBC-Thread hängt sich komplett auf.
Ein Kill-Thread von einem Überwachungs-Thread aus, funktioniert auch nicht, da der ODBC-Treiber nun einen Close auf die Connection machen will, dabei aber auf das Ende der Operation des Fetch wartet, der ja nie fertig wird.
Hier hilft dann manchmal ein TerminateProcess, manchmal aber auch nicht.
Um den gesamten Prozess dann tatsächlich zu beenden hilft hier nur, von einem weiteren Thread der ggf. mehrfache Aufruf "TASKKILL /PID 12345 /F" bis der Prozess endlich weg ist.
Das Problem ist nach 5 Tagen testen und probieren somit gelöst.

Es gibt noch so ein paar Hinweise zum Thema "KeepAlive" bei TCP/IP, was aber zentrale IP-Einstellungen für den gesamten Server bedeuten und ggf. "Offline"-Probleme bei anderen, wirklich lang wartenden Prozessen, bedeuten würde.