CCSID Problem aufs Neue

[b.horstmann]

FTP mit TYPE C 870 und (vordefinierte) Zieldatei mit CCSID=870 habe ich - erfolglos - versucht.

Das Problem beginnt eigentlich schon bei Excel, denn ich kann es nur als "UNICODE-Text" ausspielen - d.h. als DBCS-File. Bei .CSV oder nur .TXT aus EXCEL heraus gehen schon die kroatischen Sonderzeichen verlohren - aber das ist eine andere Baustelle.

erstmal Dank für die schnelle Reaktion.

[Fuerchau]

UNICODE geht auch, die CCSID hierfür ist 13488.
Übertrage die Datei als Binärformat, so dass du Unicode auch auf der AS hast.
Dann kopiere mit CCSID 13488.

[b.horstmann]

sorry - ich hätte mir aufschreiben sollen, was ich alles schon probiert habe - aber für heute muß ich Schluß machen - Montag melde ich mich wieder

schönes (problemloses!) Wochenende

[Fuerchau]

Ok, ich habe folgendes gemacht:
Die Textdatei muss als ANSI-Datei mit Codepage 1250 (Osteuropa) gespeichert sein.
Stelle diese dann ins IFS per Binär-FTP bzw. über den Explorer auf eine IFS-Freigabe.

Erstelle eine PF ohne CCSID (65535):
CRTPF FILE(FUERCHAU/TESTX) RCDLEN(256)

Kopiere die Daten per CPYFRMSTMF !!!
CPYFRMSTMF FROMSTMF('/home/fuerchau/testpolen.txt')
TOMBR('/qsys.lib/fuerchau.lib/testx.file/testx.mbr')
MBROPT(*REPLACE)
STMFCODPAG(1250)
DBFCCSID(870)
TABEXPN(*NO)

Auf einer Sitzung mit Hostcodepage 870 kann ich die Zeichen eindeutig erkennen.

[Fuerchau]

Da gibts wohl doch einige Probleme bei der CCSID(870) und der CHRID(959 870) !
Ich habe nun auch einiges getestet, aber das korrekte Ergebnis wird auf der AS bzw. vom Terminal (CA5250) nicht unterstützt.
Die einzig funktionierende Konvertierung ist von Codepage 1250 (Windows-Osteuropa) nach CCSID 870 (EBCDIC Osteuropa).
Allerdings können da einige Zeichen nicht korrekt dargestellt werden, da diese in der CHRID einfach nicht vorhanden ist.

Das Ergebnis aus

äÄöÖüÜß#?;šŠđĐčČćĆžŽ#?

ist mit Datei-/Job- und Display-CCSID:

äÄöÖüÜß#?;šŠdÐcCcCžŽ#?

Man beachte also den Darstellungsverlust.
Dies liegt nicht an den Daten, sondern einfach daran, dass in der SBCS-CCSID 870 eben die deutschen Umlaute auch vorhanden sind !

Meine Übertragungsmethode ist übrigens SQL mit ODBC.
Auch hierzu gibts einiges zu beachten:

In der Verbindungszeichenfolge gibts seit V4R? den Parameter CCSID=nnnn.
Mit dieser CCSID ist allerdings nicht die AS/400 gemeint, sondern in welcher Codepage der CLIENT arbeitet (Windows Europa läuft da normal mit 1252 ANSI).

Gibt man dort eine CCSID an, müssen die Daten in dieser Codepage angegeben werden.
Für obigen Fall habe ich den Wert also auf CSSID=1250 (Osteuropa) geändert und die Daten in eine PF mit CCSID(870) geschoben.
Alle anderen Methoden führten zu negativen Ergebnissen.

Auch folgendes sollte man wissen:

Wird ein SQL-Kommando direkt ausgeführt (also ohne Parametermarker) erfolgt die Umsetzung von UNICODE zu SBCS bereits im Client, also hier bereits mit Datenverlust.
Ausnahme, man bestimmt dass der gesamte SQL als UNICODE übergeben wird. Dies muss man allerdings in der Verbindungsfolge bereits angeben.
Um UNICODE per ODBC korrekt zu verarbeiten muss man alles in UNICODE machen.

Nun gibt es noch die Möglichkeit mit Parametermarkern zu arbeiten, also:
an Stelle von "insert into myfile values('Text')"
sollte man "insert into myfile values(?)"
verwenden. Normalerweise werden vom ODBC-Treiber alle Parameter entsprechend des Feldtyps automatisch erkannt und voreingestellt.
Aber alle String-Parameter sind GRUNDSÄTZLICH SBCS-Zeichenfolgen, also nix mit UNICODE.
Die Parameter können allerdings auf WideCharacter (adWChar, adVarWChar) geändert werden um auch tatsächlich UNICODE an die AS übertragen zu können.

Tue ich das eben nicht, also die Parameter auf WChar umstellen, erhalte ich absolut keine Chance UNICODE an die AS/400 zu senden.

Mit meiner neuen Version des ExcelAddin's Uplaod/400 (2.0), die ich demnächst ins Netz zum Download stellen werde, sind alle diese Probleme berücksichtigt und per Parameter einstellbar.
Eine kurze Beschreibung werde ich dann ins Software-Forum stellen.

