cpyfrmstmf - problem beim einlesen aus txt-datei

[easchbac]

hallo,

ich habe ein cl-programm geschrieben, das die daten aus einer csv-datei per CPYFRMSTMF in eine temporäre datei (CSV_TEMP) auf der as400 schreibt. CSV_TEMP wird wie folgt erstellt
-> CRTPF FILE(ASCHBA/CSV_TEMP) RCDLEN(2000) CCSID(*HEX)

die einzelnen felder aus der csv-datei werden in CSV_TEMP wie gwünscht mit einem ';' vonaneinander getrennt. in einer routine im weiterverarbeitenden programm zähle ich dann mit %scan diese ';' um zu erfahren, wieviele spalten die csv-datei hat. die weitere verarbeitung funktioniert auch wunderbar wenn ich die ursprungsdaten aus einem csv-file importiere!

nun sollte es aber auch möglich sein die daten aus einer txt-datei einzulesen. die datenfelder werden hier normalerweise nicht mit ';' sondern per tabulator (hex-wert 09) vonaneinander getrennt. das einlesen per CPYFRMSTMF in die datei CSV_TEMP funktioniert zwar, schau ich mir deren sätze aber im hex-editor an sind die trennzeichen nicht tabs (x09) sondern zeichen mit dem hex-wert x40. da ich für den txt-import nicht nach ';' scanne sondern nach tabulator, erhalte ich deshalb keinen korrekten wert zurück.

also meine frage, warum sind (beim txt-import) die daten im txt-sourcefile mit tabulator getrennt und in der temporären CSV_TEMP datei durch die werte mit dem hex-wert x40???

wenn mir jemand einen tipp geben kann wäre ich sehr dankbar.

lg

[Pikachu]

Bei CPYFRMSTMF gibt's (zumindest unter V5R4) einen Parameter "Tabulatorzeichenerweiterung" (TABEXPN). Gib für diesen Parameter mal *NO an.

[easchbac]

hallo pikachu,

danke dir für den super tipp... haut jetzt hin... beim txt-import wird mir jetzt zwar als delimiter das zeichen mit dem hex-wert x05 angezeigt (keine ahnung was das is - enquiry???), aber ich scan dann einfach im programm auf x05 statt x09... wunderbar... recht herzlichen dank noch einmal...

lg

[Pikachu]

0x05 ist anscheinend ein horizontaler EBCDIC-Tabulator.

[easchbac]

aha, ok... wieder was gelernt ... wünsche noch einen schönen tag und danke noch einmal...