Lesen IFS File mit korrekten Umlauten

[Fuerchau]

Die Zeichenkonvertierung wird eigentlich durch das Flag O_CCSID gesetzt und vom System dann automatisch durchgeführt.

Versuche doch erst mal alternativ einen CPYTOSTMF mit der entsprechenden Konvertierung (als Ziel eine PF mit CRTPF und Satzlänge ohne DDS) durchzuführen.

Besser ist es eigentlich, eine DDS/SQL-PF mit den Feldern anzulegen und einen CPYxxIMPF (ich weiß nie aus dem Kopf ob from oder to) durchzuführen.
Das spart erheblichen Programmieraufwand und erleichtert das spätere verarbeiten.

[hteufl]

Hallo Fuerchau!

Du bist der Sache so glaube ich schon etwas näher gekommen.
Mit CPYFRMSTMF und Parameter STMFCCSID = 1208 und Parameter DBFCCSID = 1141 werden die Zeichen in einem PF korrekt angezeigt. Ein Versuch die Daten im RPG Modul mit den Parametern:

fd = open(%trimr(path) + %trim(IFSFilename) : flags : mode : 1208 : 1141);

zu ermitteln brachte erneut folgendes Ergebnis:
"Angebotsnummer";"E-Mail";"Thema";"Datum";"Information";"Tex
t"
"O1390360";"tobias.eisemann@pool-alpin.com";"Klapprahmen
A0";"";"6";"""O1390714";"f.beyer@intelligent-group.com";"
Bodenplatte für bestehende EKZ-Bremen Stele ON91SO01";"";"5
";""
"O1389816";"werner@momag.at";"Zeitungsdispenser, AusfÃ
¼hrung Àhlnich wie Dispenser NÃ Landes- kliniken";"24.10.2
013";"2";""
"O1389422";"p.steger@forster.at";"Test: E-Mail
Nacharbeit aus CRM";"24.11.2013";"2";""

Danke

Hermann

[Fuerchau]

Vielleicht kommt der open() ein wenig durcheinander da die Flags nicht eindeutig sind:
flags = o_rdonly + o_creat + o_ccsid + o_textdata + o_text_creat;
Die roten Flags sind zu viel, da du die Datei ja nur lesen und nicht erstellen willst.

Laut Doku wird intern iconv() verwendet, es sollte also klappen.
open()--Open File

Verwirrend ist das Flag O_TEXT_CREATE:

When the O_TEXT_CREAT flag and its prerequisite flags are not set, the specified or derived CCSID is the CCSID in which data is to be returned (when reading from a file), or the CCSID in which data is being supplied (when writing to a file).

Versuche mal mit den diversen Flags zu spielen, aus der Doku werde auch ich nicht schlau wann und ob und von welcher in welche CCSID konvertiert wird.

Ich halte mich da eh an die CPYxxx-Befehle.

Nachtrag:
Per CHGATR (bzw. QSHELL "touch") kann man die CCSID der Datei anpassen.
Ggf. liegt es auch noch daran, da die ja wohl auf 819 (also ANSI) steht.

[hteufl]

Hallo Fuerchau!

Meine Experimente mit den flag-Attributen (o_text_create, o_create) haben keine Änderung gebracht. Erst als ich mit Notepad++ die Kodierung auf ANSI geändert habe funktionierte der Datenupload (ohne Angabe einer CCSID). Interessant ist nur, dass der OPS-Navigator trotzdem den Zeichensatz 819 anzeigt. So wie es aussieht hat die AS/400 mit UDF-8 ziemliche Probleme.
Letztendlich heißt es für mich den Lieferanten der TXT Datei zu kontaktieren und ihn zu bitten die Datei in ANSI und nicht in UDF-8 zu erstellen.

Danke für die vorbildliche Unterstützung

Hermann

[Anton Gombkötö]

So wie Ferrari mit manchen Kurven ein Problem hat. Es liegt auf keinen Fall am Fahrer, nein.

Der Übeltäter ist doch offensichtlich der FTP-Server, der die empfangene Datei als 819 im IFS ablegt.
Leider kenne ich keine Möglichkeit, mit irgendeinem Befehl vor dem Senden der Daten die CCSID 1208 anzugeben. (SITE CRTCCSID geht nur für EBCDIC).

(Kann man gut mit einem FTP LOCALHOST ausprobieren, einfach mit lcd und cd ins selbe Verzeichnis stellen und eine Datei mit CCSID 1208 in eine neue, andere Datei senden. Bei mir hat die Kopie dann 819.)

Vielleicht reicht es, wenn der sendende Partner nach dem PUT den Aufruf eines CHGATR einbaut?

Auf alle Fälle gibt es einen Haufen Software auf der AS/400, die mit UTF-8-Daten sehr gut umgehen können.

Aber vielleicht baut Ferrari mal Autos, mit denen man um jede Kurve fahren kann. Wurscht, wer drin sitzt. :-)

[Fuerchau]

Die Default-CCSID für IFS-Objekte die per Netzfreigabe ins System kommen, wird im NetServer festgelegt.
Die CCSID für FTP (Ascii-Modus) wird per CHGFTPA festgelegt.
Fremdsysteme außerhalb der AS/400 können das nämlich nicht.

Das Problem sind hier die C-API's.
Da die CPYxxxSTMF/CPYxxxIMPF mit der Angabe der CCSID korrekt umgehen können, liegt es wohl an denen, dass die "Standardumsetzung" so nicht funktioniert.

Wie schon oben gesagt, was ist der Vorteil der C-API's gegenüber der Verwendung von CPY-Befehlen?
Ich behaupte einfach mal: keiner!

[SNO]

Bin nach längerer Recherche in diesem Thread gelandet.
Mein Problem war, ein Blz. Verzeichnis der Deutschen Bank, per Download ins IFS gestellt (als .xmlx und per Excel konvertiert in eine .csv Datei) in eine db2 Datenbank zu übertragen. Mit dem open und Ziel-CCSID 1141 war es nicht gelöst. Die Umlaute äöü und das ß wurden falsch bzw. nicht übersetzt.
Erst ein zuvor ausgeführtes CHGATR der Datei im IFS führte zur Lösung. Das sieht dann so aus:

cmd = 'CHGATR OBJ(' + hex7D
+ %trim(pfadundname) + hex7D + ') ATR(*CCSID) VALUE(1252)';
qcmdexc(%trim(cmd) : %len(%trim(cmd)));

fd = open(%trimr(pfadundname)
: O_RDONLY + O_TEXTDATA + O_CCSID
: S_IRGRP: 1141
);

dow readline(fd: %addr(line): %size(line))>=0;
"..."


Und natürlich funktioniert es auch mit CPYFRMSTMF:
// Hinweis: Funktioniert entweder mit STMFCCSID 1252 oder 1208
cmd = 'CPYFRMSTMF FROMSTMF('
+ hex7D + %trim(pfadundname) + hex7D
+ ') TOMBR('
+ hex7D + '/qsys.lib/qgpl.lib/test.file/test.mbr' + hex7D
+ ') MBROPT(*REPLACE) STMFCCSID(1252) DBFCCSID(1141)'
+ ' ENDLINFMT(*CRLF)'
;

Hinweis: pfadundname ist der String aus IFS Pfadangabe und Dateiname