Anzahl Sätze bei CPYFRMSTMF

[Liebhoff]

Ich möchte die Anzahl der zu kopierenden Sätze beim CPYFRMSTMF begrenzen, sprich ich will aus der im IFS liegenden Datei nur eine bestimmte Anzahl (z.B. 1000 statt 4 Millionen) in eine AS/400 Datei kopieren.

Hat jemand eine Idee, wie ich das bewerkstelligen kann, leider gibt es keinen Parameter für die Anzahl der zu kopierenden Sätze.

Gruß Thomas

[Fuerchau]

Das geht dann leider nur per Programm mit den IFS-Funktionen und eigener Konvertierung (ASCII->EBCDIC).

Oder in 2 Schritten:
1. CPYFRMSTMF in Zwischendatei
2. CPYF mit Begrenzung Satzanzahl

[Liebhoff]

Das Kopieren in eine Zwischendatei erfolgt bereits, nur brauche ich auch dort nur 1000 Sätze. Ich will einfach verhindern, das die PC Datei im IFS mit 350 MB Größe nochmal vollständig kopiert wird. Das belastet erstens die Festplatte und zweitens dauert es eine ganze Weile bis das Kopieren erledigt ist.

Bislang bleibt wohl nur die Lösung die Ausgangsdatei im IFS zu verkleinern. Was aber auch nicht einfacher ist wenn alles automatisch laufen soll.

Gruß Thomas

[Fuerchau]

Da hilft mal wieder die gute alte Qshell:

head - Copy the first part of files

Synopsis
head [-n

count] [file ...]

Description

The

head utility displays the first count lines of each of the specified files, or of standard input if no files
are specified. If -n is not specified, then the first 10 lines of the file are displayed.
If more than one file is specified, each file is preceded by a header consisting of the string ″==> XXX <==″

where XXX is the name of the file.

Options
-n

Display count number of lines.

Beispiel:

qsh cmd('cd /Home/mydir;head -n1000 myfile >my1000file')

[Liebhoff]

Wir kommen der Sache näher, am Prompt funktioniert das einwandfrei.

Nun will ich das aber im CL machen und sage daher:

CHGVAR VAR(&BEFEHL) VALUE('CD /Datenaustausch/IMPCSV; +
HEAD -n1000 ' *CAT &PCFILE *CAT ' >part1000.dat')

QSH CMD(&BEFEHL)

Das Joblog zeigt dann:

Befehl wurde normal mit Ausführungsstatus 1 beendet.
Die Variable Befehl enthielt tatsächlich :

CD /Datenaustausch/IMPCSV; HEAD -n1000 AArbnaf0.dat >part1000.dat

Nur die Datei part1000.dat wurde nicht erzeugt.

Was läuft falsch ?

Gruß Thomas

[Liebhoff]

Hab es selber gefunden.

man muss das CD klein schreiben.

Wieder was gelernt.

Thomas

[holgerscherer]

man muss das CD klein schreiben.

mein Lieblingsthema, wenn es um unixoide Probleme geht: wer kam bloss auf die verrückte Idee, bei Dateinamen (und somit auch Befehlen) zwischen GrossKlein zu unterscheiden?

-h

[Fuerchau]

Tja, können ja ncht alle Windoof heißen (zur Zeit der DOS-Box kannte man das nicht und das ist so übernommen).
Und Unix ist ja viel älter !

Nicht umsonst gabs den Spruch:

Tunix mit Unix !

[holgerscherer]

Tunix mit Unix !

Der hat was ;-) Ich glaube, die GROSSklein-Unterscheidung kommt aus Zeiten, als ein ständiger Aufruf von lowercase() die CPU gebraten hätte...

-h

[BenderD]

jedenfalls war das ein Mensch, der was von der Art des Menschen zu lesen verstand, Kleinbuchstaben lesen sich schneller und mixed case schafft die Trenner, die das Auge braucht. Windoof ist allenfalls nach außen mixed case zuzulassen und intern alles als das selbe anzunehmen, da kann man nämlich dann Hugo nicht in hugo umbenennen, wer schon mal einen cvs Server auf Windows hatte, kennt das Problem, oder wird es kennenlernen.

D*B

PS: DOS und OS/400 mit seinen 8 bzw. 10 Buchstaben stammelnden Namen ist für mich keineswegs Beispielhaft, da war Unix früher schon weiter.

Tja, können ja ncht alle Windoof heißen (zur Zeit der DOS-Box kannte man das nicht und das ist so übernommen).
Und Unix ist ja viel älter !

Nicht umsonst gabs den Spruch:

Tunix mit Unix !

[holgerscherer]

jedenfalls war das ein Mensch, der was von der Art des Menschen zu lesen verstand, Kleinbuchstaben lesen sich schneller und mixed case schafft die Trenner, die das Auge braucht.

Klar kann man MixedKäse besser lesen, aber so schlau kann ein Elektronenrechner ja sein, das intern umzuwandeln. Ich halte es nur datentechnisch für eine Katastrophe. Es führt zu Auswüchsen, wie man sie bei den frühen SuSI-Installationen gesehen hatte: ein Programm namens "YaST", und diverse Dateilinks in den Schreibweisen "yast", "YAST", "YaSt" etc ;-)

-h

[Fuerchau]

Man sollte sich mal im Klaren sein, dass der EBCDIC-Code der älteste Computer-Code überhaupt ist.
Die Bit-Belegung stammt nämlich noch aus der guten alten Lochkarten-Zeit (da gabs doch mal irgendwann die 1. Volkszählung vor 100 Jahren oder so).

Die Lochkarte hatte 12 Zeilen, wobei eben Zeile 1-10 der Zahl 0-9 entsprachen und in der Kombination mit Zeile 11+12 zusätzliche Zeichen darstellbar waren.
Lochkarte - Wikipedia

So entspricht der Buchstabe A den EBCDIC X'C1', was den Löchern 1+11+12 entsprach.
Dadurch erklärt sich auch die Lücke von I nach J und R nach S im Code.

Beim ASCII wollte man sich die Sache dann einfacher machen und hat die Buchstaben A-Z einfach durchnummeriert.

Dadurch hat man im EBCDIC eben Schwierigkeiten einfach A-Z abzufragen (durch die Lücken), was im ASCII eben einfacher ist.

Durch diese Vereinfachung im ASCII war die Wandlung von Upper nach Lower und umgekehrt eben sehr einfach, was man heute immer noch in der C-Programmierung durch die Builtin-Funktionen sieht, die ganz einfach 32 addieren bzw. subtrahieren.

Durch MSDOS sollte ja alles einfacher werden und deshalb wurde sich da für caseinsensitive entschieden.

Deswegen habe ich ja heute noch Probleme mit MS-Access und SQL-Server einen Casesensitiven Unique-Key zu erstellen bzw. bei Abfragen auf Zeichenfeldern (bzw. Filterfunktion im ADO-Recordset) erhalte ich bei "where feld = 'a'" oder "where feld='A'" immer die selben Daten und muss dann selber nochmal weiterlesen bis ich den tatsächlich gewünschten Satz erhalte.

Bei Join-Abfragen wirds aber schon schwieriger.

Da liebe ich doch schon eher die DB2/400.

So, jetzt habe ich genug am Thema vorbeigeredet.