Sonderzeichen bei Spoolfilekopie aus dem iSeries Navigator

[Markus Gruebl]

Hallo zusammen,

ich bin auf ein kleines Problem gestoßen und vielleicht kennt jemand dafür eine Lösung:

Wir haben auf unserer As400 unter anderem Daten in der Codepage 1153 (Latin2 CZ) gespeichert. Die Userprofiles sind mit 65535 definiert. Mit der entsprechenden Definition der CA-Sitzung klappt auch die Anzeige wunderbar, das gleiche gilt auch für das Drucken und die Anzeige im AFP-Viewer.

Das einzige was nicht klappt ist das Kopieren einer Spooldatei via Rechtsklick in eine TXT-Datei auf dem PC. Gibt es da eine Lösung?

Vielen Dank im voraus für Infos!

Markus

[Fuerchau]

Da gibts leider so keine Lösung.
Die Spooldatei wird zwar korrekt in eine TXT kopiert, zur korrekten Anzeige des Textes benötigst du ein Latin2-Windows (1251 Osteuropa).

Die TXT-Datei ist ja SBCS-Code und wird vom Windows in 1252 (Westeuropa) angezeigt.

[Fuerchau]

Nachtrag:

Um unter Windows die Daten ggf. korrekt anzuzeigen muss man wohl Kommandos auf der AS/400 bemühen.

CPYSPLF in eine PF (geht nur CCSID 65535).
CPYTOSTMF ... DBFCCSID(1153) STMFCODPAG(1208).

Die 1208 steht dann für UTF-8, Windows erkennt diese meist automatisch.

[Markus Gruebl]

Vielen Dank für die Antwort.

Dieser Weg klappt wunderbar. Nun muss nur noch entschieden werden ob ein kleines Programm erstellt wird mit dem diese Funktion gewährleistet wird oder ob ein User mit passender CCSID angelegt wird und sich der Anwender für das Kopieren der
Datei ummelden muss. Ich bin mal gespannt ob hier die IBM mal was ändert oder ob das immer ein Problem bleibt.

MfG

Markus

Nachtrag:

Um unter Windows die Daten ggf. korrekt anzuzeigen muss man wohl Kommandos auf der AS/400 bemühen.

CPYSPLF in eine PF (geht nur CCSID 65535).
CPYTOSTMF ... DBFCCSID(1153) STMFCODPAG(1208).

Die 1208 steht dann für UTF-8, Windows erkennt diese meist automatisch.

[Fuerchau]

Die IBM wird da wohl nie was ändern, da dies eher ein Windowsproblem ist (das Windows muss die korrekte Codepage haben).

Ein Programm ist da auf jeden Fall erforderlich, da ein User das wohl nicht selber machen kann.
Ein anderer User ist auch nicht erforderlich, da du die CCSID für das IFS nicht am Userprofil anhängen kannst.

Oder wofür sollte dieser User gut sein ?

PS:
SBCS-Dateien (TXT, CSV u.ä.) sind auch zwischen Windowssprachen nicht kompatibel. Genau für sowas ist ja quasi UTF-8 erfunden worden.

Seit Windows98 hat ja Microsoft dann für die meisten Anwendungen Unicode eingeführt.

[Markus Gruebl]

Hallo,

ich hatte zu erwähnen vergessen, dass der Anwender der die Datei kopieren will angeblich ein Tschechisches Windows hat und es geht trotzdem nicht... Das muss ich aber nochmal prüfen nur der gute Mensch hat Urlaub....

Die User Profiles sind bei uns mit CCSID 65535 angelegt. Wenn nun so ein "normaler" User einen Spool in eine Windowsdatei kopiert tritt das Problem auf.
Eine mögliche Lösung ist einen "abgespeckten User" anzulegen der nur für diese Kopierfunktion genutzt wird und werden kann. Dieser User hat dann die CCSID 1153. Ich habe das getestet und es klappt dann auch mit dem Kopieren des Spools.

