SQLCODE -805 beim Zugriff auf ein fernes System

[mahones]

Danke für die erste, schnelle Rückmeldung!

Ja, das habe ich schon einmal versucht, aber auch bei der manuellen Ausführung kommen die gleichen Fehlermeldungen. Vielleicht sind da schon Parameter, die ich falsch setze...aber welche?
Die, die ich angebe, klingen schon plausibel und sind zumindest gültig.

[Fuerchau]

Das Problem bei RPG ist, dass du auf dem Zielsystem per SQL ein SQLPKG-Objekt erstellen musst.
Dies erfolgt mittels CRTSQLPKG mit der Angabe des Zielsystems und deines RPG-Programmes.
Allerdings wird das Paket auf dem Zielsystem dann mit *PUBLIC *EXCLUDE erstellt.

Ein SQLPKG enthält ebenso eine Signatur. D.h., sobald du dein Programm änderst und SQL-Befehle hinzufügst/entfernst/änderst muss das SQLPKG neu erstellt werden.

DDMF's sind aber quasi sowieso der falsche Weg, da du dann für jeden Zugriff eine DDMF benötigst.
Du kannst aber aus dem Programm via Connect zu dem Zielsystem Verbindung aufnehmen um dann per SQL direkt mit dem Ziel zu arbeiten.
Mittels "exec sql set connection ..." kannst du zwischen Lokal und Remote fliegend wechseln.

[BenderD]

... ich habe gerade keinen Bock auf Ratespiele. Was machst Du genau in deinem Programm? Remote SQL Zugriffe gehen nicht über DDM Files, sondern über einen connect.

D*B

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