UTF-8 und iSeries?

[Sven Schneider]

Also, folgende Kombinationen machen nur Sinn :

- wenn DB-Feld ALPHA mit UTF-8 dann solltest du im DSPF auch Alpha verwenden. Im Program ist dann auch keine Konvertierung mit BIF's notwendig, das macht das System selbst. Verwendest du im DSPF ein Grafik mit UTF-16/UCS-2, dann solltst du beim UTF-8 DB-Feld CCSID(1208 *NORMALIZE) verwenden.
- wenn DB-Feld Grafik mit UTF-16/UCS-2 dann kannst du in DSPF die CCSID für UTF-16/UCS-2 bei einem Grafik Feld verwenden.

[Stoeberl]

Soweit gemacht. Hab aber immer noch Probleme beim wegschreiben. Wenn ich z.B. ein 'Ä' über mein Programm in die Datei schreiben will bekomme ich folgenden Fehler:
Data mapping error on member XXX
34 -- The data could not be converted from or to a UTF-8 or UTF-16 CCSID.
The expansion of single-byte data to a double-byte value caused the
converted length to be larger than the maximum length the result could hold

Das Feld in der Datei ist mit 30 Alpha und CCSID(1208) für UTF-8 definiert.

cu
Martin

[Fuerchau]

Bei der Konvertierung von SBCS nach DBCS muss das Zielfeld eben mindestens doppelt so lang sein wie das Quellfeld.

[Stoeberl]

Ich denk mal das ist nicht das Problem da ich
- DBCS-Zeichen ohne Probleme wegschreiben kann
- der Fehler erst beim WRITE auf das Satzformat auftritt. Die Zuweisung des Wertes an das Dateifeld über EVAL DATEIFELD = %CHAR(%TRIM(MASKENFELD)) war schon ein paar Statements vorher und brachte keinen Fehler

cu
Martin

[Fuerchau]

Wie ist das DATEIFELD im RPG denn definiert (Typ) ?
Ich nehme mal an, dass dieses Feld nicht als GRAPHIC definiert ist und somit das System gezwungen ist die Konvertierung SBCS/DBCS durchzuführen und da passt dann irgendwas nicht.
Beim EVAL wird eh abgschnitten bzw. aufgefüllt, was bei Datei-IO's nicht der Fall ist.

Achja:

Wis steht denn die Job-CCSID ?
Bei Datenbankzugriffen in normale CHAR-Felder wird in/von Job-CCSID konvertiert.
Der JOB selber kann aber (glaube ich) keine DBCS-CCSID sein.
Die Programm-Felder müssen also vom Typ Grafik sein, damit eben keine Konvertierung stattfindet.

[Stoeberl]

Das Feld DATEIFELD ist in der Physischen mit 30A CCSID(1208 *NORMALIZE) definiert. Das Feld MASKENFELD ist in der Maske mit 15G CCSID(13488 *LEN 30).
Nachdem ich einen Satz in der Physischen gelesen habe weise ich dem Maksenfeld den Wert mit EVAL MASKENFELD = %UCS2(DATEIFELD) zu. Nachdem der Wert in der Maske geändert wurde wird dem Dateifeld der Wert mit der Anweisung EVAL DATEIFELD = %CHAR(%TRIM(MAKSKENFELD)) zugewiesen.
Rufe ich das Programm in einer DBCS Umgebung auf und schreibe DBCS-Zeichen in das Maskenfeld klappt das wegschreiben. Wenn ich unter einer deutschen Anmeldung ein Ä,Ö,Ü,§,²,³ od. ´wegschreiben will stürzt das Programm mit dem bereits erwähnten Fehler ab (in der DBCS-Umgebung kann ich die Zeichen gar nicht eingeben).

Ich habe auch das Maskenfeld mal auf 30A geändert und die Zuweisungen durch EVAL MASKENFELD = DATEIFELD und EVAL DATEIFELD = MASKENFELD ersetzt. Das Ergebnis war dasselbe. Die anderen Zeichen auf der Tastatur konnte er ohne Probleme wegschreiben, nur bei diesen hat er Probleme.

Hab auch gerade nochmal bei Unicode.org vorbeigeschaut. Die ganzen Zeichen mit denen es nicht funktioniert scheinen nicht im normalen ASCII-Zeichensatz zu sein und werden wohl daher beim wegschreiben umgesetzt auf einen 2-Byte Wert. Wahrscheinlich müsste man die Zeichen schon vorher nach UTF-8 konvertieren aber ausser der API QlgTransformUCSData() hab ich noch nichts dazu gefunden. Kann auch in der RPG-Source kein Feld mit CCSID(1208) definieren.

