DE3852324T2

DE3852324T2 - Verfahren und System zur Netzwerkverwaltung.

Info

Publication number: DE3852324T2
Application number: DE3852324T
Authority: DE
Inventors: Donavon William Johnson; Larry Keith Loucks; Amal Ahmed Shaheen-Gouda
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-02-13
Filing date: 1988-01-26
Publication date: 1995-05-24
Anticipated expiration: 2008-01-27
Also published as: EP0278316A2; EP0278316A3; JPS63201860A; EP0278316B1; DE3852324D1; JPH0525333B2; US5133053A

Description

Diese Erfindung befaßt sich mit dem Informationsaustausch zwischen Vorgängen, die an unterschiedlichen Knoten in einem Datenverarbeitungsnetzwerk angeordnet sind. Jeder Knoten umfaßt einen Prozessor, der zum selbständigen Betrieb in der Lage ist, und kann andere Dienste umfassen, wie etwa Datenstationen, Speicher- und E/A-Geräte. Weiterhin kann jeder Prozessor zur Simultanverarbeitung und zum Multitaskingbetrieb fähig sein. Insbesondere befaßt sich die vorliegende Erfindung mit der Unterstützung eines warteschlangenbasierten Informationsaustausches zwischen Vorgängen, die am selben oder an einem unterschiedlichen Knoten im Netzwerk angeordnet sind, indem es für ein Programm nichtmehr notwendig ist, daß es den Knoten der Warteschiangen des Informationsaustausches kennt. Die Transparenz des Warteschlangenstandortes bei der Prozeßkommunikation (IPC) wird beschrieben, wie sie in einer Umgebung mit verteilten Diensten realisiert ist.
In The Design of the UNIX¹ Operating System von M. J. Bach (Prentice-Hall 1986) wird auf den Seiten 356 bis 367 beschrieben, daß die Prozeßkommunikation (IPC) erfolgen kann, indem der Systemaufruf zum Nachrichteneinholen (MSGGET) mit eineiu Schlüssel aufgerufen wird, der im systemresidenten Kern eine Durchsuchung eines Bereiches von Nachrichtenwarteschlangen aufruft und, falls er für den angegebenen Schlüssel keinen passenden Eintrag findet, eine neue Warteschlangenstruktur zuordnet und an den Benutzer eine Kennzeichnung zurückschickt. Die mit den Systemaufrufen MSGSND und MSGRCV verbundenen Algorithmen für das Absenden beziehungsweise Empfangen von Nachrichten werden beschrieben. Es gibt jedoch keine Beschreibung oder Vorschläge hinsichtlich der Unterstützung der Prozeßkommunikation zwischen Vorgängen, die an ¹ Warenzeichen von AT&T Bell Laboratoriesunterschiedlichen Knoten eines Netzes angeordnet sind.
Der RT²-Personalcomputer von IBM wird in dem Buch IBM RT Personal Cornputer Technology (Form Nr. SA23 - 1057) beschrieben. Darin wird die Betriebssystemstruktur Advanced Interactive Executive (AIX³) als eine Erweiterung der Konzepte des UNIX-Systems C von AT&T beschrieben.
Der AIX-Kern realisiert die Arbeitsumgebung für Anwendungsprogramme und Steuerbefehle. Eine ausführlichere Beschreibung von AIX befindet sich in AIX Operating System Technical Reference (Form Nr. SV21 - 8009). Diese Technologie ist nunmehr erweitert worden, damit eine Vielzahl von RT-PC-Systemen von IBM Knoten in eineni Datenübertragungsnetzwerk sein können und damit zusätzliche Merkmale bereitgestellt werden können.
Ein solches Merkmal besteht in der verteilten Verarbeitung innerhalb des Netzwerkes. Eine solche Umgebung mit verteilten Diensten umfaßt zwei oder mehr Knoten, die durch eine Datenübertragungsstrecke oder ein Datenübertragungsnetzwerk miteinander verbunden sind. Ein derartiges Netzwerk kann entweder ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) sein, das Datenfernverarbeitungsverbindungen zu anderen Knoten oder zu anderen Netzwerken umfaßt. Ein primäres Ziel der verteilten Dienste besteht darin, lokale/Fern-Transparenz für Anwendungen bereitzustellen, die das Dateisystem und die Dienste der Prozeßkommunikation des AIX-Betriebssystems benutzen.
"Distributed System V IPC in LOCUS: A Design and Implementation Retrospective" von B. D. Fleisch in Computer Communication Review, 5. bis 7. August 1986, Nr. 3, Stowe, Vermont, USA, beschreibt ein Netzwerkverwaltungssystem zur Prozeßkommunikation zwischen Benutzeranwendungsprogrammen in einem Netzwerk mit verteilten Diensten, das Prozessoren umfaßt, von denen sich jeder ² RT und RT PC sind Warenzeichen der IBM Corporation³ AIX ist ein Warenzeichen der IBM Corporationan einem unterschiedlichen Knoten befindet. Jeder Prozessor umfaßt speicherresidente Systembetriebsmittel und Programme zum Anlegen von und zum Zugriff auf Nachrichtenwarteschlangen. Jeder Prozessor ist in der Lage, eine Vielzahl von Benutzeranwendungsprogrammen auszuführen. Der Informationsaustausch zwischen den Prozessoren erfolgt über Warteschlangen, die an jedem beliebigen Knoten im Netzwerk angeordnet sind. Für alle Untersysteme der Interprozeßkommunikation innerhalb des Netzwerkes wird eine einzige Namendatenbank aufrechterhalten.
EP-A-201 063 beschreibt ein weiteres Netzwerkverwaltungssystem für Prozeßkommunikation zwischen Benutzeranwendungsprogrammen in einem Token-Ring-Netzwerk mit verteilten Diensten, das eine Vielzahl von Zellen umfaßt. Jede Zelle umfaßt speicherresidente Systembetriebsmittel und Programme zum Anlegen von und Zugreifen auf Nachrichtenwarteschlangen. Jede Zelle ist in der Lage, eine Vielzahl von Benutzeranwendungsprogrammen auszuführen. Der Informationsaustausch zwischen Zellen erfolgt über Warteschlangen. Ein nicht residenter Cache-Speicher für Prozeßnamen in jeder Zelle bezeichnet die nächste Zelle im Token-Ring, bei der ein genannter Prozeß zu finden ist.
Gemäß der vorliegenden Erfindung wird hier ein Verfahren zur Verfügung gestellt, mit dem der Informationsaustausch zwischen Denutzeranwendungen unterstützt wird, die an Prozessoren ausgeführt werden, die an einem oder mehreren Knoten in einem Netzwerk angeordnet sind, wobei Nachrichtenwarteschlangen benutzt werden, deren aktuelle Knotenstandorte für die Benutzerprogramme transparent sind, wobei das Verfahren die Schritte umfaßt: an jedem Knoten eine Schlüsselabbildungstabelle im Speicher aufrechtzuerhalten, das die den Anwendungen, die an jedem Knoten laufen, zugeordneten knotenelndeutigen Warteschlangenschlüssel mit dem aktuellen Knotenstandort der Warteschlange und den Schlüsseln der Nachrichtenwarteschlangen verbindet; mit einem von einer Anwendung bereitgestellten Schlüssel auf eine Schlüsselabbildungstabelle zugreifen, um den Knoten und den Schlüssel einer Nachrichtenwarteschlange zu erhalten und eine Datenübertragung zwischen dem Anwendungsknoten und dem Knoten der Nachrichtenwarteschlange aufzubauen.
Wenn man die vorliegende Erfindung unter einem anderen Aspekt betrachtet, so wird nun ein Netzwerkverwaltungssystem zur Verfügung gestellt, mit dem man den Benutzeranwendungsprogrammen in einem Netzwerk mit verteilten Diensten die Knotenstandorte einer Nachrichtenwarteschlange transparent machen kann, wobei das Netzwerk Prozessoren umfaßt, von denen sich jeder an einem verschiedenen Knoten befindet, wobei jeder Prozessor speicherresidente Systembetriebsmittel und Programme zum Anlegen von und zum Zugreifen auf Nachrichtenwarteschlangen umfaßt und jeder Prozessor in der Lage ist, eine Vielzahl von Benutzeranwendungsprogrammen auszuführen, wobei der Informationsaustausch zwischen den Prozessoren über Warteschlangen erfolgt, die an einem beliebigen Knoten innerhalb des Netzwerkes angeordnet sind, wobei das System dadurch gekennzeichnet ist, daß es umfaßt: von jedem Knoten aufrufbare Bibliotheksprogrammittel zur Zuordnung von knoteneindeutigen Schlüsseln zu jedem von einem Benutzeranwendungsprogramm bereitgestellten Warteschlangennamen; Tabellenlademittel, die beim Prozessoranlauf betriebsfähig sind, damit sie an jedem Knoten eine kernresidente Abbildungstabelle mit Einträgen bereitsteilen, welche die zugeordneten knoteneindeutigen Schlüssel mit den Knoten und Schlüsseln der Standorte der Nachrichtenwarteschlangen verbinden; und Mittel zum Empfang eines vom Benutzeranwendungsprogramm bereitgestellten Schlüssels, der den zugehörigen Standortknoten einer Nachrichtenwarteschlange fixiert und eine Datenübertragung zwischen dem Knoten des Benutzeranwendungsprogramms und einem Standortknoten einer zugehörigen Nachrichtenwarteschlange aufbaut, damit ein Nachrichtenübermittlungsvorgang erfolgen kann.
Die gegenwärtige Erfindung unterstützt den Informationsaustausch zwischen Prozessen, die sich an verschiedenen Knoten in einem Netzwerk befinden können, das mindestens zwei über eine Datenübertragung miteinander verbundene Systeme umfaßt. Jeder Knoten umfaßt einen Prozessor, der zur Simultanverarbeitung und zum Multitasking in der Lage ist. Wie nachstehend beschrieben, kann jeder Knotenprozessor ebenso selbständig betrieben werden.
An unterschiedlichen Knoten angeordnete Prozesse werden in die Lage versetzt, unter Verwendung von IPC-Warteschlangen miteinander zu kommunizieren, wobei deren tatsächliche Knotenstandorte dem Programm unbekannt sind, das den Informationsaustausch auslöst. Die vorliegende Erfindung ist gegenüber der Fähigkeit der AIX-IPC-Nachrichtenwarteschlange zum Informationsaustausch zwischen Prozessen im gleichen AIX-System ein Fortschritt, indem die Nachrichteneinrichtungen von AIX IPC dahingehend erweitert werden, daß sie zum Absenden und Empfangen von Nachrichten zwischen Warteschlangen an unterschiedlichen Knoten in der Lage sind. AIX unterstützt IPC, indem es die Systemaufrufe zur Nachrichteneinholung (msgget), zur Nachrichtenabsendung (msgsnd) und zum Nachrichtenempfang (msgrcv) benutzt. Die Nachrichteneinholung wird dafür benutzt, daß eine Nachrichtenwarteschlange zu finden oder anzulegen und ihre Kennzeichnung MSQID zurückzuschicken ist. Nachfolgende Aufrufe zum Absenden oder Empfangen von Nachrichten benutzen diese MSQID zum Kennzeichnen der Zielwarteschlange.
Die vorliegende Erfindung geht über eine Modifizierung am früheren Systemaufruf AIX msgget hinaus, indem weiterhin enthalten ist, daß sie einen Schlüssel einer spezifischen Warteschlange als Argument benutzt, um eine Funktion in einer vorherdefinierten kernresidenten Tabelle zu finden, die den Eingabeschlüssel mit dem aktuellen Schlüssel und dem Knotenstandort dieser spezifischen Warteschlange verbindet. Der Knotenstandort und der Schlüssel der Warteschlange, in der eine Nachricht eingereiht werden soll, sind für die Nachrichtenaustauschvorgänge transparent.
Wenn sich die Warteschlange in einem entfernten Knoten befindet, dann benutzen die beiden Knoten eine zwischen ihnen eingerichteten Datenübermittlungsabschnitt, um die Information der Warteschlangenelemente zu übergeben. Beschreibungsgemäß benutzt die bevorzugte Ausführungsform der Erfindung die Systems Network Architecture (SNA) 6.2 Advanced Program to Program Communication von IBM.
Die IPC-Nachrichtenwarteschlangen werden mit einem Schlüssel gekennzeichnet, einem Zahlenwert, der beim Anlegen der Warteschlange zugeordnet wird. Jeglicher Vorgang, der Zugriff zu einer spezifischen Warteschlange haben möchte, muß auf solche Art darauf Bezug nehmen, daß die Bezugnahme beim aktuellen Warteschlangenkennzeichen aufgelöst werden kann.
Wie nachstehend beschrieben, wird die bevorzugte Ausführungsform der vorliegenden erfindungsgemäßen Verfahrensweise bei der Betriebssystemebene realisiert, wo Einrichtungen für verteilte Dienste zur Verfügung gestellt werden. Die vorliegende Erfindung erfordert es, daß jeder Systemknoten in einem Netzwerk seinen eigenen Profilnamenbereich der IPC-Warteschlangen für Schlüssel hat. Vom Aufruf eines Anwendungsprogramms wird ein knoteneindeutiger Schlüssel an ein Bibliotheksprograrnm zurückgegeben, das einen knoteneindeutigen Schlüssel mit einem vom Aufrufer gegebenen Warteschlangennamen verbindet.
Die vorliegende Erfindung erfordert auch Schlüsselabbildungstahellen (KMT), die im Kern jedes Systems resident sind. Jeder Eintrag in eine Schlüsselabbildungstabelle umfaßt den örtlichen Schlüssel, der sich auf eine spezifische Warteschlange bezieht, den Knoten, in dem sich die Warteschlange augenblicklich befindet, und den an dem Knoten verwendeten Schlüssel, wo sich die Warteschlange augenblicklich befindet. Die KMTs werden zum Zeitpunkt des Systemanlaufs in den Kern jedes Knotens geladen.
Die KMT-Daten werden von einem Netzwerkverwalter aufrechterhalten, der das Netzwerk beaufsichtigt. Vom Netzwerkverwalter werden je nach Bedarf Veränderungen an den KMTs durchgeführt. Diese administrative Einbeziehung des Bedieners ermöglicht eine Transparenz der Nachrichtenwarteschlangen an der Anwendungsschnittstelle.
Wie in dem Buch von Bach beschrieben, kommunizierten die Prozesse früher dadurch, daß unter Verwendung von Nachrichtenwarteschlangen Nachrichten abgesandt und empfangen wurden. Der aufrufende Prozeß muß die Warteschlange identifizieren, in welcher der empfangende Prozeß erwartet, Nachrichten zu finden. Bei dezentralen Simultanverarbeitungssystemen sind alle Warteschlangenstandorte bekannt. In einer Netzwerkumgebung mit verteilten Diensten ist es für die Vorgänge jedoch wünschenswert, über Nachrichtenwarteschlangen, die sich am gleichen oder an einem verschiedenen Knoten befinden können, mit Vorgängen zu kommunizieren, die sich an anderen Knoten befinden können. Es wäre unannehmbar, von jedem Vorgang zu fordern, daß er für alle Nachrichtenwarteschlangen im Netzwerk implizit die Standortinformation kennt. Wenn dies gefordert würde, dann wären bei jedem Aufrufvorgang immer dann Veränderungen notwendig, wenn sich der aktuelle Standort der Nachrichtenwarteschlange geändert hat.
Die vorliegende Erfindung löst dieses Problem, indem sie kernresidente Tabellen einführt, die Warteschlangenschlüssel an diesem Prozessorknoten mit dem aktuellen Schlüssel und dem Knotenstandort der Nachrichtenwarteschlange verbinden. Diese Tabellen können von einem Netzwerkverwalter geändert werden, um die Veränderungen am aktuellen Knotenstandort der Nachrichtenwarteschlange widerzuspiegeln. Die vom aufrufenden Vorgang bereitgestellten Eingabeparameter ändern sich nicht. Deshalb sind an der Schnittstelle des Anwendungsprogramms die aktuellen Knotenstandorte von Nachrichtenwarteschlangen transparent.
Auf der Kernebene erfolgt die Adressenauflösung zum aktuellen Kennzeichen der Nachrichtenwarteschlange. Die KMTs empfangen als Eingabe einen Schlüssel und stellen für die gewünschte Warteschlange eine Schlüssel- und Knoten-id zur Verfügung. Die Systemaufrufroutinen innerhalb eines Kerns jedes derart verbundenen Knotens nehmen den Schlüssel, der von dem den Informations- austausch auslösenden Vorgang bereitgestellt wird, und gehen zu dem entsprechenden Schlüssel und Knoten. Wenn in der Kennsatztabelle der Warteschlangen dieses Knotens eine Nachrichtenwarteschlange mit dieser Kennzeichnung nicht auffindbar ist, dann wird eine neue angelegt, wenn der Aufrufer das Anlegen einer Warteschlange fordert, und die Kennzeichnung dieser Nachrichtenwarteschlange wird an den Kern des aufrufenden Knotens zurückgeschickt. Im Kern des aufrufenden Knotens wird eine neue Aliaseintragung des Warteschlangenkennsatzes aufgebaut, die den aktuellen Knotenstandort und das Kennzeichen der Nachrichtenwarteschlange umfaßt. Die Anwendung ist dann in der Lage, ihre Nachricht in der beabsichtigten Nachrichtenwarteschlange unterzubringen.
Es ist eine Aufgabe der gegenwärtigen Erfindung, für Nachrichtenwarteschlangen ein wirkungsvolles Handhabungssystem mit Transparenz des Knotenstandortes, Mittel zur Vermeidung des Zuordnens von sich widersprechenden Warteschlangennamen und Mittel zur Entschachtelung von Nachrichten in einer Warteschlange von einem gegebenen Dienstprogramm aus einer Vielzahl von Mandanten zur Verfügung zu stellen.
Diese und andere Merkmale und Vorteile der Erfindung, die in den beigefügten Ansprüchen definiert ist, werden aus der folgenden Beschreibung im Zusammenhang mit den zugehörigen Zeichnungen besser augenscheinlich, wobei:
Figur 1 eine schematische Darstellung eines Netzwerkes mit einer Vielzahl von Knoten ist, in dem die vorliegende Erfindung realisiert sein kann.
Figur 2 zeigt das Ebrmat eines Eintrags in einer Schlüsselabbildungstabelle.
Figur 3 zeigt den Inhalt eines Eintrags in einer Warteschlangenkennsatztabelle.
Figur 4 zeigt das Format eines Nachrichtenwarteschlangeneintrags.
Figuren 5A, 5B und 5C zeigen den logischen Ablauf während der Prozeßkommunikation.
Figur 6 zeigt das Beispiel einer Prozeßkommunikation mit hypothetischen Werten.
Unter Bezugnahme auf Figur 1 wird nun ein Netzwerk erläutert, in dem die vorliegende Erfindung ausgeführt wurde. Es ist ein Netzwerk 10 dargestellt, das eine Vielzahl von Knoten A, B und C umfaßt, die über einen Datenübermittlungsabschnitt 30 verbunden sind. Jeder Knoten A, E, C umfaßt mindestens einen Prozessor 40, der multitasking- und simultanverarbeitungsfähig ist, dem als dezentrales System oder als Teil des Netzwerkes 10 arbeiten kann.
Es wird ein Nachrichtennetzwerk 30 dargestellt, das aus einem lokal es Netzwerk oder aus einem Weitverkehrsnetz bestehen kann, aber die bevorzugte Ausführungsform realisiert die IBM Systems Network Architecture zum Aufbau von Datenübertragungen zwischen den Knoten A, B und C. Jeder Knoten umfaßt mindestens einen Prozessor 40, für den Benutzeranwendungen 42 geschrieben wurden. Im Inneren des Prozessors 40 werden die Prozesse 44 durch ein Betriebssystem 46 gesteuert, das in der bevorzugten Ausführungsform das AIX von IBM ist. Die Beschreibungen der verschiedenen ebenfalls anhängigen gemeinsam übertragenen Anmeldungen, die durch Bezugnahme hierin enthalten sind, umfassen die Beschreibungen der verschiedenen Aspekte des Systems, in dem die vorliegende Erfindung ausgeführt ist. Die gegenwärtige Beschreibung ist auf diejenigen Aspekte der Netzwerkkonfiguration 10 beschränkt, die eine spezifische Bedeutung für die Erfindung haben.
Mit jedem Prozessor 40 sind verschiedene Arten von Speichermedien verbunden, wie sie bei 48 dargestellt sind. Die verschiedenen Datenend- Speicher- und peripheren E/A-Geräte, die mit jeden Prozessorknoten in einem Netzwerk verbunden sein können, werden nicht dargestellt, sind jedoch in der Netzwerkkonfiguration 10 mit inbegriffen. Im Inneren des Betriebssystems 46 befindet sich bei jedem Prozessor 40 ein Kern 50.
Die Beschreibung anderer Aspekte der Erfindung bezieht sich ebenfalls auf die Figur 1.
Jeder autonome Knoten A, B, C kann mit einem anderen zusammenarbeiten, um die an einem anderen Knoten verfügbaren Betriebsmittel für die Durchführung einer gegebenen Aufgabe gemeinsam zu benutzen. Bei einer solchen Umgebung mit verteilten Diensten ist ein minimaler Benutzerdialog erforderlich, um die Möglichkeiten vorteilhaft zu nutzen, die von der gegenwärtigen Erfindung zur effizienten Nachrichtenhandhabung durch die Transparenz der Standorte der Nachrichtenwarteschlangen geboten werden. Die gemeinsame Benutzung von Betriebsmitteln vermindert die Notwendigkeit, Information an jedem Knoten im Netzwerk zu wiederholen.
Der Informationsaustausch zwischen Prozessen ist effizienter, und für die Einzelheiten des Informationsaustausches sind weniger Benutzeraufrufe erforderlich, da der Knotenstandort der Warteschlangen des Nachrichtenaustausches für das Benutzerprogramm transparent ist. Obwohl sich der aktuelle Knotenstandort einer gegebenen Warteschlange verändern kann, wird der Benutzer eines gegebenen Knotens von der Verantwortung befreit, den Standort der Warteschlangen zu verfolgen. Eine Funktion des Netzwerkverwalters besteht darin, einen aktuellen Satz von Profilen aufrechtzuerhalten, welche die Warteschlangenschlüssel und den Standort miteinander verbinden, und die entsprechende Verbindungsinformation in die KNT in den Kern 50 jedes Knotens im Netzwerk zu laden.
Im Betriebssystem 46 für jeden Prozessorknoten in der Netzwerkkonfiguration 10 sind Verzeichnisdienstfunktionen inbegriffen, die für die vorherdefinierten Warteschlangen erforderliche Information aufrechterhalten. Diese Funktionen umfassen das Anlegen eines IPC-Schlüssels, die Definition seines Standortes und die Auflösung der externen IPC-Warteschlangennamen in einen Schlüssel für eine spezifische Nachrichtenwarteschlange und die Rücksendung des Netzwerkstandortes und der entfernten Warteschlange von dem Knoten, von dem die Nachricht kommen wird.
Ein Verzeichnis der Warteschlangenprofile, dessen Format bei 52 in Fig. 1 erläutert ist, wird als Ergebnis der Ausführung einer Bibliotheksroutine zur Anlage von IPC-PROF angelegt, die vom Installationsprogramm einer Anwendung aufgerufen wurde. Das Programm liefert einen Warteschlangennamen, der bis zu 14 Zeichen lang sein kann, und die Bibliotheksroutine legt das Profilverzeichnis an und ordnet einen numerischen INKEY-Wert zu, der für diesen Knoten eindeutig ist. Zum Zeitpunkt des Systemanlaufs liest das System die Profile und legt die KNT mit den Einträgen an, wie es in Figur 2 dargestellt ist, wobei der örtliche Schlüssel LKEY, der von der Bibliotheksroutine zugeordnet wird, und der aktuelle Schlüssel RKEY und der aktuelle Knoten RNODE für die vom LKEY bezeichnete Warteschlange enthalten sind.
Figur 3 zeigt das Format eines Verzeichnisses der Warteschlangenkennsätze. Ein Prozeß im Dienstprogramm gibt zum Zeitpunkt des Anlaufs einen Warteschlangennamen an find_IPC_PROF ein und empfängt den mit dieser Warteschlange verbundenen Schlüssel. Der Prozeß des Dienstprogramms gibt dann einen Systemaufruf heraus, msgget, indem er einen Schlüssel zur Verfügung stellt, und msgget legt die Warteschlange an.
Der Datensatz der Warteschlangenkennsätze in Figur 3 enthält einen Anzeiger dafür, ob die spezifische Warteschlange lokal, L, zu dem Knoten ist, an dem sich die Tabelle der Warteschlangenkennsätze befindet, oder ob sie an einem entfernten Knoten, R, angeordnet ist. Das Format des restlichen Eintrags in der Tabelle der Warteschlangenkennsätze ist eine Funktion des lokalen/- entfernten Anzeigers. Wenn die Warteschlange lokal ist, dann enthält LKEY den lokalen Warteschlangenschlüssel; und LMTYPE ist der Wert des Nachrichtentypanzeigers, der für diese Warteschlange zuletzt benutzt wurde.
Bei entfernten Warteschlangen enthält RNODE die Knoten-id und RMODE MSQID die Nachrichtenwarteschlangen-id am entfernten Knoten. Das Feld RNODE BOOTCNT enthält eine Nummer, die den Status des Leistungszyklus beim entfernten Knoten anzeigt.
Figur 4 erläutert den Inhalt-eines Eintrags der Nachrichtenwarteschlange. MTYPE enthält den Typ der Nachricht und MSGPTR einen Zeiger auf den Nachrichtentext.
Figur 5 ist ein Flußdiagramm, das die logischen Abläufe erläutert, die während IPC erfindungsgemäß ausgeführt werden. Wenn ein Prozeß am Knoten LOCNODE einen Informationsaustausch initialisiert, dann gibt er einen Systemaufruf msgget heraus, der einen LKEY als Eingabe liefert, wie es bei Block 80 dargestellt ist. Dieser Schlüssel ist das Argument für eine Suchfunktion in der kernresidenten KMT von LOCNODE. Die KMT wird durchsucht, Block 82. Wenn ein Gegenstück gefunden wird, Block 84, dann bestimmt die IPC-Logik, Block 86, ob eine Datenübertragung zwischen LOCNODE und REMNODE existiert (bei dieser Diskussion wird hier angenommen, das RNODE die Knoten-id für REMNODE enthält). Wenn es keine existierende Datenübertragung gibt, dann wird eine eingerichtet, Block 88, und der in der KMT gefundene zugehörige Schlüssel RKEY wird an seinen zugehörigen Knoten REMNODE geschickt, Block 90.
Wenn für den LKEY, der zum Aufruf von msgget benutzt wurde, in der KMT kein Eintrag gefunden wurde, dann wird angenommen, daß die Nachrichtenwarteschlange örtlich ist, Block 92, und der Informationsaustausch erfolgt auf die übliche Weise.
Bei Block 94 empfängt das msgget-Transaktionsprogramm von REMNO- DE RKEY und durchsucht dann, Block 96, die Warteschlangenkennsätze bei REMNODE. Wenn kein Gegenstück gefunden wurde, Block 98, dann existiert eine Febierbedingung, und dies wird bei Block 100 angezeigt. Wenn die Warteschlangenkennsätze von REMNODE einen zu RKEY passenden Eintrag enthalten, dann wird an LOCNODE eine MSQID mit der Bootzählung von RENNODE, RNODE BOOTCNT, Block 102, zurückgeschickt.
Nach der Rückkehr zu LOCNODE wird, wie bei Block 104 dargestellt, ein Warteschlangen-Kennsatzeintrag im Format R (siehe Fig. 3) der Liste LOCNODE-Warteschlangenkennsätze hinzugefügt, und die MSQID des örtlichen Knotens wird an den Aufrufer zurückgeschickt. Der aufrufende Prozeß führt dann msgsnd aus, und es gilt die in Fig. 5B dargestellte Logik.
Bei LOCNODE wird MSQID, Block 110, dazu benutzt, in der Liste der Warteschlangenkennsätze von LOCNODE zu indizieren, Block 112. Bei Block 114 wird eine Bestimmung durchgeführt, ob REMNODE (RNODE im Warteschlangenkennsatz) schon mit LOCNODE verbunden ist. Wenn nicht, wird eine Verbindung hergestellt, Block 116, und LOCNODE msgsnd veranlaßt, daß der Nachrichtentext, MSQID RNODE BOOTCNT und ein MTYPE an REMNODE, Block 118, abgeschickt werden.
Bei REMNODE empfängt sein msgsnd-Transaktionsprogramm MSQID, BOOTCNT und MTYPE bei Block 120. REMNODE empfängt diese Daten und vergleicht zuerst, Block 122, die empfangene mit der bei REMNODE aktuellen Bootzählung. Wenn sie nicht zusammenpassen, dann existiert eine Fehlerbedingung, Block 124, und sie wird an LOCNODE zurückgeschickt. Wenn die Bootzählungswerte passen, dann benutzt das msgsnd-Transaktionsprogramm von REMNODE MSQID, um einen Warteschlangenkennsatz auszuwählen und den Zeiger des Nachrichtentextes MSGPTR zusammen mit dem MTYPE, Block 126, in seiner Nachrichtenwarteschlange unterzubringen. REMNODE antwortet LOCNODE, Block 128, der dann zu seinem Aufrufer, zum erfolgreichen Abschluß zurückkehrt.
Fig. 5C erläutert den Vorgang des msgrcv-Systemaufrufs. Bei LOCNODE empfängt msgrcv eine MSQID und MTYPE, Block 140. Es benutzt die MSQID, um in seiner Liste der Warteschlangenkennsätze zu indizieren und den richtigen Warteschlangenkennsatz zu finden. Unter Verwendung der RNODE-Information, die im Kennsatz enthalten ist, bestimmt es, Block 144, ob mit REMNODE eine Verbindung zum Informationsaustausch existiert, und wenn nicht, stellt er eine Verbindung her, Block 146. Bei Block 148 werden MSQID, RNODE BOOTCNT und MTYPE über den aufgebauten Datenübermittlungsabschnitt an RENNODE geschickt.
Nachdem das msgrcv-Transaktionsprogramm von REMNODE diese Information empfangen hat, Block 150, vergleicht es zuerst die Bootzählungswerte (empfangene und aktuelle), Block 152. Wenn die Bootzählungen nicht zueinander passen, dann wird eine Fehlerbedingung angezeigt, Block 154, und es erfolgt eine Rückkehr zu LOCNODE.
Wenn die Bootzählungen zueinander passen, dann benutzt die Logik des msgrcv-Transaktionsprogramms von REMNODE, Block 156, die empfangene MSQID, um einen Warteschlangenkennsatz auszuwählen. Die Logik prüft dann die Nachrichteneinträge der Warteschlange um zu bestimmen, ob es eine Nachricht mit dem passenden MTYPE gibt, Block 158. Wenn in der Nachrichtenwarteschlange von REMNODE keine Nachricht einen passenden MTYPE hat, dann erwartet die Logik die Ankunft einer Nachricht, Block 160. Wenn eine Nachricht mit einem passenden MTYPE gefunden wird, dann wird bei Block 162 der Zeiger des Nachrichtentextes über die gleiche Datenübertragung an LOCNODE zurückgeschickt, die oben schon aufgebaut wurde. LOCNODE schickt bei Block 164 den Nachrichtentext zu seinem Aufrufer zurück.
Fig. 6 erläutert unter Verwendung eines spezifischen Satzes von hypothetischen Umständen die Logik, die in Verbindung mit den Figuren 5A, B und C beschrieben wird. Es wird angenommen, daß es bei LOCNODE ein Rahmen-Befehlsprogramm gibt, das Benutzer aufrufen, um Konferenzräume zu planen. Der Rahmenbefehl gibt für seinen LKEY 71000 eine msgget aus, damit er für die IPC-Nachrichtenwarteschlange des Planungsdämons eine MSQID erhält. Es wird angenommen, daß der Netzwerkverwalter bestimmt hat, daß Anforderungen von Konferenzräumen von LOCNODE vom Dämon in REMNODE bedient werden, und daß der Schlüssel für die Warteschlange des Dämons in REMNODE 67000 ist. Diese Information ist in die IPC- KMT des Kerns von LOCNODE geladen worden.
1. get_room ruft MSGGET mit Schlüssel 71000 auf.
2. MSGGET fragt bei der KNT von LOCNODE nach dem Schlüssel 71000 nach.
3. Die KMT zeigt an, daß där Schlüssel 71000 im RNODE REMNODE zum RKEY 67000 neu abgebildet worden ist.
4. MSGGET weiß nun, daß es in REMNODE nach Schlüssel 67000 suchen muß.
5. MSGGET findet oder erstellt eine SNA-Verbindung mit REMNODE und sendet eine Netzwerknachricht, die eine MSQID für Schlüssel 67000 abfordert.
6. Das MSGGET-Transaktionsprogramm in REMNODE findet den Kennsatz der Nachrichtenwarteschlange für diejenige Warteschlange, deren Schlüssel 67000 ist; in diesem Falle ist MSQID 2;
7. das MSGGET-Transaktionsprogramm in REMNODE sendet an MSGGET in LOCNODE eine Netzwerkantwort mit der Feststellung, daß MSQID 2 ist;
8. MSGGET fügt seiner Liste der Warteschlangenkennsätze einen Eintrag hinzu. Der Kennsatzeintrag enthält unter anderem REMNODE in RNODE, wobei 2 die RNODE MSQID ist, und ein Etikett R, das angibt, daß dies ein lokaler "Ersatz" für einen entfernten Warteschlangenkennsatz ist. In diesem Beispiel befindet sich der Ersatzkennsatz für die entfernte Warteschlange in Fach 1 der Liste der Warteschlangenkennsätze von LOCNODE, so daß die LOCNODE MSQID 1 ist;
9. MSGGET schickt MSQID=1 an seinen Aufrufer zurück.
10. get_room benutzt diese MSQID dazu, IPC-Nachrichten an den Dämon der Konferenzräume zu schicken. Die Information im Ersatz des Warteschlangenkennsatzes teilt LOCNODE mit, wohin er die Nachrichten zu senden hat.
Das Folgende ist eine Pseudocode-Darstellung des logischen Ablaufs, wie er im Zusammenhang mit den Fig. 5A, B, C und 6 beschrieben wird:
Die Zuordnung der Warteschlangenschlüssel muß so verwaltet werden, daß für "wohlbekannte" Warteschlangen, also solche, die wahrscheinlich von vielen Mandanten benutzt werden, keine doppelten Schlüssel angelegt werden. Gemäß der vorliegenden Erfindung wird eine Strategie zur Verfügung gestellt, mit der Erzeuger von Anwendungsprojekten in die Lage versetzt werden, global eindeutige Schlüssel anzulegen, ohne daß die Notwendigkeit besteht, die zugeordneten Schlüssel extern zu registrieren. Das Hauptelement dieser Strategie ist die Verwendung eines Warteschlangennamens mit 14 alphanumerischen Zeichen im Eintrag des Warteschlangenprofils (Fig. 1, 52).
Die Anwendungsentwickler wählen Namen mit 14 Zeichen, die sich selbst eindeutig darstellen. Jeder Eintrag im Warteschlangenprofil hat die folgenden Felder: QNAME, LKEY, RNODE, PKEY, wie in Fig. 1 dargestellt.
Die Bibliotheksroutine create_ipc_prof (QNAME, LKEY, RKEY, NICK- NAME) legt ein Warteschlangenprofil an. Der Aufrufer stellt den Namen zur Verfügung, und die Routine legt einen Eintrag im Warteschlangenprofil an, ordnet ihm einen eindeutigen lokalen Schlüssel zu und schickt den lokalen Schlüssel an den Aufrufer zurück. Nachfolgend stellt der Netzwerkverwalter Daten für RNODE und RKEY zur Verfügung.
Es wird angenommen, daß eine verteilte Anwendung aus einem Serverdämon und einem Befehlsprogramm besteht, das Anforderungen an das Dienstprogramm hat. Das Dienstprogramm befindet sich an einem spezifischen Netzwerkknoten; das Befehlsprogramm kann an jedem beliebigen von mehreren Knoten im Netzwerk betrieben werden. Die Installation und der Betrieb einer solchen Anwendung werden im folgenden Beispiel erläutert.
An der Stelle, wo der Dämon betrieben werden soll, ruft das Installationsprogramm der Anwendung create_ipc_prof(3) auf, was einen Warteschlangennamen von "ACMEsfwr032686" vergibt. Das von create_ipc_prof(3) angelegte Profil enthält:
Name "ACMEsfwr032686"
lokaler Schlüssel Ein Wert, der von create_ipc_prof(3) aus dem Bereich 0x30000 bis 0xFFFFF ausgewählt wurde, der mit einem beliebigen anderen Profil an diesem Knoten nicht in Konflikt kommt
entfernter Knoten Null
entfernter Schlüssel 0
An jeder Stelle, an der das Befehlsprogramm betrieben werden soll, ruft das Installationsprogramm der Anwendung create_ipc_prof(3) auf, das einen Warteschlangennamen von "ACMEsfwr032686" vergibt. Das von create_ipc_prof(3) angelegte Profil enthält:
Name "ACMFsfwr032686"
örtlicher Schlüssel Ein Wert, der von create_ipc_prof(3) aus dem Bereich 0x30000 bis 0xFFFFF ausgewählt wird, der mit einen anderen beliebigen Profil an diesem Knoten nicht in Konflikt kommt.
entfernter Knoten Null
entfernter Schlüssel 0
Der Netzwerkverwalter ist über das Modifizieren der Profile an den Befehlsknoten unterrichtet, damit sie enthalten:
entfernter Knoten Der Knoten der Gottheit
entfernter Schlüssel Der örtliche Schlüssel der Warteschlange am Knoten der Gottheit
Wenn der Dämon anläuft, ruft sie find_ipc_prof(3) auf und gibt einen Warteschlangennamen "ACMEsfwr032686" vor, damit der mit diesem Namen verbundene Schlüssel gefunden wird. Dann ruft sie msgget (Schlüssel,0) auf, um für die Warteschlange eine id zu erhalten.
Ein Warteschlangenname mit 14 Zeichen läßt den Softwareentwicklern bei der Auswahl von Warteschlangennamen sehr viele Wahlfreiheiten. Sogar ohne Zusammenarbeit zwischen Anwendungsentwicklern besteht eine sehr geringe Wahrscheinlichkeit, daß ein von einem Entwickler sorgfältig ausgewählter Name mit einem von einem anderen sorgfältig ausgewählten Namen kollidiert. Ein vorsichtiger Entwickler könnte jedoch seinen Entwurf so wählen, daß der Fall einer Kollision eintritt. Eine beispielhafte Strategie für den Umgang mit solchen Kollisionen besteht darin:
* Der bevorzugte Warteschlangenname wird im Anwendungsprogramm fest codiert, aber es kann durch ein Befehlsargument sowohl des Dämons wie den Befehlsprogrammen eine Überschreibkette zur Verfügung gestellt werden.
* Wenn ein Dämon oder ein Befehlsprogramm installiert werden, dann benutzt es create_ipc_prof(3) dazu, die notwendigen Warteschlangenprofile anzulegen. Wenn das Anlegen wegen einer Namenkollision mißlingt, dann wird dem Verwalter ein eindeutiger Warteschlangenname abgefordert. Das Installationsprogramm benutzt dann diesen Warteschlangennamen, um das Profil anzulegen.
* Das Installationsprogramm und/oder die Dokumentation weisen den Verwalter an sicherzustellen, daß der Dämon und das Befehlsprogramm immer mit dem Argument des Warteschlangennamens aufgerufen werden.
Es wird nun die Verfahrensweise beschrieben, die dafür eingerichtet wurde, daß eine korrekte Nachrichtenvermittlung erfolgt. Bei einer dezentralen Anwendung, wie sie in der oben erwähnten Quelle von Bach beschrieben ist, wird der Parameter MTYPE geeignet festgelegt, damit der Kern die erste Nachricht eines gegebenen Typs zurückschicken kann. Wenn keine Nachrichten in der Warteschlange dem Typ genügen, dann legt der Kern den Vorgang schlafen. Die Vorgänge können zusammenarbeiten, damit sie an einer Nachrichtenwarteschlange mehrfache Kanäle einrichten, wodurch jeder Vorgang Nachrichten mit spezifischen Typen in der Reihenfolge ihrer Ankunft extrahieren kann, wobei der Kern die richtige Reihenfolge aufrechterhält.
In einer Netzwerkumgebung mit verteilten Diensten ist es jedoch für mehrere Anforderer möglich, sich gleichzeitig mit demselben Dienstprogramm zu befassen. Die vorliegende Erfindung bietet unter Verwendung des Nachrichtentyps eine Entschachtelungsfunktion von Antwortnachrichten.
MTYPE-Werte sollen als eindeutig zugeordnet werden, indem sie im Kennsatz der Nachrichtenwarteschlange (Fig. 3) einen MTYPE-Wert von 32 Bit zur Verfügung stellen, der dem letzten verwendeten MTYPE-Wert entspricht. Ein neuer Befehl zum Aufruf des Nachrichtensteuersystems (msgctl) veranlaßt, daß der aktuelle Wert des Nachrichtentyps einer Warteschlange zurückgeschickt wird. Jedesmal, wenn MTYPE an einen Vorgang (Fig. 5B, Block 128) zurückgeschickt wird, wird es nachinkrementiert.
Da es für Anforderungen und Antworten effizienter ist, durch die gleiche Warteschlange zu laufen, erweitert die für MTYPE bei der Entschachtelung von Vorwärts-Rückwärts-Warteschlangen getroffene Vereinbarung den Netzwerkdurchsatz noch mehr.
Das folgende Scenario erläutert ein potentielles Problem in Form eines Beispiels. In den Vorgang des Anlegens einer Warteschlange, deren Kennzeichnungsinformation in das erste Fach der Warteschlangenkennsätze eingeht, wird ein Dienstprogramm eingeschaltet. Ein Mandant vollführt eine msgget, wobei er eine MSQID empfängt. In der Zwischenzeit durchläuft das Dienstprogramm einen Leistungszyklus. Zu einem etwas späteren Zeitpunkt legt ein Vorgang in diesem Dienstprogramm eine weitere Warteschlange an, wobei er deren Kennsatzinformation in das erste Fach der Warteschlangenkennsätze plaziert. Der Mandantenvorgang vollführt dann eine msgsnd unter Verwendung der ursprünglichen MSQID. Die Nachricht vom Mandanten geht dann nicht in die Warteschlange, die der Mandant erwartet.
Mit der Verfahrensweise der vorliegenden Erfindung wird dieses Problem vermieden, weil immer dann, wenn ein Mandant eine Nachricht absendet, ein Vergleich der Bootzählungen vorgenommen wird; und wenn die Bootzählungen nicht gleich sind, dann wird der Mandant über die Fehlerbedingung informiert. Es ist wieder Bezug zu nehmen auf Fig. 5B, Blöcke 122, 124, und 50, Blöcke 152, 154.
Jeder Knoten enthält im Superblock seines Grundgerätes (Fig. 1, 54) einen Zähler, BOOTCNT, der eine Anzeige für den Einschaltstatus des Dienstprogramms ist. Dieser Zähler wird jedesmal dann inkrementiert, wenn das Dienstprogramm ausgeschaltet und wieder eingeschaltet wird. Dieser Zähler wird bei Nachrichtenvorgängen benutzt, wie etwa den in Fig. 5B und 5C beschriebenen, die einen Kennsatz von Nachrichtenwarteschlangen benutzen, wobei dann sichergestellt wird, daß sich das Dienstprogramm in demselben Zustand befindet, in dem es war, als es den Kennsatz der Nachtichtenwarteschlange herausgab.
Zusammenfassend stellt die vorliegende Erfindung eine auf Kernebene zu betreibende Verfahrensweise zur Prozeßkommunikation zwischen Prozessoren zur Verfügung, die sich an beliebigen Knoten in einem Mehrfachknoten-Netzwerk befinden. Der Informationsaustausch wird über Nachrichten durchgeführt, die in mit Schlüssein gekennzeichneten Nachrichtenwarteschlangen untergebracht sind, die sich an einem beliebigen Knoten innerhalb des Netzwerkes befinden können.
Auf der Anwendungsebene gibt es keine Notwendigkeit, daß der Knotenstandort der Nachrichtenwarteschlange bekannt ist, weil die Schlüsselabbildungstabellen und ihre oben beschriebene Verwendung die Auflösung des von der Anwendung zur Verfügung gestellten Schlüssels in eine aktuelle Adresse einer Nachrichtenwarteschlange ermöglicht, die von Systemaufrufen zur Nachrichtenhandhabung benutzt wird. Die Unversehrtheit der Nachrichtenübertragung wird durch den Schritt des Bootzäblungsvergleichs in den erforderlichen Systemaufrufen verbessert. Das Multiplexen von Nachrichten für verschiedene Knoten wird dadurch verbessert, daß in den Kennsatzeinträgen der Warteschlangen ein ausführlicher beschreibender MTYPE zur Verfügung gestellt wird. Die beschriebene Übereinkunft zur Vergabe von Warteschlangennamen beseitigt im wesentlichen das Risiko von Konfliktfällen, d.h. der Verwendung des gleichen Namens durch unterschiedliche Anwendungen, bei Nachrichtenwarteschlangen in der Netzwerkumgebung mit verteilten Diensten.

