MSQuery hängt sich auf beim Zugriff auf AS400

[Fuerchau]

Du kannst per "WRKOBJLCK UserName *USRPRF" den zuständigen QZDASOINIT-Job ermitteln und dort mal ins Joblog schauen.

In der ODBC-Konfig kannst du im Register "Diagnose" mal den STRDBG aktivieren um ggf. erweiterte Fehlermeldungen zu sehen.
Im Register "Katalog" sollte "Suchmuster aktivieren" nicht angehakt sein. Dies führt nämlich zu temporären Indizees auf der QSYS2/SYSCOLUMNS, falls eine Bibliothek einen Unterstrich "_" enthält. ODBC versucht nämlich dann, die Spalteninformationen per "like" zu ermitteln und das kann dauern.

[ozean]

Danke für eure Infos! An der Berechtigung auf AS/400 kann es eigentlich nicht liegen, kann ich mir zumindest nicht vorstellen.
Die Optionen in der ODBC-Konfig habe ich so eingestellt, leider hat es nichts gebracht. QUERY hängt und es kommt auch keine Fehlermeldung.

[ozean]

Was aber die Befehle auf AS/400 angeht, da habe ich keine Ahnung davon. Ich kann solche Vorschläge nur an unseren AS400 Spezialisten weiterleiten. Er kann aber nur verzögert antworten.

[Fuerchau]

Dann wird auf eine Antwort der AS/400 gewartet.
Jetzt muss dein AS/400-Spezi mal im System nachschauen.

[ozean]

AS400 Spezialist sagt, dass alles in Ordnung ist. Es gibt auch keine Fehlermeldungen. Die Verbindung wird aufgebaut, der User ist eingeloggt, beim Klick auf das Auswahl-Fenster im Query wird ein Datenpaket vom Rechner zu AS400 geschickt und ein von der AS400 zum Rechner. Ich denke, das diese sind begrüßt haben. Danach geht nichts mehr.
Diese Pakete konnte man mit dem Programm Wireshark sehen.
Kann es vielleicht am Netzwerk selbst liegen? Wir haben bei uns im Netzwerk eine Firewall/Proxy. Diese fundiert auch als Gateway für alle Rechner. Dass da irgendwas blokiert wird?
Kann mir eigentlich nicht vorstellen, da es früher funktioniert hat.

Ich weiß nicht mehr, wo ich anfangen soll

[Fuerchau]

So pauschal, dass alles in Ordnung ist, kann man das nicht gelten lassen.
Ein Netzwerk-Protokoll besagt da überhaupt nichts.

Dein Spezi soll doch bitte den obigen Weg mal nachvollziehen (WRKOBJLCK ...), wenn dein MS-Query hängt.

Starte vorher in deiner ODBC-Konfig über Diagnose mal den STRDBG, so dass der Spezi im Joblog auch was sehen kann.

Manchmal kann auch die Ursache ein "kaputtes" SQLPKG auf der AS/400 sein.
Um dieses auszuschließen geh in deine ODBC-Konfig ins Register "Pakete" und trage als Paketbibliothek "QTEMP" ein.
Das stellt sicher, dass nicht auf "alte" Pakete referiert wird.

[ozean]

Ok, werde ich ihm sagen.

Die Sache mit QTEMP hat nichts gebracht. Hängt auch wieder.

[mors]

Hallo zusammen,

ich bin dann wohl der Spezi.

Wir haben STRDBG gestartet und dabei ist folgendes rausgekommen:

Joblog

