Datei in CL durchlesen

[woodstock99]

pps: @ Pikachu

danke aber ich habe diesen befehl noch nie gebraucht .

[Fuerchau]

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.

[andreaspr@aon.at]

@Baldur: Stimme dir zu. Ich bin froh nicht diese Probleme lösen zu müssen
Dieses oder zumindest ein ähnliches Problem hatte ich auch mit ODBC in .Net. Habs dann mit dem IBM.DB2.Net Provider proibert und dort ging es dann.

[woodstock99]

ich weiß zwar jetzt nicht genau ob dir das hilft aber per z.b.

netstat -ano

kann man in der commando zeile die offenen verbindungen des computers abfragen. aslo kann man das doch auch programmieren . fehlt dann dieser odbc eintrag/port ist die verbindung doch gekappt worden .

evtl schreib ich ja ier jetzt den totalen müll weil ich zu wenig in deinem problem drinnen bin

[Fuerchau]

Das liegt nicht am Provider, da es in den Tiefen der Sockets verborgen ist.
Man findet diesbezüglich auch mit .NET ähnliche TCP/IP Hinweise in Google bis zum Hängenbleiben der Anwendung.
Selbst der Garbage-Collector hängt sich auf da sich TCP/IP-Ressourcen nicht freigeben lassen.
Das Schlimme beim Testen ist ja, den genauen Zeitpunkt für die Netztrennung zu erwischen. Im Debug-Modus funktionierts meistens nämlich nicht, da ja alles gebremst ist und der Fehler reproduzierbar nur 1x bei 10 oder mehr Versuchen klappt.

[Fuerchau]

Der netstat liefert ja die Verbindung noch als offen, da diese lesend wartet!
Während des Lesens kann man ja kein Ping oder sonstwas auf der selben Verbindung machen da diese ja gerade liest. Und eine neue Verbindung klappt ja da das Netz wieder da ist.
Es geht also nur um eine kurzfristige Unterbrechung, wenn der Sender gerade schreibt und daher disconnected und der Empfänger eben ewig wartet.

PS:
Das passiert auch schon mal bei 5250-Verbindungen, wenn nach Funktionstaste auf AS/400 gewartet wird und der Job auf der AS/400 auf Grund der Unterbrechung trennt oder umgekehrt, die AS/400 trennt den Job nicht, was aber mit CHGTELNA beeinfussbar ist (Defualt 2 Stunden!).
Da hilft auch kein 5250-KeepAlive, da die Unterbrechung zu kurz war, so dass der Keepalive, der ja eine 2. Verbindung braucht, beantwortet wurde.

[woodstock99]

ich raffs nicht . ändert sich dann der status nicht von hergestellt auf weiß der geier was ??
aber das problem wird ja sein das du sie ständig überprüfen müsstest . sprich z.b. dummy select = true oder halt wirklich prüfen per funktion ob die verbindung zum server noch da ist aber das geht ja auch die performance ..

programmieren kann man das ja alles .

evtl hilft dir das a bissi weiter

Set Keep-Alive Values - CodeProject

[woodstock99]

ps du kannst doch aber auch beim odbc treiber unter verbindungspools mit der zeit spielen wenn du den nur speziell für diese connection brauchst ..

[Fuerchau]

Ich glaub dir ja dass du es nicht raffst.
Also:
Du hast eine Verbindung, die man sich als Rohr vorstellen muss.
Du unterhältst dich über genau dieses Rohr mit dem Partner in dem du eine Frage stellst, das Rohr also am Mund hast, und auf die Antwort wartest, also das Rohr ans Ohr hängst.
Während du also auf dem Rohr wartest, will der andere dir antworten, stellt aber fest, dass das Rohr defekt ist und legt sein Ende weg.
Da dir nun die Antwort zu lange dauert, du das Rohr vom Ohr aber nicht wegnehmen kannst, stellst du nun über ein 2. Rohr die Frage "Bist du noch da?" und bekommst die Antwort "ja".
Also wartest du auf dem 1. Rohr weiter auf die Antwort.
Dieses Keepalive-Spielchen dauert nun ewig, da ja die Verbindung über das 2.Rohr geht nur das 1. Rohr ja kaputt ist.
Leider muss man nun das 1. Rohr irgendwie von deinem Ohr wieder wegbekommen, was du aber nicht zulässt da du behauptest "Ich arbeite doch noch".
Hier hilft leider nur, so leid es mir tut, dich zu erschießen und einen neuen Arbeiter zu nehmen.

[malzusrex]

Das ist doch mal ne Sprache, die jeder versteht