Unicode- und Codepage-Unterstützung aktivieren

#### Search Results

Search

# Unicode- und Codepage-Unterstützung aktivieren

Folgende Themen werden behandelt:

- International Components for Unicode for Software AG (ICS)

- ICS-Modul SAGICU

- Alternative ICS-Module zur Unterstützung von Architecture Levels

- Lademodule mit minimalen Collation-Daten

- ICU Data Libraries

- ICU-Datenelemente

- Unicode- und Codepage-Support für Adabas

- Umsetzungstabellen (Translation Tables)

- Unterstützung von Multi-Byte-Codepages

## International Components for Unicode for Software AG (ICS)

Für die Konvertierung 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/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 heisst, 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 im Dokumentensatz Debugger und Dienstprogramme.

## 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 311).

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 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.

- Collation Services

- Codepages und Locales

### 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ücksichtung 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.

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

Wenn Ihr Natural-System auf z/OS 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 Maschieneninstruktionen 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 321 ausgeliefert, weil die Lademodule von ICS 321 (`SAGICU` und `SAGICUA9`) schon minale Größen haben und keine statisch gelinkten ICU-Lokailisierungsdaten enthalten.

## ICU Data Libraries

Von der Software AG zur Verfügung gestellte Data Libraries werden bei ICS 321 nicht unterstützt.

ICS 321 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.

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 für Natural für Großrechner.

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/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).

Sie haben die Möglichkeit Ihrer 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

- Dynamisch geladene einzelne ICU-Datenelemente

### 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 lokalisierten 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.

## 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 Eingeschaften 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üzung 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 nicht berücksichtigt werden:

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

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

Natural passt 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. 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 konvertiert werden. Aufrund 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. IBM-1140, werden noch die herkömmlichen, auf EBCDIC basierenden Ein- und Ausgaben zum Aufbewahren von Ressourcen benutzt.

### On this page

- International Components for Unicode for Software AG (ICS)
- ICS-Modul SAGICU
- Alternative ICS-Module zur Unterstützung von Architecture Levels
- Lademodule mit minimalen Collation-Daten
- ICU Data Libraries
- ICU-Datenelemente
- Unicode- und Codepage-Support für Adabas
- Umsetzungstabellen (Translation Tables)
- Unterstützung von Multi-Byte-Codepages