Claims

1. Ein Verfahren zur Unterstützung von Datenübertragungen zwischen Benutzeranwendungen, die an Prozessoren ablaufen, die an einem oder mehreren knoten innerhalb eines Netzwerkes angeordnet sind, wobei Nachrichtenwarteschlangen benutzt werden, deren aktuelle Knotenstandorte für die Benutzeranwendungen transparent sind, gekennzeichnet durch die Schritte:

Aufrechterhalten einer Schlüsselabbildungstabelle, die knoteneindeutige Warteschlangenschlüssel, die den an jedem Knoten laufenden Anwendungen zugeordnet sind, mit dem aktuellen Knotenstandort der Warteschlange und den Schlüsseln der Nachrichtenwarteschlangen verbindet, im Speicher an jedem Knoten;

Zugreifen auf eine Schlüsselabbildungstabelle mit einem von der Anwendung bereitgestellten Schlüssel, um den Knoten und den Schlüssel einer Nachrichtenwarteschlange zu erhalten, und Einrichten einer Datenübertragung zwischen dem Anwendungsknoten und dem Knoten der Nachrichtenwarteschlange.

2. Das Verfahren gemäß Anspruch 1, das zusätzlich den Schritt umfaßt:

Bestimmen, ob der Knoten der Nachrichtenwarteschlange während eines Zeitraumes zwischen der Rücksendung eines Nachrichtenwarteschlangen-Kennsatzes an einen Knoten und seiner Verwendung durch den Knoten einen Leistungszyklus durchgemacht hat.

