Ab Natural Version 5 sind generierte Natural-Programme (GPs) auf alle UNIX-, OpenVMS- und Windows-Plattformen portierbar.
Dieses Dokument behandelt folgende Themen:
Ab Natural Version 5 ist eine Source, die auf einer von Natural unterstützten UNIX-, OpenVMS- oder Windows-Plattform katalogisiert wurde, auf allen von Natural unterstützten Open-Systems-Plattformen ohne Neu-Kompilierung ausführbar.
Natural-Anwendungen, die mit Natural Version 4 or Natural Version 3 erstellt wurden, können mit Natural Version 5 oder höher ausgeführt werden, ohne dass diese Anwendungen erneut katalogisiert werden müssen (Aufwärtskompatibilität). In diesem Fall ist die portierbare GP-Funktionalität nicht verfügbar. Um diese Funktionalität und andere Verbesserungen nutzen zu können, ist das Katalogisieren mit Natural Version 5 oder höher erforderlich.
Kommandoprozessor-GPs sind nicht portierbar. Das GP-Portierbarkeitsmerkmal steht nicht für Großrechnerplattformen zur Verfügung. Das bedeutet, dass die auf Großrechnern erstellten GPs nicht ohne Neu-Kompilierung auf UNIX-, OpenVMS- und Windows-Plattformen und umgekehrt ausgeführt werden können.
Ab Natural Version 5 verhält sich Natural folgendermaßen: Je nachdem, auf welcher UNIX-, OpenVMS- oder Windows-Plattform Natural läuft, berücksichtigt es die Byte-Reihenfolge, in der mehrere Bytes umfassende Zahlen im GP gespeichert werden. Die Formate mit Zwei-Byte-Reihenfolge werden als "Little Endian" und "Big Endian" bezeichnet.
"Little Endian" bedeutet, dass das niederwertige Byte der Zahl unter der niedrigsten Adresse und das höherwertige Byte unter der höchsten Adresse im Speicher abgelegt werden (zuerst kommt der Little Endian).
"Big Endian" bedeutet, dass das höherwertige Byte der Zahl unter der niedrigsten Adresse im Speicher abgelegt wird (zuerst kommt der Big Endian).
Die UNIX-, OpenVMS- und Windows-Plattformen verwenden beide Endian-Formate: Intel-Prozessoren und AXP-Computer verwenden die "Little-Endian"-Byte-Reihenfolge, andere Prozessoren wie HP-UX, Sun Solaris oder RS6000 verwenden das "Big-Endian"-Format.
Falls erforderlich, wandelt Natural ein portierbares GP automatisch in das Endian-Format der Ausführungsplattform um. Diese Endian-Umwandlung erfolgt nicht, wenn das GP schon im Endian-Format der Plattform erzeugt worden ist.
Um die Performance bei der Ausführung von portablen GPs zu erhöhen,
wurde der Natural-Profilparameter ENDIAN eingeführt.
ENDIAN bestimmt das Endian-Format, in dem ein GP bei der
Kompilierung generiert wird.
| DEFAULT | Das Endian-Format der Maschine, auf der das GP generiert wird. |
|---|---|
| BIG | Big-Endian-Format (höherwertiges Byte zuerst). |
| LITTLE | Little-Endian-Format (niederwertiges Byte zuerst). |
Die Werte DEFAULT, BIG und LITTLE
können alternativ angegeben werden, wobei DEFAULT der Standardwert
ist.
Der ENDIAN-Parameter kann folgendermaßen gesetzt
werden:
als Profilparameter in der Natural Configuration Utility,
als Startup-Parameter,
als Session-Parameter oder mit dem Systemkommando
GLOBALS.
Um portierbare GPs auf verschiedenen Plattformen (UNIX, OpenVMS- und Windows) verwenden zu können, müssen die generierten Natural-Objekte auf die Zielplattform übertragen werden oder sie müssen von der Zielplattform aus erreichbar sein, z.B. über NFS.
Für die Verteilung von Natural-GPs oder von ganzen Natural-Anwendungen wird der Natural Object Handler empfohlen. Dabei werden die Objekte in der Source-Umgebung in ein Work File geladen, danach das Work File in die Zielumgebung übertragen und dann die Objekte aus dem Work File entladen.
Um Ihre generierten Natural-Objekte über Open-Systems-Plattformen zu
verteilen
Starten Sie den Natural Object Handler. Laden Sie alle gewünschten katalogisierten Objekte in ein Work File des Typs PORTABLE.
Falls Fehlermeldungen benötigt werden, können diese ebenfalls in das Work File geladen werden.
Wichtig:
Der angegebene Work-File-Typ muss PORTABLE sein, weil Natural
bei diesem Typ eine automatische ENDIAN-Formatumwandlung eines Work Files
vornimmt, wenn dieses auf eine andere Maschine übertragen wird. Siehe auch
Informationen zum Work-File-Typ in der
Beschreibung des DEFINE WORK
FILE-Statements in der
Statements-Dokumentation.
Übertragen Sie das Work File in die Zielumgebung. Je nach Übertragungsmedium (Netzwerk, CD, Diskette, Band, Email, Download usw.) kann es sinnvoll sein, ein komprimiertes Archiv (z.B. ZIP-Datei) oder eine Codierung/Decodierung (z.B. mit UUENCODE/UUDECODE) vorzunehmen. Beim Kopieren per FTP muss die Übertragungsart binär sein.
Anmerkung:
Je nach verwendetem Übertragungsverfahren kann es nötig, sein, das
Record-Format und die Attribute oder die Blockgröße des zu übertragenen Work
Files an die Zielumgebungsplattform anzupassen, bevor die Ladefunktion benutzt
wird. Das Work File sollte auf der Zielplattform dasselbe Format und dieselben
Attribute haben wie ein Work File desselben Typs, das auf der Zielplattform
selbst erstellt wurde. Falls eine Anpassung nötig sein sollte, können Sie dazu
Betriebssystem-Tools benutzen.
Starten Sie den Natural Object Handler in der Zielumgebung. Als Work-File-Typ wählen Sie PORTABLE. Laden Sie die Natural-Objekte und -Fehlermeldungen aus dem Work File.
Weitere Informationen zur Benutzung des Natural Object Handler finden Sie im Teil Object Handler in der Utilities-Dokumentation.
Weitere Informationen, wie Sie eine Anwendung von einer Natural-Entwicklungs-Workstation auf eine Natural-Laufzeit-Workstation portieren können, finden Sie im Abschnitt Porting Procedure Overview in der Operations-Dokumentation.
Außer dem oben beschriebenen bevorzugten Verfahren gibt es noch verschiedene andere Möglichkeiten, um Natural-GPs oder sogar ganze Libraries oder Teile davon mittels Betriebssystem-Tools und verschiedenen Übertragungsverfahren zu verschieben oder zu kopieren. Damit die Objekte unter Natural ausführbar sind, müssen sie in all diesen Fällen in die Natural-Systemdatei FUSER importiert werden, damit die FILEDIR.SAG-Struktur angepasst wird. Informationen zu Verzeichnis FNAT bzw. FUSER finden Sie im Abschnitt System Files FNAT and FUSER in der Operations-Dokumentation.
Sie können eines der folgenden Verfahren anwenden:
Sie können die Import-Funktion der Natural-SYSMAIN-Utility benutzen.
Sie können die FTOUCH-Utility benutzen. Diese Utility können Sie außerhalb von Natural aufrufen und benutzen.
Darüber hinaus können Sie auch Dateien vom Windows Explorer in die Natural-Umgebung importieren, indem Sie Drag-and-Drop oder die Menübefehle , und benutzen. Das heißt, wenn Sie Zugriff auf die Natural-Objekte haben, die Sie über den Windows Explorer importieren wollen, können Sie Drag-and-Drop oder , und benutzen, und die FILEDIR.SAG-Datei wird dabei automatisch aktualisiert. Weitere Informationen zum Kopieren, Verschieben und Importieren von Objekten finden Sie im Abschnitt Natural-Objekte verwalten in der Dokumentation Natural Studio benutzen.
Dasselbe gilt, wenn der direkte Zugriff von einer Zielplattform auf generierte Objekte in einer solchen Umgebung möglich ist, z.B. über NSF, Netwerk-File-Server usw. In diesem Fall müssen die Objekte ebenfalls importiert werden.
Ab Natural Version 6.2 sind die Datei FILEDIR.SAG und die Fehlermeldungsdateien plattformunabhängig. Somit ist es möglich, FUSER-Systemdateien gemeinsam von unterschiedlichen Open-Systems-Plattformen aus zu nutzen. Zum Beispiel ist es möglich, unter Verwendung von Kopierfunktionen des Betriebssystems mehrere Natural-Libraries von einer Open-Systems-Plattform zu einer anderen zu kopieren. Die gemeinsame Nutzung von FNAT-Systemdateien wird jedoch nicht empfohlen. Weitere Informationen zur portierbaren FILEDIR.SAG-Datei finden Sie im Abschnitt Portable Natural System Files in der Operations-Dokumentation.
