SQL-Select aus RPG auf eine andere AS400

[TobiasHe]

Hallo zusammen

Vor kurzem haben wir es endlich geschafft! Unsere alte 270 mit V5R2 wurde auf einen i5 mit V5R3 umgestellt. Jedoch haben wir gerade im Bereich SQL unheimliche Probleme!

Folgendes Problem:
Wir haben Programme (RPGLE), die Daten von Maschine A (570 mit V5R3) auf Maschine B (820 mit V5R2) übertragen.
Die Programme laufen dabei auf der 820, lesen per SQL auf der anderen Maschine (570)und schreiben diese auf die 820 in eine extern beschriebene Datei!

Folgender Ablauf wird zum auslesen verwendet!

Open Cursor Datei 1
Fetch Satz aus Datei 1 in eine Datenstruktur (bis EOF)
Open Cursor Datei 2
Fetch Satz aus Datei 2 in eine Datenstruktur (bis EOF)
Open Cursor 3
Fetch Satz aus Datei 3 in eine Datenstruktur (bis EOF)
Lokalen Satz schreiben
Close Cursor 3
Close Cursor 2
Close Cursor 1

Der Durchlauf für den Satz 1 aus Datei 1 klappt problemlos! Bei Satz 2 aus Datei 1, kommt es beim Fetch für Datei 3 zum SQL-Error -901 (Systemfehler). Als wir beide Maschinen noch unter V5R2 laufen hatten, gab es damit keine Probleme!

Hat jemand ne Idee?? Dieses Problem taucht vor allem in allen Programm auf, wo auf der anderen Maschine per Fetch gelesen wird!

Schönen Dank und schönen Abend!

Tobias

[BenderD]

Hallo Tobias,

hört sich nach kranker Datenbank an, falls sich ausßer dem Release nix geändert hat; was machen denn eure Database Group PTFs? Hast du auch schon mal einen blick in die Joblogs der SQL Server Jobs geworfen, ob da noch Hinweise zu finden sind?

mfg

Dieter Bender

Hallo zusammen

Vor kurzem haben wir es endlich geschafft! Unsere alte 270 mit V5R2 wurde auf einen i5 mit V5R3 umgestellt. Jedoch haben wir gerade im Bereich SQL unheimliche Probleme!

Folgendes Problem:
Wir haben Programme (RPGLE), die Daten von Maschine A (570 mit V5R3) auf Maschine B (820 mit V5R2) übertragen.
Die Programme laufen dabei auf der 820, lesen per SQL auf der anderen Maschine (570)und schreiben diese auf die 820 in eine extern beschriebene Datei!

Folgender Ablauf wird zum auslesen verwendet!

Open Cursor Datei 1
Fetch Satz aus Datei 1 in eine Datenstruktur (bis EOF)
Open Cursor Datei 2
Fetch Satz aus Datei 2 in eine Datenstruktur (bis EOF)
Open Cursor 3
Fetch Satz aus Datei 3 in eine Datenstruktur (bis EOF)
Lokalen Satz schreiben
Close Cursor 3
Close Cursor 2
Close Cursor 1

Der Durchlauf für den Satz 1 aus Datei 1 klappt problemlos! Bei Satz 2 aus Datei 1, kommt es beim Fetch für Datei 3 zum SQL-Error -901 (Systemfehler). Als wir beide Maschinen noch unter V5R2 laufen hatten, gab es damit keine Probleme!

Hat jemand ne Idee?? Dieses Problem taucht vor allem in allen Programm auf, wo auf der anderen Maschine per Fetch gelesen wird!

Schönen Dank und schönen Abend!

Tobias

[TobiasHe]

Hallo Dieter!
Auf der V5R3 Maschine haben wir den neusten PTF-Stand! Unter V5R2 haben wir das neuste gerade bestellt!

Im Log ist nur folgendes zu finden:
Auf die lokale relationale Datenbank wurde von OSNA zugegriffen.
Zeiger für angegebene Position nicht gesetzt.

Tobias

[BenderD]

Hallo Tobias,

für mich sieht das eher nach einem Fehler auf der Server Maschine aus und das ist die 5.3 er, wenn ich dein Posting richtig verstanden habe. Da würde ich an eurer Stelle in jedem Fall eine Fehlermeldung machen und eruieren, ob es einen neueren Group PTF für die Datenbank gibt (WRKPTFGRP). Zeiger nicht gesetzt könnte ein Problem mit dem Cursor sein, das allerdings auch schon vor dem fetch aufgetreten sein könnte.
Ich würde auch nochmal sicher stellen, dass alle SQL Codes tatsächlich abgefragt und protokolliert werden, um sicher zu sein an welcher Stelle der Fehler wirklich auftritt.

mfg

Dieter Bender

Hallo Dieter!
Auf der V5R3 Maschine haben wir den neusten PTF-Stand! Unter V5R2 haben wir das neuste gerade bestellt!

Im Log ist nur folgendes zu finden:
Auf die lokale relationale Datenbank wurde von OSNA zugegriffen.
Zeiger für angegebene Position nicht gesetzt.

Tobias

[Fuerchau]

