SQLCODE -805 beim Zugriff auf ein fernes System

[BenderD]

... so der connect ist erst mal da und funzt. Beim lokalen connect wird das implizit ausgeführt, ohne dass man was programmiert.
Static sql (das ist das, was embedded SQL macht) braucht ein package. Für den lokalen Zugriff wird das an das Programm automatisch angehängt (kann man sich mit PRTSQLINF ansehen). In dem Package ist der Code für den Datenbankzugriff. Für den remote Zugriff muss das Package auf dem Zielsystem angelegt werden. Das Programm ist also "aufgeteilt" in lokal und der Datenbankcode remote.
Zu empfehlen ist hier, das Porgramm wie gehabt zu erstellen und das Package mit CRTSQLPKG zu erzeugen, hierbei gibt man im Parameter RDB die Maschine an, auf die man zugreifen will, dort wird dann das Package erzeugt.

D*B

[Fuerchau]

Das hatte ich doch oben mit dem Hinweis CRTSQLPKG ja schon beschrieben;-).
Auf dem lokalen System:
CRTSQLPKG PGM(MYPROG) RDB(MYRDB)
Auf dem Remotesystem ggf. für das erstellte SQLPKG noch einen EDTOBJAUT durchführen, falls andere User dein Programm auch verwenden wollen oder sollen.

[mahones]

Danke, der PRTSQLINF hat mich auf die richtige Spur gebracht...
Ich habe beim CRTSQLRPGI die Parameter aber schon angepasst, denn ein nachträgliches CRTSQLPKG wollte mir nicht gelingen. Außerdem sind die Berechtigungen für den angegebenen User auch mit *ALL korrekt, denke ich.
Aber nach ein paar Anpassungen im Programm (z.B. RELEASE der RDB) klappt das mickrige SELECT nun zumindest. Jetzt schauen wir nach dem Verbindungsaufbau, denn der dauert noch seeehr lange.

[BenderD]

Danke, der PRTSQLINF hat mich auf die richtige Spur gebracht...
Ich habe beim CRTSQLRPGI die Parameter aber schon angepasst, denn ein nachträgliches CRTSQLPKG wollte mir nicht gelingen. Außerdem sind die Berechtigungen für den angegebenen User auch mit *ALL korrekt, denke ich.
Aber nach ein paar Anpassungen im Programm (z.B. RELEASE der RDB) klappt das mickrige SELECT nun zumindest. Jetzt schauen wir nach dem Verbindungsaufbau, denn der dauert noch seeehr lange.

Bist Du sicher, dass das der Verbindungsaufbau ist? Fehlende Indexe werden beim verteilten Zugriff natürlich doppelt bestraft. Da würde ich mal ein PRTSQLINF auf das Package machen. Den Job unter debug laufen lassen und mal sehen, was es da so vor hat.

D*B

[mahones]

Wir haben mittels DBMON gesehen, dass der CONNECT (laut SQL Statement summary) mehr als 10s dauert. OPEN, FETCH, etc. dauern nur einige ms.

Ist das Programm, bzw. der SQL-Zugriff als solches, damit aus dem Schneider?

Welche Einstellungen muss man sich dazu anschauen?

[BenderD]

... das sollte alles im unteren millisekunden Bereich liegen. 10 sec ist gröbst daneben und selbst durch Netzwerk oder Subsystem Konfiguration kaum erklärbar. Was ist denn sonst so auf der Maschine los?

[mahones]

Eigentlich nicht viel und erst recht nicht mehr als sonst.
Die Maschine ist (so sagten andere externe Partner) auch ausreichend groß dimensioniert.
(QMODEL > 42A, PRCFEAT > EP1F)
Beide Systeme befinden sich auf einer physischen Maschine, aber auf 2 LPAR
Die 128GB RAM sind auf 96 / 32 aufgeteilt...

[BenderD]

... bleibt das bei mehreren connects nacheinander aus demselben Job genauso langsam? bei verschiedenen Jobs?

[mahones]

Ja, wenn ich das Programm mehrmals hintereinander aufrufe (selbe Sitzung = selber Job), dauert jeder Aufruf so lange!
Wenn ich es parallel auf mehreren Sitzungen aufrufe, dauert jeder einzelne Aufruf auch so lange...

[BenderD]

... da gabs mal was mit DNS Lookup - ich würde da mal software defect reklamieren.

[mahones]

Ohoh, es geht immer weiter in Regionen, die mir unbekannt sind.
Heißt das übersetzt: "am besten ein Ticket bei der IBM aufmachen"?

[Fuerchau]

Mach mal nur einen PING von deiner Maschine zur RDB-Maschine.
Im Joblog gibts dann die Antwortzeiten.
Wenn du per WRKRDBDIRE die IP statt des Namens im Feld IP-Adresse eingibst, sparst du die DNS und kannst den Unterschied messen da dann DNS nicht benötigt wird.