CPYTOIMPF - Ausgabe auf anderen Server möglich?

[Fuerchau]

Das geht auch ohne Programm nur mit CLP:
Per WRKDIRE kann man die anderen DB's native verbinden und dann per SQL direkt zugreifen.
Die Notation ist dann:

select f1, f2, ...
from RDBNAME.LIB.FILE
where ...

Voraussetzung ist am Besten, wenn das ausführende Profil auf allen Systemen mit identischem Kennwort vorhanden ist.


Nun lässt sich mit einem CLP und dem Kommando RUNSQL (Achtung: nicht RUNSQLSTM) jeder beliebige SQL ausführen.
Also warum nicht:

RUNSQL '
create table qtemp.xxx as
(
select .... from lib.file where ...
union all
select ... from RDB2.lib.file where ...
union all
select ... from RDB3.lib.file where ...
) with data
'

cpyfrmimpf qtemp/xxx .....

Nachtrag:
Mit ACS SQL-Scripts kann man dies auch auf einem PC automatisieren, da auch CSV ausgegeben werden können. Somit hat man die Daten u.U. direkt auf dem PC der die Daten ggf. ja haben will.

[Robi]

SQl im CL ..
ja da war mal was ...
Haben wir NIE verwendet, da müsste ich mal öfter dran denken ...

[UFi]

Besten Dank, ich werde das einmal ausprobieren.

[camouflage]

... wobei, ich lass meine SQL's im CL immer über RUNSQLSTM laufen. Dies lässt mir die Möglichkeit offen, die SQL-Anweisungen zu ändern, ohne dass ich das CL neu kompilieren muss.

[B.Hauser]

... wobei, ich lass meine SQL's im CL immer über RUNSQLSTM laufen. Dies lässt mir die Möglichkeit offen, die SQL-Anweisungen zu ändern, ohne dass ich das CL neu kompilieren muss.

Nur leider kannst Du dabei keine Fehler behandeln, oder implementierst Du dynamische Compound statements mit Condition Handler? Wen ja, dann kannst Du auch gleich eine Stored Procedure (oder User Defined Function) daraus machen.
Was ich sowieso empfehlen würde. Diese Prozedur kann ja dann aus dem CL aufgerufen werden.

[Fuerchau]

Außerdem verlangt das RUNSQLSTM, dass die SQL-Erweiterungsoption für z.B. STRSQL installiert ist.
Bei manchen Kunden ist diese Option eben nicht installiert. Dann gibts auch kein RUNSQLSTM.
SQL ist aber grundsätzlicher Bestandteil des OS und deshalb ausführbar.
Daher hatte ich früher ein eigenes RUNSQL als ILERPG-Programm, was nun durch das systemeigene RUNSQL abgelöst werden konnte.
Wenn du jedoch auch SRCPF's verwenden willst, schreib einfach einen Wrapper.

RUNSQLSTM hat jedoch auch Vorteile.
Man kann Fehler zwar nicht überwachen, aber mit RUNLVL(40) ignorieren.
Es erlaubt Kommentare und mehrere Befehle.
Sowie mittels der "cl: xxx" Erweiterung den Aufruf von Kommandos.

Aber wie immer so im Leben gibt es viele Möglichkeiten.
Kennt jemand eigentlich noch REXX?
Mittels STRREXPRC lassen sich ebenso Scripts ausführen, die sowohl SQL als auch Kommandos mit Parametern ausführen können. Und STRREXPRC erlaubt sogar die Übergabe von Parametern, die in SQL und CMD's verwendet werden können.
REXX kann auch SQL-Cursor lesen, also komplexe Abfragen zu verarbeiten.
Unterstützt werden auch Funktionen und Sub-REXX-Prozeduren (also andere Member) sowie Variaben und Schleifen.
Das wird schon ziehmlich vernachlässigt;-).

https://www.ibm.com/docs/en/search/r...3&intitle=true

[BenderD]

create table qtemp.xxx as
(
select .... from lib.file where ...
union all
select ... from RDB2.lib.file where ...
union all
select ... from RDB3.lib.file where ...
) with data
'

... seit wann kann three part alias mehrere Datenbanken in einem select?

[Fuerchau]

Ich habs noch nicht probiert.
Allerdings klappt ja ein
Insert into lib.file
select * from rdb.lib.file

Also könnte man das dann auch in 3 Schritte zerlegen:
1x create .... select * from lib.file
2x insert into ...