3. Das Verfahren gemäß Anspruch 1, das die zusätzlichen Schritte umfaßt:

Verbinden eines eindeutigen Typenwertes mit jeder Warteschlange;

Nachinkrementieren des eindeutigen Typenwertes, wenn eine Anwendung einen eindeutigen Typenwert abfordert; und

Benutzen des Typenwertes, um eine gewünschte Nachricht aus einer Vielzahl von Nachrichten in einer Nachrichtenwarteschlange auszuwählen.

4. Ein Netzwerkverwaltungssystem, mit dem die Knotenstandorte von Nachrichtenwarteschlangen Benutzeranwendungsprogrammen in einem Netzwerk mit verteilten Diensten (10) transparent gemacht werden, wobei das Netzwerk Prozessoren (40) umfaßt, von denen sich jeder an einem unterschiedlichen Knoten (A, B, C) befinden kann, wobei jeder Prozessor (40) speicherresidente Systembetriebsmittel (46) und Programme (44) umfaßt, mit denen Nachrichtenwarteschlangen angelegt werden und auf diese zugegriffen wird, und wobei jeder Prozessor (40) in der Lage ist, eine Vielzahl von Benutzeranwendungsprogrammen (42) auszuführen, in denen der Informationsaustausch zwischen den Prozessoren (40) über Warteschlangen erfolgt, die an jedem beliebigen Knoten im Netzwerk (10) angeordnet sind, wobei das Netzwerkverwaltungssystem dadurch gekennzeichnet ist, daß das System umfaßt:

