PDA

View Full Version : Datenaustausch per SQL zw. 2 Systemen?



rebe
01-07-03, 16:49
Hallo!

Ist es möglich per SQL Daten zwischen 2 AS400-Systemen auszutauschen?

Etwa mit dem Befehl:
insert into sys1/lib/file select * from sys2/lib/file

Aber leider kommt je nach connect auf lokaler oder remote AS400 die Fehlermeldung "Relationale Datenbank SYS2 nicht mit dem aktuellen Server *N identisch".

Gibt es vielleicht doch einen Weg in diese Richtung?

Danke für Hinweise.

Schönen Gruß
Reiner

Fuerchau
01-07-03, 17:21
Genau dieses geht leider nicht, da SQL nur eine Verbindung parallel aufrecht erhalten kann.

Lösung (nur Pauschal):

Programm 1 mit ACTGRP(X1): select * from myfile
call Programm 2 parm "Satzpuffer"
Programm 2 mit ACTGRP(X2): insert into myfile :satzpuffer

Getrennte Aktivierungsgruppen sind notwendig, da nur dann 2 DB-Verbindungen aufrecherhalten werden können.

Im Zielsystem muss noch ein SQLPKG aus Programm 2 erstellt werden (CRTSQLPKG .... RDB(ZSys) ...).

Anschließend kann die Programmsequenz durchgeführt werden.

Lösung 2: funktioniert garantiert !

Mein Tool SQLCPY, Testversion auf meiner Internetseite verfügbar !

horschma
02-07-03, 18:36
Hallo Reiner,

mit
SET CONNECTION xxxx

kannst du auch innerhalb eines Programms auf mehrere Datenbanken zugreifen.

Beim kompilieren gibst du die Default Datenbank an, mit
CONNCET TO yyyy [USER ..]
baust du die Verbindung zur zeiten DB auf, diese wird dann automatisch zur aktuellen DB

mit
SET CONNECTION
kannst du jetzt zwischen beiden Datenbanken hin- und hertoggeln.

der Ansatz mit SELECT INTO ... funktioniert so natürlich nicht, stattdessen müsste man Satzweise kopieren.

Bleibt noch das SQLPKG das natürlich auf dem fernen System angelegt werden muß.
Hie liegt dann auch der Haken, da zum erstellen des Packages auf dem fernen System alle Tabellen in den entsprechenen Collections(Libraries) vorhanden sein müssen, auch die, die eigentlich nur von der lokalen Collection verwendet werden. Das lässt sich nur durch verwenden von dynamischem SQL vermeiden.

Thomas

Fuerchau
02-07-03, 20:44
Auch innerhalb der Anwendung zwischen Connection to wechseln dauert ziehmlich lange, da ja für jeden einzelnen Satz die Verbindung unterbrochen und wieder aufgenommen wird.
Die Übertragung mehrerer 100 Sätze kann da schon in die Stunden gehen !!!
Ich habe dies getestet, und daher mein SQLCPY auf 2 Programme in 2 Aktivierungsgruppen geteilt, so dass die Übertragung fast genauso schnell ist wie ein CPYF per DDM.

Ach ja, die Alternative:

1. Erstellen einer DDM-Datei mit Verknüpfung ins Zielsystem
2. CPYF ........ mit Feldtest Quelldatei in die Zieldatei
Ggf. Levelcheck ausschalten (per OVRDBF)

horschma
02-07-03, 22:27
Hallo,

wahrscheinlich war ich mal wieder zu 'neu',

Ab V5R1 wird auch über TCP/IP die Distributed Unit of Work (DUW) unterstützt, vorher nur über APPC.

Das mit dem Verbindungsaufbau stimmt aber nur, wenn für den Compilerparameter RDBCNNMTH(*RUW) angegeben wird, bei *DUW bleibt die Verbindung erhalten.

Siehe
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/ddp/rbal1mst28.htm

Natürlich erzeugt das Toggeln der Verbindungen einen Overhead, den erzeugt aber auch die Lösung mit 2 Programmen ( die ich im übrigen für das SQLCPY für sehr gut halte )

Thomas

Fuerchau
03-07-03, 09:13
Das mit dem Erhalten der Verbindung stimmt schon, aber das ständige toggeln der Verbindung mit CONNECT ging schon ganz schön auf die Zeit. Ich habe nur ca. 50 Sätze pro Sekunde geschafft.

Die Lösung mit 2 Programmen bringt nur Overhead in der Startphase, da ich die Daten des SELECT's in einem Puffer an das 2. Programm für INSERT übergebe => ca. 200-300 Sätze pro Sekunde.
Alles auf 100MBit-Ethernet !

Desweiteren werden an das 2. Programm ja nur Adressen und nicht die Daten selbst übergeben.

Ausserdem erlaubt die AS/400 mehrere tausend CALLS's pro Sekunde. Da alle OS-Funktionen intern per CALL aufgerufen werden, würde der Overhead gewaltig sein, wenn der CALL nicht als sog. LONG JUMP (C-Sementik) ausgeführt würden.

In der Programm-Initialisierung werden sämtliche Adressen bereits aufgelöst, bei ILE merkt man das bereits daran, dass bei fehlenden Funktionsverweisen das Programm erst gar nicht gestartet wird.
Für externe (OPM) CALL's findet die Auflösung genauso bei der Initialisierung statt, so dass beim tatsächlichen Call ggf. eine MCH-Meldung ausgegeben wird, wenn die Adresse ungültig ist.

Nur die Iniialisierung des gerufenen Programmes dauert etwas (Speicher zuordnen, Referenzen auflösen, usw.) aber beim Verlassen des Programmes kann man die Deaktivierung des Programmes steuern: RPG/LE "*INLR = *OFF", COBOL "EXIT PROGRAM".
Dadurch ist der 2. Aufruf und folgende in der Zeit nicht mehr messbar.