Voraussetzungen und vorbereitende Informationen

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:


Beteiligte Produkte

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.

Verwendete Natural-Statements

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.

Natural-Utilities zur Verwendung mit Natural RPC

Die folgenden Natural-Utilities werden bei der Erstellung und Pflege einer Natural RPC-Umgebung verwendet:

  • SYSRPC

    Diese Utility wird für die Pflege von Remote-Procedure-Call-Umgebungen verwendet.

  • SYSEXT

    Diese Utility dient zum Auffinden und Testen von Natural-Anwendungsprogrammierschnittstellen (APIs, siehe unten), die in der aktuellen System Library SYSEXT enthalten sind.

  • SYSPARM

    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.

Anwendungsprogrammierschnittstellen zur Verwendung beim Natural RPC

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.

Abbildung (Mapping) von Software AG IDL auf Natural

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.

Abbilden der IDL-Datentypen der Software AG auf Natural-Datenformate

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.

Anmerkungen:

  1. Der Datentyp K ist ein RPC-spezifisches Datenformat, das nicht Teil der Natural-Sprache ist.

  2. 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).

  3. 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:

    1. Jahre, die geradzahlig durch 4 teilbar sind, sind Schaltjahre.

    2. Jahre, die geradzahlig durch 100 teilbar sind, sind keine Schaltjahre, es sei denn, Regel 3 (siehe unten) ist zutreffend.

    3. Jahre, die geradzahlig durch 400 teilbar sind, sind Schaltjahre.

    4. 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)
  4. 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)
  5. 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

Abbilden von Bibliotheksname und Alias

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:

Beginn der AnweisungslisteUm einen anderen Library-Namen als SYSTEM von einem Client an einen Server zu senden:

  1. Aktivieren Sie auf dem Client die Logon-Option.

  2. 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.

Abbilden von Programmname und Alias

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.

Abbilden von Parameternamen

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.

Abbilden von Fixed und Unbounded Arrays

  • 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.

Abbilden von Gruppen und periodischen Gruppen

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).

Abbilden von Strukturen

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).

Abbilden der Richtungsattribute IN, OUT, INOUT

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

Abbilden des ALIGNED-Attributs

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.

Aufrufen von Servern als Prozeduren oder Functions

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.

Client- und Server-Seite

Der Natural RPC unterstützt keine Functions.