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 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:
CFICU und
CP auf OFF
gesetzt sind.
SYSCP angezeigt.
Siehe SYSCP
Utility aufrufen und beenden in der Debugger und
Dienstprogramme-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 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 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.
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 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 |
de_DE |
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 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. |
Diese Module werden nicht mit ICS 311 ausgeliefert, weil die
Lademodule von ICS 311 (SAGICU und SAGICUA9) schon
minale Größen haben und keine statisch gelinkten ICU-Lokailisierungsdaten
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 eine schlanke Konfiguration und eine bessere Performance für
bestimmte Anwendungsfälle.
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ß.
Anmerkung: |
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 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).
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 Translation
Tables 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.