Vielleicht wurde ja nur ein Fehler behoben.
Meine Versuche mit 2 SQL-Verbindungen zu arbeiten funktionieren nur korrekt, wenn entsprechende Connect's durchgeführt werden.
Ein geöffneter Cursor bezieht sich immer auf die aktuelle Verbindung, also:

connect Systema
open Cursor1
connect Systemb
open Cursor2

connect Systema
fetch Cursor1
connect Systemb
fetch cursor2
:
usw.

Da das ständige hin- und her-connecten sehr auf die Performance geht, habe ich dies mit 2 Programmen in unterschiedlichen Aktivierungsgruppen gelöst, da jede für sich eine eigene Verbindung aufrecht erhalten kann.

Siehe auch mein Tool SQLCPY, dass genau diese Problem löst.

[BenderD]

Hallo,

wie wär's mit set connection?

mfg

Dieter Bender

Vielleicht wurde ja nur ein Fehler behoben.
Meine Versuche mit 2 SQL-Verbindungen zu arbeiten funktionieren nur korrekt, wenn entsprechende Connect's durchgeführt werden.
Ein geöffneter Cursor bezieht sich immer auf die aktuelle Verbindung, also:

connect Systema
open Cursor1
connect Systemb
open Cursor2

connect Systema
fetch Cursor1
connect Systemb
fetch cursor2
:
usw.

Da das ständige hin- und her-connecten sehr auf die Performance geht, habe ich dies mit 2 Programmen in unterschiedlichen Aktivierungsgruppen gelöst, da jede für sich eine eigene Verbindung aufrecht erhalten kann.

Siehe auch mein Tool SQLCPY, dass genau diese Problem löst.

[Fuerchau]

@Dieter

Ja klar, set connection meinte ich auch. Aber das Umschalten der Verbindung dauert doch verhältnismäßig lange.

[BenderD]

@Baldur,

ich habe zwar jettt keine Analyse im Ärmel, aber ich halte das für eine reine Compileranweisung, die keinerlei Zeit verbrummen darf (beim gesamten embedded SQL kann ich nirgends eine Connection angeben), da wird nur ein Conetxt Wechsel durchgeführt, der zur Runtime nicht wirklich ausgeführt wird, wenn das Zeit verdonnert, dann ist was oberfaul (was ich nicht ausschließen mag).

mfg

Dieter

@Dieter

Ja klar, set connection meinte ich auch. Aber das Umschalten der Verbindung dauert doch verhältnismäßig lange.

[sim]

Hallo Tobias,

wir haben aktuell auch ein Problem auf V5R3 mit der Verbindung per SQL (APIs) zu einer anderen AS400.

Evtl. hilft dir dieses PTF (SI16160) und die abhängigen ja weiter ?

Kann leider noch keine Erfahrungsberichte geben da wir selber noch nicht zum testen gekommen sind.

[TobiasHe]

Guten Morgen zusammen!

Das ist ja schon ne ausgelassene Diskussion hier geworden! Finde ich gut und deshalb schon mal Danke an alle....

Folgendes noch mal zu den Programmen! Ich denke da habe ich wohl nicht alles ganz sauber beschreiben:

Per SQL nutze ich nur eine Connection und das ist die zur V5R3. Somit wird beim Aufbauen der Verbindung einmal ein "set Connection" auf die Maschine der V5R3 gemacht!
Auf der V5R2 schreibe ich die Daten mit nem ganz normalen "Write". Gelesen wird dort nicht...

@Sim: Das PTF habe ich noch nicht drauf...werde es mal direkt laden!

Gruß
Tobias

[BenderD]

Hallo Tobias,

sieht eindeutig nach PTF für die V5.3 aus, ich würde soweit noch nicht geschehen Fehlermeldung an IBM machen und begleitend in die
news://comp.sys.ibm.as400.misc posten da tummelt sich meist der ein oder andere IBMer, der weiss, was sie mit V5R3 wieder in der Datenbank für Unfug angerichtet haben.

mfg

Dieter Bender

Guten Morgen zusammen!

Das ist ja schon ne ausgelassene Diskussion hier geworden! Finde ich gut und deshalb schon mal Danke an alle....

Folgendes noch mal zu den Programmen! Ich denke da habe ich wohl nicht alles ganz sauber beschreiben:

Per SQL nutze ich nur eine Connection und das ist die zur V5R3. Somit wird beim Aufbauen der Verbindung einmal ein "set Connection" auf die Maschine der V5R3 gemacht!
Auf der V5R2 schreibe ich die Daten mit nem ganz normalen "Write". Gelesen wird dort nicht...

@Sim: Das PTF habe ich noch nicht drauf...werde es mal direkt laden!

Gruß
Tobias

[Fuerchau]

Ggf. erstelle das SQLPKG deines Programmes auf dem Zielsystem noch mal neu (CRTSQLPKG) !
Möglicherweise stimmen dort verschiedene Verweise, Zugriffsoptimierungen usw. nicht mehr bzw. sind nicht mehr passend zum Release.

Ich meine damit nicht, das SQLPKG auf deinem aktiven System zu erstellen und dann auf das Zielsystem zu kopieren sondern gezielt per CRTSQLPKG auf dem Zielsystem direkt zu erstellen.