View Full Version : Datei in CL durchlesen
Das liegt an der Prüfung, dass die selben Parameter wieder übergeben werden müssen.
PS:
Mich fragen?
Seid froh, dass ihr nicht meine Probleme lösen müsst :).
woodstock99
06-12-12, 10:52
ach komm :)).. also solange es sich ums thema Iseries dreht dann laß mal hören :)) .
bei evtl. Frauen/nachbarschaftsstreit etc :p
musst allein die suppe auslöffeln :D .
woodstock99
06-12-12, 10:54
pps: @ Pikachu
danke aber ich habe diesen befehl noch nie gebraucht :) .
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
06-12-12, 11:57
@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
06-12-12, 11:58
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 :(
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.
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
06-12-12, 12:33
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 (http://www.codeproject.com/Articles/117557/Set-Keep-Alive-Values)
woodstock99
06-12-12, 12:43
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 ..