Folgende Themen werden behandelt:
In diesem Dokument stellt die Notation vr die aus zwei Zeichen bestehende ICU-Versionsnummer dar.
In ICU werden verschiedenste Datentabellen verwendet, um vielfältige Dienste zur Verfügung zu stellen, beispielsweise Converter-Abbildungstabellen, Collationsregeln, Transliterationsregelen, Regeln für Umbruch-Iteratoren und Diktionäre und sonstige Locale-Daten. Die ICU Data Library für Natural wird als Paket (Package) zur Verfügung gestellt, das die gewünschten Datenelemente enthält. Die Verwendung von Paketen anstelle von einzelnen Datenelementdateien steigert die Performance, weil während der Initialisierung nur ein Dateizugriff zum Laden des Pakets erfolgt. Es ist jedoch nicht so flexibel, denn es erfordert einen Rebuild des Pakets, wenn Datenelemente hinzugefügt werden müssen.
Die ICU Data Library kann kundenspezifisch angepasst werden, um existierende oder neue Converter-Abbildungstabellen oder um andere Datenelemente, z.B. Collationsregeln, Regeln für Umbruch-Iteratoren und sonstige Locale-Daten hinzuzufügen.
Das Tool für die kundenspezifische Anpassung der ICU Data Library kann aus dem Download Components-Bereich in Empower (https://empower.softwareag.com/) heruntergeladen werden. Benutzen Sie die mitgelieferte icudtvr.zip-Datei (vr = Version), um die Data Libraries für die ICU-Version anzupassen, die in Ihrer Natural-Umgebung erforderlich ist: Für ICS Version 2.2 ist icudt58.zip erforderlich. Die in diesem Abschnitt beschriebenen Dateien sind in der icudtvr.zip-Datei enthalten.
Um ein neues ICU Data Library Package zu erstellen, sind mehrere Schritte erforderlich. Einige davon werden auf einem PC durchgeführt, andere auf der zugehörigen Großrechner-Plattform.
Folgende Themen werden behandelt:
Für neue Datenelemente gibt es verschiedene Quellen:
Der ICU Data Library Customizer auf http://apps.icu-project.org/datacustom/.
Das ICU Converter Data Archive auf http://source.icu-project.org/repos/icu/data/trunk/charset/data/ucm/.
Benutzerdefinierte Converter-Abbildungstabellen.
Der ICU Data Library Customizer ist ein web-basiertes Tool, das von IBM zur Verfügung
gestellt wird. Für jede unterstützte Version ist ein ICU Data Library Customizer
verfügbar. Die ICU-Version kann mit Hilfe der SYSCP-Utility
festgestellt werden (siehe Funktion ICU Information).
Der Data Library Customizer zeigt die Datenelemente in einer Baumstrukturansicht an. Zunächst sind alle Datenelemente als ausgewählt markiert. Man kann alle Elemente zusammen abwählen, indem man die Advanced-Option erweitert und die Schaltfläche wählt.
Die Menge der angezeigten Elemente kann reduziert werden, wenn man bei den
Advanced-Optionen die Schaltfläche wählt. Um zum Beispiel die Baumstrukturansicht so einzuschränken,
dass nur Elemente für Japanisch angezeigt werden, muss man die Zeichenkette
japanese in das Texteingabefeld eingeben und die Schaltfläche
wählen. Danach können mehrere Elemente ausgewählt
oder abgewählt werden. Alle ausgewählten Elemente werden später zur ausgelieferten ICU
Data Library hinzugefügt und stehen dann für Natural zur Verfügung.
Die zweite Möglichkeit besteht darin, für den gewünschten Converter eine (Source) Mapping-Datendatei .ucm zu übernehmen oder zu erstellen. Das ICU-Team unterhält ein umfangreiches Archiv mit Converter-Daten. Dieses Archiv ist versionsunabhängig. Falls die gewünschte Konvertierungstabelle nicht im Archiv vorhanden ist, kann man sich eine neu erstellen. Das Layout von Converter Mapping-Tabellen (.ucm-Dateien) ist im Kapitel Conversion Data im ICU User Guide dokumentiert, siehe http://userguide.icu-project.org/conversion/data. Es wird empfohlen, aus dem Archiv eine ähnliche Mapping-Tabelle zu kopieren und sie an die neuen Erfordernisse anzupassen.
Anmerkung
Es ist untersagt, die Zeichenabbildung eines existierenden Converters zu ändern.
Tatsächlich handelt es sich dabei um das Erstellen eines neuen Converters, was die
Vergabe eines neuen Namens erfordert, um Verwechslungen zu vermeiden.
Ausführliche Informationen zur kundenspezifischen Anpassung der ICU Data Library finden Sie in der Datei readme.txt, die Teil der heruntergeladenen zip-Datei ist.
Converter-Quelldateien werden mit dem Tool makeconv.exe in binäre Converterdateien (.cnv-Dateien) kompiliert. Es ist möglich, mehr als einen Converter anzugeben:
Beispiel:
| Kommando | Beschreibung |
|---|---|
makeconv ibm-1142_P100-1997.ucm |
Kompiliert die dänische Zeichenabbildungstabelle der Codepage IBM-1142 in das binäre Format. In einem anschließenden Schritt kann die Ausgabedatei ibm-1142_P100-1997.cnv zu dem neuen Data Library-Paket hinzugefügt werden. |
Converters, die vom ICU übernommen werden, sind bereits in der Tabelle der Aliasnamen
registriert. Falls die Converter-Source-Datei eine benutzerdefinierte Datei ist,
existiert noch kein zugehöriger Name in der Tabelle der Aliasnamen. In diesem Fall
müssen Sie die neue Codepage in der Tabelle der Aliasnamen registrieren. Öffnen Sie die
Textdatei convrtrs.txt und fügen Sie einen entsprechenden Eintrag
am Ende der Datei im Abschnitt "User defined code pages"
(benutzerdefinierte Codepages) hinzu. Der Name der Codepage muss angegeben werden, die
Angabe des IANA-Namens ist optional. Die Zeichenkette { IANA* } deklariert
iana-name als IANA-Namen. Für jede benutzerdefinierte
Codepage muss ein Eintrag in der Tabelle der Aliasnamen vorgenommen werden.
Der Eintrag hat folgendes Format:
name-of-code-page iana-name { IANA* }
Wenn die Codepage "my_cp-100" mit dem IANA-Namen "MYCP" hinzugefügt werden soll, ist in convrts.txt die folgende Zeile erforderlich:
my_cp-100 MYCP { IANA*}
Weitere Informationen finden Sie im Kopfdatenbereich der Datei convrtrs.txt oder im ICU User Guide.
Die geänderte Tabelle muss mit gencnval.exe in eine binäre Datei (cnvalias.icu) kompiliert werden, um sie dann mit dem neuen Data Library-Paket zu verlinken.
Ein neues Data Library-Paket wird mit dem Tool makpkg.bat erstellt. Es benutzt das gelieferte Paket icudtvr.dat (vr = Version) und sortiert neue, benutzerdefinierte Elemente ein. Ein benutzerdefiniertes Element kann ein zusätzliches Paket sein, das neue Datenelemente enthält, ein einzelnes Datenelement, z.B. ein neuer Converter (.cnv-Datei), oder eine Textdatei, die eine Liste neuer Elemente enthält.
Beispiele:
| Kommando | Beschreibung |
|---|---|
makepkg icudtvrl.dat |
Fügt die Datenelemente, die in icudtvrl.dat enthalten sind, zum Basispaket icudtvrb.dat hinzu. |
makepkg ibm-1142_P100-1997.cnv |
Fügt die dänsiche Codepage IBM-1142 zum Basis-Data-Library-Paket icudtvrb.dat hinzu. |
makepkg newitems.txt |
Fügt alle Datenelemente (Converters), die in der Textdatei newitems.txt aufgeführt sind, zum Basis-Data-Library-Paket icudtvrb.dat hinzu. |
makepkg.bat erzeugt zwei Dateien: eine Big-Endian EBCDIC-basierte
binäre Datei und eine HL Assembler Source. Die Assembler Source enthält das binäre
Abbild der ersten Datei, gepackt in DC X'...'-Statements. Der Name der
binären Datei icudtvre.dat und der Name der Assembler Source ist
icudtvre_dat.s. Die Datei icudtvre ist eine
Kopie von icudtvre_dat.s. Die Dateien dürfen niemals umbenannt
werden, weil der Paketname
"icudtvre" als Bestandteil
interner Referenzen bei Datenelementen verwendet wird. Sie wird von der ICU Runtime für
den Zugriff auf Datenelemente, z.B. Converters, und zum Validieren der Datendatei
benutzt. "icudt" identifiziert die Datei als Big-Endian
EBCDIC-kodiert.
Wenn mehr als ein Element hinzugefügt werden soll oder wenn die Tabelle der Aliasnamen geändert worden ist, müssen die Elemente als Liste in der Datei newitems.txt deklariert werden.
Beispiele:
Hinzufügen der Codepages ibm-939_P120-1999 und ibm-942_P12A-1999
Einträge in newitems.txt:
ibm-939_P120-1999.cnv
ibm-942_P12A-1999.cnv
Hinzufügen der benutzerdefinierten Codepage my_cp-100
Einträge in newitems.txt:
cnvalias.icu
my_cp-100.cnv
Weitere Informationen siehe ICU User Guide.
Das Ergebnis der vorangegangen Schritts ist ein Assembler-Modul. Das Assembler-Modul mit dem neuen Data Library-Paket icudtvre muss auf die Zielplattform übertragen werden. Das File Transfer Protocol (FTP) ist auf jedem PC vorhanden und kann für diesen Zweck benutzt werden. Wenden Sie sich an den Systemadministrator wegen der Informationen (z.B. Host-Name, Port-Nummer, Benutzername und Passwort), die Sie benötigen, um Zugang zur Zielmaschine über FTP zu erhalten. Da es sich bei icudtvre um eine Textdatei handelt, muss der Transfermodus auf ASCII gesetzt werden, um die korrekte Umsetzung der Datei auf der Zielplattform sicherzustellen. Der Name der Datei auf der Zielplattform kann frei gewählt werden. Es wird jedoch empfohlen, den Namen icudtvre zu verwenden. Falls eine Umbenennung der Datei icudtvre gewünscht wird, muss das Tool renamepkg.bat benutzt werden.
Das Assembler-Source-Modul muss auf der Zielplattform assembliert und gelinkt werden.
Es kann entweder mit dem Nukleus verlinkt oder dynamisch geladen werden mit
RCA=name und
CFICU=(DATFILE=name).
In diesem Abschnitt sind die Natural-Profilparameter und Parameter-Makros aufgeführt, die im Zusammenhang mit der Unicode- und Codepage-Unterstützung benutzt werden.
Falls nicht anderes angegeben ist, werden die in diesem Abschnitt erwähnten Profilparameter und Makros in der Parameter-Referenz-Dokumentation ausführlich beschrieben.
| Parameter oder Makro | Beschreibung |
|---|---|
CFICU oder Makro NTCFICU
|
Aktiviert die Unicode-Unterstützung für verschiedene
Unicode-Einstellungen.
Siehe auch |
CMPO oder Schlüsselwort-Subparameter
CPAGE des Makros NTCMPO |
Generiert codepage-sensitive Natural-Programme.
Siehe auch
|
CP |
Definiert die Standard-Codepage für Natural.
Diese Codepage wird für die Laufzeit- und die Entwicklungsumgebung benutzt, falls die Angabe nicht mit einer Codepage überschrieben wird, die für ein einzelnes Objekt (z.B. ein Natural-Quellcode-Objekt) definiert ist. Es können nur Codepages benutzt werden, die zur Plattform passen. Das bedeutet, dass für eine Großrechner-Plattform keine ASCII-Codepage definiert werden kann. Falls eine falsche Codepage benutzt wird, erscheint bei der Initialisierung eine Fehlermeldung. Siehe auch |
CPCVERR |
Gibt an, ob eine Fehlermeldung angezeigt wird, wenn ein
Umsetzungsfehler bei folgenden Umsetzungen auftritt: von Unicode nach Codepage
oder von Codepage nach Unicode oder von einer Codepage in eine andere Codepage.
Dieser Parameter wird nicht bei der Umsetzung von Natural-Sourcen berücksichtigt, wenn diese in den Editierbereich geladen oder katalogisiert werden. Es wird nicht berücksichtigt, ob ein Unicode-Feld vor einer Eingabe/Ausgabe
über eine Terminalemulation in die Codepage umgesetzt wird. In diesem Fall wird
das durch ICU definierte Ersatzzeichen durch das in |
CPOBJIN |
Dient zur Angabe der Codepage, in der die Batch-Eingabedatei
codiert ist. Diese Datei ist im Dataset CMOBJIN definiert.
|
CPPRINT |
Dient zur Angabe der Codepage, in der die Batch-Ausgabedatei
codiert ist. Diese Datei ist im Dataset CMPRINT definiert.
|
CPSYNIN |
Dient zur Angabe der Codepage, in der die Batch-Eingabedatei
für Kommandos codiert ist. Diese Datei ist im Dataset CMSYNIN
definiert.
|
NTCPAGE-Makro
|
Dieses Makro definiert im Modul NATCONFG eine Codepage und alle zugehörigen
Informationen, z.B. Platzhalterzeichen, Locale ID und Collation Tables.
Siehe
auch Makro
|
OPRB oder NTOPRB-Makro
|
Dient zum Setzen der Optionen ACODE und/oder
WCODE zur Definition der Benutzer-Zeichencodierung, wenn die
benutzte Adabas-Datenbank für Universal Encoding Support (UES) freigegeben
ist.
|
PRINT oder
CP-Schlüsselwort-Parameter im Makro NTPRINT |
Definiert die Codepage für einen Report. |
SRETAIN |
Dient zur Angabe, dass alle existierenden Quellcode-Objekte in ihrem Original-Zeichencodierungsformat gespeichert werden müssen. Siehe auch Kundenspezifische Anpassung Ihrer Umgebung. |
Siehe auch:
Natural in Batch Mode in der Operations-Dokumentation.
Informationen zu gültigen Codepages siehe http://www.iana.org/assignments/character-sets.
Folgende Themen werden behandelt:
Eine ausführliche Beschreibung des Profilparameters CFICU und seiner Schlüsselwort-Subparameter
befindet sich in der Parameter-Referenz-Dokumentation. Einige der
Schlüsselwort-Subparameter haben Einfluss auf die Performance.
Wenn Collation Services zum Vergleichen von Unicode-Zeichenketten benutzt werden,
werden beide Zeichenketten untersucht, ob sie normalisiert sind oder nicht. Die Prüfung
selbst verbraucht viel CPU-Zeit. Wenn Sie sicher sind, dass die Zeichenketten bereits
normalisiert sind, können Sie die Prüfung ausschalten (COLNORM=OFF).
In Unicode ist es möglich, dasselbe Zeichen als einen Codepoint oder als eine
Kombination von zwei oder mehr Codepoints darzustellen. Beispielsweise kann das deutsche
Zeichen "ä" durch "U+00E4" oder
durch die Kombination der Codepoints "U+0061" und
"U+0308" dargestellt werden. Bei der Umwandlung von Unicode
nach beispielsweise IBM01140 werden Zeichen als einzelne Codepoints behandelt, d.h. es
wird ein "a" gefolgt von einem Ersatzzeichen erzeugt, weil
der Codepoint "U+0308" in der Ziel-Codepage nicht
repräsentiert ist. Die Einstellung CNVNORM=ON bewirkt, dass vor der eigentlichen
Umwandlung eine Normalisierung durchgeführt wird. Die Umwandlung verbraucht zusätzliche
CPU-Zeit und Zwischenspeicherplatz. Wenn Sie sicher sind, dass bei MOVE-Statements (außer MOVE NORMALIZED) keine
zusammengesetzten Zeichen beteiligt sind, sollten Sie CNVNORM auf
OFF setzen, um die Performance zu verbessern. Beachten Sie, dass alle
möglichen Kombinationen durch einen einzeln kodierten Unicode-Codepoint repräsentiert
werden.
Die Umwandlung von Unicode in Codepage und umgekehrt erfordert keine hohe Leistung.
Dies liegt daran, dass die ICU-Implementierung in C++ geschrieben ist, das nahezu alle
Unicode-, Codepage- und Sprachenaspekte in der Welt abdeckt. Manche Codepages können
jedoch über Umsetzungstabellen (Translation Tables) in Unicode (und umgekehrt)
abgebildet werden, um die Umwandlung zu beschleunigen. Mit dem
Schlüsselwort-Subparameter CPOPT des Profilparameters
CFICU werden zur Beschleunigung Accelerator Tables aktiviert.
Ist der Subparameter auf ON gesetzt, erstellt Natural unter Benutzung von
ICU-Konvertierungsfunktionen bei der Session-Initialisierung zwei Accelerator Tables.
Die erste Tabelle (mit einer Größe von 512 Bytes) wird für die Umwandlung von Codepage
in Unicode und die andere Tabelle (mit einer Größe von 65535 Bytes) für die Umwandlung
von Unicode in Codepage benutzt. Während der Natural-Session werden dann alle
Umwandlungen über Accelerator Tables statt mit ICU-Aufrufen ausgeführt. Accelerator
Tables werden nur für die Standard-Codepage (*CODEPAGE) verfügbar gemacht. Temporäre
Codepages (z.B. in MOVE
ENCODED-Statements) benutzen keine Accelerator Tables, wenn das
Modul NATCPTAB nicht verlinkt ist. Wenn es verlinkt ist, werden bis zu 30
auf der ICU-Datenbank basierende Accelerator Tables benutzt, um die Performance zu
beschleunigen.
Die Profilparameter CFICU und CP können Sie benutzen, um Natural für bestimmte
Zwecke anzupassen:
| Einstellungen | Beschreibung |
|---|---|
CFICU=OFF, CP=OFF |
Kompatibilitätsmodus, um existierende Anwendungen ohne
Unicode- und ohne Codepage-Unterstützung auszuführen.
Für die Umsetzung der
Ein- und Ausgaben werden herkömmliche Umsetzungstabellen verwendet. Im
Vergleich zu früheren Versionen tritt kein signifikanter Ressourcenverbrauch
(CPU-Zeit und Puffernutzung) auf. In diesem Modus braucht das ICS-Modul
|
CFICU=ON, CP=OFF |
Für neue Anwendungen, bei denen Unicode- und
Codepage-Umwandlung (MOVE
ENCODED), aber keine Standard-Codepage-Unterstützung
verwendet wird. Deshalb ist die Systemvariable *CODEPAGE leer.
Es ist möglich,
Variablen im Format U zu benutzen, aber es ist nicht möglich, z.B. |
CFICU=ON, CP=value
* |
Für neue Anwendungen, bei denen vollständige Unicode- sowie Codepage-Unterstützung verwendet wird. |
CFICU=OFF, CP=value
* |
Diese Kombination ist nicht sinnvoll, weil zur
Codepage-Unterstüzung ICU Services für die Umwandlung benötigt werden. Deshalb
wird in diesem Fall die Einstellung CFICU=ON erzwungen und bei der
Session-Initialisierung eine Meldung ausgegeben.
|
* dabei ist value ein beliebiger Wert ungleich
OFF.
Die Compiler-Option CPAGE erstellt Objekte, die mit einer anderen Codepage als
die zur Erstellungszeit verwendete Codepage ausgeführt werden können. Das bedeutet, dass
alle alphanumerischen Konstanten des Objekts, die in der zur Erstellungszeit verwendete
Codepage kodiert sind, in die Codepage umgesetzt werden müssen, die zur Ausführungszeit
aktiv ist. Um es dem Natural Object Loader zu ermöglichen, alphanumerische Konstanten zu
finden und umzusetzen, wird vom Compiler eine zusätzliche Tabelle erstellt. Dadurch
nimmt die Größe des generierten Objekts in Abhängigkeit von der Anzahl der verwendeten
alphanumerischen Konstanten zu. Die Umwandlung zur Laufzeit verbraucht zusätzliche
CPU-Zeit. Wenn die Standard-Codepage (Wert der Systemvariablen *CODEPAGE)
dieselbe ist wie die zur Erstellungszeit verwendete Codepage oder wenn die Session keine
Standard-Codepage hat (CP=OFF), wird keine Umwandlung durchgeführt.
Unabhängig von der Einstellung des Profilparameters CPCVERR werden Umsetzungsfehler ignoriert. Wenn
die Compiler-Option CPAGE auf OFF gesetzt ist, wird zur
Laufzeit keine Umwandlung durchgeführt und die alphanumerischen Konstanten werden so
behandelt, wie sie sind.
Das folgende Beispiel-Programm ist mit der Codepage IBM01141 (German) katalogisiert und wird mit der Standard-Codepage IBM01140 (us) ausgeführt. Die Zeichen "Ä", "Ö" und "Ü" sind in beiden Codepages definiert, jedoch an verschiedenen Codepoints.
Beispiel 1 - CPAGE=OFF:
OPTIONS CPAGE=OFF WRITE *CODEPAGE 'ÄÖÜ' END
Ausgabe mit Codepage IBM01140 (us):
Page 1
IBM01140 ¢\!
Beispiel 2 - CPAGE=ON:
OPTIONS CPAGE=ON WRITE *CODEPAGE 'ÄÖÜ' END
Ausgabe mit Codepage IBM01140 (us):
Page 1 IBM01140 ÄÖÜ
Am gebräuchlichsten für Codepage-Namen ist der IANA-Name. Deshalb enthält die
Systemvariable *CODEPAGE den IANA-Namen der
Standard-Codepage. Bei z/OS wird eine Codepage durch ihre Coded Character Set ID (CCSID)
qualifiziert. Adabas verwendet zurzeit die Entire Conversion Service Definition
(ADAECS).
Das Parameter-Makro NTCPAGE kann benutzt werden, um diese verschiedenen Namen
zu dem eindeutigen IANA-Namen zuzuweisen. NTCPAGE ist Teil des
Natural-Konfigurationsmoduls (NATCONFG). Es spielt keine Rolle, ob der IANA-Name, die
CCSID/CCSN oder der Aliasname beim Profilparameter CP angeben
wird. Der Aliasname kann ein benutzerdefinierter Name sein, der verwendet wird, um der
Codepage einen aussagefähigeren Namen zuzuweisen. In jedem Fall enthält die
Systemvariable *CODEPAGE den IANA-Namen der gewählten
Codepage.
Zusätzlich kann für eine Codepage ein Platzhalterzeichen definiert werden. Es
überschreibt das Standard-Ersatzzeichen der betreffenden Codepage, das normalerweise ein
nicht anzeigbarers Zeichen ist (z.B. H’3F’ in einer EBCDIC-Codepage). Das
Platzhalterzeichen kann benutzt werden, um zu vermeiden, dass nicht anzeigbarer Zeichen
an Terminals gesendet werden.
Beispiel:
NTCPAGE IANA=IBM01140,CCSID=1140,ECS=1140,ALIAS=’US’,PHC=003F
Die Werte IBM01140, 1140 oder US können mit dem
Profilparameter CP eingegeben werden, um die Codepage zu
aktivieren. Die Systemvariable *CODEPAGE enthält den Namen IBM01140. Das
Ersatzzeichen der Codepage wird durch "U+003F" ersetzt, was
ein Fragezeichen (?) ist
Die Anzahl der verfügbaren Codepages ist abhängig von der verwendeten ICU Data Library.
Alle im zurzeit verwendeten Datenpaket definierten Codepages können von Natural benutzt
werden. Ein Eintrag in NTCPAGE ist nur nötig, wenn ein alternativer
Aliasname oder ein alternatives Platzhalterzeichen gewünscht wird.
Beim Natural Development Server (NDV) steht der folgende Konfigurationsparameter zur Verfügung:
| Einstellung | Beschreibung |
|---|---|
TERMINAL_EMULATION=WEBIO
|
Gibt an, welcher Natural Web I/O Interface Client (der Unicode unterstützt) für die Ein- und Ausgabe benutzt wird. |
Die Codepage-Information des Objekts ist Teil des Objektverzeichnisses, das mit dem
Systemkommando LIST angezeigt werden kann. Weitere Informationen
siehe Directory-Informationen anzeigen in der
Systemkommandos-Dokumentation.
Die Zeichenkodierung von Codepage-Daten kann auf verschiedenen Ebenen angegeben werden.
Die Standard-Codepage kann mit dem Natural-Profilparameter CP (Name der
Standard-Codepage) angegeben werden.
Eine Codepage kann angegeben werden für: Natural-Quellcode-Objekte,
Batch-Eingabedateien (CPOBJIN - Codepage der Batch-Eingabedatei,
CPSYNIN -
Codepage der Batch-Eingabedatei für Kommandos) und Ausgabedateien (CPPRINT - Codepage der
Batch-Ausgabedatei).
Die Definition einer Codepage auf der Objektebene ist maßgeblich für das betreffende Objekt und hat dort Vorrang vor der Standard-Codepage.