Datei in CL durchlesen

[Fuerchau]

Ja, aber eben erst ab V6 und ich meine auch nur bei CLLE.

[woodstock99]

nö funzt auch bei CLP ...

[B.Hauser]

Welches Problem habt Ihr denn mit CLLE, dass Ihr CLP braucht?

Birgitta

[woodstock99]

ich hab überhaupt keins ..
da must du unseren baldur fragen ) .

Ich weiß ehrlich gesagt eh nicht warum man noch clp braucht .
gibts ein beispiel ??

[Pikachu]

Beispiel: Der Befehl TFRCTL ist nur in einem CLP (ohne ILE) gültig.

[Fuerchau]

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]

ach komm ).. also solange es sich ums thema Iseries dreht dann laß mal hören ) .

bei evtl. Frauen/nachbarschaftsstreit etc
musst allein die suppe auslöffeln .

[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.

[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.

[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