Dateien in IFS-Bereich kopieren

[juergenkarthaus]

Hallo,

wir haben folgendes Problem:

wir arbeiten mit einer älteren AS400 V4R2M0 und Client Access V3R2M0. Die User haben auf ihren PCs CA mit der 5250 Terminal-Emulation, aber keine Übertragungsfunktionen ( aus Sicherheitsgründen).

Nun möchten wir den Usern Dateien von der AS400 auf ihrem PC zur Verfügung stellen. Dies soll so aussehen, dass sich die User die Daten selbst abholen ( vielleicht ein CL mit entspr. Copy-Befehl starten, damit die Daten in den IFS-Bereich kopiert werden).

Hat jemand eine Idee wie man das realisieren kann ? Wir haben schon erfolglose Versuche mit CPYTOSTMF und CPYTOIMPF hinter uns. Hier wurden die Daten zwar zum Teil kopiert, jedoch klappte dies bei gepackten Feldern nicht.

Vielen Dank im voraus.

J. Karthaus

[Fuerchau]

Bei V4R2 ist das auch nicht so einfach, da sich inzwischen einiges getan hat.

Die einfachste Version für mich ist eigentlich ein QM-Query.
Per SQL kann ich das Format einer CSV-Datei direkt erzeugen:

select trim(char(numfield)) || ';'
|| trim(charfield) || ';'
:
:
from myfile
where ....

Die Where-Bedingung fülle ich per Dialog, starte mit STRQMQRY ... OUTFILE(QTEMP/MYFILE) den SQL und kopiere per CPYTOIMPF diese Datei ins IFS.

Parameter in der Where-Bedingung werden analog zu CL-Parametern definiert:

where feld1=&PARM1 and feld2=&PARM2 ....

die ich dann beim STRQMQRY übergeben kann. Beispiele hierzu gibts im Forum.
Die CSV-Datei kann ich dann relativ einfach in Excel oder sonstwo wieder aufdröseln.

Die 2. Alternative ist das Bereitstellen von Sichten (VIEW, LF) in eigenen Bibliotheken, die bereits bestimmte Selektionen enthalten.
Per MS-Query (Excel->Externe Daten) sind diese auch problemlos herunterzuladen.

[juergenkarthaus]

Bei V4R2 ist das auch nicht so einfach, da sich inzwischen einiges getan hat.

Die einfachste Version für mich ist eigentlich ein QM-Query.
Per SQL kann ich das Format einer CSV-Datei direkt erzeugen:

select trim(char(numfield)) || ';'
|| trim(charfield) || ';'
:
:
from myfile
where ....

Die Where-Bedingung fülle ich per Dialog, starte mit STRQMQRY ... OUTFILE(QTEMP/MYFILE) den SQL und kopiere per CPYTOIMPF diese Datei ins IFS.

Parameter in der Where-Bedingung werden analog zu CL-Parametern definiert:

where feld1=&PARM1 and feld2=&PARM2 ....

die ich dann beim STRQMQRY übergeben kann. Beispiele hierzu gibts im Forum.
Die CSV-Datei kann ich dann relativ einfach in Excel oder sonstwo wieder aufdröseln.

Die 2. Alternative ist das Bereitstellen von Sichten (VIEW, LF) in eigenen Bibliotheken, die bereits bestimmte Selektionen enthalten.
Per MS-Query (Excel->Externe Daten) sind diese auch problemlos herunterzuladen.

Hallo,

vielen Dank für die Tips. Habe die erste Variante versucht. Doch habe leider noch Probleme damit. Ist/war die folgende Vorgehensweise richtig ?

1. Erstellen SoourceFile CRTSRCPF
2. Hier habe ich den Quellcode in einer Teildatei erstellt
und als Art QMQRY (richtig ???) angegeben
3. Mit CRTQMQRY Abfrage erstellt
4. Mit STRQMQRY Abfrage ausgeführt ( mit Outfile )
5. Diese mittels CPYTOIMPF kopiert

Dies hat bei einem meiner vielen Versuche funktioniert, aber nach dem Kopieren kam in der Zieldatei nichts Gescheites an.
Danach "meckert" die AS schon beim ausführen des STRQMQRY ein ungültiges Token am Ausführungsende an.
Vielleicht hat jemand ein kurzes Codebeispiel für ein einfaches
select.....from mit den entsprechenden Zeichen am Ende.

Vielen Dank

J. Karthaus

[Fuerchau]

Am einfachsten startest du STRQM.
Mit Auswahl 1 kannst du dann QM-Queries erstellen. Schalte ggf. in die SQL-Sicht um, dann kannst du die SQL's direkt eingeben und mit F5 auch testen.
Speichere diese dann ab und und mittels STRQMQRY kannst du diese dann ausführen.

[juergenkarthaus]

Am einfachsten startest du STRQM.
Mit Auswahl 1 kannst du dann QM-Queries erstellen. Schalte ggf. in die SQL-Sicht um, dann kannst du die SQL's direkt eingeben und mit F5 auch testen.
Speichere diese dann ab und und mittels STRQMQRY kannst du diese dann ausführen.