Bibliotheksroutinenmittel, die von jedem Knoten aus zur Zuordnung von knoteneindeutigen Warteschlangenschlüsseln (LKEY) zu einem Warteschlangennamen (QNAME) aufrufbar sind, der von jedem Benutzeranwendungsprogramm zur Verfügung gestellt wird;

Tabellenlademittel (52), die beim Prozessoranlauf betrieben werden, damit an jedem Knoten (A, B, C) eine kernresidente Abbildungstabelle (KMT) zur Verfügung steht, die Einträge hat, mit denen die zugeordneten knoteneindeutigen Schlüssel (LKEY) mit den Knotenstandorten der Nachrichtenwarteschlangen (RNODE) und den vom Benutzeranwendungsprogramm bereitgestellten Schlüsseln (RKEY) verbunden werden; und Mittel zum Annehmen eines von einem Benutzeranwendungsprogramm bereitgestellten Schlüssels (RKEY), das einen zugehörigen Knotenstandort einer Nachrichtenwarteschlange auffindet (RNODE) und eine Datenübertragung zwischen dem Knoten des Benutzeranwendungsprogramms (A, B, C) und einem zugehörigen Knotenstandort der Nachrichtenwarteschlange (RNODE) errichtet, damit ein Nachrichtenvorgang durchgeführt wird.

5. Ein System, wie es mit Anspruch 4 belegt wird, das Mittel zum Bestimmen umfaßt, ob ein Knotenstandort einer Nachrichtenwarteschlange während eines Zeitraumes zwischen der Rücksendung eines Nachrichtenwarteschlangen-Kennsatzes an den Knoten einer Benutzeranwendung und seiner Verwendung am Benutzeranwendungs knoten einen Leistungszyklus durchgemacht hat.