Das Problem des Zeichenverlustes im obigen Beispiel läßt sich auch mit UNICODE nicht lösen, da nun mal die EBCDIC-CCSID(890) diese Zeichen nicht enthält.
Ob es eine andere CCSID gibt müsste untersucht werden, gefunden habe ich erstmal keine.

Noch eine kleine Anmerkung am Rande:
Man darf sich von VB/VBA nicht ins Boxhorn jagen lassen.
Strings sind Unicode und bleiben auch Unicode !
Gibt man allerdings Strings mit z.B. Debug.Print aus, werden diese in ANSI umgewandelt und können daher nicht mehr alles enthalten.
Auch die ASC-Funktion liefert keine Werte > 255, so dass man mit VB/VBA keine Chance hat den Inhalt zu prüfen.

[b.horstmann]

Hallo Herr Fürchau,
das Thema ist nach wie vor aktuell - nur ich komme z.Zt nicht dazu.

Wie ich schon schrieb, fängt das Problem schon auf dem PC an (und da kenne ich mich nicht so gut aus): Wie bekomme ich aus einer Exceltabelle (mit UNICODE oder Codepage 1252) eine Text-Datei mit Codepage 1250. Bis jetzt habe ich das nur mit OpenOffice geschafft.

zu ihren letzten ausführlichen Anmerkungen - soweit es die iSeries betrifft - kann ich nur zustimmen. Den "Verlust" der Zeichen konnte ich aber durch eine andere Schriftart im CA ausgleichen (ich glaube alles andere war möglich nur nicht die IBM3270)

Ich werde kommende Woche noch mal einen intensiven Test machen mit einem rein (!)kroatisch installiertem PC (d.h. WIN2K und Office stammen von dort) und dann wieder berichten.

Ich glaube das Thema CCSID ist es Wert, dass dazu mal ein Redbuch geschrieben wird !

Zunächst mal vielen Dank und bis bald wieder

[JustMe]

sowas wie das hier ?

HTH
R.

[b.horstmann]

sowas wie das hier ?

HTH
R.

ich habe von IBM 2 CD hier mit allen(?) Redbooks (Stand 2004), ich habe auf der redbook-Hompage mit allen möglichen Stichworten zu diesem Thema gesucht - warum habe ich das nicht gefunden - na ja, auf jeden Fall viiiiiiielen Dank für den Hinweis.

Ich kann im Moment nur sporadisch an diesem Problem weitermachen, werde aber auf jeden Fall euch über das Forum auf dem laufenden halten!

Gruß Ho.

[KM]

Hallo B. Horstmann,

ich weiß jetzt nicht, ob Du das automatisch per Programm machen willst oder ob Dir ein manueller Upload ausreicht. Dann könntest Du nämlich folgendes machen:

- Excel File-Upload Add-In von iSeries Access benutzen
- Damit wird eine neue iSeries-Datei mit CCSID 13488 erstellt (Feldarten sollten auf Unicode stehen) -> das wird glaube ich seit iSeries Access V5R3 unterstützt
- Dann eine Datei mit entsprechenden Feldern mit CCSID 1153 (oder 870) erstellen
- CPYF aus der Datei mit CCSID 13488 in Datei mit CCSID 1153 bzw. 870

Und schon hast Du Deine Daten im richtigen Format. Diese werden dann auch bei entsprechender Sitzungs-Codepage korrekt angezeigt.

Gruß,
KM

[Fuerchau]

Oder mit meinem Tool Upload400 !

[b.horstmann]

Hallo Interessierte,

ich war mal wieder an meinen Problem und wollte ein "vorläufiges Endergebnis" kurz mitteilen. Zur Erinnerung: Excel-Daten, die in Kroation auf einem kroatischen PC (Codepage 852 Latin2) erstellt werden soll in eine iSeries-Datei (CCSID 870) übernommen werden (... durch ein USRPRF/JOB mit CCSID 870, LANGID HRV, der Rest der DB hat CCSID 273 Latin1). Ich möchte das ganze mit iSeries-Mitteln lösen.

Der einzig gangbare Weg zur Übernahme ist ein CPYFRMSTMF in eine TEMP-File mit CCSID 65535 und dann ein CPYF in die eigentliche Zieldatei mit CCSID 870. Bei dieser Vorgehensweise gibt es keinen Zeichenverlust - zumindest konnte ich keinen mehr feststellen.

Das Hauptproblem dabei ist das Ausspielen aus Excel als .CSV bzw. .TXT. Wir haben inzwischen einen kroatischen PC bei uns im Netz und wenn ich von diesem aus, direkt ins IFS die Daten ausspielen - und dann übernehme (siehe oben) - nur dann habe ich keinen Zeichenverlust. Komischer Weise wird immer(!) für die von Excel ausgespielten Daten die Codepage 1252 (Ansi Latin1) angezeigt - egal ob von einem deutschen oder von dem kroatischen PC aus (hat jemand eine Erklärung dafür?). Vom kraotischen PC aus sind aber die Zeichen korrekt und werden korrekt auf die iSeries übernommen.

soviel für heute