Unicode- und Codepage-Unterstützung aktivieren

Folgende Themen werden behandelt:


International Components for Unicode for Software AG (ICS)

Bei der Umsetzung von Codepages und der Unterstützung von Unicode kommt Funktionalität zur Anwendung, die im Rahmen der International Components for Unicode for Software AG (ICS) zur Verfügung steht. Damit Natural zur Unicode- und Codepage-Unterstützung in der Lage ist, müssen die im ICS gelieferten Komponenten installiert werden: Das ICS-Modul SAGICU oder ein alternatives ICS-Modul (nur bei z/VSE und z/OS) und ICU Data Libraries.

Anmerkungen:

  1. Zur Ausführung von Anwendungen ohne Unicode- und Codepage-Unterstützung braucht keine ICS-Komponente installiert zu werden, das heißt, wenn die Profilparameter CFICU und CP auf OFF gesetzt sind.
  2. Informationen zur aktuell benutzten ICU-Version und Unicode Specification werden im Hauptmenü der Utility SYSCP angezeigt. Siehe SYSCP Utility aufrufen und beenden in der Debugger und Dienstprogramme-Dokumentation.

ICS-Modul SAGICU

Damit Natural zur Unicode- und Codepage-Unterstützung in der Lage ist, muss bei der Installation von Natural eine ICU Data Library verlinkt und geladen werden. Weitere Informationen siehe Installing International Components for Unicode for Software AG for z/OS (siehe ICS Transition Version 222 und ICS 311), z/VSE und BS2000.

Das ICS-Modul SAGICU ist dafür vorgesehen, unabhängig von Lokalisierungsdaten benutzt zu werden. Es enthält keine statisch gelinkten Codepages und Locales. Ein Dataset, der die gesamten, als Datenelemente ("Data Items") modularisierten ICU-Lokalisierungsdaten enthält, wird mit ICS 311 ausgeliefert. Der Dataset-Name kann mit dem Schlüsselwort-Subparameter STEPLIB des Profilparameters CFICU oder statisch in der JCL als eine Natural Steplib angegeben werden.

Statisch gelinkte Collation Data zur Sortierung (ein Satz Codepages und Locale IDs) werden noch unterstützt und sind Bestandteil der ICS Transition Version 222.

Collation Services

Eine weitere Besonderheit dieses Moduls sind die Collation Services. Diese werden verwendet, um Unicode-Zeichenketten miteinander zu vergleichen. Dabei wird berücksichtigt, dass die alphabetische Sortierfolge von Sprache zu Sprache unterschiedlich ist. Die Sprachen und Schreibsysteme dieser Welt und die jeweils verwendeten unterschiedlichen Einsortierungsregeln zu akkommodieren stellt eine große Herausforderung dar. Die ICU Collation Services stellen jedoch ausgezeichnete Mittel zur Verfügung, mit denen Zeichenketten unter Berücksichtigung von Gebietsschemaparametern (Locales) verglichen werden können. Beispiele: Beim deutschen Locale wird das Zeichen "Ä" zwischen "A" und "B" einsortiert, beim schwedischen Locale nach dem "Z". Im Litauischen wird das Zeichen "y" zwischen "i" und "k" einsortiert.

Die ICU-Implementierung der Collation Services ist konform mit dem Unicode Collation Algorithm und mit ISO 14651. Die Algorithmen wurden von Experten auf dem Gebiet der mehrsprachen Sortierung entworfen und überprüft und sind deshalb stabil und umfassend.

Codepages und Locales

Statisch gelinkte Collation Data zur Sortierung (ein Satz Codepages und Locale IDs) werden bei ICS 311 nicht unterstützt. Sie werden noch von der ICS Transition Version 222 (siehe ICS Transition Version 222) unterstützt und sind Bestandteil davon.

ICS 311 verwendet alle ICU-Lokalisierungsdaten.

Das ICS-Modul SAGICU stellt folgende Codepages und Locales zur Verfügung:

Codepages Locales

