Dieses Kapitel liefert einen Überblick über die allgemeinen Voraussetzungen und eine kurze Beschreibung der Funktionalitäten, die in Natural für die Implementierung einer Natural Remote Procedure Call-Umgebung (RPC-Umgebung) zur Verfügung stehen.
Die folgenden Themen werden behandelt:
Wenn die RPC-Umgebung auf verschiedenen Plattformen implementiert werden soll, werden die jeweils aktuellen Versionen von Natural for Mainframes, Windows, UNIX oder OpenVMS benötigt. Darüber hinaus sind die folgenden erforderlichen oder optionalen Produkte, Unterprodukte und Funktionalitäten für den Einsatz in einer Natural RPC-Umgebung verfügbar:
Produkt | Zweck |
---|---|
EntireX Communicator (EntireX Broker) | Der EntireX Broker des Software AG-Produkts EntireX Communicator stellt in der Regel die Middleware-Schicht zwischen dem Natural-Client und einem Natural-Server dar. Er verwendet das ACI-Protokoll und umfasst die entsprechenden Client/Server-Stubs. |
Entire Net-Work | Dieses Software AG-Produkt wird benötigt, wenn die von EntireX Broker verwendete Transportmethode Entire Net-Work ist. Dies ist die bevorzugte Transportmethode. |
TCP/IP | Erforderlich, wenn die vom EntireX Broker verwendete
Transportmethode TCP/IP ist.
Siehe auch TCP/IP als Transportmethode verwenden in Einrichten einer Natural RPC-Umgebung. |
EntireX Developer's Kit | Dieses Kit ist im Produkt EntireX Communicator enthalten und wird für die Unterstützung von Nicht-Natural-Programmiersprachen benötigt. |
Directory Services | Ein Remote Directory Server (RDS) ermöglicht es Ihnen, Directory-Definitionen an einem Ort zu definieren, so dass seine Dienste von allen Clients in einer RPC-Umgebung genutzt werden können. |
Natural Security | Optional.
Dieses Zusatzprodukt der Software AG wird auf der Server-Seite benötigt, um Natural RPC Server und -Dienste zu schützen, wenn die Security auf dem Client aktiv ist und auch umgekehrt. |
EntireX RPC | Optional.
Natural RPC unterstützt den EntireX RPC für 3GL vollständig. EntireX RPC ist im Produkt EntireX Communicator enthalten. |
EntireX Security | Optional.
Natural RPC unterstützt EntireX Security sowohl auf der Client- als auch auf der Server-Seite vollständig. EntireX Security ist im Produkt EntireX Broker enthalten. |
Hinweise, wie Sie Informationen zu den unterstützten Software AG-Produktversionen erhalten, finden Sie unter Verfügbare und unterstützte Software AG-Produktversionen in der Freigabemitteilung (Release Notes).
Informationen zu anderen Produkten, die in einer Natural RPC-basierten Umgebung eingesetzt werden können, finden Sie in der entsprechenden Produktdokumentation.
Die folgenden Natural-Statements werden bei der Erstellung einer Natural RPC-Umgebung verwendet:
Im Abschnitt Grenzen und Einschränkungen finden Sie in den Abschnitten Reaktionen der Natural-Statements und Hinweise zu Natural-Statements auf dem Server Informationen darüber, was Sie über ein abweichendes Verhalten dieser Statements wissen sollten, wenn sie in einer Natural RPC-Umgebung verwendet werden.
Die folgenden Natural-Utilities werden bei der Erstellung und Pflege einer Natural RPC-Umgebung verwendet:
Diese Utility wird für die Pflege von Remote-Procedure-Call-Umgebungen verwendet.
Diese Utility dient zum Auffinden und Testen von
Natural-Anwendungsprogrammierschnittstellen (APIs, siehe unten), die in der
aktuellen System Library SYSEXT
enthalten sind.
Auf Großrechnern dient diese Utility zur Erstellung und Pflege eines Satzes von Natural-Profilparametern, der unter einem Profilnamen gespeichert wird.
Configuration Utility
Unter Windows, UNIX und OpenVMS wird diese Utility verwendet, um globale und lokale Konfigurationsdateien zu ändern und Parameterdateien zu erstellen oder zu ändern.
Natural Anwendungsprogrammierschnittstellen (APIs) können verwendet
werden, um Informationen abzurufen oder zu ändern oder Dienste zu nutzen, die
nicht über Natural-Statements zugänglich sind. Die für die Verwendung beim
Natural RPC vorgesehenen Anwendungsprogrammschnittstellen befinden sich in der
Natural Library SYSEXT
.
Weitere Informationen siehe Kapitel APIs zur Verwendung beim Natural RPC.
Dieser Abschnitt beschreibt die spezifische Abbildung (Mapping) von Software AG IDL-Datentypen, -Gruppen, -Arrays und -Strukturen auf die Programmiersprache Natural. Bitte beachten Sie auch die Anmerkungen und Hinweise zu den IDL-Datentypen, die für alle Sprachbindungen gelten und in der Software AG IDL-Datei (in der EntireX-Dokumentation) zu finden sind.
In der folgenden Tabelle werden die folgenden Metasymbole und informellen Begriffe für die IDL verwendet.
Die Metasymbole [
und ]
umschließen
optionale lexikalische Einheiten.
Der informelle Begriff number (oder in manchen Fällen number.number) ist eine Folge von numerischen Zeichen, zum Beispiel 123.
Software AG IDL | Beschreibung | Natural-Datenformat | Anmerkung |
---|---|---|---|
Anumber | Alphanumerisch | Anumber | |
AV | Alphanumerisch, variable Länge | A DYNAMIC | |
AVnumber | Alphanumerisch, variable Länge mit maximaler Länge | A DYNAMIC | |
Bnumber | Binär | Bnumber | |
BV | Binär, variable Länge | B DYNAMIC | |
BVnumber | Binär, variable Länge mit maximaler Länge | B DYNAMIC | |
D | Datum | D | 3,5 |
F4 | Fließkomma (klein) | F4 | 2 |
F8 | Fließkomma (groß) | F8 | 2 |
I1 | Ganzzahl (klein) | I1 | |
I2 | Ganzzahl (mittel) | I2 | |
I4 | Ganzzahl (groß) | I4 | |
Knumber | Kanji | Anumber | 1 |
KV | Kanji, variable Länge | A DYNAMIC | 1 |
KVnumber | Kanji, variable Länge mit maximaler Länge | A DYNAMIC | 1 |
L | Logisch | L | |
Nnumber[.number] | Ungepackte Dezimalzahl | Nnumber[.number] | |
NUnumber[.number] | Ungepackte Dezimalzahl ohne Vorzeichen | Nnumber[.number] | |
Pnumber[.number] | Gepackte Dezimalzahl | Pnumber[.number] | |
PUnumber[.number] | Gepackte Dezimalzahl ohne Vorzeichen | Pnumber[.number] | |
T | Zeit | T | 3,4 |
Unumber | Unicode | Unumber | |
UV | Unicode, variable Länge | U DYNAMIC | |
UVnumber | Unicode, variable Länge mit maximaler Länge | U DYNAMIC |
Siehe auch Hinweise und Einschränkungen zu den IDL-Datentypen der Software AG (in der EntireX-Dokumentation), die für alle Sprachbindungen gelten.
Der Datentyp K ist ein RPC-spezifisches Datenformat, das nicht Teil der Natural-Sprache ist.
Bei der Verwendung von Fließkomma-Datentypen kann es zu Rundungsfehlern kommen, so dass die Werte von Sendern und Empfängern leicht voneinander abweichen können. Dies gilt insbesondere, wenn Client und Server unterschiedliche Darstellungen für Fließkommadaten verwenden (IEEE, HFP).
Anzahl der Tage AD (anno domini, nach Christi Geburt). Der gültige Bereich reicht von 1.1.0001 bis zum 28.11.2737. Die Zuordnung (Mapping) der Zahl zum Datum im gesamten Bereich ab 1.1.0001 erfolgt nach dem Julianischen und Gregorianischen Kalender unter Berücksichtigung der folgenden Regeln:
Jahre, die geradzahlig durch 4 teilbar sind, sind Schaltjahre.
Jahre, die geradzahlig durch 100 teilbar sind, sind keine Schaltjahre, es sei denn, Regel 3 (siehe unten) ist zutreffend.
Jahre, die geradzahlig durch 400 teilbar sind, sind Schaltjahre.
Vor dem Jahr 1582 n. Chr. wird die Regel 1 des Julianischen Kalenders angewendet. Nach dem Jahr 1582 n. Chr. werden die Regeln 1, 2 und 3 des gregorianischen Kalenders angewandt.
In der folgenden Tabelle finden Sie die Beziehung zwischen der gepackten Zahl und einem realen Datum:
Datum / Datumsbereich | Wert / Wertebereich |
---|---|
1.1.0000 | 0 (spezieller Wert - kein Datum) |
nicht definierte Daten | 1 - 364 (nicht verwenden) |
1.1.0001 | 365 |
1.1.1970 | 719527 (Beginn der C-Zeitfunktionen) |
28.11.2737 | 999999 (maximales Datum) |
Zählung von Zehntelsekunden AD (anno domini, nach Christi Geburt). Der gültige Bereich reicht von 1.1.0001 00:00:00.0 bis 16.11.3168 9:46:39 plus 0,9 Sekunden. In der folgenden Tabelle finden Sie das Verhältnis zwischen der gepackten Zahl und einer realen Zeit:
Zeit / Zeitbereich | Wert / Wertebereich |
---|---|
1.1.0000 00:00:00.0 | 0 (spezieller Wert - kein Datum) |
nicht definierte Zeiten | 1 - 315359999 |
1.1.0001 00:00:00.0 | 315360000 |
1.1.1970 00:00:00.0 | 621671328000 (Beginn der C-Zeitfunktionen) |
Die Beziehung zwischen der gepackten Zahl eines Datums- und Zeit-Datentyps ist wie folgt:
Zehntel einer Sekunde pro Tag = 24*60*60*10 = 864000
Zahl der Zeit | = Zahl des Datums | * 864000 |
315360000 | = 365 | * 864000 1.1.0001 00:00:00.0 |
621671328000 | = 719527 | * 864000 1.1.1970 00:00:00.0 |
Zahl des Datums | = Zahl der Zeit | / 864000 |
365 | = 315360000 | / 864000 1.1.0001 |
719527 | = 621671328000 | / 864000 1.1.1970 |
Der Bibliotheksname, wie er in der IDL-Datei angegeben ist, wird
von Natural nicht unterstützt. Standardmäßig sendet ein Natural-Client den
Library-Namen SYSTEM
an den Server. Um einen anderen Library-Namen
als SYSTEM
von einem Client an einen Server zu senden, sind für
den Client die folgenden Schritte erforderlich:
Um einen anderen Library-Namen als SYSTEM
von
einem Client an einen Server zu senden:
Aktivieren Sie auf dem Client die Logon-Option.
Rufen Sie die Anwendungsprogrammierschnittstelle
USR4008N
auf, um den
Namen der Library anzugeben, andernfalls wird der Name der aktuellen Library
gesendet.
Die Länge des Library-Namens ist auf 8 Zeichen begrenzt. Die Länge des Library-Namens ist auf 8 Zeichen begrenzt.
Der Programmname wird von einem Client an den Server gesendet. Sonderzeichen werden nicht ersetzt. Der Programm-Aliasname wird nicht an den Server gesendet.
Das generierte Natural-Interface-Objekt hat denselben Namen.
Im RPC-Server wird der gesendete IDL-Programmname zum Auffinden des Natural-Subprogramms verwendet.
Die Länge des Programmnamens ist auf 8 Zeichen begrenzt.
Die Parameternamen, die in der Parameter-Daten-Definition der IDL-Datei angegeben sind, werden im generierten Natural-Interface-Objekt durch künstliche Namen ersetzt.
Siehe parameter-data-definition im Abschnitt Software AG IDL Grammar in der EntireX-Dokumentation.
Feste Arrays innerhalb der IDL-Datei werden auf feste Natural Fixed Arrays abgebildet. Die untere Grenze wird auf 1 gesetzt und die obere Grenze wird auf die in der IDL-Datei angegebene obere Grenze gesetzt.
Informationen über die Syntax zur Beschreibung Fixed Arrays in der IDL-Datei siehe array-definition und fixed-bound-array-index (im Abschnitt Software AG IDL Grammar in der EntireX-Dokumentation).
Unbounded Arrays innerhalb der IDL-Datei werden auf Natural X-Arrays abgebildet. Die untere Grenze ist immer fest und auf 1 gesetzt.
Siehe die array-definition (im Abschnitt Software AG IDL Grammatik in der EntireX-Dokumentation) für die Syntax von nichtbegrenzten Arrays innerhalb der IDL-Datei und siehe unbounded-array-index.
Anmerkung:
Natural Variable Arrays (Natural Notation
(../1:V)
) können auf der Natural RPC Server-Seite anstelle von
Natural Fixed Arrays oder X-Arrays verwendet werden. Ein RPC-Client kann
entweder ein IDL Fixed Array oder ein IDL Unbounded Array an einen Natural RPC
Server mit einem solchen Natural Variable Array übergeben. Im RPC-Server kann
das Variable Array nicht in der Größe verändert werden. Das bedeutet, dass die
Anzahl der Array-Ereignisse nicht verändert werden kann und der Natural RPC
Server immer die gleiche Anzahl an Ausprägungen zurückgibt.
Gruppen in der IDL-Datei werden auf Natural-Gruppen abgebildet. Die Syntax für die Beschreibung von Gruppen in der IDL-Datei finden Sie unter group-parameter-definition (im Abschnitt Software AG IDL Grammar in der EntireX-Dokumentation).
Strukturen innerhalb der IDL-Datei werden auf Natural-Gruppen abgebildet. Die Syntax für die Beschreibung von Strukturen in der IDL-Datei finden Sie unter structure-definition (im Abschnitt Software AG IDL Grammar in der EntireX-Dokumentation).
Die IDL-Syntax erlaubt es, Parameter als IN-Parameter, OUT-Parameter oder INOUT-Parameter zu definieren (INOUT ist der Standard, wenn nichts angegeben wird). Diese Richtungsangabe wird von Natural wie folgt wiedergegeben:
Parameter mit dem OUT
-Attribut
werden vom RPC-Client an den RPC-Server gesendet. Sie werden immer mit der
Call-by-Reference-Methode bereitgestellt.
Parameter mit dem IN
-Attribut
werden vom RPC-Server an den RPC-Client gesendet. Sie werden immer mit der
Call-by-Reference-Methode bereitgestellt.
Parameter mit dem
INOUT
-Attribut werden vom RPC-Client an den
RPC-Server und dann zurück an den RPC-Client gesendet.
Nur die Richtungsinformation der Top-Level-Felder (Level 1) ist relevant. Gruppenfelder erben immer die Spezifikation von ihrem übergeordneten Feld. Eine andere Spezifikation wird ignoriert.
Siehe attribute-list (im Abschnitt Software AG IDL Grammar in der EntireX-Dokumentation) für die Syntax zur Beschreibung von Attributen innerhalb der IDL-Datei und siehe direction-attribute.
Anmerkung:
Wenn Sie in der Natural-Utility SYSRPC
ein
Interface-Objekt-Layout definieren, ist die
Bedeutung
der Richtungsattribute IN
und
OUT
gegenüber der IDL vertauscht:
IN
in SYSTRPC
ist
OUT
in IDL
OUT
in SYSTRPC
ist
IN
in IDL
Das ALIGNED
-Attribut ist für die
Programmiersprache Natural nicht relevant. Ein Natural-Client kann jedoch das
ALIGNED
-Attribut an einen RPC-Server senden, wo
es eventuell benötigt wird. Dazu benötigen Sie ein Natural-Interface-Objekt,
das aus einer IDL-Datei generiert wurde.
Siehe attribute-list (im Abschnitt Software AG IDL Grammar in der EntireX-Dokumentation) für die Syntax der Attribute in der IDL-Datei und siehe aligned-attribute.
Die IDL-Syntax erlaubt nur die Definition von Prozeduren. Sie kennt nicht das Konzept der Function. Eine Function ist eine Prozedur, die neben den Parametern auch einen Wert zurückgibt. Prozeduren und Functions sind zwischen Client und Server transparent. Das bedeutet, dass ein Client, der eine Function verwendet, einen Server aufrufen kann, der als Prozedur implementiert ist, und umgekehrt.
Der Natural RPC unterstützt keine Functions.