Folgende Themen werden behandelt:
Es gibt keinen Einfluss von Unicode auf existierende Anwendungen. Das bedeutet, das
existierende Natural-Anwendungen ohne Änderungen ausgeführt werden sollten. Vergewissern
Sie sich, dass die Profilparameter CFICU und CP auf OFF gesetzt sind. In diesem
Fall ist es nicht nötig, irgendwelche Komponenten zu installieren, die mit den
ICU for Adabas & Natural (ICS) geliefert werden. Es wurden
lediglich die Ein-/Ausgabepuffer deutlich vergrößert, da die Attribute verbessert wurden,
um potenzielle Unicode-Felder zu unterstützen. Wenn CPauf
OFF gesetzt ist, wird der Inhalt der Systemvariablen *CODEPAGE
gelöscht und die vertrauten Umsetzungstabellen (z.B. Standard-Tabelle und alternative
Tabelle) werden weiterhin für Ein-/Ausgabe-Umsetzungen benutzt.
Natural wurde so erweitert, dass die Codepage-Informationen auf mehreren Ebenen definiert werden können:
Der Natural-Profilparameter CP definiert die Natural-Standard-Codepage.
Bei manchen Objekten (Natural-Quellcode-Objekt, Natural-Batch-Ein-/Ausgabedateien, Print Reports, Adabas-Dateien) kann eine objektspezifische Codepage definiert werden.
Wenn weder eine objektspezifische Codepage noch eine Standard-Codepage definiert ist
(d.h., es gilt die Einstellung CP=OFF), führt Natural keine
Umwandlung von Daten durch.
Da es nicht möglich ist, die korrekte Codepage automatisch zu identifizieren, ist es wichtig, dass Sie die erforderliche Codepage selbst angeben. Dabei sind folgende Szenarien möglich:
| Status | Aufwand | Maßnahme |
|---|---|---|
| Alle Daten liegen in der Codepage des Betriebssystems vor. | Keiner. | Keine. |
| Alle Daten werden mit einer Codepage gespeichert, aber diese Codepage unterscheidet sich von der Codepage des Betriebssystems. | Einfach. | Im Natural-Profilparameter CP muss die korrekte Codepage angegeben
sein. Vergewissern Sie sich, dass das Ein-/Ausgabegerät diese Codepage
unterstützt. Bei der Einstellung CP=AUTO läuft Natural
zwangsweise mit der Codepage des Ein-/Ausgabegeräts.
|
| Die Daten liegen in unterschiedlichen Codepages vor. | Abhängig von der Anzahl der Codesources und Codepages. | Die korrekte Codepage muss bei jedem Natural-Objekt angegeben werden: |
| Verschiedene Codepages sind in einem Objekt gemischt vorhanden (zum Beispiel in einer Source). | Hoch | Das Objekt muss im entsprechenden Codepage-Format neu geschrieben werden. |
Quellcode-Objekte, die mit früheren Natural-Versionen gespeichert
(SAVE) oder gespeichert und katalogisiert
(STOW) worden sind, haben keine Codepage-Informationen. Das
Codepage-Feld des Verzeichnisse (Directory) ist leer.
Da Natural-Quellcode-Objekte nicht in Unicode-Format gespeichert werden, muss das
Quellcode-Objekt in die Standard-Codepage (Wert der Systemvariablen *CODEPAGE)
umgesetzt werden, die für die Session gilt. Wenn die Codepage-Unterstützung abgeschaltet
ist (CP=OFF), wird die Codepage-Information des Quellcode-Objekts
ignoriert und es erfolgt keine Umwandlung. Alphanumerische Konstanten müssen an die
Standard-Codepage angepasst werden, wenn sie in den Quellcode-Bereich
geladen werden.
Da Natural-Quellcode-Objekte nicht in Unicode-Format gespeichert werden, müssen
alphanumerische Konstanten beim Start des Objekts an die Standard-Codepage angepasst
werden. Dies kann mit der Compiler-Option CPAGE erreicht werden. Wenn CPAGE auf
ON gesetzt ist, wird eine zusätzliche Tabelle in das Objekt generiert. Der
Natural Loader benutzt diese Tabelle, um jede alphanumerische Konstante in die
Standard-Codepage umzusetzen (Wert der Systemvariablen *CODEPAGE). Je
nach Anzahl an alphanumerischen Konstanten erhöht die zusätzliche Tabelle die Größe des
resultierenden Objekts und die Umwandlung verbraucht zusätzliche CPU-Zeit.
Es ist wichtig, dass abhängige Objekte (z.B. ein Programm und ein lokaler Datenbereich (LDA), der von dem Programm benutzt wird) die gleiche Codepage benutzen. Wenn abhängige Objekte unterschiedliche Codepages benutzen, sollte sichergestellt werden, dass die verwendeten Zeichen (z.B. "#") in den benutzten Codepages auf dieselben Codepoints abgebildet werden. Die folgenden Objekte haben keine zugehörige objektspezifische oder datenspezifische Codepage:
Datendefinitionsmodule (DDMs),
Predict Rules,
Predict XRef Data.
Es ist Vorsicht geboten, wenn solche Daten in Objekten benutzt oder von Objekten erzeugt
werden, für die eine spezifische Codepage angegeben worden ist. Wenn die Anwendung selbst
nicht notwendigerweise Codepage-fähig sein muss, und wenn Sie wollen, dass die Anwendung
in Hinblick auf zu verarbeitende Daten Codepage-sensibel ist, sollten Sie den Wert
(ON,EXCEPTNEW) beim Profilparameter SRETAIN in Betracht ziehen.
Existierende Anwendungen lassen sich leicht mit neuem, auf dem Format U basierendem Quellcode auf Unicode-Unterstützung erweitern. Für das Format U müssen (im Vergleich zum Format A) die folgenden Regeln berücksichtigt werden:
Eine Redefinition des Formats U in ein Format ungleich U unter Benutzung des
REDEFINE-Statements
sollte vermieden werden, weil es zu gespaltenen Zeichen führen kann.
Das Format U ist Endian-abhängig. Dies muss beim Übertragen (MOVE)
zwischen den Formaten B und U berücksichtigt werden.
Denken Sie daran, dass beim Übertragen (MOVE) von U nach A Daten
verloren gehen können.
Wenn Sie das Format existierender Felder von A nach U ändern wollen, müssen Sie folgenden Regeln beachten:
Code, der eine spezifische Zeichencodierung von Zeichenketten voraussetzt, muss geändert werden (zum Beispiel durch Vergleich mit einem Feld im Format B).
Alle REDEFINE-Statements
des Feldes müssen auf Gültigkeit geprüft werden.
Ein REDEFINE nach N ist nicht möglich (d.h., Sie erhalten nicht das
erwartete Ergebnis).
Das Datenbankfeld muss nach Unicode migriert werden (vorausgesetzt, das wird von Ihrer Datenbank unterstützt).
Es ist möglich, dass Sie die Länge des Feldes ändern müssen: Wenn ein Feld im Format A BDCS-Zeichen enthält, dann ist beim Feld im Format U nur die halbe Länge erforderlich.
Der Profilparameter CP
wird in Verbindung mit dem Parameter-Makro NTCPAGE (im Source-Modul NATCONFG) benutzt, um den Namen der Standard-Codepage für
Natural-Daten anzugeben oder automatisch den Codepage-Namen vom Benutzer-Terminal zu
nehmen.
Der Schlüsselwort-Subparameter CPRPC wird beim Profilparameter RPC und dem
entsprechenden Makro NTRPC benutzt.