[Sven Schneider]

Ausprobiert habe ich es noch noch, aber versuch mal unter "iSeries Access für Windows - Eigenschaften" --> Sprache mit den Codepage Einstellungen zu spielen.

Wie gesagt , ich weis nicht ob der OpsNav das in diesem Fall berücksichtigt.

[Fuerchau]

@Sven
Es kommt auf die Windows-Codepage und nicht auf die AS/400-CCSID an.

Es ist immer eine Frage des Font's, der für die Darstellung der Zeichen zuständig ist.

[Sven Schneider]

@Sven
Es kommt auf die Windows-Codepage und nicht auf die AS/400-CCSID an.

Es ist immer eine Frage des Font's, der für die Darstellung der Zeichen zuständig ist.

Genau diese kann ich u.a. dort pflegen.

-ANSI-Codepage

Gibt die Nummer der ANSI-Codepage an, mit der die aktuelle ANSI-Codepage des Clients überschrieben werden soll. Geben Sie die entsprechende Nummer der ANSI-Codepage ein, oder wählen Sie in der Liste die Angabe "Standardwert" aus, um iSeries Access für Windows anzuweisen, die ANSI-Standardcodepage des Clients zu verwenden.

- OEM-Codepage

Gibt die Nummer der OEM-Codepage (OEM = Original Equipment Manufacturer) an, mit der die aktuelle OEM-Codepage des Clients überschrieben werden soll. Geben Sie die entsprechende Nummer der OEM-Codepage ein, oder wählen Sie in der Liste die Angabe "Standardwert" aus, um iSeries Access für Windows anzuweisen, die OEM-Standardcodepage des Clients zu verwenden.

- EBCDIC-CCSID

Gibt die ID des codierten Zeichensatzes (CCSID) für den EBCDIC-Zeichensatz an, mit der die aktuelle EBCDIC-CCSID überschrieben werden soll.

Anmerkung

Bei Angabe eines Werts "Standard" im Feld für die EBCDIC-CCSID wird die CCSID für alle Server, mit denen dieser Client verbunden ist, überschrieben.

Die Einträge werden in der Windows Registrierung abgelegt unter :

\HKU\Software\IBM\Client Access Express\CurrentVersion\NLS

Ich weis nur nicht, welche iSeries Access-Funktion diese Einträge benutzt.

[Fuerchau]

Das ist zwar korrekt, aber für Windows unerheblich.

Wenn in Windows eine TXT-Datei in SBCS geöffnet wird, entscheidet die aktuelle Windowsumgebung über die Darstellung der Zeichen.
Steht Windows auf 1252 (Latin1) werden osteuropäische Zeichen eben nicht dargestellt, da die Codes durch westeuropäische Zeichen belegt sind.

Du kannst es auch einfach wie Fonts vergleichen.
Erfasse ich in Word deutsche Zeichen und ändere den Font auf Wingdings (Symbol o.ä.) wird eben was anderes dargestellt.

Die selben Probleme hast du auch manchmal beim Austausch mit Linux/Unix oder wenn du noch TXT-Dateien aus einer DOS-Welt (Codepage 850) bekommst.

Du kannst es auch einfach ausprobieren:

Starte NOTEPAD, erfasse ÄÖÜ und speicher die Datei als TXT.
Starte eine DOS-Box und öffne diese Datei mit EDIT, dann verstehst du, was die grundsätzliche Problematik des Datenaustausches zwischen Sprachräumen in SBCS ist.

OEM-Codepage ist in deutschen Windows die 850, ANSI dann 1252.
CCSID eben 273, 500, 037 u.s.w.

Für Polnisch/Chechisch ist OEM 852, ANSI 1251, CCSID 870,1153 u.ä.

Durch die Windows-Sprachumgebung kann ich OEM und ANSI beeinflussen.

Einzig UNICODE/UCS und UTF unterstützen mehrere Sprachräume.