Dateiausgabe variable Feldlängen?

[SUBUIS]

Gibt es eine Möglichkeit, große Dateien im ASCII-Format auszugeben mit variablen Feldlängen und Trennzeichen?

Mit CPYTOIMPF sind zwar Trennzeichen möglich, aber trotz DTAFMT *DLM haben die Felder fixe Längen.

Mit Client Access sind die var. Längen zwar möglich, aber außer ein Komma als Trennzeichen ist sonst nichts möglich. Nachträglich ist es
leider nicht mehr möglich, die Trennzeichen 'umzuschiessen' (Datenmenge ist zu groß).

Mit Rumba habe ich es leider auch nicht geschafft.

SUBUIS

[Fuerchau]

Standardmässig gibts das leider nicht. Normalerweise stört das den Empfänger auch nicht.
Ich gehe inzwischen auch einen anderen Weg, nämlich SQL (ist auch flexibler) mit einem QM-Query in eine Ausgabedatei und anschließendem CPYTOSTMF:

select trim(myfld1) concat ';' concat trim(char(mydec)) concat ';' ...
from myfile
where .....

[SUBUIS]

Hört sich gut an. Wie ist das bei 80 Mio. Datensätzen in einer Datei?
(ist dann nur eine von vielen Dateien, aber die grösste).

Bsp.: 2,8 Mio. Sätze mit Client Access ca. 10 Minuten
mit CPYTOIMPF ca. 6 1/2 Minuten

Mit SQL kann ich auch var. Felder definieren, bei dem Verfahren wird
aber gleich auf die schlechte Performance hingewiesen.

SUBUIS

[BenderD]

Hallo,

wenn es da um Streamfiles geht, dann geht das mit C-APIs auch aus RPG, da gibt es auf meiner Freeware Seite auch ein Serviceprogramm (OUTSTREAM) dafür.
Das VARCHAR Gedöns im DB2/400, das ist was völlig anderes, das ist eigentlich nur die Möglichkeit Blöcke in einer Datei mit Luft aufzufüllen und das Feld weiss anschließend wieviel Luft drin ist.

mfg

Dieter Bender

Gibt es eine Möglichkeit, große Dateien im ASCII-Format auszugeben mit variablen Feldlängen und Trennzeichen?

Mit CPYTOIMPF sind zwar Trennzeichen möglich, aber trotz DTAFMT *DLM haben die Felder fixe Längen.

Mit Client Access sind die var. Längen zwar möglich, aber außer ein Komma als Trennzeichen ist sonst nichts möglich. Nachträglich ist es
leider nicht mehr möglich, die Trennzeichen 'umzuschiessen' (Datenmenge ist zu groß).

Mit Rumba habe ich es leider auch nicht geschafft.

SUBUIS

[Fuerchau]

An welcher Stelle die Daten umgesetzt werden müssen ist letztendlich egal.
Von der Gesamtleistung tut sich da nicht so viel.
Bei ClientAccess ist da wohl eher das Netz der Engpass, schließlich werden die Daten ja sowieso per SQL gelesen.

Wichtiger scheint mir bei dir die Größe der Ausagbedatei zu sein, die du ja nach meinem Verfahren drastisch reduzieren kannst. Damit wird der Performanceverlust ggf. mehr als wettgemacht mit der späteren Übertragung/Verarbeitung der Ergebnisse.

[SUBUIS]

Die SQL-Variante ist mit Abstand am schnellsten gewesen (incl. kopieren ins IFS)! Superklasse. Danke.