Migration existierender Anwendungen

#### Search Results

Search

# Migration existierender Anwendungen

Folgende Themen werden behandelt:

- Einfluss von Unicode auf existierende Anwendungen

- Existierende Objekte migrieren

- Existierende Anwendungen auf Unicode-Unterstützung erweitern

- Migration von Natural Remote Procedure Calls (RPC)

## Einfluss von Unicode auf existierende Anwendungen

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 International Components for Unicode for Software AG (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 `CP`auf `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.

## Existierende Objekte migrieren

Natural wurde so erweitert, dass die Codepage-Informationen auf mehreren Ebenen definiert werden können:

- Der Natural-Profileparameter `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 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: Sources Speicher Sie jedes Objekt in der Session mit der korrekten Codepage. Batch Files Setzen Sie im Natural-Profilparameter `CPOBJIN`, `CPSYNIN` und `CPPRINT` die korrekte Codepage. Adabas Files (ECS-fähig) Setzen Sie im Natural-Profilparameter `OPRB` die Option `ACODE`.
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 alpahnumerische 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 auf Unicode-Unterstützung erweitern

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.

## Migration von Natural Remote Procedure Calls (RPC)

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.

### On this page

- Einfluss von Unicode auf existierende Anwendungen
- Existierende Objekte migrieren
- Existierende Anwendungen auf Unicode-Unterstützung erweitern
- Migration von Natural Remote Procedure Calls (RPC)