Folgende Themen werden behandelt:
Für die Konvertierung von Codepages und der Unterstützung von Unicode kommt
Funktionalität zur Anwendung, die im Rahmen der ICU for Adabas & Natural (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:
CFICU und CP auf OFF gesetzt
sind.
SYSCP angezeigt. Siehe SYSCP Utility aufrufen und
beenden in der Debugger und Dienstprogramme
(Utilities)-Dokumentation.
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 322).
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 322 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.
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.
Statisch gelinkte Collation Data zur Sortierung (ein Satz Codepages und Locale IDs) werden bei ICS 322 nicht unterstützt.
ICS 322 verwendet alle ICU-Lokalisierungsdaten.
Das ICS-Modul SAGICU stellt folgende Codepages und Locales zur
Verfügung:
| Codepages | Locales |
|---|---|
|
IBM037 |
de_DE |
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
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. |
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 der aktuellen Natural-Freigabemitteilung
(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/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ß.
|
Sie haben die Möglichkeit Ihrer eigene ICU Data Library zu erstellen, die exakt Ihren Erfordernissen entspricht (siehe ICU Data Library kundenspezifisch einrichten).
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:
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.
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 322-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.
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.
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 Umsetzungstabellen in der
Operations-Dokumentation.
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.