IBM037
IBM273
IBM1025
IBM1026
IBM1047
IBM1097
IBM01140
IBM01141
IBM01145
IBM01146
IBM01147
US (alias for IBM01140)
DE (alias for IBM01141)
ES (alias for IBM01145)
EN (alias for IBM01146)
FR (alias for IBM01147)
IBM-37_P100-1995,SWAPLFNL
IBM-1047_P100-1995,SWAPLFNL
IBM-1140_P100-1997,SWAPLFNL
EBCDIC-XML-US
EDF03DRV (BS2000 code page)
EDF03IRV (BS2000 code page)
EDF04DRV (BS2000 code page)
EDF04IRV (BS2000 code page)
EDF041 (BS2000 code page)
EDF04F (BS2000 code page)
IBM-290 (Japanese code page SBCS)
IBM-930 (Japanese code page SBCS/DBCS)
IBM-939 (Japanese code page SBCS/DBCS)
IBM-1390 (Japanese code page SBCS/DBCS)
IBM-1399 (Japanese code page SBCS/DBCS)
IBM-932 (Japanese code page ASCII MBCS)
IBM-942 (Japanese code page ASCII MBCS)
IBM-943 (Japanese code page ASCII MBCS)
EUC-JP (Japanese code page ASCII MBCS)
IBM-420 (RTL code page)
IBM-424 (RTL code page)
IBM-916 (RTL code page)

de_DE
en_US
es_ES
fr_FR
sv_SE

Alternative ICS-Module zur Unterstützung von Architecture Levels

Dieser Abschnitt gilt nicht bei BS2000.

Wenn Ihr Natural-System auf z/OS oder z/VSE mit einem IBM-Prozessor mit Architecture Level 9 oder höher läuft, können Sie das ICS-Modul SAGICU durch SAGICUA9 ersetzen. SAGICUA9 ist so aufgebaut, dass es erweiterte Maschineninstruktionen nutzt, die mit der ESA/390 und z/Architecture von IBM eingeführt worden sind. Sie können das Systemkommando TECH benutzen (siehe Systemkommandos-Dokumentation), um festzustellen, welcher Architecture Level auf Ihrer derzeitigen Maschine unterstützt wird.

SAGICUA9 bewirkt eine Performance-Verbesserung insbesondere bei der Ausführung von Natural-Statements, die Unicode-Variablen oder Instruktionen zur Codepage-Zeichencodierung benutzen (z.B. MOVE ENCODED). Weitere Informationen siehe themenspezifische IBM-Dokumentation (z/Architecture, Principles of Operation).

Warnung:
Ein Operation Exception Error (Abend Code S0C1) kann auftreten, wenn das ICS-Modul SAGICUA9 verwendet wird, aber der Architecture Level der zugrunde liegenden Maschine niedriger als 9 ist.

Lademodule mit minimalen Collation-Daten

Diese Module werden nicht mit ICS 311 ausgeliefert, weil die Lademodule von ICS 311 (SAGICU und SAGICUA9) schon minimale Größen haben und keine statisch gelinkten ICU-Lokalisierungsdaten enthalten.

Wenn ICS Version 222 in Ihrer Umgebung installiert ist, können Sie die Lademodule SAGICUM und SAGICUM9 benutzen, um nur das nötige Minimum an Collation-Daten beim Bauen des Moduls zu laden. Dies ermöglicht für bestimmte Anwendungsfälle eine schlanke Konfiguration und eine bessere Performance.

ICU Data Libraries

Von der Software AG zur Verfügung gestellte Data Libraries werden bei ICS 311 nicht unterstützt. Sie werden noch von der ICS Transition Version 222 (siehe ICS Transition Version 222) unterstützt und sind Bestandteil davon.

ICS 311 verwendet alle ICU-Lokalisierungsdaten.

Wenn Sie Natural für die Unicode- und Codepage-Unterstützung aktivieren wollen, müssen Sie bei der Installation von Natural eine ICU Data Library verlinken und laden, siehe Installing International Components for Unicode for Software AG für z/OS, z/VSE und BS2000.

ICU Data Libraries werden mit den folgenden ICU Data Modules geliefert. Dabei steht nn für die aktuelle Version des Moduls entsprechend der Ankündigung in den aktuellen Natural Release Notes.

