Sekundärsprache Griechisch

[KM]

Da wir jetzt auch Polnisch benötigen, stellt sich für mich die Frage, ob für die reine Datenerfassung bzw. Datenanzeige überhaupt die Sekundärsprache Polnisch benötigt wird. Würde es nicht ausreichen, wenn wir die Einstellungen an DEVD, Tastatur, USRPRF, Sprachen-ID, Landes-ID, Host-Codepage, usw. auf Polnisch umstellen ? Wie schon erwähnt sind unsere Datenbankdateien alle mit CCSID 65535 erstellt. Uns ist jetzt auch klar, dass wir für die Datenausgabe die gleichen Einstellungen benötigen wie für die Datenerfassung, damit die Zeichen wieder korrekt dargestellt werden. Brauchen wir dann die Sekundärsprache überhaupt ? Oder wird diese nur für Systemmeldungen o.ä. benötigt ?

Gruß,
KM

[Fuerchau]

Die Sekundärsprache wird für alle Systemfunktionen und Meldungen benötigt, die polnische/griechische User verwenden können.
Denke dabei mal an WRKSPLF, beantworten von Druckernachrichten, DSPMSG usw.

Wenn eure Datenbanken schon auf 65535 stehen dann sollten auch die Jobs auf 65535 stehen damit auch garantiert keine Code-Wandlung durchgeführt wird.

Wie siehts mit euren PGM-Quellen aus ?
Welche CCSID wird da verwendet ?
Verwendet ihr in den Programme konstante "variante" Zeichen ?

Das "#"-Zeichen ist. z.B. variant, d.h. wenn gegen eine polnische/griechische Eingabe verglichen wird, das Zeichen aber in der Quelle deutsch ist, ist der Vergleich negativ.
Den Link auf nichtvariante Zeichen habe ich schon mal im Forum abgelegt.

[KM]

Die "ID des codierten Zeichensatzes (CCSID)" des Jobs steht auf 65535, während die "Standard-ID des codierten Zeichensatzes" auf 273 steht. Was ist eigentlich der Unterschied zwischen diesen beiden bzw. worauf wirken die sich aus ?
Wie kann ich feststellen welche CCSIDs die Programmquellen haben ?
Wäre es da sinnvoll solche varianten Zeichen direkt als HEX-Codes abzufragen, wenn sowieso keine Umsetzung erfolgt ? Diese müssten dann ja gleich sein.

Gruß,
KM

[Fuerchau]

Die "ID des codierten Zeichensatzes" gilt für alle Zugriffe auf Datenobjekte mit CCSID (DB/MSGF) für die Codewandlung.
Die "Standard-Id..." gilt für Erstellbefehle (CRTPF, CRTDSPF, CRTPRTF, SQL: CREATE TABLE, ...) ohne explizite CCSID-Angabe.

Die CCSID deiner Quellen steht in der Quellendatei (Source) "DSPFD FILE(QRPGSRC) TYPE(*ATR)".

Die Hex-Abfrage eines varianten Zeichens ist genauso unsinnig wie die direkte Abfrage.

Probier doch mal folgendes aus:

Gib folgendes Kommando ein:
"DSPLIB LIB(#LIBRARY)"

Stelle dein Terminal nun z.B. auf 297 (Französisch) und wiederhole den Befehl.

[KM]

So langsam kommt bei mir ein wenig Licht ins Dunkel der Zeichensätze. Ich habe jetzt festgestellt, dass wir bei unseren Datenbankdateien doch ein Mischmasch aus CCSID 65535 und 273 haben. Ich habe jetzt schon überlegt alle Dateien auf 273 zu ändern, hab's aber zum Glück noch nicht gemacht. Jetzt ist nämlich noch folgendes passiert. Ein polnischer Benutzer (mit CCSID 1153 im USRPRF) hat sich angemeldet. Somit hat sein Job auch 1153. Er wollte auf eine Datei zugreifen, die mit CCSID 273 definiert ist. Dann kam folgender Fehler:

Message . . . . : Datei PROGTEXT in Bibliothek DTDAT nicht geöffnet.
Ursache . . . . : Die Öffnung der Datei PROGTEXT in der Bibliothek DTDAT
wurde wegen Ursachencode 2 abgebrochen. 1 -- Die Kennzeichnung für den
codierten Zeichensatz (CCSID) 1153 wurde nicht gefunden. 2 -- Die Umsetzung
zwischen der Job-oder Programm-CCSID 1153 und der CCSID 273 für die Datei
PROGTEXT mit dem Format *N in der Bibliothek DTDAT ist nicht definiert. 3 --
Die Umsetzung der ASCII-Daten mit der CCSID 1153 wird nicht unterstützt. 4

Offenbar kann nicht von CCSID 273 in 1153 umgewandelt werden. Verstehe ich das so richtig ? Habe jetzt den Job in 65535 geändert. Jetzt kann wieder mit der Datei gearbeitet werden.

Was bringt es mir dann eigentlich, wenn ich überall eine CCSID gemäß der Primärsprache eintrage, die dann aber wegen der nicht durchführbaren Konvertierung zu Programmabbrüchen führt ? Sollte ich nicht doch die Dateien auf 65535 umstellen und lieber dafür sorgen, dass immer mit einer entsprechend konfigurierten Device auf die Daten zugegriffen wird ?

Gruß,
KM

[Fuerchau]

Hier muss man den Unterschied zwischen den Sprachräumen Latin1 (deutsch, englisch, franz., ital., span. ...) und Latin2 (poln. grich., kroat., serb., russ. ...) betrachten !
Zwischen diesen ist eine Konvertierung nicht definiert, da auch generell unterschiedliche Symbole in den Zeichensätzen vorkommen und es somit zu Darstellungsverlusten kommt.
Solange du die Daten sortenrein auseinanderhalten kannst, magst du mit 65535 gut fahren. Spätestens wenn du mit ODBC/FTP, IFS o.ä. auf die Daten zugreifen willst, werden die Probleme erst richtig anfangen.
Woher soll denn die AS/400 wissen, welche ASCII-Codepage gilt ?
Beim ODBC werden Zeichenfelder mit 65535 normalerweise NICHT umgesetzt, du erhältst auf dem PC dann den EBCDIC-Code.
Klickst du aber "Zeichenumsetzung für CCSID 65535" an, nimmt die AS/400 den Standardwert der installierten Primärsprache (e.g.273) an und wandelt dann in die ANSI-Codepage des PC's (Deutsch 1252, Polnisch ????).
Was das nun für die polnischen Daten bedeutet kannst du dir ja vorstellen.

Mehrsprachigkeit vor allem unterschiedlicher Sprachräume erfordert ggf. ein Redesign der DB !
D.h., Normalisierung bezüglich der Text- und Nicht-Text-Felder, wobei es Textschlüssel geben mag, die überall gleich sind, aber das weiß die AS/400 ja nicht.
Pro Sprachraum (Latin1, Latin2, ...) eine eigene Daten-Lib !
Wo gibt es tatsächlich den Zwang für Konsolidierung der Daten über Sprachgrenzen ?

Anwendung von DBCS, noch besser UNICODE so wie es die Windows-PC's schon länger machen.

Bei einem anderen Kunden von mir arbeiten die Polen halt in Englisch !