Linked Server von SQL2008 zu AS400 zeigt keine Bibliotheken

[hs]

Hallo,

wir möchten von einem SQL2008-Server auf unser Testsystem mit OS 5.2 zugreifen.

Auf unserem Livesystem V 5.4 klappt das wunderbar mit folgender Verbindung:

Anbieter: IBM DB2 for i5/OS IBMDASQL OLE DB PRovider
Anbieterzeichenfolge: "default collection = QGPL"
Unter Sicherheit haben wir den Namen und das Kennwort eines User mit *SECOFR Berechtigung eingegeben - um Berechtigungsprobleme auszuschließen.

Auf V5.4 klappt das wunderbar, ich kann alle Tabellen der Bibliothek einsehen und SQL darauf ausführen.

Auf dem Testsystem aber nicht, die Tabellen der Bibliothek werden mir nicht angezeigt.

Muss das auf der AS400 noch was gestartet werden oder geht es so nicht mit OS 5.2?

Danke für euere Hilfe
HS

[B.Hauser]

Ist bei beiden Systemen die Default Collection auf QGPL gesetzt?
Ist vielleicht bei einem System zusätzlich eine Bibliotheksliste gesetzt und beim anderen nicht?

Birgitta

[hs]

Hallo Birgitta ,
QGPL habe ich nur als Beispiel reingeschrieben.
In Wirklichkeit steht dort einen Bibliothek unseres ERP-Systems. Ist bei beiden aber identisch.

Gruß
HS

[Fuerchau]

Das Problem ist ggf. die Inkompatibilität des Treibers von V5R4 zu V5R2.
Wenn du V5R4-Treiber eingesetzt hast, stehen bestimmte Funktionen für V5R2 nicht zur Verfügung, da sich die internen SQL-Aufrufe diesbezüglich verändert haben.

Umgedreht können V5R2-Treiber aber auf V5R4-System zugreifen (aber nicht mehr auf V6 und höher).

Wenn du die Verbindung im SQL-Server offen hast, kannst du auf der AS/400 per
"WRKOBJLCK <USER> *USRPRF"
den zugehörigen QZDASOINIT-Job ermitteln.

Der OLEDB/ODBC-Treiber versucht einen CHGLIBL per QCMDEXC-Aufruf.
Du kannst also die Bibliotheksliste des Job's prüfen und ebenso ggf. das Joblog, ob Fehler aufgetreten sind.

Alternativ hilft dann ggf. nur noch das Anpassen des Systemwertes QUSRLIBL oder in der Jobbeschreibung für QZDASOINIT-Job's den USRLIBL-Teil.

[KingofKning]

Das Problem ist ggf. die Inkompatibilität des Treibers von V5R4 zu V5R2.
Wenn du V5R4-Treiber eingesetzt hast, stehen bestimmte Funktionen für V5R2 nicht zur Verfügung, da sich die internen SQL-Aufrufe diesbezüglich verändert haben.

Umgedreht können V5R2-Treiber aber auf V5R4-System zugreifen (aber nicht mehr auf V6 und höher).

Wenn ich Dich richtig verstehe, muß ich beim Umstieg auf einer V7R1 Kiste alle PCs die ODBC machen mit dem neuen Client Access ausstatten?

GG

[hs]

Vielen Dank für die Antwort.

Joblog sagt mir folgendes:

Job . . : QZDASOINIT Benutzer : QUSER Nummer . . . : 051029

Job 051029/QUSER/QZDASOINIT im Subsystem QSERVER in QSYS am 04.07.12 um
09:53:58 gestartet. Job im System am 04.07.12 um 09:53:58. angekommen.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Benutzer XXX an Client <unsere ip> ist mit dem Server verbunden.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.

Meldung " Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'. "
kommt mehrfach

Den Systemwert habe ich mal geändert, bringt aber leider auch nichts.

[hs]

Kann hier was falsch sein:

In WRKDBDIRE sehe ich folgende Einstellung:

Relationale Datenbank . . . . . : RCHASN32
Ferner Standort:
Ferner Standort . . . . . . . : *LOCAL
Art . . . . . . . . . . . . : *IP
Port-Nummer oder Servicename . : *DRDA
Ferne Authentifizierungsmethode:
Bevorzugte Methode . . . . . : *ENCRYPTED
Einfachere Authentifizierung
zulassen . . . . . . . . . : *ALWLOWER
Text . . . . . . . . . . . . . . : Eintrag durch System hinzugefügt


Art der relationalen Datenbank . : *LOCAL

[hs]

Der DBDIRE ist übriges identisch auf dem Livesystem. scheint also zu passen.

Komme nochmals zurück aufs Joblog:

Die Fehlermeldung mit ODBCAUT bekomme ich nicht im Live, bringt uns das auf die Spur?

Das Objekt gibt es übrigens weder auf der 5.2 noch auf der 5.4 Maschine...

Wir probieren es mal mit ODBC, vielleicht klappt das ja.

[Fuerchau]

Das scheint was spezielles des SQL-Servers oder eures Systems zu sein.
Ein Programm namens ODBCAUT gibt es so eigentlich nicht.

Prüfe mal auf dem funktionierenden System das Joblog.

Mit dem OLEDB-Treiber von CA habe ich im Wesentlichen immer Probleme gehabt.
Deshalb empfehle ich hier auch eher den ODBC-Treiber.
Der Linkedserver unterstützt ebenso ODBC-Verbindungen per DSN. Zumal die DSN-Konfiguration besser unterstützt wird und der DEBUG-Modus besser konfigurierbar ist.

Was ODBC und V6/V7 angeht, so ist das richtig. Es ist mindestens CA-V6 erforderlich.

Bisher hatte ich auch immer V5R2 im Einsatz und konnte zu verschiedenen Systemen von V4R3 (ja, die gibts noch) bis V5R4 verbinden.
Mit V6R1 war dann auch das CA V6 erforderlich.

Für die 5250-Emulation war das unerheblich, schließlich hat sich da sogut wie nichts verändert.

[Fuerchau]

Der RDB-Eintrag ist nicht so wichtig, da, wenn dieser fehlt, der Systemname (DSPNETA) als RDB-Name verwendet wird.

DRDA ist ein anderes Protokoll (DB2/DB2Connect) und ist nicht ODBC/JDBC.

[hs]

Vielen Dank für die Unterstützung, mit ODBC klappt es jetzt einwandfrei

[Fuerchau]

Nun ja, ich weiß nicht was denn der SQL-Server bzw. der OLEDB-Treiber da so machen.

Wichtig ist folgendes:
In der QGPL werden Objekte der Art *SQLPKG angelegt.
In dem Paket QZDAPKG stehen die SQL's die vom QZDASOINIT verwendet werden.
Der ODBC/OLEDB-Treiber legt automatisch Pakete an, deren Namen in der Verbindung konfigurierbar ist, ansonsten definert er den selber.

Da SQL-Server (MS-Access teilweise ebenso) ggf. verschiedene Zugriffe versucht, kann es eben sein, dass auf V5R4 bestimmte Aktionen verfügbar sind, auf V5R2 eben nicht und somit der SQL-Server SQL-Funktionen/Prozeduren versucht aufzurufen.

Der OLEDB-Treiber unterstützt bzgl. SQL leider nicht so viel, wie der ODBC-Treiber, ins besonders Schema-Abfragen und Transaktionen.
Deshalb empfehle ich grundsätzlich den ODBC-Treiber. Dies gilt leider auch für den in CA enthaltenen .NET-Treiber.

Was also den Unterschied der Systeme angeht, so kann man das genau tatsächlich nur mit Analyse der Joblogs und SQL-Pakete feststellen.
Hierzu kann man den Debug-Modus aktivieren.