Job 179454/QUSER/QZDASOINIT im Subsystem QUSRWRK in QSYS am 15.09.09 um
11:15:27 gestartet. Job im System am 15.09.09 um 11:15:27. angekommen.
Benutzer POHL an Client 192.168.80.8 ist mit dem Server verbunden.
DESCRIBE für vorbereitete Anweisung STMT0002 beendet.
PREPARE für Anweisung STMT0002 beendet.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.
Abfrageoptionsdatei kann nicht abgerufen werden.
Abfrageoptionsdatei kann nicht abgerufen werden.
Alle Zugriffspfade wurden für Datei QADBXRDBD berücksichtigt.
Zugriff nach Eingangsfolge für Datei QADBXRDBD verwendet.
****: Debug-Nachrichten für Abfrage werden beendet.
ODP erstellt.
Blockung für Abfrage.
Cursor SQL_CUR00FD45C0 eröffnet.
Offener Datenpfad (ODP) gelöscht.
Cursor SQL_CUR00FD45C0 wurde geschlossen.
STATEMENT TEXT FOUND : SELECT TABLE_NAME, TABLE_TYPE, COLUMN_COUNT,
TABLE_TEXT, LONG_COMMENT, TABLE_SCHEMA, SYSTEM_TABLE_NAME,
FILE_TYPE FROM QSYS2/SYSTABLES WHERE (((TABLE_TYPE = 'T' OR TABLE_TYPE
= 'P') AND TABLE_NAME NOT LIKE 'QIDCT%' AND
TABLE_NAME NOT LIKE 'QADB') OR ((TABLE_TYPE = 'L' AND
TABLE_NAME NOT LIKE 'QIDCT%') OR (TABLE_TYPE = 'V' AND TABLE_NAME
NOT LIKE 'SYS%')) OR (TABLE_TYPE = 'A')) AND TABLE_SCHEMA IN
(?,?) ORDER BY TABLE_TYPE, 
STATEMENT NAME FOUND : FIFAABTALL0002.
STATEMENT NAME FOUND : FIFAABTALL0002.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.
Abfrageoptionsdatei kann nicht abgerufen werden.
Alle Zugriffspfade wurden für Datei QADBXREF berücksichtigt.
Alle Zugriffspfade wurden für Datei QADBXMQT berücksichtigt.
Datei QADBXREF in Verknüpfungsposition 1 verarbeitet.
Datei QADBXMQT in Verknüpfungsposition 2 verarbeitet.
Empfohlener Zugriffspfad für Datei QADBXREF.
****: Debug-Nachrichten für Abfrage werden beendet.
ODP erstellt.
Blockung für Abfrage.
Cursor FILE eröffnet.
Offener Datenpfad (ODP) gelöscht.
Cursor FILE wurde geschlossen.
STATEMENT TEXT FOUND : SELECT COLUMN_NAME, TABLE_NAME, DATA_TYPE, LENGTH,
NUMERIC_SCALE, IS_NULLABLE, LONG_COMMENT, NUMERIC_PRECISION,
TABLE_SCHEMA, NUMERIC_PRECISION_RADIX, COLUMN_TEXT, CCSID,
SYSTEM_TABLE_NAME, SYSTEM_COLUMN_NAME, ORDINAL_POSITION FROM
QSYS2/SYSCOLUMNS WHERE TABLE_NAME = ? AND SYSTEM_TABLE_SCHEMA = ?
ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION.
STATEMENT NAME FOUND : FDLCDALCLL0001.
STATEMENT NAME FOUND : FDLCDALCLL0001.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.


Da meine AS400-Kenntnisse eigentlich eher rudimentär sind, sagt mir das jetzt nicht allzuviel.
Ist es normal, dass beim ersten Auftreten von 'STATEMENT TEXT FOUND' das Statement einfach abbricht?

[Fuerchau]

Soweit sieht eigentlich alles normal aus.
Allerdings ist meine Vermutung des temporären Index nicht ganz falsch.

Die nachricht "Empfohlener Zugriffspfad für Datei QADBXREF." sollte man mal mit F1 im Detail ansehen.
Es sieht mir ganz danach aus, dass Query nicht steht, sondern die AS/400 ganz einfach für die Schemaabfrage so lange benötigt.

Das kann auch an einem fehlerhaften SQLPKG QGPL/QZDAPKG liegen.

Bereinigung:
ENDHOSTSVR *DATABASE
DLTSQLPKG QGPL/QZDAPKG
STRHOSTSVR *DATABASE

Das SQLPKG wird automatisch neu erstellt.

[mors]

Ok, hab das mal probiert:

Beim Ausführen des dlt-Befehls kommt die Meldung "Objekt QZDAPKG [...] kann nicht zugeordnet werden".
Laut F1-Hilfe sind noch Sperren auf diesem Objekt.
Kann ich die betreffenden Jobs einfach beenden?

PS: Die Jobs, die die Sperren halten sind "QZDAINIT" und etliche "QZDASOINIT"-Jobs des Benutzers QUSER

[Fuerchau]

Ich hab noch mal gesucht, hier die vollständige Vorgehensweise:

ENDHOSTSVR *DATABASE
ENDPJ QUSRWRK QZDASOINIT *IMMED
ENDPJ QUSRWRK QZDASSINIT *IMMED
ENDPJ QSERVER QZDAINIT *IMMED
DLTSQLPKG QGPL/QZDAPKG
STRHOSTSVR *DATABASE
STRPJ QSERVER QZDAINIT