Schade. STRQM klappt leider auch nicht. Wir haben das dumme Problem daß wir mit unserem OS/400 auf R 4.3.0 sind
( sorry, habe ich leider vorher falsch angegeben ) und bei vielen Lizenzprogrammen aber auf R 4.2.0 . So läßt sich leider STRQM nicht ausführen ( da 4.2.0 ).

Trotzdem vielen Dank für die rasche Antwort.

[Fuerchau]

Da wundert mich doch einiges. QM ist Bestandteil von SQL und gabs auch schon bei V3.
Wenn du STRSQL machen kannst, dann müsste STRQM auch gehen ansonsten ist es nicht korrekt oder gar nicht installiert.

Ansonsten ist der Umweg von dir (Quelle => CRTQMQRY => STRQMQRY) schon der richtige, nur halt mühsam.
Ersetze dabei aber die "||" durch "concat" !

Du kannst auch per WRKQRY einen Query erstellen, diesen per RTVQMQRY in eine Quelle umwandeln.

[BenderD]

Einspruch, Euer Ehren,

STRQMQRY ist das SQL für Arme und Kranke und ist Bestandteil des Base Operation Systems, genau wie die SQL Engine selber und braucht keine SQL Lizenz. Umso seltsamer, dass das nicht korrekt installiert ist. Dann kann der ganze Rest natürlich auch an der PTF Lage scheitern, woran wahrscheinlich auch der CPYTOIMPF krankt, den gab es nämlich auch mit V4R2 bereits, nur eben sehr buggy.

mfg

Dieter Bender

Da wundert mich doch einiges. QM ist Bestandteil von SQL und gabs auch schon bei V3.
Wenn du STRSQL machen kannst, dann müsste STRQM auch gehen ansonsten ist es nicht korrekt oder gar nicht installiert.

Ansonsten ist der Umweg von dir (Quelle => CRTQMQRY => STRQMQRY) schon der richtige, nur halt mühsam.
Ersetze dabei aber die "||" durch "concat" !

Du kannst auch per WRKQRY einen Query erstellen, diesen per RTVQMQRY in eine Quelle umwandeln.

[Fuerchau]

@Dieter

Für STRQMQRY gilt das so, aber für STRQM selber nicht. Dieser ist Bestandteil vom SQL-Produkt, also zu STRSQL gehörend (QSQL-Lib).

[holgerscherer]

der CPYTOIMPF krankt, den gab es nämlich auch mit V4R2 bereits, nur eben sehr buggy.

Herr Anwalt wollen doch nicht etwa behaupten, dass der CPYTOIMPF inzwischen weniger buggy ist? ;-)

Ich eiere immer noch mit dem CPYFRMIMPF (ok, Gegenrichtung) unter V5R3 rum. Kaum will man mal 20Mio Sätze importieren, lässt er ein paar Sätze weg, ohne Kommentar. (das Meckern über fehlenden Aufruf CEEGOTO ignoriere ich inzwischen)
Unter V5R2 mit gleichen Daten klappts latürnich.

Hat jemand noch eine Idee, ausser PTFs? (Die sind bei mir zwangsweise aktuell)

-h

[Fuerchau]

@Holger

Ich denke dafür ist ggf. MS-Access die bessere Lösung.
- Import in MS-Access (von CSV)
- Export (Upload) aus MS-Access in AS/400

Das klappt (naja fast) immer !

[BenderD]

@Holger

doch, doch, das will ich durchaus behaupten, obwohl das Verhalten in den ersten Releases kalkulierbarer war, da ist meist die Genereierung des C Programmes bereits in den Ofen gegangen und das mit dem CEEGOTO, das ist halt ein Mainframe API vom Feinsten...

Idee? aber immer, selber einen CPYTOIMPF oder CPYFRMIMPF schreiben; eh ich mich da auf ACCESS verlassen würde...

Dieter Bender

Herr Anwalt wollen doch nicht etwa behaupten, dass der CPYTOIMPF inzwischen weniger buggy ist? ;-)

Ich eiere immer noch mit dem CPYFRMIMPF (ok, Gegenrichtung) unter V5R3 rum. Kaum will man mal 20Mio Sätze importieren, lässt er ein paar Sätze weg, ohne Kommentar. (das Meckern über fehlenden Aufruf CEEGOTO ignoriere ich inzwischen)
Unter V5R2 mit gleichen Daten klappts latürnich.

Hat jemand noch eine Idee, ausser PTFs? (Die sind bei mir zwangsweise aktuell)

-h

[holgerscherer]

@Holger
Ich denke dafür ist ggf. MS-Access die bessere Lösung.

Ok, auf Deine Gefahr hin werde ich nachher mal eine 30GB-Tabelle in Access importieren. Für mentale Schäden an meinem PC haftest Du <g>

Idee? aber immer, selber einen CPYTOIMPF oder CPYFRMIMPF schreiben; eh ich mich da auf ACCESS verlassen würde...

Das mache ich auch momentan (Schnautze voll)

-h