[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Feb 2002
    Beiträge
    162

    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

  2. #2
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Ich würde als erstes den IBM i Job untersuchen, der das SQL ausführt. Dazu

    WRKOBJLCK benutzerprofilnameDesJDBCUsers *USRPRF [/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

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #4
    Registriert seit
    Feb 2002
    Beiträge
    162
    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?

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Lies mal hierzu das Thema QAQQINI:
    https://www.ibm.com/support/knowledg...ajq/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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #6
    Registriert seit
    Feb 2002
    Beiträge
    162
    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.

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Dann hat die Anwendung aber doch eine Macke.
    Versuche es doch mal ohne Connectionpooling.
    Ich schalte das meistens sowieso ab oder mache ein Eigenes.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    Feb 2002
    Beiträge
    162
    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

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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...windows-server
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Feb 2002
    Beiträge
    162
    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

Similar Threads

  1. Antworten: 12
    Letzter Beitrag: 03-11-17, 22:05
  2. sql vs Nativ read delet ...
    By ILEMax in forum IBM i Hauptforum
    Antworten: 17
    Letzter Beitrag: 03-03-16, 17:09
  3. Nicht lesbare Daten nach Read aus dem IFS
    By msost in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 25-07-14, 15:54
  4. READ / READE in free-rpg
    By Gimli in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 10-03-03, 13:08
  5. VA RPG Read anweisung schlägt fehl
    By Peter Kosel in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 18-10-01, 13:49

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •