SQLCODE -805 beim Zugriff auf ein fernes System

[Fuerchau]

Tja Dieter, bei DDMF mit *RDB kann man tatsächlich auch per DRDA sequentiell auf Dateien zugreifen.
Vergleichbar zu DDMF mit SNA.

[BenderD]

... ok, dann halt präziser: das macht man so nicht! (gilt auch für den three part alias Huddel)!

[mahones]

Danke für die Informationen und Hilfestellungen!
Ich versuche mal, das zu sortieren:
1. Ich habe im Programm nun folgendes eingebaut:
Exec SQL Connect to :LOCNAME USER :AUTHID USING :PASSWORD;
...wobei die Variablen entsprechend definiert und gefüllt sind.
Im Joblog sehe ich nun auch die Meldung "CONNECT für relationale Datenbank >DBNAME< abgeschlossen. Aktuelle Verbindung besteht zur relationalen Datenbank >DBNAME<."
=> Damit bin ich also vom SQL per DDMF weg...Schelte von D*B verstanden :-)

2. Nach der Deklaration des Cursors, also beim OPEN, bekomme ich trotzdem wieder einen -805.
=> Muss ich trotzdem "...auf dem Zielsystem per SQL ein SQLPKG-Objekt erstellen..."?
Auf dem Zielsystem ist das Programm ja gar nicht vorhanden, somit kann ich es dort nicht angeben. (es kommt ja sonst der Fehler "SQL0204 >PGMNAME< der Art *PGM in >LIBNAME< nicht gefunden."
Das Programm versucht ja auch irgendwie, dieses zu machen, es klappt aber auch nicht.

Evtl. ist das ja ne banale Frage, aber da ich damit bisher noch nie gearbeitet habe, fehlt mir da einfach die Basis, wie man es beginnt...wie funktioniert das also mit dem CRTSQLPKG?

[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...