CCSID Problem aufs Neue

[b.horstmann]

Hallo zusammen,

das Problem im Telegrammstile:
- deutsch eingerichte iSeries (CCSID=273 durchgängig) hat einen Bereich (Libl's/DB's) für eine in sich geschlossene kroatische Anwendung (CA/USRPRF/Job/DB CCSIS=870) - läuft Problemlos!
- Excel-File mit deutsch/kroatischer Übersetzung soll in diese kroatisch iSeries-Umgebung übernommen werden.

Trotz der schon mehrfach hier im Forum beschiebenen (guten!!!) Hinweise zu dieser Problematik (Latin-1/Latin-2/Unicode-Umsetzung) bekomme ich es nicht hin, z.B. diesen Zweizeiler von PC korrekt in eine Datei (CCSID=870) auf der iSeries zu bekommen:
Deutsch;Kroatisch
äÄöÖüÜß#?;šŠđĐčČćĆžŽ#?

es gehen entweder die kroatischen Sonderzeichen verlohren (die dt. Umlaute kommen an, aber auf die kommt es nicht an) oder es wird "Schrott" angzeigt.

gescheiterte Versuche: FTP und CPYFRMIMPF in unterschiedlichen Varianten (vielleicht nur nicht die richtige ...) und unterschiedlichen Bedingungen (verschiedene Kombinationen von CA/JOB-CCSID und Datei-CCSID).

wo liegt der Kasus-Knacktus - die Zeit läuft mir davon ... und ich dachte nach 15 Jahren AS/400-Erfahrung ich wüßte (fast) alles.

bin um jeden Tipp dankbar
Gruß b.horstmann

[Fuerchau]

Ja, Ja, immer wieder das selbe
Beim FTP auf die AS/400 wird automatisch die System-CCSID (e.g. 273) herangezogen, aber:
mittels
TYPE C 870
PUT ...
Wird die CCSID der zu erstellenden Datei auf 870 gestellt und während der Übertragung entsprechend gewandelt.
Wichtig ist also, dass die CCSID der Datei auf der AS im richtigen Format ist.
Dann klappts auch hinterher mit dem CPYFRMIMPF wenn Job und Zieldatei eine passende CCSID haben.

Beim Zugriff mittels Freigabe über den Explorer wird die CCSID eingestellt, die im NetServer als Default hinterlegt ist (Standard ggf. 850/1252).
Diese CCSID's sind WESTEUROPÄISCH ASCII bzw ANSI und Singlebytes. Ost- und Westeuropa kann leider nicht gemischt werden.

Mittels WRKLNK können im IFS mit Auswahl 8 die Attribute angesehen werden.

Aber:
Beim CPYFRMIMPF kann auch eine Codepage angegeben werden. Du musst halt nur die richtige herausfinden, für Osteuropa gilt 1250 !
http://www.asphelper.de/Referenz/Codepage.asp

[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 !