Einführung in Natural RPC

#### Search Results

Search

# Einführung in Natural RPC

Dieses Kapitel behandelt die folgenden Themen:

- Allgemeine Informationen zum Natural RPC

- Natural RPC-Betrieb im nicht-konversationellen Modus

- Natural RPC-Betrieb im konversationellen Modus

- Konversationeller versus nicht-konversationeller Modus

- Datenbank-Transaktionen

- Behandlung der mit den Profilparametern LT, MAXCL, MADIO und MT gesetzten Limits auf dem Server

- Ort der Konversationen

- Natural RPC-Terminologie

## Allgemeine Informationen zum Natural RPC

- Zweck des Natural RPC

- Vorteile von Natural RPC-Aufrufen

- Natural RPC-Betriebsarten

- Verfügbarkeit auf verschiedenen Plattformen

- Unterstützung von Nicht-Natural-Umgebungen (EntireX RPC)

### Zweck des Natural RPC

Der Natural Remote Procedure Call (RPC) ermöglicht es einem Natural-Client-Programm ein `CALLNAT`-Statement abzusetzen, um ein Subprogramm in einem Natural-Server aufzurufen. Die Natural-Client- und Server-Sitzungen können auf demselben oder auf einem anderen Computer laufen. So kann beispielsweise ein Natural-Client-Programm auf einem Windows-Computer ein `CALLNAT`-Statement an einen Großrechner-Server senden, um Daten aus einer Großrechner-Datenbank abzurufen. Derselbe Windows-Computer kann als Server fungieren, wenn ein Natural-Client-Programm, das z. B. unter UNIX läuft, ein `CALLNAT`-Statement absetzt, um Daten von diesem Natural-Server anzufordern.

### Vorteile von Natural RPC-Aufrufen

Beim Natural RPC werden die Vorteile des Client-Server-Computing genutzt. In einem typischen Szenario greift Natural auf einem Windows-Client-Computer über eine Middleware-Schicht auf Serverdaten von einem Natural auf einem Großrechner zu. Daraus ergeben sich folgende Vorteile:

- Der Endbenutzer auf der Client-Seite kann eine Natural-Anwendung mit einer grafischen Benutzeroberfläche nutzen.

- Der Zugriff auf eine große Datenbank kann auf einem Großrechner-Server erfolgen.

- Der Netzwerkverkehr kann minimiert werden, wenn nur relevante Daten vom Client zum Server und zurückgesendet werden.

### Natural RPC-Betriebsarten

Der Natural RPC bietet folgende Betriebsarten:

- Nicht-konversationeller Modus (in den folgenden Texten ist, wenn nicht anders angegeben, dieser Modus gemeint)

- Konversationeller Modus

Diese Betriebsarten werden in den folgenden Abschnitten beschrieben. Eine Gegenüberstellung der Vor- und Nachteile dieser Betriebsarten finden Sie unter Konversationeller versus nicht-konversationeller Modus.

### Verfügbarkeit auf verschiedenen Plattformen

Sie können den Natural RPC auf verschiedenen Plattformen unter den folgenden Betriebssystemen verwenden:

- z/OS

- Windows

- Linux

Natural RPC auf Großrechnern wird unter den folgenden TP-Monitoren unterstützt:

- Com-plete

- CICS

- TSO

Natural RPC ist auch im Batch-Modus verfügbar.

Auf all diesen Plattformen kann Natural sowohl als Client-Natural als auch als Server-Natural fungieren.

### Unterstützung von Nicht-Natural-Umgebungen (EntireX RPC)

Nicht-Natural-Umgebungen (3GL und andere Programmiersprachen) werden sowohl auf der Client- als auch auf der Server-Seite unterstützt. So kann ein Nicht-Natural-Client mit einem Natural RPC Server und ein Natural-Client mit einem Nicht-Natural-RPC-Server kommunizieren. Ermöglicht wird dies durch die Verwendung des EntireX RPC.

## Natural RPC-Betrieb im nicht-konversationellen Modus

Der nicht-konversationelle Modus sollte nur verwendet werden, um einen einzelnen Datenaustausch mit einem Partner durchzuführen. Siehe auch Konversationeller versus nicht-konversationeller Modus.

Die Natural RPC-Technik verwendet das Natural-Statement `CALLNAT`, so dass sowohl lokale als auch entfernte Subprogramm-Aufrufe parallel abgesetzt werden können. Entfernte Programmaufrufe arbeiten synchron. Als entfernter Prozeduraufruf würde ein `CALLNAT`, einfach ausgedrückt, den folgenden Weg nehmen:

