Dieses Kapitel behandelt die folgenden Themen:
Remote-Procedure-Call (RPC)-Techniken bilden einen Rahmen für die Kommunikation zwischen Server- und Client-Systemen, die sich auf demselben Computer oder in einem Netz aus identischen oder heterogenen Maschinen und Betriebssystemen befinden können. Es sind mehrere grundsätzlich ähnliche Methoden bekannt.
Diese Dokumentation beschreibt die Funktionsweise und den Einsatz der von Natural bereitgestellten RPC-Techniken, um den Entwurf und die Anwendung verteilter Softwaresysteme zu vereinfachen. Informationen zu anderen Produkten, die an einer Natural RPC-basierten Umgebung beteiligt sein können, finden Sie in der Dokumentation zu EntireX RPC for 3GL, Entire Network und EntireX Broker.
Ausführliche Informationen zu den Funktionen, die zur Verwaltung von Remote Procedure Calls zur Verfügung stehen, finden Sie im Kapitel SYSRPC Utility in der Debugger und Dienstprogramme-Dokumentation.
Dieses Dokument gilt für alle Plattformen, auf denen Natural verwendet werden kann. Je nachdem, welche Natural-Dokumentation Sie gerade verwenden, gibt es jedoch die folgenden Unterschiede:
Die Beispiele für die Verwendung der Natural Utility SYSRPC zeigen
plattformspezifische Abbildungen (entweder mit GUI- oder CUI-Schnittstelle).
Bei Natural for Windows und Linux sind die RPC-spezifischen Parameter als Profilparameter verfügbar.
Bei Natural for z/OS sind die Parameter als Schlüsselwort-Subparameter des
Profilparameters RPC oder des Parameter-Makros NTRPC verfügbar.
Die in dieser Dokumentation verwendete Schreibweise vrs oder vr steht für die jeweilige Produktversion (siehe auch Version im Glossar).
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.
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.
Der Natural RPC bietet folgende Betriebsarten:
Nicht-konversationeller Modus (in den folgenden Texten ist, wenn nicht anders angegeben, dieser Modus gemeint)
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.
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.
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.
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 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.
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:
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.
Das Interface-Objekt richtet dann ein CALLNAT zu einer
RPC-Client-Service-Routine ein.
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.
In diesem Beispiel besteht die Middleware-Schicht aus dem Produkt EntireX Broker.
Daher werden die CALLNAT-Daten zunächst an einen EntireX Broker Stub
auf dem Client übergeben.
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.
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).
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.
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.
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.
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.
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-CALLNATs können Konversationen
zunächst lokal geschrieben und getestet und dann an die Server übertragen werden.
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: 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.
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 CALLNATs
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 CALLNATs 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.
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.
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 CALLNATs warten müssen oder weitere Server-Tasks
gestartet werden müssen.
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
Führen Sie ein explizites END
TRANSACTION aus, bevor Sie den CALLNAT
verlassen.
Setzen Sie den Natural-Profilparameter ETEOP auf ON. Dies führt zu einem impliziten
END TRANSACTION am Ende eines jeden nicht-konversationellen
CALLNATs.
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
Führen Sie ein explizites END
TRANSACTION aus, bevor die Konversation durch den Client beendet
wird.
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.
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.
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
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
CALLNATs 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.
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 |
| 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 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-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. |