SQLCODE -805 beim Zugriff auf ein fernes System

[mahones]

Beim PING sieht alles super aus...

PING RMTSYS('*SYSNAME*')
Verbindung zum Host-System *SYSNAME* an der Adresse *IP-ADRESSE* wird gerade geprüft.
PING-Antwort 1 von *IP-ADRESSE* dauerte 0 Millisekunden 256 Byte. Lebensdauer 64.
PING-Antwort 2 von *IP-ADRESSE* dauerte 0 Millisekunden 256 Byte. Lebensdauer 64.
PING-Antwort 3 von *IP-ADRESSE* dauerte 0 Millisekunden 256 Byte. Lebensdauer 64.
PING-Antwort 4 von *IP-ADRESSE* dauerte 0 Millisekunden 256 Byte. Lebensdauer 64.
PING-Antwort 5 von *IP-ADRESSE* dauerte 0 Millisekunden 256 Byte. Lebensdauer 64.
Umlauf (in Millisekunden) min./durchschnittl./max. = 0/0/0.
Statistik der Verbindungsprüfung: 5 von 5 erfolgreich (100%).

Den CHGRDBDIRE mit der IP-Adresse als RMTLOCNAME habe ich gemacht - aber bei der Zeitspanne für CONNECT ändert sich nichts.
Kann man außer mit einem DBMON noch anders, mehr Infos holen? Evtl. mit einem >Get Diagnostics< ...

Ergänzung ...30min später (klingt komisch, aber):
jetzt dauert der Exec SQL Release :LOCNAME so lange!
Wenn ich den weglasse, kommt das Ergebnis beim ersten Aufruf superschnell! (egal ob über DNS oder IP)
ABER: dadurch bleibt eine Objektsperre bestehen :-(
Trotz
Exec SQL Commit Work;
Exec SQL Connect Reset;
ist auf dem RMTSYS noch ein LOCK auf dem SQLPKG.
Melde ich mich ab und neu an (=neuer Job), ist alles wieder ok und schnell.

...das ist doch jetzt bestimmt nur noch eine Kleinigkeit, die ich übersehe (bzw. nicht weiß), oder?

Aber

[BenderD]

... der lock auf dem package ist die weiter bestehende Verbindung. Was heißt: neue Anmeldung ist alles ok und schnell, auch der connect?

[mahones]

Genau, nach einer erneuten Anmeldung ist die Anzeige mit korrektem Inhalt sofort da.

Den RELEASE habe ich direkt nach dem CLOSE vom Cursor, also noch vor der Anzeige auf dem Bildschirm.

Beim zweiten Aufruf (ohne RELEASE) wird das SQL nicht korrekt ausgeführt, also kommt auch nix auf den Bildschirm...aber alles im ms-Bereich.

[BenderD]

... connect beenden geht entweder mit disconnect oder mit release gefolgt von commit (selbstredend mit exec sql commit und nicht mit dem RPG commit).
In einer neuen session dürfte allerdings die vorhergehende keinen Einfluss mehr haben.
Als nächstes würde ich mich mal um die listener Jobs auf dem Server kümmern, das sieht so aus, dass mit den Einstellungen im Subsystem was verbogen wurde.

D*B

[mahones]

Ok, dann schaue ich morgen mal, was "listener jobs" sind.

Im Programm ist es so, wie du geschrieben hast:
Exec SQL Connect to :LOCNAME USER :AUTHID USING :PASSWORD;
...
Exec SQL open CURSOR;
...FETCH...
Exec SQL close CURSOR;
Exec SQL Release :LOCNAME;
Exec SQL Commit Work;
Exec SQL Connect Reset;

Jetzt habe ich auf der IBM-Seite bei der Suche nach "COMMIT" noch etwas gelesen:
"...SQL connections are ended when ... The DISCONNECT(AUTOMATIC) bind option is in effect"

[BenderD]

... Murks! (Schwafel, schwafel, schwafel)

[Fuerchau]

@D*B: tsts...

Bei mirt sieht das i.d.R. so aus:



begsr CloseConnect;
exec sql set connection :ORDatabase;
exec sql commit;
exec sql disconnect :ORDatabase;
exec sql connect reset;
exec sql commit;
endsr;


Einen Release benötige ich nicht.

[BenderD]

@Baldur: tststs...

was ist BEGSR? ich kenne nur noch procedures - der Rest ist Geschmacksache.

[Fuerchau]

Wenn mein ein RPG in RPGLE konvertiert, schreibt man nicht gleich alle BEGSR in Proc's um.
Zumal die meisten Proc's die ich sehe, nichts als bessere BEGSR's sind (ohne Parameter und Returnwerte).
Schließlich werde ich nicht für "Schön" sonder für "Ergebnis" bezahlt;-).

[BenderD]

... für die Konvertierung gibt es doch Tools, die das können (würde RDI was taugen, dann könnte der das => siehe refactor in Eclipse/Java). Der Haupt unterschied zwischen Procedure und SR sind die lokalen Variablen. Mit der Bezahlung ist halt so eine Sache, mancher will billig, egal was es wirklich kostet!