Das vom Natural-Client abgesetzte `CALLNAT` wird über eine Middleware-Schicht an den Natural-Server geleitet, der die Daten an den Client zurückgibt.

In der Regel besteht die Middleware-Schicht aus dem Software AG-Produkt EntireX Broker, das das ACI-Protokoll verwendet. EntireX Broker verwendet entweder Entire Net-Work oder TCP/IP als Kommunikationsschicht.

Ein detailliertes Beispiel für den RPC-Kontrollfluss wird im Folgenden beschrieben.

### Ausgabe von CALLNATs in einer RPC-Umgebung

Einzelheiten des `CALLNAT`-Kontrollflusses in einer Remote-Prozedur werden im Folgenden dargestellt. Aus Gründen der Übersichtlichkeit ist der Rückweg nicht dargestellt, aber er verläuft analog; die Zahlen beziehen sich auf die Beschreibung:

1. Vom Natural-Client aus sendet das Programm `PGM1` einen `CALLNAT` an das Subprogramm `SUB1`. `PGM1` weiß nicht, ob das Ergebnis seines `CALLNAT` ein lokales oder ein entferntes `CALLNAT` sein wird.

   Da sich das Ziel `SUB1` auf einem Server befindet, greift das `CALLNAT` stattdessen auf ein Interface-Objekt `SUB1` zu. Dieses Client-Interface-Objekt wurde automatisch oder manuell (mit der Funktion Interface Object Generation (IG) der `SYSRPC`-Utility) erstellt.

   Das Interface-Objekt hat den gleichen Namen wie das Ziel-Subprogramm und enthält Parameter, die mit den im Programm `PGM1` und auf dem Server im Ziel-Subprogramm `SUB1` verwendeten Parametern identisch sind. Außerdem enthält es Steuerinformationen, die intern vom RPC verwendet werden.

   Wenn der Schlüsselwort-Subparameter `AUTORPC` des Natural-Profilparameters `RPC` oder des Parametermakros `NTRPC` auf `ON` gesetzt ist und Natural das Subprogramm in der lokalen Umgebung nicht finden kann, interpretiert Natural dies als Remote Procedure Call und generiert den Parameterdatenbereich (PDA) dynamisch zur Laufzeit.

   Außerdem versucht Natural, dieses Subprogramm im Service Directory `NATCLTGS` zu finden.

   Weitere Informationen zur Interface-Objekt-Generierungsfunktion der `SYSRPC`-Utility siehe Interface-Objekte erstellen.

   Wenn Sie ohne Interface-Objekte arbeiten wollen, lesen Sie bitte den Abschnitt Mit automatischer Natural RPC-Ausführung arbeiten.

2. Das Interface-Objekt richtet dann ein `CALLNAT` zu einer RPC-Client-Service-Routine ein.

3. Die Client-RPC-Laufzeit überprüft im Service Directory `NATCLTGS`, auf welchem Knoten und Server das `CALLNAT` ausgeführt werden soll und ob eine Anmeldung erforderlich ist.

   Die `CALLNAT`-Daten einschließlich der Parameterliste und, falls erforderlich, der Anmeldedaten werden an eine Middleware-Schicht übergeben.

4. In diesem Beispiel besteht die Middleware-Schicht aus dem Software AG-Produkt EntireX Broker. Daher werden die `CALLNAT`-Daten zunächst an einen EntireX Broker Stub auf dem Client übergeben.

5. Vom EntireX Broker Stub aus werden die `CALLNAT`-Daten an den EntireX Broker weitergeleitet. Der EntireX Broker ist ein Produkt, das an folgenden Stellen installiert sein kann:

   - auf dem Client-Computer,

   - auf dem Server-Computer oder

   - auf einer dritten Plattform.

   Damit die Daten erfolgreich weitergeleitet werden können, muss der Server `SRV1` in der EntireX Broker-Attributdatei definiert sein und `SRV1` muss bereits aktiv sein, sich also beim EntireX Broker registriert haben.

   Informationen zur Definition von Servern in der EntireX Broker-Attributdatei finden Sie in der EntireX Broker-Dokumentation.

6. Von der Middleware-Schicht werden die `CALLNAT`-Daten an den EntireX Broker-Stub auf der Natural Server-Plattform und von dort an die RPC-Server-Service-Routine weitergeleitet.

   Die RPC-Server-Service-Routine validiert die Anmeldedaten (falls vorhanden) und führt eine Anmeldung durch (falls angefordert).

