DE69126223T2

DE69126223T2 - System zur Erstellung eines Übertragungsweges in einem eng gekoppelten Rechnersystem

Info

Publication number: DE69126223T2
Application number: DE69126223T
Authority: DE
Inventors: Miyoko Kawaguchi; Takayoshi Kurita
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1990-02-14
Filing date: 1991-02-14
Publication date: 1997-09-18
Anticipated expiration: 2011-02-15
Also published as: US5758078A; EP0447038A3; EP0447038A2; DE69126223D1; EP0447038B1

Description

Die vorliegende Erfindung betrifft ein System zum Aufbauen eines Kommunikationspfades zwischen Servern in einem eng gekoppelten Computersystem. Spezieller gesagt, wird der Kommunikationspfad zwischen einem globalen Server und einer Vielzahl von örtlichen Servern aufgebaut und es wird eine Nachrichtenkommunikation zwischen den Servern basierend auf einem Zugriff auf die "Leistungsfähigkeit" (capability) durchgeführt. Im allgemeinen ist der Server definiert als "irgendeiner von Prozessoren, der sich um eine Verarbeitung kümmert", das heißt der Server ist definiert als eine Vorrichtung, um verschiedene Resourcen vorzusehen, beispielsweise eine Datei, einen Drucker, ein Kommunikationsnetzwerk und ähnliches, und zwar in einem Computersystem. Ferner ist die Leistungsfähigkeit (capability) als eine Art einer "Eintrittskarte" oder "eines Zugriffsrechtes" für die Server in der Nachrichtenkommunikation zwischen den Servern definiert.
In IBM Systems Journal, Vol 2b (1987), Nr. I, Part A, NY, USA, Seiten 13-36, ist der Stand des SNA-Netzwerksystems dargestellt. Es wird der Aufbau von SNA dargelegt und auf die Konfigurationsflexibilität, das Netzwerkmanagement und Unterstützung hinsichtlich SNA-Konstruktionen unter anderen Dingen hingewiesen.
Ein eng gekoppeltes Computersystem ist gebildet aus einer Vielzahl von Subsystemen, von denen jedes eine Vielzahl von Prozessoren besitzt. In dem Subsystem kann die Zahl der Prozessoren in Einklang mit den Anforderungen des Anwenders vergrößert werden. Bei dem eng gekoppelten Computersystem ist lediglich ein globaler Server in dem System vorgesehen und ein ortsgebundener Server ist für jedes Subsystem vorgesehen. Demzufolge sind ein globaler Server und eine Vielzahl von örtlichen Servern in dem dicht gekoppelten Computersystem vorgesehen und eine Anfrage, eine Resource zu verwenden, wird zwischen dem globalen Server und einem örtlichen Server übertragen.
Bei dem eng gekoppelten Computersystem werden der globale Server und die örtlichen Server unabhängig (asynchron) gestartet, und zwar nachdem eine anfängliche Programmlade-(IPL)-operation in dem Computersystem vervollständigt wurde. Demzufolge ist es bei einer Nachrichtenkommunikation zwischen Servern erforderlich, den Anlaufzustand bei den Servern zu bestätigen und es ist nach der Bestätigung erforderlich, einen Kommunikationspfad zwischen den Servern aufzubauen. In einer herkömmlichen Weise wird eine Anfrage für die Bestätigung eines Starts von dem globalen Server zu dem örtlichen Server gesendet. Das heißt, der globale Server übernimmt die Initiative bei der Nachrichtenkommunikation zwischen den Servern. Es ist demzufolge für den globalen Server erforderlich, immer den Anlaufzustand aller örtlicher Server zu überprüfen und der globale Server muß nachfolgende Ereignisse erkennen, um den Anlaufzustand für alle örtlichen Server zu managen.
Zuerst muß der globale Server Definitionsdaten für den örtlichen Server erhalten und er muß die Lage erkennen, wo der örtliche Server vorhanden ist. Als zweites muß der globale Server den Anlaufzustand des örtlichen Servers erkennen. Daher treten bei der geschilderten herkömmlichen Art und Weise die im folgenden erläuterten Nachteile auf. Wenn erstens die Definitionsdaten für den örtlichen Server geändert werden, ist es für den globalen Server erforderlich, eine erneute Startoperation für alle Server durchzuführen. Da zweitens der Kommunikationspfad zwischen den Servern fest aufgebaut wird, ist es erforderlich, an früherer Stelle eine Reihenfolge der Nachrichtenkommunikation zwischen den örtlichen Servern festzulegen. Wenn zweitens irgendeiner der örtlichen Server nicht angelaufen ist, muß der globale Server periodisch den Anlauf zustand dieses örtlichen Servers überprüfen.
Gemäß der vorliegenden Erfindung wird im Sinne des Anspruches 1 ein System zum Erstellen eines Kommunikationspfades zwischen einem globalen Server und einer Vielzahl von örtlichen Servern geschaffen und es wird eine Anfrage nach der Verarbeitung einer Nachricht über den Kommunikationspfad in einem eng gekoppelten Computersystem übertragen, wobei das Aufbausystem folgendes enthält: eine erste Leistungsfähigkeit, die von dem globalen Server oder dem örtlichen Server zu einem willkürlichen Klienten ausgegeben wird, um eine Anfrage zu empfangen, die von dem willkürlichen Klienten gesendet wurde; eine zweite Leistungsfähigkeit, die von dem globalen Server oder dem örtlichen Server an einen spezifizierten Server ausgegeben wird, um den Kommunikationspfad aufzubauen, wobei eine Sicherheit der Nachricht von dem spezifizierten Server sichergestellt wird; eine Nachrichtenkommunikationseinheit zum Übertragen der Nachricht zwischen dem globalen Server und dem örtlichen Server unter Verwendung der ersten und der zweiten Leistungsfähigkeit (capability); und eine Bestimmungs-Zwischeneinheit zum Registrieren der ersten Leistungsfähigkeit und um die erste Leistungsfähigkeit des örtlichen Servers mitzuteilen, um die Kommunikation zwischen dem globalen Server und dem örtlichen Server zwischenzeitlich zu speichern; wobei der globale Server die Registrierung der ersten Leistungsfähigkeit von der Bestimmungs-Zwischeneinheit anfragt, der örtliche Server die erste Leistungsfähigkeit von der Bestimmungs-Zwischeneinheit erhält und der örtliche Server nach dem Aufbau des Kommunikationspfades von dem örtlichen Server zu dem globalen Server unter Verwendung der zweiten Leistungsfähigkeit anfragt.
Spezielle Ausführungsformen der vorliegenden Erfindung sollen nun unter Hinweis auf die beigefügten Zeichnungen beschrieben werden, in denen:
In den Zeichnungen:
Fig. 1 ein grundlegendes Blockschaltbild zur Erläuterung eines ersten Aspektes der vorliegenden Erfindung ist;
Fig. 2 ein Flußdiagramm zur Erläuterung eines Initialisierungsschrittes des globalen Servers ist;
Fig. 3 ein Flußdiagramm zur Erläuterung weitere Verarbeitungsschritte des globalen Servers zeigt;
Fig. 4 ein Flußdiagramm zur Erläuterung eines Initialisierungsschrittes des örtlichen Servers zeigt;
Fig. 5 ein schematisches Blockschaltbild eines eng gekoppelten computersystems unter Verwendung der vorliegenden Erfindung darstellt;
Fig. 6 eine Ansicht ist, um ein Aufbauverfahren eines Kommunikationspfades gemäß der vorliegenden Erfindung zu erläutern;
Fig. 7 eine Ansicht ist, um ein detailliertes Verfahren zur Stellung des Kommunikationspfades, der in Fig. 6 gezeigt ist, zu zeigen;
Fig. 8 ein grundlegendes Blockschaltbild ist, um einen zweiten Aspekt der vorliegenden Erfindung zu erläutern;
Fig. 9 eine Ansicht ist, um eine Betriebsweise der Kommunikation gemäß dem zweiten Aspekt der vorliegenden Erfindung zu erläutern;
Fig. 10 eine Ansicht ist, um eine R-CAP-Managementtabelle in dem Empfangsserver gemäß der vorliegenden Erfindung zu erläutern;
Fig. 11 ein Flußdiagramm zeigt, um die Registrierung in der R-CAP-Managementtabelle zu erläutern, die in Fig. 10 gezeigt ist; und
Fig. 12 ein Flußdiagramm ist, um den Suchschritt in der R-CAP-Managementtabelle zu erläutern, die in Fig. 10 gezeigt ist.
Fig. 1 zeigt ein grundlegendes Blockschaltbild zur Erläuterung des ersten Aspektes der vorliegenden Erfindung. In Fig. 1 bezeichnet das Bezugszeichen 10 ein eng gekoppeltes Computersystem, welches durch eine Vielzahl von Prozessormodulen gebildet ist, 11 eine Bestimmungs-Zwischeneinrichtung (im folgenden als Vermittler bezeichnet) und 12 eine Nachrichtenkommunikationseinrichtung bezeichnet, um eine Nachrichtenkommunikation unter Verwendung der Leistungsfähigkeit (capability) als Bestimmung zu verarbeiten. Ferner ist mit 13 ein globaler Server und mit 14 und 14' sind lokale Server bezeichnet.
Bei dem ersten Aspekt der vorliegenden Erfindung sind zwei Arten von Leistungsfähigkeiten für die Nachrichtenkommunikation zwischen den Servern vorgesehen. Das heißt, die erste Leistungsfähigkeit wird als "Ruf-Leistungsfähigkeit" bezeichnet und die zweite Leistungsfähigkeit wird als "Resourcen-Leistungsfähigkeit" bezeichnet. Die Ruf-Leistungsfähigkeit (im folgenden mit C-CAP bezeichnet) wird durch den Server ausgegeben (in Fig. 1 wird C-CAP von dem globalen Server 13 ausgegeben), um eine Anfrage zu empfangen, die von einem willkürlichen Klienten ausgesendet wurde. In diesem Fall ist der Klient als ein Subjekt definiert, welches nach der Verarbeitung der Resource anfragt. Der Server kann einen Kommunikationspfad zu einem nicht spezifizierten Klienten aufbauen, der an einer willkürlichen Stelle in dem System existiert. Dieser Aufbau des Kommunikationspfades wird durch Öffnen von C-CAP zur Öffentlichkeit durchgeführt.
Die Resourcen-Fähigkeit (im folgenden mit R-CAP bezeichnet) wird von dem Server ausgegeben (in Fig. 1 wird R- CAP von dem örtlichen Server 14 oder 14' ausgegeben), und zwar zu einem spezifizierten Klienten (in Fig. 1 dem globalen Server 13). R-CAP kann die Sicherheit der Nachricht bzw. Nachrichtenübertragung zu dem spezifizierten Klienten in dem Kommunikationspfad sicherstellen.
In Fig. 1 bezeichnen die Zahlen 1 bis 5 Grundschritte für den Aufbau des Kommunikationspfades von dem örtlichen Server zu dem globalen Server.
Bei dem Schritt 1 fragt der globale Server 13, nachdem die Initialisierung des globalen Servers selbst vervollständigt ist, nach der Registrierung des C-CAP am Vermittler 11, um den Empfang der Verarbeitungsanfrage von dem örtlichen Server zu starten.
Bei dem Schritt 2 prüft der Vermittler 11, ob die Anfrage von dem globalen Server 13 für die Registrierung C- CAP geeignet ist oder nicht. Wenn die Anfrage von dem globalen Server 13 geeignet ist, registriert der Vermittler 11 C-CAP von dem globalen Server 13 darin.
Bei den Schritten 3 und 3' gibt der örtliche Server 14, 14', nachdem die Initialisierung des örtlichen Servers selbst vervollständigt ist, die Anfragen aus, um C-CAP von dem globalen Server 13 für den Vermittler 11 zu erhalten und um den Kommunikationspfad zu dem globalen Server 13 aufzubauen.
Bei den Schritten 4 und 4' gibt der lokale Server 14, 14' R-CAP an den globalen Server 13 aus, um die Nachrichtenkommunikation aufzubauen. Die Bestimmung der Ausgabe von R-CAP wird basierend auf C-CAP des globalen Servers 13, das von dem örtlichen Server bereits erhalten wurde, bestimmt.
Bei dem Schritt 5 überprüft der globale Server 13, nachdem der globale Server R-CAP empfangen hat, ob der örtliche Server eine Autorisierung besitzt oder nicht. Wenn der örtliche Server die Autorisierung besitzt, managt der globale Server 13 die Beziehung zwischen R-CAP und der Resource des örtlichen Servers.
Wie aus den oben erläuterten Schritten hervorgeht, besitzt der Vermittler 11 eine Funktion, die Bestimmung zwischen dem globalen Server und dem örtlichen Server zwischenzuspeichern. Die Kommunikationspfade von dem globalen Server zu dem Vermittler 11 und von den örtlichen Servern zu dem Vermittler 11 sind fest in der Nachrichtenkommunikationseinrichtung bestimmt. Es ist daher für den Server möglich, mit dem Vermittler 11 immer dann zu kommunizieren, wenn der Server gestartet wird. Es ist ferner möglich, auf C-CAP zuzugreifen, welches in dem Vermittler 11 registriert ist, und zwar von irgendeinem örtlichen Server aus. Demzufolge empfängt der globale Server 13 bei der vorliegenden Erfindung die Information hinsichtlich der Vervollständigung des Starts von dem örtlichen Server 14, 14', so daß es möglich ist, die Resource des örtlichen Servers ohne feste Definitionsdaten für den örtlichen Server zu managen.
Da in diesem Fall die Möglichkeit besteht, daß der globale Server den Kommunikationspfad immer dann aufbaut, wenn der globale Server die Information hinsichtlich der Vervollständigung des Starts von dem örtlichen Server empfängt, ist es für den globalen Server nicht erforderlich, periodisch den Startzustand des örtlichen Servers zu überprüfen und es ist für den globalen Server nicht erforderlich, die Initiative bei der Nachrichtenkommunikation zwischen den Servern zu ergreifen.
Fig. 2 zeigt ein Flußdiagramm zur Erläuterung des Initialisierungsschrittes des globalen Servers. Wie bei dem Schritt 1 gezeigt ist, werden bei dem Initialisierungsschritt des globalen Servers eine Mailbox und eine Steuertabelle vorbereitet und, wie im Schritt 2 gezeigt ist, fragt der globale Server nach der Registrierung von C-CAP von dem Vermittler 11 an.
Fig. 3 ist ein Flußdiagramm zur Erläuterung von weiteren Verarbeitungsschritten des globalen Servers. Dieses Flußdiagramm erläutert die Schritte für die Erstellung der Kommunikation von dem globalen Server zu dem örtlichen Server.
Bei dem Schritt 1 empfängt der globale Server eine Nachricht von jedem der örtlichen Server. Bei dem Schritt 2 analysiert der globale Server die Nachrichten und prüft, ob der Sender von jeder der Nachrichten (das heißt dem örtlichen Server) eine Autorisierungsvollmacht besitzt oder nicht. Wenn der Sender einer Nachricht autorisiert ist, erhält der globale Server R-CAP und die Örtlichkeit des lokalen Servers durch Analysieren der Nachricht. Bei dem Schritt 3 erwirbt der globale Server einen Bereich von Steuerdaten und managt die Beziehung zwischen R-CAP und der Lage oder Örtlichkeit.
Fig. 4 zeigt ein Flußdiagramm zur Erläuterung der Initialisierungsschritte des örtlichen Servers. Wie bei dem Schritt 1 gezeigt ist, werden eine Mailbox, eine Steuertabelle und ein R-CAP bei dem Initialisierungsschritt des örtlichen Servers vorbereitet. Um ferner, wie bei dem Schritt 2 gezeigt ist, den Kommunikationspfad aufzubauen, erwirbt der örtliche Server C-CAP des globalen Servers von dem Vermittler und informiert den globalen Server über R- CAP.
Fig. 5 zeigt ein schematisches Blockschaltbild des dicht gekoppelten Computersystems, welches die vorliegende Erfindung verwendet. In Fig. 5 ist mit FCMP ein fest gekoppelter Multiprozessor, mit GCMP ein global gekoppelter Multiprozessor und mit SCCH ein Systemkommunikationskanal bezeichnet. Ferner bezeichnet das Bezugszeichen 20 einen Prozessor mit einer Befehlsausführungsfunktion.
Wie in der Zeichnung gezeigt ist, ist FCMP durch eine Vielzahl von GCMPs gebildet und jedes der GCMPs ist durch SCCH mit dem anderen verbunden, welches zweifach vorhanden ist. Ferner sind die GCMPs durch eine Vielzahl von Prozessoren gebildet. In diesem Fall kann die Zahl der Prozessoren in Einklang mit den Anforderungen des Anwenders vergrößert werden.
Irgendeiner der Prozessoren in FCMP kann die Aufsicht übernehmen über den globalen Server 13, der in Fig. 1 gezeigt ist, und irgendeiner der Prozessoren in GCMP kann die Aufsicht über den lokalen Server 14, 14' übernehmen, der in Fig. 1 gezeigt ist.
Fig. 6 ist eine Ansicht zur Erläuterung eines Verfahrens zur Herstellung eines Kommunikationspfades gemäß einer Ausführungsform der vorliegenden Erfindung. In Fig. 6 sind die gleichen Bezugszeichen, wie sie in Fig. 1 verwendet sind, an die gleichen Komponenten in dieser Zeichnung angehängt. Das Bezugszeichen 50 bezeichnet einen Klienten, das heißt ein Subjekt, welches nach einer Verarbeitung einer Resource anfragt. Das Bezugszeichen 51 bezeichnet eine Managementeinrichtung zum Managen einer Leistungsfähigkeit.
Wie in der Zeichnung gezeigt ist, ist die Managementeinrichtung 51 mit einem Vermittler 11, dem globalen Server 13, dem örtlichen Server 14 und dem Klienten 15 versehen.
In Fig. 6 geben die Zahlen 1 bis 8 die grundlegenden Schritte für die Verarbeitung einer Nachricht gemäß der vorliegenden Erfindung an.
Bei dem Schritt 1 fragt der globale Server 13, nachdem die Initialisierung des globalen Servers 13 selbst vervollständigt ist, nach der Registrierung von C-CAP von dem Vermittler 11 an. In diesem Fall wird C-CAP als ein Bestimmungsort für die Nachricht verwendet.
Bei dem Schritt 2 prüft der Vermittler 11, ob das von dem globalen Server 13 angefragte C-CAP basierend auf dem Namen des Servers und einem Attribut, welches von dem Server angefragt wurde, geeignet ist. Wenn das C-CAP geeignet ist, wird C-CAP in dem Vermittler 11 registriert. In diesem Fall wird das Attribut dem Vermittler 11 mit der Anfrage nach der Registrierung von C-CAP über die Nachrichtenkommunikationseinrichtung 12 mitgeteilt.
Bei dem Schritt 3 sendet der örtliche Server 14, nachdem dieser gestartet wurde, die Anfrage zu dem Vermittler 11, um einen Kommunikationspfad zu dem globalen Server 13 aufzubauen und erhält C-CAP von dem globalen Server 13. Zu einem früheren Zeitpunkt wurde der globale Server mit einer spezifizierten Identifizierung (ID) versehen, um dessen eigenen Server zu spezifizieren und diese ID wird durch den Vermittler 11 gemanagt. Demzufolge verwendet der örtliche Server diese ID, um das C-CAP des globalen Servers 13 zu gewinnen.
Bei dem Schritt 4 gibt der örtliche Server 14 das R- CAP an den globalen Server 13 aus. In diesem Fall ist der Bestimmungsort von R-CAP gegeben aus dem C-CAP des globalen Servers 13. Das R-CAP wird für die Nachrichtenkommunikation danach verwendet. Ferner managt der lokale Server 14 ein Volumen und informiert den globalen Server 13 über den Namen des Volumens. Das "Volumen" ist definiert als eine Managementeinheit von Daten, die in einer Datei gespeichert sind.
Bei dem Schritt 5 überprüft der globale Server 13 das Attribut des örtlichen Servers 14, der das R-CAP sendet und managt die Beziehung zwischen dem R-CAP und dem Volumennamen nach der Bestätigung des Attributs. Nach diesen Schritten ist der Kommunikationspfad zwischen dem globalen Server 13 und dem örtlichen Server 14 aufgebaut.
Bei dem Schritt 6 fragt der Klient 15 bei dem globalen Server 13 an, um die Datei des Volumens darzustellen. Der globale Server 13 sucht nach dem örtlichen Server, in welchern die Resource existiert, basierend auf dem Namen des Volumens. Wenn der richtige örtliche Server gefunden wurde, fragt der globale Server 13 nach einer Verarbeitung der Nachricht unter Verwendung des entsprechenden R-CAP.
Bei den Schritten 7 und 8 fragt der globale Server 13 bei dem örtlichen Server 14 an, um die Nachricht zu verarbeiten, und zwar unter Verwendung des entsprechenden R-CAP, und der örtliche Server 14 empfängt die Nachricht von dem globalen Server 13 und führt die Verarbeitung der Anfrage durch.
Fig. 7 ist eine Ansicht zur Erläuterung eines detaillierten Verfahrens zur Herstellung eines Kommunikationspfades, der in Fig. 6 gezeigt ist. Die gleichen Bezugszeichen, die in Fig. 6 verwendet sind, sind an die gleichen Komponenten in dieser Zeichnung angeheftet. Der Vermittler 11 besitzt eine Steuertabelle 11a und auch der globale Server 13 besitzt eine Steuertabelle 13a. Die Steuertabelle 11a enthält den Namen des Servers und den Bestimmungsort und die Steuertabelle 13a enthält den Namen des Volumens und den Bestimmungsort des örtlichen Servers.
Wenn bei dem Schritt 1 der globale Server (a) nach der Registrierung des C-CAP von dem Vermittler 11 anfragt, registriert der Vermittler 11 den globalen Server (a) (als den Namen des Servers) und die Leistungsfähigkeit C-CAP 1 des Bestimmungsortes in der Steuertabelle 11a.
Bei dem Schritt 2 informiert der örtliche Server 14 den Vermittler 11 über den Namen des Servers (globaler Server (a)), wenn der örtliche Server wünscht, C-CAP von dem globalen Server 13 zu erwerben.
Bei dem Schritt 3 informiert der Vermittler 11 den örtlichen Server 14 über einen Bestimmungsort (C-CAP) des globalen Servers 13, wenn der Vermittler 11 die Anfrage nach C-CAP von dem örtlichen Server 14 empfängt.
Bei dem Schritt 4 überträgt der örtliche Server 14 eine Nachricht an den globalen Server 13. In diesem Fall enthält die Nachricht das R-CAP, welches dessen eigenen Bestimmungsort angibt und auch den Namen des Volumens (Volumen α), das von ihm selbst gemanagt werden soll. Der globale Server 13 registriert den Namen des Volumens (Volumen α) und den entsprechenden Bestimmungsort des örtlichen Servers 14 in der Steuertabelle 13a. Das C-CAP 1 wird als Bestimmungsort verwendet.
Wenn bei dem Schritt 5 der Klient 50 wünscht, ein Volumen zu verarbeiten, vermittelt der Klient 50 eine Information über den Namen des Volumens (Volumen α) unter Verwendung des C-CAP als Bestimmungsort.
Wenn bei dem Schritt 6 der globale Server 13 eine Verarbeitungsanfrage von dem Klienten empfängt, prüft der globale Server 13 die Steuertabelle 13a und erhält den Bestimmungsort (R-CAP 1) des örtlichen Servers 14, der das Volumen α managt. Ferner informiert der globale Server 13 den örtlichen Server 14 über die Anfrage des Klientenservers 50.
Wie oben erläutert wurde, empfängt der örtliche Server 14 den Bestimmungsort (C-CAP 1) des globalen Servers 13 von dem Vermittler 11, fragt dann nach dem Aufbau des Kommunikationspfades an, und zwar unter Verwendung von C-CAP 1 von dem globalen Server. Es ist demzufolge möglich, willkürlich den Kommunikationspfad zwischen dem globalen Server und dem örtlichen Server aufzubauen. Es ist daher nicht erforderlich, daß der globale Server die festen Definitionsdaten für den örtlichen Server speichert und der globale Server kann die Startinformation des lokalen Servers asynchron empfangen, so daß es möglich ist, den Kommunikationspfad zwischen den Servern in einfacher Weise zu erstellen.
Fig. 8 zeigt ein grundlegendes Blockschaltbild zur Erläuterung des zweiten Aspektes der vorliegenden Erfindung. Die gleichen Bezugszeichen, die in Fig. 1 verwendet sind, sind an die gleichen Komponenten in dieser Zeichnung angeheftet. Das Bezugszeichen 15 bezeichnet einen Empfangsserver. Als ein Merkmal der Erfindung ist lediglich ein Empfangsserver 15 in dem zusammengesetzten Computersystem 10 vorgesehen, um Anfragen für die Verwendung der Resource von dem Klientenserver 50 zu empfangen.
Der Empfangsserver so ist gebildet durch eine Managementeinrichtung 15a, eine den Volumennamen ableitende Einrichtung 15b und eine Bestimmungsortdaten-Erwerbseinrichtung 15c. Die Managementeinrichtung 15a managt die Leistungsfähigkeit (capability) und den Namen des Volumens, welcher von dem globalen Server 13 gesendet wurde. Die den Volumennamen ableitende Einrichtung 15b leitet den Namen des Volumens ab, in welchem die Resource existiert, und zwar von dem Namen der Resource, die durch den Klienten 50 bezeichnet wurde. Die Bestimmungsortdaten-Erwerbseinrichtung 15c erwirbt die entsprechende Leistungsfähigkeit, indem sie nach der Managementeinrichtung 15a sucht, und zwar basierend auf dem Namen des Volumens, der von der Volumenname-Ableiteinrichtung 15b abgeleitet wurde.
Bei dem Schritt 1 informiert der globale Server 13 den örtlichen Server 14, 14' über die Vervollständigung der Verbindung des Volumens und fragt nach einem Eintrag des Volumens in den örtlichen Server 14, 14' an, um eine Umgebung zu schaffen, in der die Anfrage von dem Klienten 50 gehandhabt werden kann. Der Eintrag ist definiert als der Aufbau der Verbindung zwischen den Servern.
Bei dem Schritt 2 führt der örtliche Server 14 den Eintrag des Volumens in Abhängigkeit von der Anfrage nach dem Eintrag des Volumens von dem globalen Server 13 durch.
Bei dem Schritt 3, wenn der Eintrag des Volumens durch den örtlichen Server 14 vervollständigt ist, sendet der globale Server 14 die Leistungsfähigkeit (capability), welche den Bestimmungsort des in diesen eingegebenen Volumens anzeigt, aus.
Bei dem Schritt 4, wenn der globale Server 13 die Leistungsfähigkeit empfängt, die von dem lokalen Server 14 übertragen wurde, sendet der globale Server 13 die Leistungsfähigkeit und den Namen des Volumens an den Empfangsserver 15.
Die Managementeinrichtung 15a des Empfangsservers 15 managt die Leistungsfähigkeit und den Namen des Volumens, die von dem globalen Server 13 gesendet wurden. Wenn der Empfangsserver 15 die Anfrage empfängt, die Resource von dem Klienten 50 zu verwenden, leitet die den Volumennamen ableitende Einrichtung 15c den Namen des Volumens ab, in welchem die Resource existiert, und zwar von dem Namen der Resource, der durch den Klienten angezeigt wurde. Ferner erwirbt die Bestimmungsortdaten-Erwerbseinrichtung 15b die Leistungsfähigkeit des angefragten Volumens, und zwar durch Suchen nach der Managementeinrichtung 15a, basierend auf dem Namen des Volumens, der von der den Volumennamen ableitenden Einrichtung 15c abgeleitet wurde. Demnach gibt der Empfangsserver 15 die Anfrage nach der Verwendung des Volumens an den örtlichen Server 14 aus, und zwar durch Verwendung der Leistungsfähigkeit als Bestimmungsgröße. Bei der vorliegenden Erfindung ist es für den Empfangsserver möglich, unmittelbar den örtlichen Server zu spezifizieren, der das von dem Klienten angefragte Volumen managt, und zwar ohne Aussendung von irgendeiner Anfrage an den globalen Server und den örtlichen Server.
Fig. 9 zeigt eine Ansicht zur Erläuterung eines Betriebs der Kommunikation gemäß dem zweiten Aspekt der vorliegenden Erfindung.
In Fig. 9 sind die gleichen Bezugszeichen, wie sie in Fig. 8 verwendet sind, an die gleichen Komponenten in dieser Zeichnung angeheftet. Zuerst führt der globale Server 13 die Verarbeitung durch, um den Kommunikationspfad zwischen dem globalen Server 13 und dem örtlichen Server 1 aufzubauen, und auch zwischen dem globalen Server und dem Empfangsserver 15 aufzubauen.
Wie bei dem ersten Aspekt der vorliegenden Erfindung erläutert wurde, wird der Aufbau des Kommunikationspfades in solcher Weise durchgeführt, daß, nachdem die Initialisierung des globalen Servers 13 selbst vervollständigt ist, der globale Server 13 das C-CAP in dem Vermittler 11 (siehe Fig. 1) registriert, der örtliche Server 14 das C-CAP von dem globalen Server 13 von dem Vermittler 11 erwirbt, und zwar nachdem die Initialisierung vervollständigt ist, und der lokale Server 14 das R-CAP an den globalen Server 13 sendet, und zwar unter Verwendung von C-CAP als Bestimmungsgröße oder Bestimmungsort.
Bei dem zweiten Aspekt der vorliegenden Erfindung wird die Erstellung des Kommunikationspfades zwischen dem globalen Server 13 und dem Empfangsserver 15 auf der Grundlage der folgenden Schritte realisiert. Zuerst registriert der Empfangsserver 15, nachdem die Initialisierung des Empfangsservers 15 selbst vervollständigt ist, das C-CAP in dem Vermittler 11. Nachdem die Initialisierung des globalen Servers 13 vervollständigt ist, erwirbt der globale Server 13 das C-CAP des Empfangsservers 15 und sendet sein eigenes C-CAP zu dem Empfangsserver 15, und zwar unter Verwendung des erworbenen C-CAP als den Bestimmungsort oder Bestimmungsgröße. Ferner wird die Erstellung des Kommunikationspfades zwischen dem Klienten 50 und dem Empfangsserver 15 unter Verwendung des C-CAP des Empfangsservers 15 durchgeführt, welches in dem Vermittler 11 registriert ist.
Die in Fig. 9 gezeigten Verarbeitungsschritte werden nun im folgenden im einzelnen erläutert.
Bei dem Schritt 1 informiert der globale Server 13 den örtlichen Server 14 über die Vervollständigung der Verbindung, der nach der Verarbeitung angefragt hat. Die Informationsgabe wird für das Volumen durchgeführt, bei dem die Verbindung vervollständigt ist. Ferner fragt der globale Server 13 nach dem Eintrag des Volumens am lokalen Server 14 an, um die Voraussetzungen vorzubereiten, um die Anfrage von dem Klienten 50 zu handhaben. In diesem Fall wird die Nachrichtenkommunikation von dem globalen Server 13 zu dem örtlichen Server 15 unter Verwendung von R-CAP des örtlichen Servers 14 als Bestimmungsort oder Bestimmungsgröße durchgeführt.
Bei dem Schritt 2 führt der örtliche Server 14, wenn der örtliche Server 14 die Anfrage nach dem Eintrag des Volumens von dem globalen Server 13 empfängt, den Eintrag des Volumens durch, um die Voraussetzungen für die Verwendung des angefragten Volumens zu schaffen. Ferner gibt der örtliche Server 14 das R-CAP unter Verwendung des Bestimmungsortes des Volumens an den globalen Server 13 aus.
Bei dem Schritt 3 informiert der globale Server 13, wenn der globale Server 13 das R-CAP des Volumens von dem örtlichen Server 14 empfangen hat, den Empfangsserver 15 über das empfangene R-CAP und über den Namen des Volumens.
Bei dem Schritt 4 registriert der Empfangsserver 15, wenn der Empfangsserver 15 das R-CAP und den Namen des Volumens von dem globalen Server 13 empfangen hat, das R-CAP und den Namen des Volumens in einer R-CAP-Mangagementtabelle 30 (siehe Fig. 10).
Bei dem Schritt 5 gibt der Klient 50, nachdem der Kommunikationspfad zwischen dem Klienten 50 und dem Empfangsserver 15 aufgebaut ist, die Anfrage zur Verwendung der Resource an den Empfangsserver 15 aus, und zwar unter Verwendung des C-CAP des Empfangsservers 15 als Bestimmungsort.
Bei dem Schritt 6 erwirbt der Empfangsserver 15, wenn der Empfangsserver 15 die Anfrage zur Verwendung der Resource empfangen hat, das Volumen, in welchem die Resource existiert, und zwar basierend auf dem bezeichneten Resourcennamen unter Verwendung einer Namenauflöseeinrichtung (nicht gezeigt).
Bei dem Schritt 7 sucht der Empfangsserver 15, wenn der Empfangsserver 15 den Namen des Volumens erwirbt, in der R-CAP-Managementtabelle 30. In diesem Fall wird für die Suche der erworbene Volumennamen als ein Schlüsselwort verwendet. Der Empfangsserver 15 erwirbt das R-CAP von dem Volumen, welches dem Volumennamen entspricht.
Bei dem Schritt 8 gibt der Empfangsserver, wenn der Empfangsserver 15 das R-CAP des Volumens erworben hat, die Anfrage nach der Verwendung des Volumens an den örtlichen Server 14 aus, der die Resource managt, die von dem Klienten 50 angefragt wurde, und zwar unter Verwendung des erworbenen R-CAP des Volumens als Bestimmungsort.
Bei dem Schritt 9 startet der örtliche Server 14, wenn der örtliche Server 14 die Anfrage zur Verwendung der Resource empfangen hat, die Verwendung des Volumens.
Da, wie oben erläutert wurde, der Empfangsserver 15 das R-CAP des Volumens managt, welches der örtliche Server managt, kann der Empfangsserver 15 den örtlichen Server 14 spezifizieren, der das angefragte Volumen managt, und zwar ohne die Aussendung einer Anfrage zu dem globalen Server und den örtlichen Servern.
Fig. 10 ist eine Ansicht zur Erläuterung einer R-CAP- Managementtabelle in dem Empfangsserver gemäß dem zweiten Aspekt der vorliegenden Erfindung. Diese R-CAP-Managementtabelle wird dafür verwendet, um das R-CAP in dem Empfangsserver 15 zu registrieren, was bei dem Schritt 4 von Fig. 9 erläutert wurde. In Fig. 10 besitzt der Empfangsserver 15 eine Basissteuertabelle 31 und eine Vielzahl von R-CAP-Managementtabellen 30. Auf die Basissteuertabelle 31 wird von einem festen Bereich eines Raumes aus gezeigt und diese wird als ein Ankerpunkt verwendet. Die R-CAP-Managementtabellen 30 sind miteinander verbunden, und zwar in Form einer Kette. Jede R-CAP-Managementtabelle 30 managt ein R-CAP und den Namen eines Volumens. In diesem Fall sind R-CAP und der Name des Volumens durch das Volumen angezeigt, welches von dem globalen Server 13 gesendet wurde.
Fig. 11 zeigt ein Flußdiagramm zur Erläuterung der Registrierung in der R-CAP-Managementtabelle, die in Fig. 10 gezeigt ist. Dieses Flußdiagramm erläutert im einzelnen den Registrierungsprozeß bei dem Schritt 4 von Fig. 9.
Wenn die Managementeinrichtung 15a in dem Empfangsserver 15 die Nachricht des R-CAP von dem globalen Server 13 empfängt (Schritt 1), so erwirbt die Managementeinrichtung 15a exklusiv die Kette der R-CAP-Managementtabelle 30 (Schritt 2). Als nächstes sucht die Managementeinrichtung 15a in der R-CAP-Managementtabelle 30, um den gleichen Volumennamen wie den empfangenen Volumennamen zu finden. Das heißt, die Managementeinrichtung 15a definiert eine Kopfadresse der Kette als einen Parameter P (Schritt 3), um den gleichen Volumennamen wie den empfangenen Volumennamen zu finden, und sie beurteilt, ob der Parameter P einen NULL- Punkt anzeigt (Schritt 4) und, wenn der Parameter P kein NULL-Punkt ist (NEIN), beurteilt die Managementeinrichtung 15a, ob der Volumennamen der R-CAP-Managementtabelle der gleiche Volumennamen ist wie der empfangene Volumennamen oder nicht (Schritt 5). Wenn der Volumennamen der gleiche ist wie der empfangene Volumennamen (JA), ersetzt ein neues R-CAP das frühere R-CAP des Volumens in der R-CAP-Managementtabelle 30 (Schritt 6). Ferner gibt die Managementeinrichtung 15a die exklusive Steuerung der Kette der R-CAP- Managementtabelle 30 frei.
Beim Schritt 4 bereitet die Mangementeinrichtung 15a, wenn der Parameter P ein NULL-Punkt ist (JA) eine neue R- CAP-Managementtabelle vor (Schritt 9). Wenn ferner bei dem Schritt 5 der Volumenname der R-CAP-Managementtabelle nicht der gleiche ist wie der empfangene Volumenname (NEIN), wird der Parameter P auf eine neue Adresse erneuert (Schritt 8).
Fig. 12 zeigt ein Flußdiagramm zur Erläuterung des Suchschrittes in der R-CAP-Managementtabelle, die in Fig. 10 gezeigt ist. Diese Schritte erläutern im Detail den Suchprozeß bei den Schritten 5, 6 und 7 von Fig. 9. Wenn der Empfangsserver 15 die Anfrage empfängt, die Resource von dem Klienten zu verwenden (Schritt 1), erwirbt die Managementeinrichtung 15a in dem Empfangsserver 15 den Volumennamen basierend auf dem Resourcennamen von dem Klienten 50 (Schritt 2) und die Mangementeinrichtung 15b erwirbt exklusiv die Kette der R-CAP-Managementtabelle 30 (Schritt 3). Als nächstes sucht die Managementeinrichtung 15a die R- CAP-Managementtabelle 30, um den gleichen Volumennamen zu finden, wie der empfangene Volumennamen. Das heißt, die Mangementeinrichtung 15a definiert eine Kopfadresse der Kette als einen Parameter P (Schritt), um den gleichen Volumennamen wie den empfangenen Volumennamen zu finden und sie beurteilt, ob der Parameter P einen NULL-Punkt anzeigt oder nicht (Schritt 5) und, wenn der Parameter P kein NULL- Punkt ist (NEIN), beurteilt die Mangementeinrichtung 15a, ob der Volumenname der R-CAP-Managementtabelle der gleiche Volumenname ist wie der empfangene Volumenname oder nicht (Schritt 6). Wenn der Volumenname der gleiche ist wie der empfangene Volumenname (JA), führt die Managementeinrichtung 15b exklusiv den Erwerb der entsprechenden R-CAP-Managementtabelle durch (Schritt 7). Ferner gibt die Managementeinrichtung 15a die exklusive Steuerung der Kette der R- CAP-Managementtabelle 30 frei.
Bei dem Schritt 5 informiert die Managementeinrichtung 15a, wenn der Parameter P ein NULL-Punkt ist (JA) über die Nachricht, welche das Volumen nicht verwenden kann (Schritt 10). Wenn ferner bei dem Schritt 6 der Volumenname der R- CAP-Managementtabelle nicht dem empfangenen Volumennamen entspricht (NEIN), wird der Parameter P auf eine neue Adresse (Schritt 9) erneuert.

Claims

1. System zum Aufbauen eines Kommunikationspfades zwischen einem globalen Server und einer Vielzahl von örtlichen Servern und zum Senden einer Anfrage nach einer Verarbeitung einer Nachricht über den Kommunikationspfad in einem eng gekoppelten Computersystem, wobei das Aufbausystem folgendes enthält:

eine erste Leistungsfähigkeit (C-CAP), die von dem globalen Server (13) oder dem örtlichen Server (14, 14') zu einem willkürlichen Klienten ausgegeben wird, um eine Anfrage zu empfangen, die von dem willkürlichen Klienten gesendet wurde;

eine zweite Leistungsfähigkeit (R-CAP), die von dem globalen Server oder dem örtlichen Server an einen spezifizierten Server ausgegeben wird, um einen Kommunikationspfad aufzubauen, der eine Sicherheit einer Nachricht von dem spezifizierten Server garantiert;

eine Nachrichtenkommunikationseinrichtung (12) zum Übertragen der Nachricht zwischen dem globalen Server und dem örtlichen Server unter Verwendung der ersten und der zweiten Leistungsfähigkeit; und

eine Bestimmungs-Zwischenspeichereinrichtung (11) zum Registrieren der ersten Leistungsfähigkeit und um den örtlichen Server über die erste Leistungsfähigkeit zu informieren, um die Kommunikation zwischen dem globalen Server und dem örtlichen Server zwischenzuspeichern;

wobei der globale Server nach der Registrierung der ersten Leistungsfähigkeit von der Bestimmungsort-Zwischenspeichereinrichtung anfragt, der örtliche Server die erste Leistungsfähigkeit von der Bestimmungsort-Zwischenspeichereinrichtung erwirbt und der örtliche Server nach dem Aufbau des Kommunikationspfades von dem örtlichen Server zu dem globalen Server unter Verwendung der zweiten Leistungsfähigkeit anfragt.

2. System zum Aufbauen eines Kommunikationspfades nach Anspruch 1, ferner mit einem Empfangsserver (15) zum Empfangen einer Anfrage von einem Klienten (50) (requester), der eine Resource zu verwenden wünscht, wobei der globale Server (13) eine Fähigkeit zu dem Empfangsserver sendet und die den Bestimmungsort einer Volumendatei anzeigende Fähigkeit, die von dem örtlichen Server gesendet wurde und der Volumendatei entspricht.

3. System zum Aufbauen eines Kommunikationspfades nach Anspruch 2, bei dem der Empfangsserver eine Managementeinrichtung (15a) aufweist, um den Namen des Volumens und die von dem globalen Server übersandte Fähigkeit zu managen, eine Volumennamen-Ableiteinrichtung (15b) aufweist, um den entsprechenden Volmennamen von der Resource, die durch den Klienten (requester) angezeigt wurde, abzuleiten, und eine Bestimmungsort-Datenerwerbseinrichtung enthält, um die entsprechende Fähigkeit durch Suchen nach der Managementeinrichtung basierend auf dem Volumennamen, der von der Volumennamen-Ableiteinrichtung abgeleitet wurde, zu erwerben.

4. System zum Aufbauen eines Kommunikationspfades nach irgendeinem der vorhergehenden Ansprüche, bei dem die Bestimmungsort-Zwischenspeichereinrichtung (11) eine Steuertabelle (11a) enthält, die durch den Namen des Servers und den Bestimmungsort des Servers gebildet ist.

5. System zum Aufbauen eines Kommunikationspfades nach irgendeinem der vorhergehenden Ansprüche, bei dem der globale Server (13) eine Steuertabelle aufweist, die durch den Namen des Servers und den Bestimmungsort des lokalen Servers gebildet ist.

6. System zum Aufbauen eines Kommunikationspfades nach irgendeinem der Ansprüche 2 bis 5, bei dem der Empfangsserver ferner eine Vielzahl von R-CAP-Managementtabellen aufweist, um den Volumennamen und die Fähigkeit zu managen.