Datenmodul Beschreibung
ICSDTnnE Enthält die gebräuchlichsten Codepages und Locales. Die Codepages sind schon in NATCONFG deklariert.
ICSDTnnJ Wie bei ICSDTnnE, jedoch erweitert um japanische Codepages. ICSDTnnJ ist schon mit dem ICS-Modul SAGICU (oder einem alternativen ICS-Modul auf z/VSE oder z/OS) verlinkt. Es enthält die oben genannten Codepages und Locales.
ICSDTnnX Enthält alle möglichen Converters und Locales, die von den zurzeit unterstützten ICU-Versionen angeboten werden. Es unterstützt ca. 230 verschiedene Codepages (überwiegend EBCDIC-Codepages) und 238 Locales. Deshalb ist das Modul sehr groß.

ICSDTnnX unterstützt alle Codepages und Locale IDs, die von der zurzeit unterstützten ICU-Version unterstützt werden (siehe http://demo.icu-project.org/icu-bin/convexp).

Anmerkung:
Aufgrund technischer Beschränkungen wird ICSDTnnX nicht für z/VSE und BS2000 geliefert.

Sie haben die Möglichkeit, Ihre eigene ICU Data Library zu erstellen, die exakt Ihren Erfordernissen entspricht (siehe ICU Data Library kundenspezifisch einrichten).

ICU-Datenelemente

Die von Natural unterstützten ICU-Datenelemente (Data Items) beinhalten Converters und Collators. Beispiel: Ein Converter wird benutzt, wenn ein MOVE ENCODED-Statement ausgeführt wird, und ein Collator, wenn Zeichenketten in einem IF-Statement verglichen werden.

Ein ICU-Datenelement ist entweder statisch mit einer ICU Data Library verlinkt oder es wird auf Anforderung während der Natural-Session dynamisch geladen.

ICU-Datenelemente werden als ladbare Module in dem für die Installation von Natural gelieferten ICU-Dataset mitgeliefert und müssen über die Natural-Steplib-Kette zugänglich sein.

Wird ein ICU-Datenelement zum ersten Mal aufgerufen, versucht ICS, es aus der verlinkten oder geladenen ICU Data Library zu öffnen. Falls kein ICU-Datenelement mit einer Library verbunden ist, versucht ICS, das Datenelement dynamisch aus dem ICS-Dataset zu laden.

Folgende Themen werden behandelt:

Namenskonventionen für Datenelementmodule

Die Länge des Namens eines Datenelementmoduls im ICS-Dataset ist auf acht Zeichen beschränkt. Wie in der folgenden Tabelle aufgeführt, hat der Name folgende Bestandteile:

  • Ein Präfix (I),

  • eine zweistellige ICU-Version (xx),

  • eine logische Gruppenkennung (C, B, S, L, M oder D) und

  • eine vierstellige Folgenummer (nnnn).

Modulname Inhalt
IxxCnnnn Zeichensatz-Abbildungstabellen (Converter-Module)
IxxBnnnn Umbruch-Iteratoren
IxxSnnnn Collators (Collation Services)
IxxLnnnn Lokalisierung (Formatierung, Anzeigenamen und sonstige lokalisierte Daten)
IxxMnnnn Verschiedene Daten (regelbasierte Zahlenformate und Transliteratoren)
IxxDnnnn Basisdaten

Beispiel:

I58C0074 ist der Name eines Converters für ICU Version 58.2 und Codepage ibm-1148_P100-1997.

In einem MOVE ENCODED-Statement erwartet Natural jedoch den Langnamen der Codepage, die dem Datenelementmodul entspricht. Es kann jeder gültige Aliasname der Codepage verwendet werden. Der Name der Codepage wird automatisch auf den achtstelligen Kurznamen abgebildet, wenn das Datenelementmodul geladen wird.

Weitere Informationen siehe relevante ICU Website.

Dynamisch geladene einzelne ICU-Datenelemente

Die Verwendung von dynamisch geladenen individuellen Datenelementmodulen ermöglicht eine hohe Flexibilität. Die Daten werden bei Bedarf geladen und unterstützen alle Codepages. Ein Dataset mit allen ICU-Lokalisierungsdaten, modularisiert in einzelne Datenelemente, ist Teil der ICS 311-Lieferung.

Ein einzelnes Datenelementmodul wird beim erstmaligen Zugriff (z.B. durch ein MOVE ENCODED-Statement) geladen und ist für die künftige Verwendung sofort verfügbar, ohne dass es neu geladen werden muss. Nur die bereits verwendeten Codepages werden im Speicher gehalten, jedoch keine statisch verlinkten Daten oder eine separate Data Library, wie es bei früheren ICS-Versionen der Fall war.

Einzelne Datenelementmodule sind besonders nützlich bei z/VSE und BS2000, weil diese Betriebssysteme die erweiterte Data Library-Funktionalität nicht unterstützen (die bei den vorigen ICS-Versionen zur Verfügung standen).

Unicode- und Codepage-Support für Adabas

Wenn eine Natural-Session für die Codepage- und Unicode-Unterstützung aktiviert ist, sollten Sie sich vergewissern, dass Naturals Adabas-Benutzer-Session ebenfalls die entsprechende Zeichencodierung (Encoding) für den Zugriff auf Adabas-Daten verwendet.

Da Adabas für die Konvertierung die Entire Conversion Services (ECS) benutzt, muss der ECS-Name in dem zugehörigen NTCPAGE-Eintrag im Modul NATCONFG angegeben sein. Um sicherzustellen, dass Naturals Adabas-Benutzer-Session die richtige Codepage benutzt, müssen Sie die Option ACODE und/oder WCODE im OPRB-Parameter für die benutzten Datenbanken angeben.

Weitere Informationen zur Adabas-Unicode- und Codepage-Unterstützung siehe Adabas-Dokumentation für Großrechner.

Umsetzungstabellen (Translation Tables)

Natural benutzt zahlreiche Tabellen zur Umsetzung von Zeichen und zur Festlegung der Eigenschaften ("Properties") eines Zeichens. Der Inhalt der Tabellen kann während des Starts einer Natural-Session über die entsprechenden Profilparameter geändert werden: TAB, UTAB1, UTAB2 und SCTAB.

Wenn Natural mit Codepage-Unterstützung läuft (d.h. wenn der Profilparameter CP auf einen Wert ungleich OFF gesetzt ist), können die Tabelleninhalte nicht durch den Benutzer geändert werden. In diesem Fall erscheint beim Natural-Start die folgende Meldung, um den Benutzer in Kenntnis zu setzen, dass die oben erwähnten Session-Parameter ignoriert werden:

Character translation parameter table-name ignored due to CFICU=ON.

(Zeichenumsetzungsparameter table-name wird ignoriert wegen CFICU=ON.)

Natural paßt die Tabellen automatisch entsprechend der für die Natural-Session benutzten Codepage (Wert der Systemvariablen *CODEPAGE) an. Siehe auch Translation Tables in der Operations-Dokumentation.

Unterstützung von Multi-Byte-Codepages

Natural unterstützt Multi-Byte-Codepages (MBCS), z.B. die Codepage BM-939, bei der es sich um eine japanische Codepage handelt, die auf EBCDIC und DBCS basiert. Die Auswahl einer Multi-Byte-Codepage kann mit dem Natural-Profilparameter CP erfolgen, indem die Einstellung AUTO=AUTO (falls unterstützt) gewählt oder der Name der Codepage angegeben wird. Wenn Natural mit einer Multi-Byte-Codepage läuft, benutzt es interne Ein-/Ausgabepuffer, die auf Unicode basieren. Das bedeutet, dass alle Daten, die von einem Ein-/Ausgabe-Statement in die internen Ein-/Ausgabepuffer geschrieben werden, in Unicode umgewandelt werden. Aufgrund der von Unicode und Multi-Byte-Codepages gestellten Anforderungen sind die Puffer größer als bei herkömmlichen Ein- und Ausgaben, weil Unicode-Zeichen doppelt so viel Platz wie EBCDIC-Zeichen benötigen und weil verbesserte Attribute zur Beschreibung eines Feldes benötigt werden.

Im Falle von Single-Byte Codepages (SBCS), z.B. Codepage IBM-1140, werden noch die herkömmlichen, auf EBCDIC basierenden Ein- und Ausgaben zum Aufbewahren von Ressourcen benutzt.