7. Die RPC-Server-Service-Routine ruft das Ziel-Subprogramm `SUB1` auf und übergibt die Daten, falls angefordert.

   Zu diesem Zeitpunkt verfügt das Ziel-Subprogramm `SUB1` über alle erforderlichen Daten zur Ausführung, als ob es von einem lokalen Programm `PGM1` aufgerufen worden wäre.

8. Dann kann das Subprogramm `SUB1` z.B. ein `FIND`-Statement an die Adabas-Datenbank des Servers senden. `SUB1` weiß nicht, ob es von einem lokalen oder von einem entfernten `CALLNAT` gestartet wurde.

9. Adabas findet die Daten und übergibt sie an `SUB1`.

   Anschließend gibt `SUB1` die Adabas-Daten an die aufrufende Server-Service-Routine zurück. Von dort werden sie über die Middleware-Schicht an `PGM1` zurückgegeben. Dies geschieht auf demselben Weg wie in den Schritten 1 bis 8 beschrieben, jedoch in umgekehrter Reihenfolge.

## Natural RPC-Betrieb im konversationellen Modus

Ein konversationeller RPC ist eine statische Verbindung von begrenzter Dauer zwischen einem Client und einem Server. Sie bietet eine Reihe von Diensten (Subprogrammen), die vom Client definiert werden und die alle innerhalb einer Server-Task ausgeführt werden, die für die Dauer der Konversation ausschließlich dem Client zur Verfügung steht. Sie wird in einem Programm mit einem `OPEN CONVERSATION`-Statement und einem `CLOSE CONVERSATION`-Statement implementiert.

Es können mehrere Verbindungen (Konversationen) gleichzeitig bestehen. Sie werden vom Client mit Hilfe von Konversationskennungen (Conversation-IDs) verwaltet, und jede von ihnen wird auf einem anderen Server ausgeführt. Remote Prozeduraufrufe, die nicht zu einer gegebenen Konversation gehören, werden innerhalb einer anderen Server-Task auf einem anderen Server ausgeführt.

Während einer Konversation können die entfernten Subprogramme auf der Serverseite einen Datenbereich, den sogenannten Kontext-Bereich, definieren und gemeinsam nutzen. Weitere Informationen finden Sie unter Definition von Kontext-Variablen für den Natural RPC in der Natural Statements-Dokumentation.

Definieren von Kontextvariablen für Natural RPC in der Dokumentation Natural Statements.

Eine Conversation kann lokal oder remote sein.

#### Beispiel:

    OPEN CONVERSATION USING SUBPROGRAM 'S1''S2'
         CALLNAT 'S1' PARMS1
         CALLNAT 'S2' PARMS2
    CLOSE CONVERSATION ALL

Beide Subprogramme (S1 und S2) müssen an der gleichen Stelle aufgerufen werden, d.h. entweder lokal oder fern (remote). Es ist nicht zulässig, lokale und ferne CALLNATs innerhalb einer Konversation zu vermischen. Wenn die Subprogramme fern ausgeführt werden, werden beide Subprogramme von derselben Server-Task ausgeführt.

So wie bei nicht-konversationellen RPC-`CALLNAT`s können Konversationen zunächst lokal geschrieben und getestet und dann an die Server übertragen werden.

### Allgemeine Regeln für die lokale/ferne Ausführung von Subprogrammen

#### Lokale Ausführung von Subprogrammen

Wenn Sie Subprogramme lokal ausführen, gilt die folgende Regel:

- Ein Subprogramm darf kein anderes Subprogramm aufrufen, das Teilnehmer der Konversation ist.

Andere Subprogramme, die nicht in dem `OPEN CONVERSATION`-Statement aufgeführt sind, können aufgerufen werden. Sie werden jedoch im nicht-konversationellen Modus ausgeführt.

#### Entfernte Ausführung von Subprogrammen

Wenn Sie Subprogramme remote ausführen, gilt die folgende Regel:

- A subprogram `S1` may call another subprogram `S2` which is a member of the conversation.

  Ein Subprogramm S1 darf ein anderes Subprogramm `S2` aufrufen, das Teilnehmer der Konversation ist.

Dieses `CALLNAT` wird im nicht-konversationellen Modus ausgeführt, da es indirekt aufgerufen wurde. Das Subprogramm `S2` hat also keinen Zugriff auf den Kontextbereich.

## Konversationeller versus nicht-konversationeller Modus