Ne Idee wie man das noch elegant lösen könnte? Ansonsten muss ich es mal mit der API probieren, auch wenn ich im Moment noch nicht genau weiss wie ich die im RPG verwenden muss.

JobCCSID unter der deutschen Anmeldung ist 273. Das ganze funktioniert auch wenn ich statt UTF-8 UTF-16 od. UCS2 in meiner Physischen verwende, mich hätte aber eben gerade UTF-8 interessiert da hier bei den meisten Zeichen weniger Platz verbraucht wird beim speichern.

cu
Martin

[RobertMack]

Hallo,

möglicherweise hilft Dir das API iconv (System API Reference, SC41-5801), damit habe ich im RPGLE von 273 nach 1208 konvertiert (für MQ Series).

Gruß,
Robert

[Stoeberl]

Hallo Robert,

weisst du zufällig wie ich die Parameter in RPG kodieren muss bzw. ob ich die API überhaupt von RPG aus aufrufen kann? Hab zwar schon mit API's gearbeitet aber da waren die Typen meist char* oder binary.

Was mir auch gerade erst aufgefallen ist: Ich kann mir mit SQL die Sätze (Feld mit CCSID 1208 *NORMALIZE) in der Datei gar nicht anzeigen lassen. Bringt immer nen SQL system error (SQL0901). Im Log steht:
Function error X'0306' in machine instruction. Internal dump identifier
(ID) 0100265A.
*** DBOP open FAILED. Exception from call to SLICÜ ***.
Internal failure occurred in query processor.
File QAP0ZDMP in library QTEMP already exists.
User Trace data for job 022054/XXX/QPADEV0008 dumped to member
QP0Z022054 in file QAP0ZDMP in library QTEMP.
27 records copied from member QP0Z022054.
1 User Trace buffer(s) deleted.
SQL system error.

Irgendwie scheint das alles noch etwas buggy zu sein ...

cu
Martin

[RobertMack]

Hab's mal rauskopiert, aber der Anhang konnte leider nicht hochgeladen werden.

[Fuerchau]

Definiere das Dateifeld mit CCSID 13488, verwende im RPG das Feld als 15G (Grafik) !
Zwischen DB<->JOB<->DSPF darf bei DBCS keinerlei Umsetzung erfolgen, allerdings kannst du dieses Progrmm nur in einer DBCS-Umgebung verwenden. Bei SBCS geht das nicht, da hier Inkompatibilität herrscht.
Für SBCS benötigst du ein eigenes Programm.

[Stoeberl]

Definiere das Dateifeld mit CCSID 13488, verwende im RPG das Feld als 15G (Grafik) !
Zwischen DB<->JOB<->DSPF darf bei DBCS keinerlei Umsetzung erfolgen, allerdings kannst du dieses Progrmm nur in einer DBCS-Umgebung verwenden. Bei SBCS geht das nicht, da hier Inkompatibilität herrscht.
Für SBCS benötigst du ein eigenes Programm.

Hallo Fuerchau,

wie ich bereits weiter oben geschrieben hab funktioniert es mit UCS2 (13488) oder UTF-16 (1200) ohne Probleme. Mich würd aber gerade UTF-8 interessieren da hier bei den Zeichen des Standard-Ascii Satzes nur 1 Byte beim Speichern verwendet wird. Bei UCS2 und UTF16 sind es mindestens 2 Byte pro Zeichen.
Inwiefern kann es da Inkompatibilitäten geben? Ich kann mit dem Programm (wenn ich UCS2 od. UTF-16 anstatt UTF-8 verwende) sowohl unter ner SBCS- als auch ner DBCS-Anmeldung Daten schreiben und auslesen. Hab's nicht detailiert getestet aber auf anhieb wär mir nichts aufgefallen. Die DBCS Zeichen werden halt unter der SBCS-Anmeldung falsch dargestellt und manche Sonderzeichen wie Ä,Ö,Ü sieht man nicht in der DBCS-Umgebung. Aber ansonsten hat es funktioniert.
Die Probleme hab ich nur bei UTF-8.

cu
Martin

[Sven Schneider]

Was ich nicht verstehe :

Warum definierst du im DSPF ein DBCS-Grafik Feld, willst aber nur UTF-8 Daten speichern.

Ich habe es oben schon beschreiben, definiere im DSPF ein Alpha-Feld mit UTF-8 CCSID, dann solltest du keine Probleme bekommen.

Sven