Anmelden

View Full Version : PC, CCSID und IFS



ILEMax
10-12-14, 10:53
Hallo
um PC Daten, die von verschiedenen externen Quellen kommen, verarbeite zu können
verschieben wir diese von einem PC Server (Auf der AS400 über MKDIR /qntc/... bekannt gemacht) ins IFS (/home/temp/)
Dort machen wir ein chgatr *ccsid 1208

Frage 1:
nach dem MOV steht im Joblog ein

CPFA0B8 Beendigung 40 10.12.14 11:35:05,093345 QP0LCCFN QSYS *STMT MV_PCFILE T1411011 *STMT
Ausgangsmodul . . . . . . . : QP0LCEXH
Ausgangsprozedur . . . . . : qgc_sendpm__Fv
Anweisung . . . . . . . . . : 17
Zielmodul . . . . . . . . . : MV_PCFILE
Zielprozedur . . . . . . . : MV_PCFILE
Anweisung . . . . . . . . . : 2200
Nachricht . . . : 6 Objekte versetzt. 0 Objekte fehlerhaft.
Fehlerbeseitigung: Das Jobprotokoll (mit dem Befehl DSPJOBLOG) durchsehen
oder die Taste F10 (Nachrichten im Jobprotokoll anzeigen) drücken, um
Nachrichten in nicht versetzten Objekten anzuzeigen. Die Fehler korrigieren
und die Anforderung wiederholen.


Das ist ein 40er Fehler, obwohl alles ok ist.
Ok, den kann ich abfangen, aber warum kommt der?

2. Frage
nach dem CHGATR kommt ein

CPFB414 Beendigung 40 10.12.14 11:35:05,120286 QP0LCCFN QSYS *STMT MV_PCFILE T1411011 *STMT
Ausgangsmodul . . . . . . . : QP0LCEXH
Ausgangsprozedur . . . . . : qgc_sendpm__Fv
Anweisung . . . . . . . . . : 17
Zielmodul . . . . . . . . . : MV_PCFILE
Zielprozedur . . . . . . . : MV_PCFILE
Anweisung . . . . . . . . . : 2800
Nachricht . . . : Attribute wurden für 6 Objekte geändert. 0 Objekte wurden



auch hier, Warum?

3 Frage
Die Dateien sollen anschließend zurück auf eine PC
Der Copy bricht ab mit

CPFA098 Diagnose 40 10.12.14 11:35:05,613050 QP0LCCFN QSYS *STMT MV_PCFILE T1411011 *STMT
Ausgangsmodul . . . . . . . : QP0LCEXH
Ausgangsprozedur . . . . . : qgc_sendpm__Fv
Anweisung . . . . . . . . . : 17
Zielmodul . . . . . . . . . : MV_PCFILE
Zielprozedur . . . . . . . : MV_PCFILE
Anweisung . . . . . . . . . : 3000
Nachricht . . . : Die CCSID der Zieldatei konnte nicht mit der CCSID der
Quellendatei abgeglichen werden.
Ursache . . . . : Das Kopieren schlug fehl, weil die CCSID der Zieldatei
nicht mit der CCSID der Quellendatei abgeglichen werden konnte. Folgende
Ursachen sind möglich: -- Das Zieldateisystem, in das kopiert wird,
unterstützt das Festlegen der CCSIDs nicht. -- Es wird versucht in eine
Datenbankteildatei (.MBR) zu kopieren, und die Teildatei konnte nicht mit
derselben CCSID wie die Quellendatei erstellt werden. Teildateien müssen
dieselbe CCSID besitzen wie die Datenbankdatei (.FILE), zu der sie gehören.
Die CCSID der Datenbankdatei stimmt nicht mit der der Quellendatei überein.
Fehlerbeseitigung: Wenn es sich um eine Datenbankteildatei handelt, in die



Das verstehe ich nicht!
manche der Dateien SIND in utf-8, hätten also nicht umgesetzt werden müssen
Da sie von einem (anderen) PC Pfad kommen muß der PC doch UTF-8 können

Kann das jemand erklären?

Danke
Der ILEMax

ILEMax
10-12-14, 11:27
Ok, ich bin ein Stück weiter.
Das CHGATR setzt keine Daten um, es ändert stumpf die ccsid am Objekt, egal ob das zum Inhalt der Datei passt oder nicht.