In einer Client-Server-Umgebung, in der mehrere Clients im nicht-konversationellen Modus auf mehrere Server zugreifen, kann es zu dem Problem kommen, dass identische `CALLNAT`-Anforderungen von verschiedenen Clients auf demselben Server ausgeführt werden.

Das bedeutet z.B., dass ein `CALLNAT 'S1'` von Client 1 das Subprogramm `S1` auf Server 1 ausführt (`S1` schreibt einen Datensatz in die Datenbank). Die Transaktion für Client 1 ist noch nicht abgeschlossen (kein `END TRANSACTION`), wenn Client 2 ebenfalls einen CALLNAT 'S1' an Server 1 sendet und damit die Daten von Client 1 überschreibt. Sendet Client 1 daraufhin ein `CALLNAT 'S2'` (d.h. `END TRANSACTION`), geht Client 1 davon aus, dass seine Daten korrekt gespeichert wurden, obwohl in Wirklichkeit die Daten des identischen `CALLNAT` von Client 2 gespeichert wurden.

Das folgende Diagramm veranschaulicht dies mit zwei Clients und zwei Servern. In einem solchen Szenario können Sie nicht kontrollieren, ob zwei identische `CALLNAT`s von zwei verschiedenen Clients auf dasselbe Subprogramm auf demselben Server zugreifen:

Im obigen Beispiel kann `CALLNAT 'S2'` von Client 1 auf das Subprogramm `S2` auf Server 1 und auf Server 2 zugreifen. `CALLNAT 'S2'` von Client 2 hat die gleiche Wahl.

Ähnlich könnte `CALLNAT 'S1'` von Client 1 auf das Subprogramm `S1` auf Server 1 und auf Server 2 zugreifen, während `CALLNAT 'S1'` von Client 2 die gleiche Wahl hat.

Es ist offensichtlich, dass es hier zu Überschneidungen kommen kann, wenn die Subprogramme so konzipiert sind, dass sie innerhalb eines Server-Task-Kontextes ausgeführt werden.

Sie können die potenziellen Probleme eines nicht-konversationellen RPC vermeiden, indem Sie eine komplexere RPC-Transaktion im konversationellen Modus definieren:

Dazu eröffnen Sie eine Konversation. Dazu wird auf der Client-Seite das `OPEN CONVERSATION`-Statement verwendet, das sich auf `CALLNAT 'S1'` und `CALLNAT 'S2'` bezieht. Durch das Eröffnen einer solchen Konversation wird eine ganze Server-Task (z. B. Server 1) reserviert, und keine anderen entfernten `CALLNAT`s dürfen diese Konversation auf diesem Server unterbrechen, bevor diese Konversation geschlossen wurde. Zusätzlich können Sie mit dem `DEFINE DATA CONTEXT`-Statement einen gemeinsamen Kontextbereich für die beiden Subprogramme auf der Server-Seite definieren.

### Allgemeine Regeln für die Verwendung von konversationellem/nicht-konversationellem RPC

Als allgemeine Regel gilt Folgendes:

- Verwenden Sie konversationellen RPC, um sicherzustellen, dass eine definierte Liste von Subprogrammen ausschließlich in einem Kontext ausgeführt wird.

- Verwenden Sie nicht-konversationellen RPC, wenn jedes Ihrer Subprogramme innerhalb einer anderen Server-Task verwendet werden kann oder wenn sich die Transaktion nicht über mehr als einen Server-Aufruf erstreckt. Dies hat den Vorteil, dass kein Server über einen längeren Zeitraum blockiert und Sie nur eine relativ geringe Anzahl von Server-Tasks benötigen.

### Möglicher Nachteil bei Verwendung von konversationellem RPC

Ein möglicher Nachteil von konversationellen RPCs ist, dass Sie eine ganze Server-Task reservieren und damit alle anderen Subprogramme auf diesem Server blockieren. Dies kann dazu führen, dass andere `CALLNAT`s warten müssen oder weitere Server-Tasks gestartet werden müssen.

## Datenbank-Transaktionen

Die Datenbank-Transaktionen auf der Client- und der Server-Seite laufen unabhängig voneinander. Das heißt, ein `END TRANSACTION` oder `BACKOUT TRANSACTION`, das auf der Server-Seite ausgeführt wird, hat keinen Einfluss auf die Datenbank-Transaktion auf der Client-Seite und umgekehrt.

