View Full Version : Read failure ODBC
geschätzte ForenteilnehmerIinnen,
es geht um eine Windows-Anwendung (C++), die seit Jahren auf einem Windows Server 2008 fehlerfrei läuft. Dabei werden Daten von IBM i gelesen und auch wieder geschrieben.
Seit wenigen Tagen läuft diese Anwendung auf Windows Server 2019, dabei kommt es einige Male am Tag zu einer Fehlermeldung (Read failure), deren Ursache ich nicht finden kann.
Auf Windows Server wurde der aktuellste IBM i access for Windows (SI68573) installiert, und auch auf IBM i sind die passenden PTF's installiert.
Hat jemand eine Idee, wie man die Ursache ausfindig machen kann?
LG
RR
dschroeder
22-02-19, 12:44
Ich würde als erstes den IBM i Job untersuchen, der das SQL ausführt. Dazu
WRKOBJLCK benutzerprofilnameDesJDBCUsers *USRPRF<user><user> [/CODE]aufrufen.
Dort bekommt man dann alle aktiven Jobs aufgelistet, die dem Userprofil zugeordnet sind. Wahrscheinlich ist es dann einer der QZDASOINIT-Jobs. Ich würde mir das Joblog dieser Jobs ansehen und schauen, ob es da eine Fehlermeldung gibt.
Dieter</user></user>
ODBC läuft immer per QZDASOINIT.
Man sollte die JOBD auf LOG(4 00 *SECLVL) stellen, eine QAQQINI in die QUSRSYS per CRTDUPOBJ aus der QSYS stellen und den DEBUG_MESSAGE (o.ä.) einschalten.
Ich hoffe, du hast auf dem Server die neueste iAccess Client Solution mit dem Windows-Action-Pack installiert und nicht eine alte CA-Installation.
Du kannst ebenso über die Windows-ODBC-Verwaltung eine SQL-Verfolgung einschalten. Diese wird allerdings sehr umfangreich.
Hallo Baldur,
auf dem Server ist IBM i Access für Windows 7.1 mit dem aktuellsten Service Pack installiert.
Könnte das eine mögliche Fehlerquelle sein?
Und: was meinst du in diesem Zusammenhang mit DEBUG_MESSAGE einschalten?
Lies mal hierzu das Thema QAQQINI:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzajq/qryopt.htm
Stichwort "MESSAGES_DEBUG".
Per STRDBG, allgemein bekannt, bekommt man ja diverse Diagnosenachrichten. Bei Programmen, auf die man kein Einfluss hat, kann man diese Nachrichten dann per QAQQINI trotzdem bekommen.
Ansonsten hat man bei den ODBC-Einstellungen / im Connection-String auch eine TRACE-Option.
Oder eben die SQL-Verfolgung des ODBC-Managers, wenn es denn kein AS/400-Problem ist.
Mittlerweile habe ich entdeckt, dass die Meldung nur dann kommt, wenn die PC-Anwendung über einen längeren Zeitraum - schätzungsweise 60 Minuten - inaktiv ist, und der Anwender dann wieder einen Button betätigt, der eine SQL-Anforderung an die IBM I sendet.
Womöglich ist das Connection-Pooling dafür verantwortlich.
Dann hat die Anwendung aber doch eine Macke.
Versuche es doch mal ohne Connectionpooling.
Ich schalte das meistens sowieso ab oder mache ein Eigenes.
Hallo Leute,
ich konnte jetzt feststellen, dass der Job xxxxxx/QUSER/QZRCSRVS, von IBM I automatisch nach genau 60 Minuten beendet wird, nachdem in der PC-Anwendung der letzte Zugriff auf die IBM i erfolgt ist.
In der Subsystembeschreibung QUSRWRK kann ich leider keine passende Einstellung für dieses Phänomen finden.
Welche Einstellungen könnten dafür relevant sein?
Lg
RR
Das hat ja nun mit ODBC nichts zu tun. Dies ist der Server-Job für Remote-Command!
Ggf. wird hier statt mit SQL-CALL die erweiterte Call-Unterstützung des CA-Drivers mit "{CALL ....}" bzw. "{{CALL ...}}" verwendet. Ich weiß nie, wann welche Version genommen wird.
Der Timeout wird ggf. durch CHGTCPA, Keepalive-Timer auf weniger als 1 Stunde (Default = 2 Stunden) beeinflusst. Per Keepalive werden inaktive Jobs verlängert, wenn der Client noch antworten kann.
Umgekehrt gibt es diesen Timer ebenso in Windows, den ihr ggf. in Win2008 verändert aber nicht dokumentiert habt;-).
https://www.consic.de/de/einstellung-der-tcp-keepalive-zeit-fuer-windows-server
Hallo Baldur, hallo Dieter,
nochmals vielen Dank für eure Antworten.
Jetzt, einige Wochen später, hat mir der Kunde mitgeteilt, dass die Ursache an der Firewall lag.
Also, Problem gelöst.
LG
RR