Die Situation ist nun folgende
manche Datein sind in utf-8 und brauchen nicht geändert werden
manche sind in Ansi und müssen Inhaltlich und im Atribur auf 1208
manche sind Inhaltlich in utf-8, werden aber auf dem PC als 1252 geführt
(Die hatte ich mal mit dem kopieren ins ifs und nem chgatr so bereinigt das ich sie verarbeiten konnte)
Nun weis ich aber nicht, welche Datei wie steht!
Jemand nen vorschlag?

ILEMax

Fuerchau
10-12-14, 11:51
Der Inhalt der Dateien muss vorher geklärt sein um sie korrekt verarbeiten zu können.
Wenn ich immer wieder raten muss, ist da ein Problem.

Wie du schon beschreibst, der CHGATR ändert nur das Attribut aber nicht die Daten.
Das Attribut ist entsprechend den Daten zu setzten!
D.h., UTF-8 in 1208, ANSI in 1252!
Automatisch passiert da nichts.

Ggf. kannst du da eine Analyse der Inhalte (nach dem CPY) machen ob z.B. UTF-8-Zeichen im Text vorkommen. Dies geht z.B. mit QSH "fgrep ...". Anhand des Ergebnisses machst du dann einen passenden CHGATR.

Da QNTC ein Fremdserver ist wird hier keine CCSID unterstützt. Beim Kopieren muss der Binärmodus gewählt werden.

Das Problem hierbei ist der MOV, da dieser bei verschiedenen IFS'n erst einen CPY und anschließend einen DEL aufruft.
Der CPY versucht auch das Attribut CCSID mitzunehmen, was hier leider nicht geht.
Das Kopieren ins QNTC geht auf 2 Wegen:
a) per QSH mit dem "cp fromfile tofile", hier geht ja auch "cp * /qntc/verz"
b) per CPYTOSTMF ... CVTDATA(*NONE), nur jede Datei einzeln

ILEMax
10-12-14, 12:24
Wonach muß ich beim fgrep suchen?
Nach einem/mehreren Hex-Werten?
Wie kann ich sicher sein, das es die nur in der codierung gibt?

Hab ich dich richtig verstanden, das ein CPY/MOV vom IFS ins QNTC nie geht und ich immer QSH verwenden muß?
Danke
der ILEMax

Fuerchau
10-12-14, 13:02
Der "fgrep" war jetzt eigentlich nicht so ganz ernst gemeint.
Aber wenn du suchen willst, dann stimmt es schon dass du nach dem Vorkommen von UTF8-Zeichen suchen musst.
Der "grep" ist da ggf. besser (laut WIKI) da er "reguläre Ausdrücke" verarbeiten kann.
Wie du nun UTF-8 erkennen willst, kannst du an Hand folgender Tabelle analysieren:
http://www.utf8-zeichentabelle.de/

Westeuropäische UTF-8-Zeichen beginnen i.W. mit x"C2" = Â (http://en.wikipedia.org/wiki/%C3%82) und x"C3" Ã (http://en.wikipedia.org/wiki/%C3%83).
Kommen diese also vor, ist UTF-8 wahrscheinlich (aber nicht sicher wenn es normale Zeichen in ANSI 1252 wären).

Bzgl. des QNTC hast du das korrekt verstanden, wobei eben ein CPYTOSTMF auch geht.

ILEMax
10-12-14, 14:00
Danke
ich hab mich jetzt für die try and error variante entschieden
Ich mach den Cpyfrmstmf mit 1208, knallt der mach ich ihn mit 1252 nochmal
nicht schön aber effektiv

AG1965_2
10-12-14, 14:24
Und zu Deinen Nachrichten - das sind Beendigungsnachrichten, also *COMP. Keine Abbruchnachrichten (*ESCAPE), also solltest Du auch überhaupt keine Probleme mit den Nachrichten haben.
Und das "System", das was falsch macht, ist der PC - denn da muss der User selber wissen, wie seine Daten kodiert sind oder es schlägt künstliche Dummheit zu, die es erkennen soll.
Auf dem IBM i gibt es eben dafür die CCSID.
Am PC hat man das erst mit XML mehr oder weniger gelöst, indem man die Kodierung in der Verarbeitungsanweisung angibt. (Aber auch da lügen genügend Programme / Anwender. Schreiben oben UTF-8 und schicken dann 1252-Daten.)