Am Ende jedes nicht-konversationellen `CALLNAT` und am Ende jeder Konversation wird auf der Server-Seite ein implizites `BACKOUT TRANSACTION` ausgeführt. Um die von dem/den entfernten `CALLNAT`(s) vorgenommenen Änderungen zu übernehmen, haben Sie folgende Möglichkeiten:

Nicht-konversationelles CALLNAT

1. Führen Sie ein explizites `END TRANSACTION` aus, bevor Sie den `CALLNAT` verlassen.

2. Setzen Sie den Natural-Profilparameter `ETEOP` auf `ON`. Dies führt zu einem impliziten `END TRANSACTION` am Ende eines jeden nicht-konversationellen `CALLNAT`s.

   Je nach Einstellung des Subparameters `SRVCMIT` wird das `END TRANSACTION` entweder vor dem Senden der Antwort an den Client (`SRVCMIT=B`) oder nach dem erfolgreichen Senden der Antwort an den Client (`SRVCMIT=A`) ausgeführt. `SRVCMIT=B` ist die Standardeinstellung und ist mit früheren Versionen des RPC kompatibel.

Konversationelles CALLNAT

1. Führen Sie ein explizites `END TRANSACTION` aus, bevor die Konversation durch den Client beendet wird.

2. Setzen Sie den Natural-Profilparameter `ETEOP` auf `ON`. Dies führt zu einem impliziten `END TRANSACTION` am Ende jeder Konversation.

   Je nach Einstellung des Subparameters `SRVCMIT` wird das `END TRANSACTION` entweder vor dem Senden der Antwort an den Client (`SRVCMIT=B`) oder nach dem erfolgreichen Senden der Antwort an den Client (`SRVCMIT=A`) ausgeführt. `SRVCMIT=B` ist die Standardeinstellung und ist mit früheren Versionen des RPC kompatibel.

3. Bevor Sie das `CLOSE CONVERSATION`-Statement ausführen, rufen Sie die Anwendungsprogrammierschnittstelle `USR2032N` auf der Client-Seite auf. Dadurch wird am Ende der einzelnen Konversation ein implizites `END TRANSACTION` ausgelöst.

## Behandlung der mit den Profilparametern LT, MAXCL, MADIO und MT gesetzten Limits auf dem Server

Die folgenden Natural-Limits gelten für jede einzelne Remote-CALLNAT-Ausführung auf dem Natural RPC Server:

Natural-Profilparameter | Art des Limits
--- | ---
`LT` | Limit für Verarbeitungsschleifen
`MADIO` | Maximale Anzahl der DBMS-Aufrufe zwischen Bildschirm-Ein-/Ausgaben
`MAXCL` | Maximale Anzahl an Programmaufrufen
`MT` | Maximale CPU-Zeit

Diese Limits werden nach jeder Remote-`CALLNAT`-Ausführung zurückgesetzt, und Sie können bestimmte Limits für jede Remote-`CALLNAT`-Ausführung erzwingen.

Diese Maßnahme trägt dazu bei, unvorhersehbare Fehlersituationen zu vermeiden, wenn die Ausführung einer Client-Anforderung aufgrund der Verarbeitung einer früheren Client-Anforderung eines der Limits erreicht

## Ort der Konversationen

Die beiden Subprogramme S1 und S2 (in der obigen Abbildung dargestellt) müssen am selben Ort aufgerufen werden, d.h. entweder lokal oder entfernt (remote). Lokale und entfernte `CALLNAT`s dürfen innerhalb einer Konversation nicht vertauscht werden. Wenn die Subprogramme entfernt ausgeführt werden, werden beide Subprogramme von der gleichen Server-Task ausgeführt.

## Natural RPC-Terminologie

Die folgende Tabelle enthält wichtige Schlüsselbegriffe, die in der `SYSRPC` Utility und in der Natural RPC-Dokumentation verwendet werden:

Begriff | Erklärung
Client-Stub | Veralteter Begriff, siehe Client-Interface-Objekt.
EntireX Broker Stub | Schnittstelle zwischen der Natural RPC-Laufzeit und der EntireX Broker-Transportschicht, die umgewandelten ("marshalled") Daten zwischen Client und Server austauscht.
Client-Interface-Objekt | Nimmt die `CALLNAT`-Anforderungen auf der Client-Seite entgegen, wandelt das Format der übergebenen Parameter um ("marshalling"), überträgt die Daten durch die Natural RPC-Laufzeit und die Transportschicht zum Remote-Server, wandelt das Ergebnis zurück ("unmarshalling") und gibt es an den Aufrufer zurück. Der Interface-Objekt-Stub ist das lokale Subprogramm, über das das Server-Subprogramm aufgerufen wird. Das Client-Interface-Objekt hat den gleichen Namen und enthält die gleichen Parameter wie das entsprechende Server-Subprogramm.
Impersonation | Impersonation setzt voraus, dass der Zugriff auf das Betriebssystem, auf dem ein Natural RPC Server läuft, durch ein SAF-konformes externes Security-System kontrolliert wird. Die Benutzerauthentifizierung wird von diesem externen Security-System durchgeführt. Impersonation bedeutet, dass nach erfolgreicher Authentifizierung und Feststellung der Identität des Benutzers alle nachfolgenden Berechtigungsprüfungen auf der Grundlage dieser Identität durchgeführt werden. Dazu gehören auch Berechtigungsprüfungen für den Zugriff auf externe Ressourcen (z. B. Datenbanken oder Arbeitsdateien). Nach erfolgreicher Authentifizierung kann der Benutzer "seine Identität nicht ändern", d. h. er kann keine andere Benutzerkennung verwenden. Siehe Impersonation in Verwendung von Security.
Interface-Objekt | In früheren Versionen von EntireX wurde der Begriff "Stub" auch für anwendungsabhängige, von der Workbench generierte Codestücke zum Absetzen und Empfangen von Remote Procedure Calls verwendet. Diese Objekte werden jetzt als "Interface-Objekte" bezeichnet.
Knotenname | Der Name des Knotens, an den der Remote-`CALLNAT` gesendet wird. Bei der Kommunikation über den EntireX Broker ist der Knotenname beispielsweise der Name des EntireX Brokers, wie er in der EntireX Broker-Attributdatei im Feld `BROKER-ID` definiert ist.
Marshalling | Beim Marshalling werden Schnittstellendaten in RPC-Pakete verpackt, die über Prozess- und Netzwerkgrenzen hinweg übertragen werden. Dazu gehört die Konvertierung von Daten von ihrem eigentlichen Datentyp in eine interne Darstellung. Die Umwandlung aus einer internen Darstellung in ihren eigentlichen Datentyp wird als Unmarshalling bezeichnet.
`NATCLTGS` | Der Name des Natural-Subprogramms, das mit der SYSRPC Utility generiert wurde, um das Diensteverzeichnis (Service Directory) zu implementieren (siehe unten).
RPC-Parameter | Alle Parameter, die zur Steuerung eines Natural RPC zur Verfügung stehen, sind in der Natural Parameter-Referenz-Dokumentation ausführlich beschrieben. Siehe Abschnitt Profilparameter. Die RPC-Parameter sind im Parameter-Makro `NTRPC` enthalten (statische Definition) oder werden mit dem Profilparameter `RPC` definiert (dynamische Definition). Siehe RPC - Remote Procedure Call-Einstellungen und NTRPC-Macro-Syntax (in der Natural Parameter-Referenz-Dokumentation).
RPC-Server | Ein RPC-Server ist entweder ein Natural-Server oder ein EntireX RPC-Server.
Service Directory | Das Diensteverzeichnis (Service Directory) enthält Informationen über die Services, d.h. Dienste (Subprogramme), die ein Server anbietet. Es kann lokal auf jedem Client-Knoten verfügbar sein oder sich auf einem Remote Directory Server befinden, auf den unter Windows und UNIX durch den Profilparameter `RDS` und auf Großrechnern durch den entsprechenden Schlüsselwort-Subparameter `RDS` des Profilparameters `RPC` oder des Parameter-Makros `NTRPC` verwiesen wird.
Servername | Der Name des Servers, auf dem der `CALLNAT` ausgeführt werden soll. Bei der Kommunikation über EntireX Broker ist der Servername der Name, der in der EntireX Broker-Attributdatei im Feld `SERVER` definiert ist.
Server-Task | Eine Natural-Task, die Services, d.h. Dienste (Subprogramme), anbietet. Dies ist typischerweise eine Batch-Task oder eine asynchrone Task. Sie wird durch einen Servernamen identifiziert.

### On this page

- Allgemeine Informationen zum Natural RPC
- Natural RPC-Betrieb im nicht-konversationellen Modus
- Natural RPC-Betrieb im konversationellen Modus
- Konversationeller versus nicht-konversationeller Modus
- Datenbank-Transaktionen
- Behandlung der mit den Profilparametern LT, MAXCL, MADIO und MT gesetzten Limits auf dem Server
- Ort der Konversationen
- Natural RPC-Terminologie