DE3852378T2

DE3852378T2 - Mechanismus und Verfahren zur entgegengesetzten Flussteuerung.

Info

Publication number: DE3852378T2
Application number: DE3852378T
Authority: DE
Inventors: Surinder Paul Batra; William Elder Hammer; Gene Arthur Lushinsky; David Wayne Marquart; Walter Henry Schwane; Frederick Joseph Ziecina
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-11-18
Filing date: 1988-09-13
Publication date: 1995-05-24
Anticipated expiration: 2008-09-14
Also published as: DE3852378D1; EP0317466A3; EP0317466A2; US4930069A; EP0317466B1; JPH01142963A; JPH0673123B2

Description

Technische Grundlagen der Erfindung

Die Erfindung betrifft die Steuerung des Flusses von Verarbeitungsvorgängen zwischen Prozessen auf einem Bus und insbesondere eine Busnachricht zum Unterbrechen von Prozessen aufgrund eines Ereignisses oder nicht erwarteter Daten.
Eine Buseinheit ist eine Verarbeitungseinheit, die an einen Bus in einem verteilten Verarbeitungsnetz angeschlossen ist, und könnte beispielsweise ein Host oder ein Ein-/Ausgabe (E/A)-Prozessor sein. Jeder Prozessor weist im allgemeinen einen mit ihm verbundenen Hauptspeicher auf. In solchen Netzen werden im allgemeinen zwei Arten von Hardware mit direktem Speicherzugriff (DMA) verwendet. Haupt-DMA verleiht der Buseinheit, die dies aufweist, die Fähigkeit, auf den Speicher in einer Buseinheit mit Neben-DMA zuzugreifen, ohne den Prozessor der Buseinheit zu unterbrechen.
In früheren Prozeß-zu-Prozeß-Übertragungen, wobei die Übertragungsverfahren für die kommunizierenden Prozesse transparent sind, fordert eine Einheit, die Prozesse enthält, Verarbeitungsvorgänge an, die von einer anderen Buseinheit auf dem Bus ausgeführt werden müssen. Die Daten, die verarbeitet werden, befinden sich im Speicher des Anforderers, und die Servereinheit, das heißt die Einheit, welche die Anforderung ausführt, hat Zugriff auf die Daten.
An dem normalen Datenfluß ist die Buseinheit beteiligt, die den Prozeß enthält, der die Verarbeitungsanforderung bearbeitet, um mit DMA auf die Verarbeitungsanforderung und die mit der Anforderung verbundenen Daten zuzugreifen. Der Fluß läuft vom Speicher der anfordernden Buseinheit in den Speicher der Serverbuseinheit. Falls die Serverbuseinheit eine Steuereinheit mit Direktzugriffsspeicher ist, die an einen E/A-Bus angeschlossen ist, kann dies problemlos erfolgen, da die Ein-/Ausgabesteuereinheit Haupt-DMA aufweist und die Hostbuseinheit, welche die Verarbeitungsanforderung ausgab, Neben-DMA aufweist. Dies bedeutet, daß die Ein-/Ausgabesteuereinheit mit Haupt-DMA über den E/A-Bus direkt auf den Hauptspeicher des Host zugreifen kann, ohne den Prozessor in der Hostbuseinheit zu unterbrechen.
Ein Problem entsteht, wenn die E/A-Einheit der Absender der Verarbeitungsanforderung ist. In einer servergesteuerten Architektur zur Bearbeitung von Verarbeitungsvorgängen, wie sie in der US-Patentschrift Nr. 4 649 473 beschrieben ist, die durch Bezugnahme hierin aufgenommen ist, macht die Architektur es erforderlich, daß der Prozeß, der die Verarbeitungsanforderung bearbeitet, auf die Daten zugreifen kann, wann er möchte, und nicht die Daten mit der Meldung der Verarbeitungsanforderung empfangen muß, wie es in früheren Systemen der Fall war. Da der Host keinen Haupt-DMA aufweist und die Ein-/Ausgabesteuereinheit auch keinen Neben-DMA aufweist, kann ein Hostserver nicht auf die Daten im Anforderer von Verarbeitungsvorgängen der Ein-/Ausgabesteuereinheit zugreifen. Es müssen Mittel zur Steuerung des mit der Architektur übereinstimmenden Datenflusses vorhanden sein. Einige Systeme haben alle mit einer Anforderung verbundenen Daten über normale Busübertragungen zum Server übertragen.
In früheren Systemen wurde eine Bustransporteinrichtung verwendet, um zu gewährleisten, daß der Datenfluß für die kommunizierenden Prozesse transparent ist. Die Bustransporteinrichtungen haben im allgemeinen vorausgesetzt, daß eine der Buseinheiten stets Verarbeitungsanforderungen einleitet und die andere der Buseinheiten stets ein Server für Verarbeitungsvorgänge ist. Jede Buseinheit erhält dann den geeigneten Hardware-DMA. Da Buseinheiten immer hochentwickelter werden, ist dies nicht länger der Fall. Viele neuere Buseinheiten sind mit immer mehr Fähigkeiten erhältlich, und folglich entsteht der Bedarf, Verarbeitungsanforderungen einzuleiten. Falls Buseinheiten Peer-Prozessoren sind, besteht die Möglichkeit, daß jeder Prozessor so viele Verarbeitungsanforderungen bearbeitet, wie er Verarbeitungsanforderungen erzeugt. In vielen Fällen kann es aufgrund der Kosten der beteiligten zusätzlichen Hardware oder weil er die vollständige Steuerung seines Hauptspeichers haben möchte, unerwünscht sein, daß ein Prozessor Neben-DMA aufweist. Wo ein Ungleichgewicht bezüglich der DMA-Fähigkeiten der Buseinheiten besteht, wird die Fähigkeit, den Datenfluß zu steuern, sogar noch wichtiger.
Frühere Systeme haben die Bearbeitung einer nicht erwarteten Eingabe von E/A-Adaptern über einfache Unterbrechungen verbessert. Eine nicht erwartete Eingabe entspricht einer Verarbeitungsanforderung durch den E/A-Adapter für den Host, um Daten zu lesen. Ein fortschrittlicheres Beispiel, das jedoch typisch für viele andere ist, ist die Post-Event-Funktion eines IBM System/38(S/38)-Kanals. Sie ermöglichte einer Buseinheit, eine kurze (1 Byte)-Nachricht zum Host zu senden, um Maßnahmen anzufordern.
Zu diesem Lösungsweg gibt es mehrere Einschränkungen. In der Post-Event-Nachricht konnten keine Leitweginformationen bereitgestellt werden. Alle Post Events wurden nach dem Empfang durch den Host zu einem einzigen Prozeß (dem Kanalein-/ausgabeverwalter (IOM) auf S/38) gesendet. Die Post-Event-Nachricht würde, falls möglich, nur aufgrund der Quellenbuseinheit-ID in der Nachricht zu einem bestimmten Ein-/Ausgabeverwalter weitergeleitet. Jeder Buseinheit mußte ein einzelner, feststehender, vorbestimmter Prozeß zugewiesen werden, um die Nachricht weiterzuleiten. Außerdem konnten Post Events nur zum Host, nicht zu anderen Buseinheiten, gesendet werden. In einer Post-Event-Nachricht konnten nur sehr wenig Benutzerdaten gesendet werden.

Zusammenfassung der Erfindung

Das Hauptziel der Erfindung ist die Bereitstellung eines Buseinheitensystems gemäß Anspruch 1 und eines Verfahrens zur entgegengesetzten Flußsteuerung gemäß Anspruch 7.
In einem System mit mehreren Buseinheiten wird eine spezielle Busnachricht verwendet, um einen auf einer Buseinheit ausführenden Prozeß über ein Ereignis oder über eine nicht erwartete Eingabe von einer anderen Buseinheit zu informieren. Die Busnachricht kennzeichnet den Prozeß, den sie unterbrechen soll, und erzeugt außerdem eine Meldung der von dem unterbrochenen Prozeß durchzuführenden Maßnahme.
Die Buseinheit, welche die Nachricht empfängt, weiß sofort, wohin die Nachricht weitergeleitet werden muß, anstatt vom Absender ableiten zu müssen, wohin die Nachricht weiterzuleiten ist. Der unterbrochene Prozeß muß nicht zum Sender der Nachricht zurückgehen, um zu bestimmen, was zu tun ist. Da die Nachricht eine Meldung über das, was zu tun ist, enthält, wird wenig Zeit damit verschwendet, den Grund für das Senden der Nachricht zu ermitteln.
In einer Ausführung wird ein Bus für die Übertragung von Verarbeitungsanforderungen und damit verbundenen Daten zwischen mehreren Buseinheiten mit unterschiedlichen DMA-Graden verwendet. Eine Serverbuseinheit, die einen Prozeß, der eine Verarbeitungsanforderung bearbeitet, enthält, steuert den Fluß der Anforderung und der Daten. Falls der Server oder der Anforderer keine kompatible DMA-Fähigkeit aufweist, um die für den Serverprozeß zum Zugriff auf die Anforderung und die Daten benötigten *** Übertragungen durchzuführen, wird die spezielle Nachricht zwischen Buseinheiten verwendet, um die Zuständigkeit für die Übertragung von Daten, die mit dem Fluß der Verarbeitungsvorgänge verbunden sind, umzukehren. Der ursprüngliche Server leitet in Abhängigkeit von Informationen in der speziellen Busnachricht eine Verarbeitungsanforderung ein, so daß der ursprüngliche Anforderer nun zum Server wird, und die DMA-Fähigkeiten der jeweiligen Buseinheit sind kompatibel zu dem neuen Server, der den Datenfluß steuert.
Die spezielle Nachricht zeigt den Typ des auszuführenden Verarbeitungsvorgangs an und bewirkt, daß die Buseinheit, für die sie bestimmt ist, eine Verarbeitungsanforderung zurück zu der anfordernden Buseinheit ausgibt. Die ursprüngliche anfordernde Buseinheit überträgt die Daten, die der ursprüngliche Anforderer ursprünglich übertragen wollte, anschließend zurück zu dem neuen Anforderer. Die neue Anforderung wird so angepaßt, daß der ursprüngliche Verarbeitungsvorgang, d.h. die Übertragung von Daten, ausgeführt wird. Die Anpassung der neuen Anforderung erfolgt aufgrund von Informationen, die in der speziellen, als Signalnachricht bezeichneten Busnachricht enthalten sind.
Die ursprüngliche anfordernde Buseinheit weist Haupt-DMA auf, und die ursprüngliche bearbeitende Buseinheit weist Neben-DMA auf. Werden die Aufgaben vertauscht, sind die DMA-Fähigkeiten kompatibel, da Haupt-DMA einer Einheit ermöglicht, auf den Hauptspeicher einer anderen Einheit mit Neben-DMA zuzugreifen. In einer bevorzugten Ausführungsform ist die ursprüngliche anfordernde Einheit eine Steuereinheit mit Direktzugriffsspeicher, die mindestens Haupt-DMA aufweist. Die ursprüngliche bearbeitende Buseinheit ist ein Rost mit Neben-DMA. Eine der Einheiten könnte sowohl Haupt- als auch Neben-DMA aufweisen, aber um auf den Hauptspeicher der Ein-/Ausgabesteuereinheit zuzugreifen, würde der Rost Haupt-DMA und die Ein-/Ausgabesteuereinheit Neben-DMA benötigen.
Wenn die Ein-/Ausgabesteuereinheit nicht erwartete Informationen zum Rost übertragen muß, leitet ein Prozeß innerhalb der Ein-/Ausgabesteuereinheit eine Verarbeitungsanforderung für den Rost ein, damit er die Daten holt. Da dies nicht kompatibel zu ihren jeweiligen DMA-Fähigkeiten ist, sendet ein Busverwalter für die Ein-/Ausgabesteuereinheit stattdessen die Signalbusnachricht. Für den Prozeß in der Ein-/Ausgabesteuereinheit scheint es immer noch so, als würde ein Verarbeitungsvorgang angefordert. Der Busverwalter entnimmt die Nachricht aus den Informationen, die in der Verarbeitungsanforderung vom Prozeß der Ein-/Ausgabesteuereinheit bereitgestellt werden. In einer Ausführungsform kann das "Signal" drei verschiedene Arten von Verarbeitungsanforderungen anzeigen. Der Rost empfängt das Signal und sendet eine Verarbeitungsanforderung zurück, die von der angezeigten Verarbeitungsanforderung abhängig ist.
Das Signal weist außerdem eine Anzahl von Feldern auf, die vom Busverwalter der Ein-/Ausgabesteuereinheit erzeugte Informationen enthalten. Da eine Signalnachricht per Definition nicht als von einer anderen Buseinheit beantwortet bestätigt werden muß, wird ein codierter Wert mit dem Signal übertragen und auch von der resultierenden Verarbeitungsanforderung vom Rost ausgegeben. Auf diese Art und Weise verfolgt der Busverwalter der Ein-/Ausgabesteuereinheit, welche Signale tatsächlich empfangen und bearbeitet wurden. Falls nach einer vorbestimmten Zeitspanne keine Verarbeitungsanforderung vom Rost empfangen wurde, sendet der Busverwalter die Nachricht erneut.
Die vorliegende Erfindung ist eine kostengünstige Möglichkeit, den Fluß von Verarbeitungsanforderungen umzukehren, wo DMA-Fähigkeiten den Fluß von Verarbeitungsvorgängen in eine gewünschte Richtung nicht gestatten. Sie benötigt keinen Zusatz an DMA für eine der Buseinheiten und ermöglicht den Daten dennoch, frei zu fließen, ohne alle Daten sofort zum Rost zu senden. Sie läßt den Rost angeben, wohin die Daten gebracht werden sollen, und falls der Rost belegt ist, muß er keine Verarbeitungsanforderung zurücksenden, weil er weiß, daß ein anderes Signal gesendet wird. Er kann das erste Signal verwerfen, falls er nicht über Ressourcen verfügt, um es zu bearbeiten, oder es zur späteren Ausführung in eine Warteschlange stellen.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist eine Blockdiagrammubersicht eines Systems mit mehreren Prozessen mit einer Einrichtung zur Interprozeßkommunikation für die Übertragung zwischen Prozessen, die der US-Patentschrift Nr. 4 649 473 entnommen wurde.
Fig. 2 ist eine Blockdiagrammübersicht des Systems mit mehreren Prozessen aus Fig. 1, die logische Verbindungsgruppen mit logischen Verbindungen zwischen Prozessen zeigt.
Fig. 3 zeigt eine Tabelle und einen Steuerblock, die bei der Verwaltung logischer Verbindungsgruppen aus Fig. 2 verwendet werden.
Fig. 4 ist ein Blockflußdiagramm, das eine anfordernde Buseinheit zeigt, die auf einen Status "Warteschlange voll" für Verarbeitungsanforderungen antwortet, der für eine Verbindungsgruppe, die nicht genug Ressourcen hat, um mehr Verarbeitungsanforderungen anzunehmen, bestimmt ist.
Fig. 5 ist ein weiteres Flußdiagramm der anfordernden Buseinheit aus Fig. 4 für das Antworten auf einen Status "Warteschlange voll".
Fig. 6 ist ein Blockdiagramm von Warteschlangen, die von der anfordernden Buseinheit aus Fig. 4 zum Antworten auf einen Status "Warteschlange voll" verwendet werden.
Fig. 7 ist ein Blockflußdiagramm einer Serverbuseinheit, das den Fluß beim Bestimmen, ob genügend Ressourcen in einer Verbindungsgruppe verfügbar sind, und, falls dies nicht der Fall ist, beim Senden einer Nachricht "Warteschlange voll" zeigt.
Fig. 8 ist ein weiteres Flußdiagramm der Serverbuseinheit aus Fig. 7, um zu bestimmen, wann Ressourcen für eine Verbindungsgruppe verfügbar geworden sind, und um eine Nachricht "Pufferbereich verfügbar" zu senden.
Fig. 9 ist ein Blockdiagramm, das die Felder einer Nachricht "Busfehlerbedingung" zum Auflisten von Fehlern und zum Anzeigen eines Status "Warteschlange voll" zeigt.
Fig. 10 ist ein Blockdiagramm, das die Felder einer Nachricht "Pufferbereich verfügbar" zeigt, um anzuzeigen, daß Ressourcen für eine Verbindungsgruppe frei sind.
Fig. 11 ist ein Blockdiagramm, das die Felder einer Nachricht "Warteschlange neu starten" zeigt, um eine Verbindungsgruppe zu informieren, mit der Annahme von Verarbeitungsanforderungen zu beginnen.
Fig. 12 ist ein Diagramm des an einer Bedingung "Warteschlange voll" beteiligten Nachrichtenflusses für eine Verbindungsgruppe.
Fig. 13 ist ein Blockdiagramm, das die Felder einer Nachricht "Verarbeitungsstart" (VERARBSTART) zeigt, um anzuzeigen, daß eine Verarbeitungsanforderung für einen gekennzeichneten Prozeß vorliegt.
Fig. 14 ist ein Blockdiagramm, das die Felder eines Anforderung/Antwort-Steuerblocks zeigt, der verwendet wird, um die Positionen von Anforderungen und Daten zu kennzeichnen.
Fig. 15 ist ein Blockdiagramm, das die Felder eines Zusatzes zum Anforderung/Antwort-Steuerblock zeigt.
Fig. 16 ist ein Blockdiagramm, das die Felder einer Nachricht "Verarbeitungsende" (VERARBENDE), um anzuzeigen, daß eine Antwort auf eine Verarbeitungsanforderung vorliegt, zeigt.
Fig. 17 ist ein Blockdiagramm, das die Felder einer Nachricht "Speicheranforderung" zum Anfordern eines fernen Speichers zum Verwalten zeigt.
Fig. 18 ist ein Blockdiagramm, das die Felder einer Nachricht "Speicherliste verfügbar" zum Anzeigen der Position einer Speicherliste zur Fernverwaltung zeigt.
Fig. 19 ist ein Blockdiagramm, das die Felder eines Speicherlisten-Steuerblocks zeigt, der verwendet wird, um einen zu verwaltenden fernen Speicher zu kennzeichnen.
Fig. 20 ist ein Blockdiagramm, das die Felder einer Nachricht "Speicherliste beendet" zeigt, die verwendet wird, um die Verwaltung eines fernen Speichers auszugeben.
Fig. 21 ist ein Blockdiagramm, das die Felder einer Nachricht "Speicherliste ausgeben" zeigt, die verwendet wird, um die Ausgabe der Verwaltung eines fernen Speichers anzufordern.
Fig. 22 ist ein Diagramm des Nachrichtenflusses, der an der Übertragung der Steuerung der Verwaltung eines fernen Speichers beteiligt ist.
Fig. 23 ist ein Blockflußdiagramm, das die Weitergabe der Verwaltung eines fernen Speichers zeigt.
Fig. 24 ist ein Blockflußdiagramm, das die Ausgabe der Verwaltung eines fernen Speichers zeigt.
Fig. 25 ist ein Diagramm des Nachrichtenflusses, der an der Umkehrung des Flusses einer Verarbeitungsanforderung beteiligt ist.
Fig. 26 ist ein Blockdiagramm, das die Felder einer Signal- Busnachricht zeigt, die verwendet wird, um informell kleine Datenmengen zu übertragen.
Fig. 27 ist ein Blockdiagramm, das eine andere Version der Signal-Nachricht aus Fig. 26 zur Umkehrung des Flusses einer Verarbeitungsanforderung zeigt.
Fig. 28 ist ein Blockdiagramm, das die Felder einer Busnachricht "DMA-Anforderung" (DMA-Anf) zeigt, die verwendet wird, um eine DMA-Übertragung anzufordern.
Fig. 29 ist ein Blockdiagramm, das die Felder einer Busnachricht "DMA beendet" zeigt, die verwendet wird, um anzuzeigen, daß eine DMA-Übertragung beendet ist.
Fig. 30 ist ein Diagramm des Nachrichtenflusses, der an der Verwendung der DMA-Nachrichten aus den Fig. 28 und 29 zur Datenübertragung beteiligt ist.

Ausführliche Beschreibung

Fig. 1 ist der US-Patentschrift Nr. 4 649 473 entnommen. Sie wird verwendet, um dem Leser eine Grundlage für ein besseres Verständnis der hier vorgestellten Erfindung zu schaffen. Der anschließende Text beschreibt Fig. 1 und konzentriert sich auf die Prozeß-zu-Prozeß-Übertragung, wobei die Prozesse keine Kenntnis von der zugrundeliegende Kommunikationsverwaltung haben. Die zugrundeliegende Bustransporteinrichtung und ein Busverwalter, welcher der Gegenstand dieser Erfindung ist, werden in einem späteren Abschnitt beschrieben.
In Fig. 1 ist eine Ansicht der oberen Ebene einer verteilten Prozeßumgebung allgemein bei 10 gezeigt. Ein bei 12 dargestellter Prozessor A ist über einen mittels einer Linie 14 dargestellten physischen Pfad mit einem bei 16 dargestellten Prozessor B verbunden. Der Prozessor A ist mit einem bei 18 dargestellten Prozeß A und einem bei 19 dargestellten Prozeß B, die sich darin befinden, dargestellt. Ein Speicherbereich 20 ist mit dem Prozeß A und dem Prozeß B verbunden, wie jeweils durch die Linien 21 und 22 dargestellt ist, um die Steuerung der und den Zugriff auf die Datenspeicherung durch die Prozesse zu gewährleisten.
Der Prozessor B ist mit einem bei 23 gezeigten Prozeß C und einem bei 24 gezeigten Prozeß D, die sich darin befinden, dargestellt. Ein Speicherbereich 25 ist mit dem Prozeß C und dem Prozeß D verbunden, wie jeweils durch die Linien 26 und 28 dargestellt ist, um die Steuerung der und den Zugriff auf die Datenspeicherung durch die Prozesse zu gewährleisten.
Prozesse oder aus führende Programme innerhalb der Prozessoren müssen miteinander kommunizieren. In Prozessoren mit verschiedenen Konfigurationen oder, da er sich mit der Zeit ändert, in demselben Prozessor können sich zwei kommunizierende Prozesse an verschiedenen relativen Positionen befinden, und dazwischen können verschiedene physische Pfade liegen.
Eine Einrichtung zur Interprozeßkommunikation (IPCF) ist im Prozessor A und im Prozessor B jeweils bei 30 und 32 vorgesehen, um die Interprozeßkommunikation anzupassen, die für die kommunizierenden Prozesse positionstransparent ist. Die IPCF 30 ist mit dem Prozeß A im Prozessor A verbunden, wie durch eine Linie 34 dargestellt ist, und mit dem Prozeß B, wie durch eine Linie 36 dargestellt ist. Die Linien 34 und 36 stellen die Schnittstellen zwischen dem Prozeß A und dem Prozeß B zur IPCF 30 dar. Diese Schnittstellen ermöglichen die Übertragung zwischen dem Prozeß A und dem Prozeß B, vorausgesetzt, daß geeignete Datenpfade eingerichtet sind. Die IPCF 30 ist außerdem über eine Transporteinrichtung 40 im Prozessor B mit der IPCF 32 verbunden. Die IPCF 32 ist, wie durch die Schnittstellenlinien 42 und 44 dargestellt ist, mit dem Prozeß C und dem Prozeß D verbunden. Diese Schnittstellen mit den IPCFs und den Transporteinrichtungen ermöglichen die Einrichtung der Übertragung zwischen allen gezeigten Prozessen, ohne daß ein Prozeß die Position des Prozesses, mit dem er kommuniziert, kennt. Die Transporteinrichtungen 38 und 40 umfassen bevorzugterweise eine Mehrzahl von Transporteinrichtungen wie lokale Transporteinrichtungen, die verwendet werden, wenn der Prozeß A und der Prozeß B oder der Prozeß C und der Prozeß D mit einem einzelnen Prozessor kommunizieren. Befinden sich der Prozessor A und der Prozessor B in demselben Gerät, wird eine Bustransporteinrichtung verwendet, um die Übertragung zwischen Prozessen im Prozessor A und im Prozessor B zu erleichtern. Für Intermaschinenkommunikation ist ein Ubertragungsprotokoll wie SNA geeignet.
Die Transporteinrichtungen 38 und 40 sind Datenübertrager. Sie sind für die Übertragung von Datenbytes von einem Ort an einen anderen zuständig und verstehen die Bedeutung der übertragenen Informationen nicht. Folglich ist der Speicher 20 im Prozessor A, wie durch eine Linie 46 dargestellt ist, mit der Transporteinrichtung 38 verbunden, und der Speicher 25 im Prozessor B ist, wie durch eine Linie 48 dargestellt ist, mit der Transporteinrichtung 40 verbunden, um Informationsübertragungen unmittelbar durch die Transporteinrichtungen 38 und 40 zu ermöglichen.
Die IPCF des Prozesses, der zu kommunizieren versucht, wählt die Transporteinrichtung für die Übertragung. Die kommunizierenden Prozesse müssen die verwendete Einrichtung nicht kennen. Der Prozeß, der zu kommunizieren versucht, überträgt den Namen des Zielprozesses, da dieser dem Prozeß, der zu kommunizieren versucht, bekannt ist, an die IPCF, die einen geeigneten Verzeichniszugriffsdienst wählt, um ihn zu lokalisieren. Die IPCF wählt anschließend die geeignete Transporteinrichtung und verwendet systemunterstützte Dienste, um die Verbindung zwischen den Prozessen standardmäßig einzurichten. Die IPCF kann von allen Prozeßebenen, von Anwendungen bis hin zu Basissystemdiensten wie einem Seitenwechselverwalter, verwendet werden.
Um die Verwendung vieler verschiedener Transporteinrichtungen, von denen jede verschiedene Fähigkeiten und Merkmale hat, zu ermöglichen, weist die IPCF eine generische Transporteinrichtungs-Schnittstelle mit jedem Prozeß auf. Die Schnittstelle definiert einen Satz von Funktionen für die Einrichtung von Verbindungen und für die Übertragung von Informationen zwischen Prozessen. Die definierten Funktionen sind auf den von der IPCF verwendeten Transporteinrichtungen abgebildet. Die auf die Schnittstelle geschriebenen Programme sind unabhängig von der Transporteinrichtung und sind daher während der Übertragung unabhängig von ihren relativen Positionen.
Die Übertragung zwischen Prozessen erfolgt, was das Senden und Empfangen von Nachrichten über eine Verbindung zwischen ihnen betrifft, wie von der IPCF eingerichtet. Die Nachrichten enthalten Verarbeitungsanforderungen und/oder Daten. Entsprechend einer bestimmten Verarbeitungsanforderung übernimmt ein Prozeß die Aufgabe eines Anforderers oder eines Servers. Der Anforderer leitet eine Verarbeitungsanforderung ein, indem er eine Anforderung zu einem Server sendet, der diese ausführt. Anforderungen enthalten eine Verarbeitungsanforderung (einen Befehl und seine Parameter) und wahlweise einige Daten. Sowohl die Anforderung als auch die Daten haben eine veränderliche Länge.
Falls der Leser weitere Informationen über die IPCF und die Art und Weise, wie Verbindungen eingerichtet werden, wünscht, bietet die oben erwähnte Patentschrift weitere Einzelheiten. Nun wird ein Busverwalter, der ein Teil der Transporteinrichtungen 38 und 40 ist, beschrieben.

BUSVERWALTER

In Fig. 2 sind zwei Buseinheiten 50 und 52 über einen physischen Pfad, wie einem E/A(Eingabe und Ausgabe)-Bus 54, verbunden. In einer bevorzugten Ausführungsform umfaßt die Buseinheit 50 ein Hostsystem mit einem Prozessor 56, mit dem ein Hauptspeicher 58 durch eine Leitung 60 verbunden ist. Der Rost 56 führt eine Mehrzahl von Programmen aus, von Abrechnungsprogrammen bis hin zu Betriebssystemprogrammen. Auf eine ausführende Instanz eines Programms wird als Prozeß Bezug genommen. Einige Prozesse PA1 bis PAn, PB1 bis PBn und PC1 bis PCn sind im Rost 56 gezeigt.
Die Buseinheit 52 umfaßt in einer bevorzugten Ausführungsform einen E/A-Prozessor 66, mit dem ein Hauptspeicher 68 über eine Leitung 70 verbunden ist. Der E/A-Prozessor 66 weist außerdem eine Anzahl von Prozessen PD1 bis PDn, PE1 bis PEn und PF1 bis PFn auf, die ausführen können. Obwohl eine große Anzahl von Prozessen in jedem der Prozessoren 56 und 66 gezeigt wird, kann es Situationen geben, in denen ein Prozessor nur einen Prozeß hat. In weiteren Ausführungsformen ist der Prozessor 66 ein Peer-Prozessor in einem Netz von Prozessoren. Prozesse kommunizieren, unabhängig von den Positionen zweier kommunizierender Prozesse, über die IPCF 72 in der Buseinheit 50 und die IPCF 74 in der Buseinheit 52 miteinander. Jedes Paar kommunizierender Prozesse ist über die IPCF mittels logischer Verbindungen, die durch die Linien 80 in der Buseinheit 50 und 82 in der Buseinheit 52 dargestellt sind, logisch verbunden.
Die Einrichtung von Verbindungen ist in der oben enthaltenen Patentschrift ausführlicher beschrieben. Im wesentlichen richtet ein IPCF-Verb "Öffnen" eine IPCF-Verbindung zwischen zwei Prozessen ein. Die Verbindung ist für jedes Paar kommunizierender Prozesse eindeutig. Folglich paßt jede der Linien 80 zu einer der Linien 82. Da mehr E/A-Prozessoren oder Hosts als in Fig. 2 gezeigt vorhanden sein können, zeigen mehr Linien 80 als Linien 82 Verbindungen zu Prozessen in nicht gezeigten Prozessoren an. Das Verb "Öffnen" bewirkt, wenn von einem Prozeß ausgegeben, der eine Übertragung starten möchte, daß die IPCF eine logische Verbindung zwischen dem Prozeß, der das Verb "Öffnen" ausgab, und dem durch das Verb "Öffnen" gekennzeichneten Zielprozeß erzeugt. Das Ziel des Verbs "Öffnen" ist durch einen Instanznamen gekennzeichnet. Das Verb "Öffnen" richtet die Verbindung zu einer neuen oder einer bereits ausführenden Instanz eines Programms in Abhängigkeit von dem durch das Verb "Öffnen" übertragenen Instanznamen ein.
Das Verb "Öffnen" weist einen Instanznamen auf, der von der IPCF und den zugeordneten Betriebssystemen verwendet wird, um das Programm im Server und die aus führende Instanz dieses Programms (d.h. Prozesses), mit der die Verbindung eingerichtet werden muß, zu bestimmen. Eine Verbindungs-ID kennzeichnet die von der IPCF gemeldete Verbindung. Sie wird verwendet, um bei nachfolgenden Arbeitsgängen auf diese Verbindung Bezug zu nehmen. Eine bestimmte Verbindungs-ID ist nur innerhalb eines einzelnen Prozessors bekannt. Zwei verbundene Prozessoren haben im allgemeinen verschiedene Verbindungs-IDs für dieselbe Verbindung. Verbindungs-IDs werden von der lokalen IPCF zugewiesen und sind innerhalb eines Prozessors eindeutig. Die IPCF verwendet einen Rückkehrcode, um dem Prozeß die Beendigung des Verbs "Öffnen" anzuzeigen.
Es wird ein Busverwalter 86 gezeigt, der durch eine Anzahl von bereits eingerichteten logischen Verbindungen 80 mit dem Rost 56 verbunden ist. Ein ähnlicher Busverwalter 88 ist, ebenfalls mit Mehrfachverbindungen 82, in der Buseinheit 52 gezeigt. Der Busverwalter 86 erfüllt die gleichen Funktionen, die von den Bustransporteinrichtungen (BTMs), die in den Buseinheiten aus Fig. 1 bei 38 und 40 dargestellt sind, ausgeführt werden.
Die Busverwalter 86 und 88 verwalten die Verbindungen und geben Nachrichten aus, um den Fluß der Verarbeitungsanforderungen auf dem Bus 54 zu steuern. Die den Bus unterstützende Hardware, die bei 90 und 92 dargestellt ist, gewährleistet dem Bus Priorität für jede der Buseinheiten, DMA (Direct Memory Access, direkter Speicherzugriff) auf den Hauptspeicher einer anderen Buseinheit und Warteschlangenbildung für Nachrichten von den jeweiligen Busverwaltern bis eine Steuerung des Busses erreicht wurde, um eine Übertragung der Nachrichten und Daten zu gestalten. Die Bus-Hardware steuert auch die Warteschlangenbildung für Nachrichten von den jeweiligen Busverwaltern bis eine Steuerung des Busses erreicht wurde, um eine Übertragung der Nachrichten und Daten zu gestatten. Die Bus-Rardware steuert auch die Warteschlangenbildung für Nachrichten von den Buseinheiten in Hauptspeicher-Warteschlangen.
Der Busverwalter 86 empfängt eine Übertragung, die durch ein in der Buseinheit 52 ausgegebenes Verb "Öffnen" bewirkt wurde. Anschließend richtet er eine Verbindung zu dem angezeigten Prozeß ein. Unter Verwendung von Informationen wie der Identität des Zielprozesses (d.h.: des Serverprozesses), der Identität des anfordernden Prozesses, dem Typ des Verarbeitungsvorgangs, den eine bestimmte Einheit ausführt, oder anderen Faktoren, wird die Verbindungs-ID für diese Verbindung einer Mehrzahl von Verbindungsgruppen zugewiesen, die als CG1, CG2, ..., CGn bezeichnet werden. Einige der Informationen sind in der Kommunikation mit der Buseinheit 52 enthalten. Andere Informationen sind im Hauptspeicher 58 enthalten, und auf diese wird in Abhängigkeit von der durch die Buseinheit 52 gelieferten Informationen zugegriffen. Die Zuweisung erfolgt dann aufgrund dieser Informationen und ist in einer bevorzugten Ausführungsform durch die Entwickler voreingestellt.
Verbindungsgruppen werden verwendet, um den Fluß der Verarbeitungsanforderungen zu steuern. Jede Verarbeitungsanforderung benötigt zur Verarbeitung Systemressourcen. Falls alle Verarbeitungsanforderungen auf einer "First-Come/First-Served-Basis" bearbeitet würden, würde eine Anzahl von Einheiten mit großem Ressourcenbedarf verhindern, daß andere Einheiten bearbeitet werden können.
Ein Beispiel einer Einheit, die einen hohen Bedarf an Hauptspeicherressourcen hat, ist eine Bandlaufwerkseinheit. Damit eine Bandeinheit im Datenstrommodus, ihrem leistungsfähigsten Betriebsmodus, betrieben werden kann, wird ein großer Rauptspeicherpuffer benötigt. Falls mehrere Bandlaufwerke angeschlossen werden sollen und jedes einen hohen Speicherbedarf für Pufferdaten hat, wenn es im Datenstrommodus betrieben wird, würden durch die Zuweisung von genügend Ressourcen zu jedem Bandlaufwerk wenige Ressourcen verfügbar bleiben, um Einheiten mit Direktzugriffsspeicher zugeordnet zu werden. Indem die Bandlaufwerke in einer Verbindungsgruppe zusammengefaßt werden und genügend Ressourcen zugeordnet werden, daß eines oder zwei gleichzeitig betrieben werden können, sind viel mehr Ressourcen für Einheiten mit Direktzugriffsspeicher verfügbar. Es ist ein garantierter Unterstützungsgrad für Bandlaufwerkseinheiten und auch für Einheiten mit Direktzugriffsspeicher gewährleistet. Da es unwahrscheinlich ist, daß fünf Bandeinheiten zur gleichen Zeit betrieben werden, wird der Gesamtdienst nicht verringert.
Verbindungsgruppen können außerdem verwendet werden, um zu gewährleisten, daß stets Ressourcen für bestimmte Rostprozesse verfügbar sind. Ein Beispiel ist die Plazierung der Serverseitenverbindung zwischen einem Hostprozeß "Sichern/Fortsetzen" und einem entsprechenden E/A-Prozeß in eine Verbindungsgruppe, wo dies die einzige Verbindung in dieser Gruppe ist. Folglich sind stets Ressourcen für die Bearbeitung der Rost-Verarbeitungsanforderung "Sichern/Fortsetzen" verfügbar, obwohl der Serverprozeß Verbindungen zu anderen Gruppen haben kann.
Eine Basis für die Zuordnung von Gruppen sind die Betriebsmerkmale der Einheiten. Umfangreiche Datenübertrager wie Bandeinheiten, die außerdem nur gelegentlich verwendet werden, werden in einer Gruppe zusammengefaßt. Einheiten wie Einheiten mit Direktzugriffsspeicher, die beim Umstellen von Daten in einen und aus einem Hauptspeicher häufig verwendet werden, werden in einer anderen Gruppe zusammengefaßt, und der Gruppe wird eine große Menge von Ressourcen zugeordnet, um einen hohen Dienstgrad zu gewährleisten. Andere Einheiten, wie Datenstationen, werden in einer anderen Gruppe zusammengefaßt. Falls genügend Ressourcen verfügbar sind, hat jede Einheit ihre eigene Gruppe.
Bei der Erläuterung der Zusammenfassung von Einheiten in Gruppen soll kurz angemerkt werden, daß die Verbindungen zu Prozessen, die mit der Einheit verbunden sind, in einer Gruppe zusammengefaßt werden. Weitere Zuweisungen von Verbindungen in Gruppen werden aufgrund der Typen von Verarbeitungsanforderungen, die bearbeitet werden, gemacht. Verbindungen, die sich auf die Bearbeitung einer Fehlerbedingung beziehen, und andere, die Verwaltung betreffende Verarbeitungsanforderungen können für sich in einer anderen Gruppe zusammengefaßt werden, um solchen Anforderungen einen Mindestdienstgrad zu garantieren. Es wird deutlich, daß die Verwendung von Verbindungsgruppen eine hohe Flexibilität bei der Zuordnung von Ressourcen und folglich bei der Steuerung des Flusses von Verarbeitungsvorgängen gewährleistet.
In der Buseinheit 50 ist, wenn sie als Server betrieben wird, jede Verbindungsgruppe in einem Steuerblock 120 in Fig. 3 (die Numerierung stimmt mit Fig. 2 überein) im Hauptspeicher 58 aufgelistet. Der Steuerblock 120 beinhaltet einen Eintrag für jede Verbindungsgruppe CG1 bis n, der für die Gruppe 10 als GP10 bezeichnet wird. Ein in der Spalte 122 angezeigter Additionswert ist mit dem GPID-Eintrag verbunden, der verwendet wird, um die Anzahl der Verarbeitungsanforderungen, die über eine Verbindung in der Gruppe empfangen, jedoch noch nicht durch einen Prozeß in der Buseinheit 50 bearbeitet wurden, zu verfolgen. Die aktiven Verbindungs-IDs (C10) in Tabelle 125 haben Zeiger auf Verbindungsgruppen-Eingänge bei 120 und kennzeichnen die Gruppe, zu der eine Verbindung gehört. Die Buseinheit 52 weist ein ähnliches Verfahren auf, um die Anzahl ausstehender, unbearbeiteter Verarbeitungsanforderungen aufzuzeichnen.
Einer der Vorteile des obigen Flusses von Verarbeitungsanforderungen ist, daß Verarbeitungsvorgänge (für eine einzelne Verbindung mit derselben Priorität) in einer Verbindungsgruppe schließlich in der Reihenfolge bearbeitet werden, in der sie von der anfordernden Buseinheit angefordert wurden. Falls mehrere Prioritätsanforderungen für einen Prozeß erzeugt wurden, um Daten zu schreiben, werden diese folglich in der geforderten Reihenfolge geschrieben, auch wenn Ressourcen zu einer Zeit nicht verfügbar waren. All dies erfolgt transparent für den anfordernden Prozeß.
Es wird nun ein Flußdiagramm in einer Anfordererbuseinheit mit Bezugnahme auf Fig. 4 und Fig. 5 beschrieben. Vier Warteschlangen werden verwendet, um Verarbeitungsanforderungen, die von der Anfordererbuseinheit stammen, laufend zu verfolgen. Jede Warteschlange enthält einen Zeiger auf die Verarbeitungsanforderung, eine Anforderungs-ID und die entsprechende Verbindungsgruppe in der Serverbuseinheit, mit der während des Prozesses ÖFFNEN kommuniziert wird. Im normalen Fluß von Verarbeitungsanforderungen wird eine Warteschlange "Sendebereit" verwendet, um auf Warteschlangen-Verarbeitungsanforderungen zu zeigen, die bereit sind, zu Serverprozessoren gesendet zu werden. Wird eine Nachricht "VERARBEITUNG STARTEN" (VERARBSTART) für eine Anforderung in der Warteschlange "Sendebereit" gesendet, wird der Zeiger entfernt und auf eine Warteschlange "Auf Antwort wartend" gestellt. Wird eine Nachricht "VERARBEITUNGSENDE" (VERARBENDE) empfangen, wird der Eintrag für die Verarbeitungsanforderung aus allen Warteschlangen entfernt. Dieser normale Fluß ist durch die Blöcke 150, 152 und 154 in Fig. 4 dargestellt.
Wird eine Meldung WARTESCHLÄNGE VOLL als Antwort auf eine Verarbeitungsanforderung ausgegeben, wird der Zeiger von der Warteschlange "Auf Beendigung wartend" auf eine Warteschlange "Zurückweisen" bei 156 bewegt, llnd eine Meldung, daß eine Nachricht WARTESCHLÄNGE VOLL empfangen wurde, wird der Verbindungsgruppe, für die sie empfangen wurde, zugeordnet. Anschließend wird bei 158 eine PUFFERBEREICH-MARKIERUNG zum Anzeigen, daß die Verbindungsgruppe nun über Speicherplatz verfügt, überprüft. Diese Markierung ist normalerweise ausgeschaltet, folglich fährt der Busverwalter fort, Übertragungen zu senden und zu empfangen. Jede Verarbeitungsanforderung in der Warteschlange "Auf Beendigung wartend", für die eine Meldung WARTESCHLÄNGE VOLL ausgegeben wird, wird auf diese Art und Weise in die Warteschlange "Zurückweisen" gestellt.
In Fig. 5 überprüft ein Busverwalter, wenn er bereit ist, ein weiteres VERARBSTART entsprechend dem nächsten Eintrag in der Warteschlange "Sendebereit" zu senden, ob eine Meldung "Verbindungsgruppe voll" für die Verbindungsgruppe in der Serverbuseinheit bei 160 vorliegt. Falls diese anzeigt, daß die Verbindungsgruppen-Warteschlange voll ist, wird der Eintrag für die Anforderung in eine Zwischenwarteschlange bei 162 gestellt. Falls sie nicht voll ist, wird eine Nachricht VERARBSTART bei 164 gesendet, und der Anforderungseintrag wird in die Warteschlange "Auf Beendigung wartend" bei 166 gestellt.
Zurück im Fluß aus Fig. 4 wird, wenn eine Nachricht "Pufferbereich verfügbar" vom Anfordererprozessor bei 168 empfangen wird, die PUFFERBEREICR-MARKIERUNG bei 170 gesetzt, und die Warteschlange "Auf Beendigung wartend" wird auf Einträge nach dem einen, für den in der gekennzeichneten Verbindungsgruppe WARTESCHLÄNGE VOLL empfangen wurde, überprüft. Falls "Warteschlange voll" nicht für alle auf Beendigung wartenden Anforderungen ausgegeben wurde, fährt die Buseinheit fort, auf die nächste Übertragung bei 174 zu warten.
Falls alle bei 172 bestätigt werden, werden die Einträge aus der Warteschlange "Zurückweisen" zum Beginn der Warteschlange "Sendebereit" bei 176 übertragen. Anschließend werden Anforderungseinträge von der Zwischenwarteschlange zu der Warteschlange "Sendebereit" hinter Elemente aus der Warteschlange "Zurückweisen" bei 178 übertragen, und-die PUFFERBEREICH-MARKIERUNG wird bei 180 zurückgesetzt. Eine Nachricht "Warteschlange neu starten" wird bei 182 gesendet, und der Busverwalter beginnt, aus der Warteschlange "Sendebereit" bei 184 zu senden.
Tn Fig. 6 sind die von dem obigen Fluß verwendeten Warte-schlangen gezeigt, wobei der Fluß der Warteschlangeneinträge, die Verarbeitungsanforderungen entsprechen, durch Pfeile dargestellt ist. Die Warteschlange 200 "Sendebereit" überträgt normalerweise Einträge über die Leitung 202 zu der Warteschlange 210 "Auf Antwort wartend". Falls ein Status WARTESCHLÄNGE VOLL empfangen wird, werden Einträge über eine Leitung 222 aus der Warteschlange 210 zur Warteschlange 220 "Zurückweisen" übertragen. Da inzwischen neue Verarbeitungsvorgänge in der Warteschlange 200 eingeleitet werden, wird, falls eine Verarbeitungsanforderung für eine bereits volle Verbindungsgruppe erfaßt wird, diese über die Leitung 232 zu der Zwischenwarteschlange 230 übertragen. Wurden alle Einträge aus der Warteschlange 210 "Auf Antwort wartend", die für die volle Verbindungsgruppe bestimmt waren, zu der Warteschlange 220 "Zurückweisen" übertragen und wurde die Nachricht "Warteschlange neu starten" als Antwort auf eine Nachricht "Pufferbereich verfügbar" gesendet, werden die zurückgewiesenen Anforderungen über eine Leitung 234 zurück zum Beginn der Warteschlange 200 "Sendebereit" gesendet. Anschließend werden andere Anforderungen, die für die Gruppe bestimmt sind, die nun über Ressourcen für weitere Verarbeitungsvorgänge verfügt, auf Leitung 236 zu der Warteschlange 200 "Sendebereit" hinter die zuvor zurückgewiesenen Anforderungen übertragen.
Der entsprechende Fluß in der Serverbuseinheit ist in den Fig. 7 und 8 gezeigt. Beim Empfang einer Nachricht VERARBSTART durch eine Serverbuseinheit bei 250 wird die Verbindungsgruppe bei 252 bestimmt, und ihr Zähler wird bei 254 erhöht. Es wird ein Zählergrenzwert verwendet, um die Anzahl der Verarbeitungsanforderungen, die bei einer Verbindungsgruppe zu einer Zeit anstehen können, festzulegen. Der Wert des Zählers wird mit dem Zählergrenzwert bei 256 verglichen, und falls der Wert größer als der Grenzwert ist, wird eine MARKIERUNG W VOLL bei 258 gesetzt, und der Status WARTESCHLÄNGE VOLL wird in einer Nachricht "Busfehlerbedingung" zu der Ursprungsbuseinheit bei 260 gesendet, und die Verarbeitung geht bei 261 weiter. In einer weiteren Ausführungsform werden die tatsächlich verfügbaren Ressourcen überwacht und mit den für eine Verarbeitungsanforderung, die durch VERARBSTART angezeigt wird, benötigten Ressourcen verglichen.
Falls der Zähler nicht höher als der Grenzwert ist, jedoch erfaßt wird, daß die MARKIERUNG W VOLL bei 262 gesetzt ist, kehrt der Fluß zurück zu 260, und der Status WARTESCHLÄNGE VOLL wird als Antwort auf VERARBSTART gesendet, anderenfalls geht die Bearbeitung der Anforderung bei 264 weiter, und der Fluß geht bei 266 weiter. Falls die bei 250 empfangene Nachricht keine Nachricht VERARBSTART ist, wird sie überprüft, um festzustellen, ob es sich um eine Nachricht "Warteschlange neu starten" bei 268 handelt. Ist dies nicht der Fall, geht die Verarbeitung bei 270 weiter. Falls es eine Nachricht "Warteschlange neu starten" ist, wird die MARKIERUNG W VOLL bei 272 auf "aus" zurückgesetzt, und die Verarbeitung geht bei 274 weiter.
Um eine Bedingung "Warteschlange voll" zu löschen, muß der Serverprozeß entweder mehr Ressourcen zuordnen und den Grenzwert an ausstehenden Anforderungen erhöhen oder den Verarbeitungsvorgang bei mindestens einer der Anforderungen in einer vollen Verbindung beenden. Dieser Fluß ist in Fig. 8 dargestellt. Wird eine Verarbeitungsanforderung beendet, wird der entsprechende Verbindungsgruppenzähler bei 280 vermindert. Es wird entweder ein VERARBENDE oder eine Nachricht "Busfehlerbedingung" bei 282 gesendet. Die NARKIERUNG W VOLL wird anschließend bei 284 überprüft, und falls diese ausgeschaltet ist, geht die Verarbeitung bei 285 weiter. War die MARKIERUNG W VOLL eingeschaltet, wird der Verbindungsgruppenzähler überprüft, um festzustellen, ob er unter dem Grenzwert bei 286 liegt. Dieser Grenzwert, auf den im Block 286 als "unterer Wert" Bezug genommen wird, muß nicht der gleiche wie der zuvor erläuterte Grenzwert sein. Es kann wünschenswert sein, einen noch niedrigeren Grenzwert einzurichten, um zu gewährleisten, daß genügend Ressourcen für eine Anzahl von Anforderungen verfügbar sind. dies kann hilfreich sein, um eine konstante Folge von Flüssen WARTESCHLÄNGE VOLL zu eliminieren, wobei mehrere Anforderungen nach dem Neustart der Warteschlange des Anforderers schnell gesendet werden können. Liegt der Zähler nicht unter dem unteren Wert, geht die Verarbeitung bei 287 weiter. Liegt der Zähler unter dem unteren Wert bei 286, wird eine Nachricht "Pufferbereich verfügbar" bei 288 gesendet, und die Verarbeitung geht bei 290 weiter.
In einer bevorzugten Ausführungsform sind gesonderte Verbindungsgruppen für jedes Übertragungsprotokoll in der Buseinheit 50 festgelegt, einschließlich der Verbindungen zu den Prozessen, die X.25, LAN, SDLC und andere Übertragungsprotokolle ausführen.
Eine andere Gruppe umfaßt Verbindungen zu Fehlerbearbeitungsprozessen. Noch eine andere Gruppe ist für Verbindungen, die allgemeine Verwaltungsprozesse betreffen, zuständig.
Eine weitere Gruppe umfaßt normale Funktionen wie Verbindungen zu Prozessen, die an der Übertragung von Daten zwischen einer Plattenlaufwerkseinheit, die von der Buseinheit 52 gesteuert wird, beteiligt sind.
Mehrere Variationen hinsichtlich der Anzahl der Verbindungsgruppen liegen im Rahmen der Erfindung. Einige Prozesse können einen großen Bedarf an Ressourcen haben, so daß es wünschenswert sein kann, eine einzelne Verbindungsgruppe für Verbindungen zu jedem derartigen Prozeß zu haben. Die im einzelnen gewünschte Gruppierung von Verbindungen hängt von der vorhandenen Ausführung und den Merkmalen der Prozesse, die miteinander kommunizieren müssen, ab.
Die Einrichtung einer Verbindung zwischen einem Prozeß im Host 56 und einem Prozeß im E/A-Prozessor 66 führt auch dazu, daß der Busverwalter 88 die Verbindung beendet und seinen Prozessen eine Verbindung zu einer von mehreren Verbindungsgruppen CG1, CG2, ..., CGn zuweist. Folglich weist der Busverwalter des Prozessors, in dem sich der Zielprozeß befindet, jedem Prozeß in dem die Buseinheiten umfassenden System, der eine Verbindung zu einem anderen Prozeß hat, eine Verbindung zu einer Gruppe zu und ordnet der Verbindungsgruppe, die verwendet werden muß, um Verarbeitungsanforderungen auf der dieser Gruppe zugewiesenen Verbindung zu bearbeiten, Ressourcen zu.

FLUSSSTEUERUNGS-BUSNACHRICHTEN

Nachrichten werden zwischen Busverwaltern übertragen, um Nachrichten zu steuern und zu resynchronisieren, wenn eine Verbindungsgruppe nicht genügend Ressourcen zur Verfügung hat, um eine Anforderung, die für einen mit dieser Gruppe verbundenen Prozeß bestimmt ist, zu bearbeiten. Kann eine Zielbuseinheit keine zusätzlichen Verarbeitungsvorgänge für eine bestimmte Verbindungsgruppe annehmen, gibt sie eine Nachricht aus, die einen Status WARTESCHLÄNGE VOLL angibt. Dieser Status ist in einer Nachricht "Busfehlerbedingung" enthalten, deren Format in Fig. 9 gezeigt ist. Die Nachricht "Busfehlerbedingung" wird an Stelle von einer normalen Antwort auf eine Anforderung ausgegeben, um Fehler zu melden, welche die erfolgreiche Beendigung oder Fortsetzung von Verarbeitungen verhindern. Einige andere Bedingungen, für welche die Nachricht "Busfehlerbedingung" gesendet wird, sind Adressierfehler bei Speicherzugriffsanforderungen, Formatfehler und der Empfang nicht definierter oder nicht unterstützter Nachrichten. Einige andere Bedingungen können das Senden dieser Nachricht in Abhängigkeit von der physischen Ausführung der Bustransporteinrichtung aufrufen.
Ein mit RESERVIERT bezeichnetes Feld in der Nachricht "Busfehlerbedingung" ist für eine bevorstehende Nutzung reserviert. Ein Feld BUSEINHEIT wird verwendet, um die Quelle der Nachricht zu kennzeichnen. Es wird zum Zweck dieser Erfindung ignoriert. Ein drittes Feld NACHRICHTEN-ID (82) wird verwendet, um die Nachricht als eine Nachricht "Busfehlerbedingung" zu kennzeichnen. Ein STEUERFELD enthält Informationen, um die eindeutige Anforderung oder Verbindung, die ein Fehler betrifft, zu kennzeichnen. Die Inhalte dieses Feldes hängen von dem Fehler und der besonderen Transportnachricht/DMA und dem Flußverfahren, das der Fehler betrifft, ab. Ein Feld CFID kennzeichnet den Inhalt des STEUERFELDES. Verschiedene Werte zeigen an, daß es sich bei den Informationen im Steuerfeld um eine Anforderer-ID oder eine Serververbindungs-ID oder die Adresse eines Steuerblocks usw. handelt. Dies hängt davon ab, warum die Nachricht gesendet wurde und wer sie sendete. Ein Feld ACTN kennzeichnet eine durchzuführende Wiederherstellungsaktion. Ein Wert zeigt an, daß keine Maßnahme durchgeführt werden muß, ein anderer verlangt die Initialisierung der Schließung einer Verbindung, ein weiterer bewirkt ein Zurücksetzen, um Übertragungen zu resynchronisieren.
Die Bedingung WARTESCHLÄNGE VOLL ist im Feld FEHLERSTATUS angezeigt, auf das eine VERBIND-GRUPPEN-ID folgt, das die Verbindungsgruppe, die voll war, kennzeichnet. Es zeigt an, daß die Nachricht von der adressierten Buseinheit nicht ausgeführt wurde. Das STEUERFELD enthält verschiedene Werte, wenn der Status WARTESCHLÄNGE VOLL angezeigt ist. Es kann je nach der Art und Weise, wie Daten übertragen werden mußten, eine Steuerblockadresse oder eine Anforderer-ID enthalten. In einem Flußsteuerungsabschnitt der vorliegenden Anmeldung werden darüber hinaus weitere verschiedene Arten der Datenübertragung beschrieben. Das Feld FEHLERSTATUS wird außerdem verwendet, um den Status von anderen Fehlerbedingungen, wie den oben beschriebenen, zu kennzeichnen.
Nach der Sendung eines Status WARTESCHLÄNGE VOLL zu einer Quellenbuseinheit überwacht der Busverwalter der Zielbuseinheit, die ihn sendete, die geeignete Verbindungsgruppe, um zu bestimmen, wann genügend Ressourcen für die Verbindungsgruppe verfügbar sind.
Wenn die Zielbuseinheit in dieser bestimmten Verbindungsgruppe Speicherplatz verfügbar hat, sendet sie eine Nachricht "Pufferbereich verfügbar" zu der Quellenbuseinheit. Die Buseinheitennachricht "Pufferbereich verfügbar" wird verwendet, um dem Quellenbusverwalter anzuzeigen, daß Pufferbereich verfügbar ist. Sie wird von einer Buseinheit nur gesendet, nachdem die Buseinheit einen Status WARTESCHLÄNGE VOLL zu der Quellenbuseinheit gesendet hat. Sie zeigt an, welche Verbindungsgruppe über Pufferbereich verfügt. Das Format der Nachricht "Pufferbereich verfügbar" ist in Fig. 10 gezeigt. Es gibt vier Felder RESERVIERT, ein Feld NACHRICHTEN-ID und ein Feld GRUPPE (GP), das die Verbindungsgruppe, für die Pufferbereich zur Verfügung steht, eindeutig festlegt.
Die Quellenbuseinheit empfängt die Nachricht "Pufferbereich verfügbar" und bestimmt die Anzahl der Verarbeitungsanforderungen, die zu dieser bestimmten Verbindungsgruppe auf der Zielbuseinheit gesendet wurden. Da die Übertragung asynchron erfolgt und interne Warteschlangenverzögerungen in der Hardware der Quellenbuseinheit auftreten können, kann die Quellenbuseinheit bereits mehrere Nachrichten zur Einleitung von Verarbeitungsvorgängen gesendet haben.
Wenn Übertragungen, die wieder gesendet werden müssen, gekennzeichnet sind, d.h.: diejenigen, die später erfolgten als die Nachricht, die bewirkte, daß der Status WARTESCHLÄNGE VOLL ausgegeben werden mußte, und für die Verbindungsgruppe, die voll war, bestimmt waren, gibt der Busverwalter der Quellenbuseinheit eine Nachricht "Warteschlange neu starten" aus. Diese Nachricht wird verwendet, um zu gewährleisten, daß keine Nachrichten von der Verbindungsgruppe im Zielprozessor in der falschen Reihenfolge entnommen werden. Falls die Verbindungsgruppe sofort nach der Ausgabe einer Nachricht "Pufferbereich verfügbar" beginnen müßte, Nachrichten zu entnehmen, ist es wahrscheinlich, daß einige Verarbeitungsvorgänge in der falschen Reihenfolge bearbeitet würden. Dies wären Verarbeitungsvorgänge, die durch Nachrichten eingeleitet wurden, die von der Quellenbuseinheit ausgegeben wurden, bevor die Quellenbuseinheit den Status WARTESCHLÄNGE VOLL empfing und die vom Zielbuseinheiten-Verwalter nach der Ausgabe der Nachricht "Pufferbereich verfügbar" empfangen wurden.
Das Format der Nachricht "Warteschlange neu starten" ist in Fig. 11 gezeigt. Sie ist der Nachricht "Pufferbereich verfügbar" ähnlich, indem sie kennzeichnet, um welchen Nachrichtentyp es sich im Feld NACHRICHTEN (0/D)-ID handelt, und in einem Feld GRUPPE die Verbindungsgruppe kennzeichnet, die ihre Warteschlange neu starten muß. Bis die Nachricht "Warteschlange neu starten" vom Busverwalter der Zielbuseinheit empfangen wird, gibt der Busverwalter den Status WARTESCHLÄNGE VOLL für jede Nachricht zum Start von Verarbeitungsvorgängen aus.

BEISPIELE FÜR DEN NACHRICHTENFLUSS

In Fig. 12 ist ein Austausch von Nachrichten als Antwort auf eine volle Warteschlange für eine Verbindungsgruppe in einer Zielbuseinheit dargestellt. Die Zielbuseinheit ist als der Server bezeichnet, und die Quellenbuseinheit ist als der Anforderer bezeichnet. Vom Server gesendete und empfangene Nachrichten sind auf der Serverseite der Figur dargestellt, weil der Fluß dort gesteuert wird. Pfeile zwischen dem Anforderer und dem Server zeigen auf die Buseinheit, die jede Nachricht empfing. Die Folge der Nachrichten ist in numerischer Ordnung angegeben. Die Ereignisse sind nun in der Reihenfolge, in der sie in Fig. 12 auftreten, aufgelistet:
Der Anfordererprozessor sendet eine Nachricht, die Verarbeitungsvorgänge einleitet und als Nachricht VERARBSTART (1) (an späterer Stelle in dieser Beschreibung definiert) bezeichnet wird, zum Serverprozessor.
2. Der Serverprozessor hat eine Bedingung WARTESCHLÄNGE VOLL für die Verbindungsgruppe, für welche die Nachricht VERARBSTART bestimmt war, erkannt, und gibt eine Fehlernachricht mit einem Status WARTESCHLÄNGE VOLL aus.
3. Aufgrund der asynchronen Funktionsweise der Buseinheiten hat der Anforderer den Status WARTESCHLÄNGE VOLL noch nicht erfaßt, und er sendet eine zweite Nachricht VERARBSTART (2) zum Server.
4. Der Server hat eine frühere Verarbeitungsanforderung beendet und signalisiert dies dem Anforderer, indem er eine Nachricht VERARBENDE sendet.
5. Da der Server eine frühere Verarbeitungsanforderung beendet hat, hat der Server Ressourcen oder Pufferbereich verfügbar und sendet eine Nachricht "Pufferbereich verfügbar" zum Anforderer.
6. Der Anforderer hat die Bedingung "Warteschlange voll" aufgrund von Hardware-Warteschlangenverzögerungen im Anforderer nicht erkannt und sendet eine Nachricht VERARBSTART (3).
7. Der Server muß fortfahren, den Status WARTESCHLÄNGE VOLL zum Anforderer zu senden, bis der Server eine Nachricht "Warteschlange neu starten" empfängt.
Er gibt daher einen Status WARTESCHLÄNGE VOLL (2) als Antwort auf das Erkennen der Nachricht VERARBSTART (2) aus.
8. Der Server erkennt nun die Nachricht VERRRBSTART (3) und gibt eine Nachricht WARTESCHLÄNGE VOLL (3) aus.
9. Der Anforderer erkennt nun den Status WARTESCHLÄNGE VOLL für VERARBSTART (1), (2) und (3) und die Nachricht "Pufferbereich verfügbar" und sendet, nachdem er bestimmt hat, welche Nachrichten er zurücksenden muß und in welcher Reihenfolge sie gesendet werden müssen, eine Nachricht "Warteschlange neu starten".
10, 11 und 12. Der Anfordererprozessor sendet die Nachrichten VERARBSTART in der richtigen Reihenfolge zurück.
Wenn ein Verarbeitungsvorgang von einem Server beendet wird, wird eine Nachricht VERARBENDE zu der anfordernden Buseinheit gesendet, um anzuzeigen, daß der Verarbeitungsvorgang beendet wurde. Ihr Format wird später beschrieben.

DATENFLUSS

In der bevorzugten Ausführungsform aus Fig. 2 ist die Bushardware 90 und 92 der Buseinheiten 50 und 52 mit direkten Speicherzugriff (DMA) dargestellt. Diese Fähigkeit ist eine Standardhardware-Fähigkeit, welche der größte Teil der Hardware heut zutage aufweist. Haupt-DMA ermöglicht der Buseinheit, die ihn besitzt, direkt auf den Hauptspeicher einer Buseinheit mit Neben-DMA zuzugreifen, ohne den Prozessor in der Buseinheit mit Neben-DMA zu unterbrechen. Folglich werden die Einzelheiten ihres Betriebs nicht beschrieben, da sie für ein umfassendes Verständnis der Erfindung nicht notwendig sind.
Die Buseinheit 50 weist Neben-DMA 90 auf. In der bevorzugten Ausführungsform ist die Buseinheit 50 ein Host. Neben-DMA ermöglicht einer Buseinheit, andere Buseinheiten auf ihren Hauptspeicher 58 zugreifen zu lassen, ohne den Host 56 zu unterbrechen. Folglich ist die Leitung 60, die dem Host 56 den Zugriff auf den Hauptspeicher 58 ermöglicht, außerdem mit dem Busverwalter 86 und mit der Neben-DMA-Hardware verbunden, um der Hardware 90 den direkten Zugriff auf den Hauptspeicher 58 zu ermöglichen. Dies ermöglicht einer anderen Buseinheit, wie der Buseinheit 52, die Hardware 92 mit Haupt-DMA aufweist, auf den Hauptspeicher 58 der Buseinheit 50 zuzugreifen, ohne den Host 56 zu unterbrechen. Eine Buseinheit, die nur Neben-DMA aufweist, kann nicht direkt auf den Hauptspeicher einer anderen Buseinheit zugreifen, während eine Einheit, die nur Haupt-DMA aufweist, keine andere Buseinheit aktivieren kann, zu versuchen, direkt auf ihren Hauptspeicher zuzugreifen.
Falls ein Prozeß in der Buseinheit 52 eine Verarbeitungsanforderung zu einem Prozeß in der Buseinheit 50 sendet, müssen die eigentlichen Datenübertragungen transparent für die Prozesse erfolgen. Die IPCFs 72 und 74 sind die von den Prozessen verwendeten Verbschnittstellen zur Bearbeitung von Verarbeitungsvorgängen. Ein Serverprozeß greift auf die vom Anforderer gekennzeichneten Daten in seinem eigenen Takt zu. Da die Serverbuseinheit in diesem Fall nur Neben-DMA aufweist, wird ein Mittel bereitgestellt, um die Daten sowohl für die IPCF als auch für die Prozesse transparent zu machen.
Im normalen Fluß, wo gewährleistet ist, daß jede Buseinheit volle DMA-Fähigkeit aufweist, würde der Busverwalter 88 Informationen von IPCF-Verben von der IPCF 74 empfangen, die anzeigen, daß ein Prozeß eine Verarbeitungsanforderung senden möchte. Der Busverwalter 88 würde anschließend den Busverwalter 86 informieren, daß ein Verarbeitungsvorgang für ihn vorliegt, indem er eine Nachricht VERARBSTART sendet. Das Format der Busnachricht VERARBSTART ist in Fig. 13 gezeigt, und sie enthält genügend Informationen für den Busverwalter 86 in der Serverbuseinheit 50, um einen Anforderung/Antwort-Steuerblock (RRCB), der Steuerinformationen und Datenadressen angibt, vom Hauptspeicher 68 der Buseinheit 52 in den Hauptspeicher 58 der Buseinheit 50 zu übertragen, falls er dies könnte. Weitere Einzelheiten des RRCB sind in den Fig. 14 und 15 gezeigt. Der Busverwalter 86 könnte anschließend den vorgesehenen Prozeß im Host 56 über die IPCF 72 informieren, daß eine Verarbeitungsanforderung ansteht, die von dem Prozeß in eine Warteschlange gestellt würde. Der Prozeß würde die Anforderung, für die eine Datenübertragung zwischen den Buseinheiten notwendig wäre, anschließend ausführen. Die Kopie des RRCB, die sich nun im Hauptspeicher 58 befinden würde, würde vom Busverwalter 86 verwendet, um die Datenübertragung zwischen den Buseinheiten zu steuern. Der angeforderte Arbeitsgang würde durch eine Nachricht VERARBENDE (siehe Fig. 16), die zum Busverwalter 88 gesendet würde, der den anfordernden Prozeß über die IPCF 74 informieren würde, als "beendet" signalisiert.
Das Problem bei dem oben dargestellten Vorgang ist, wie in Fig. 2 ausgeführt, daß die Bushardware 90 nicht direkt auf den Hauptspeicher 68 zugreifen kann. Auch wenn die Bushardware 90 Haupt-DMA aufweisen würde, müßte die Bushardware außerdem Neben- DMA aufweisen. Das Problem wird gelöst, indem ein Speicherverteiler-Steuerblock und mehrere neue Busnachrichten verwendet werden, um die Verwaltung der Puffer im Hauptspeicher 58 der Hostbuseinheit 50 dem Busverwalter 88 der Buseinheit 52 zu übergeben. Dies ermöglicht dem Busverwalter 88 im Anforderer, Daten, die sich auf die Anforderung beziehen, zu den Puffern im Hauptspeicher 58 des Servers zu übertragen, und anschließend dem Server Daten gemäß dem normalen Fluß von Verarbeitungsvorgängen aus den Puffern in einen Speicher, den der Serverprozeß nutzen kann, zu übertragen. Folglich scheint der Datenfluß für die IPCF 72 normal zu erfolgen. Der RRCB wird verwendet, um wie gewöhnlich anzuzeigen, wo sich die Daten befinden, auf die der Server zugreifen muß. Der Anfordererbusverwalter 88 gewährleistet einfach, daß die Daten in Puffern im Hauptspeicher 58 lokalisiert sind. Es folgt nun eine ausführlichere Beschreibung des RRCB und der Nachrichten.
Ein RRCB ist in den Fig. 14 und 15 gezeigt. Er wird verwendet, um eine Verarbeitungsanforderung und die mit ihr verbundenen Daten zu kennzeichnen. Der RRCB ist ein Steuerblock, der vom Busverwalter in der Anfordererbuseinheit und dem Busverwalter in der Serverbuseinheit verwendet wird, um die Verschiebung von Daten zwischen den Buseinheiten zu steuern. Informationen im RRCB werden für den physischen DMA-Prozeß verwendet. Die Inhalte des RRCB sind bevorzugterweise Lesedaten. Die Inhalte werden vom Busverwalter in der Serverbuseinheit nicht geändert oder modifiziert.
Der RRCB kann, wie vom Busverwalter des Anforderers angegeben, in der bevorzugten Ausführungsform jede Länge bis zu 4088 Bytes aufweisen. Um Festblock-Pufferverwaltung durch den Anforderer zu erleichtern, können RRCBs segmentiert und verkettet werden. Falls ein Festblock beispielsweise 512 Bytes lang ist und ein RRCB ist länger, wird ein RRCB in einen ersten Typ segmentiert, der einige Kennsatzinformationen und eine Mehrzahl von Segmenten des zweiten Typs, die in Fig. 15 gezeigt werden, enthält, wobei keines der Segmente länger als der Festblock ist. Das erste Feld des ersten Typs des RRCBs weist eine Länge des gesamten RRCBs in Bytes auf. Die Länge ist die Summe der Längen aller der RRCB- Segmente. Ein Feld RRCB-TYP gibt an, daß es sich um ein RRCB- Segment des ersten Typs handelt. Eine SERVERVERBINDUNGS-ID gibt die Kennung des Zielprozesses für diese Anforderung an. Ein Feld ANFORDERUNGSPRIORITÄT gibt die vom Serverprozessor zu verwendende Priorität an, wenn eine Anforderungsmeldung in die Eingangswarteschlange des Serverprozesses eingefügt wird. Ein Feld MARKIERUNG legt fest, ob vom Server eine unbedingte Antwort oder nur eine Ausnahmeantwort benötigt wird. Ein Feld ANFORDERER-RID gibt die Kennung der Anforderung an. Es ist nur dem Anforderer bekannt.
Ein ERWEITERTER STATUS ZEIGER gibt eine Adresse eines Bereichs an, in dem ein erweiterter Status (Statusdaten, welche die architekturbedingte Größe, die für einen Status erlaubt ist, überschreiten) plaziert werden kann. Dieser Bereich muß bevorzugterweise verfügbar sein und vom Anfordererbusverwalter vor der Nutzung auf Null gesetzt werden. Die Adresse gilt für denselben Speicher wie der RRCB in dem vom Anforderer verwalteten Speicher.
Der Rest des Segmentes des ersten Typs ist identisch mit Segmenten des zweiten Typs. Er besteht aus einer Mehrzahl von Deskriptorelementworten, die den Typ der Daten, die im Feld DATENNARKIERUNGEN durch das Deskriptorelement beschrieben werden, angeben. Ein Deskriptortyp im Feld DATENNARKIERUNGEN kennzeichnet den Deskriptortyp wie Anforderung, Dateneingabe vom Serverspeicher zum Anfordererspeicher, Datenausgabe zum Serverspeicher vom Anfordererspeicher oder eine Segmentverbindung zum nächsten RRCB-Segment, wenn ein weiteres Segment benötigt wird. Das Deskriptorelement für die RRCB-Segmentverbindung muß am Ende des RRCB-Segmentes auftreten, falls ein anderes RRCB-Segment vorhanden ist. Ein Deskriptorformat-Feld innerhalb des Feldes DATENMARKIERUNGEN wird verwendet, um anzugeben, daß Direktdaten linksbündig ausgerichtet sind, wobei sie das Datenwort starten und bis maximal 44 Bytes weitermachen. Ein Anforderungs- oder ein Datenausgabe-Deskriptor kann Direktdaten oder ein Bezug sein, der die Buseinheitennummer und die Datenadresse enthält, um zu kennzeichnen, wohin Daten mit DMA übertragen werden müssen oder wo auf sie zugegriffen werden muß. Eine Buseinheitennummer muß stets erscheinen, wenn das Bezugsdeskriptorformat angegeben wird. Das Feld DATENMARKIERUNGEN kennzeichnet durch die Buseinheitennummer die Buseinheit, auf die sich die Adresse in dem nächsten Feld bezieht.
Ein Feld DATENLÄNGE gibt die Länge der Daten des durch das folgende Adreßfeld angegebenen Feldes in Byte an. Es handelt sich um einen ganzzahligen Wert ohne Vorzeichen, der einen zusammenhängenden, realen Speicher angibt. Die Daten werden bis zu einem Vielfachen von 8 Bytes mit Nullen aufgefüllt.
Ein Feld DATENADRESSE/DATEN wird entweder als Adresse oder als Direktdaten verwendet. Bei diesem Feld handelt es sich um Direktdaten, falls Direktdaten in dem Deskriptorformat von DATENMARKIERUNGEN des vorhergehenden Wortes des RRCB-Segmentes angegeben sind; anderenfalls ist es eine Adresse. Die Adresse könnte sich im Speicher des Servers, im Speicher des Anforderers oder im Speicher einer dritten Buseinheit, die nicht gezeigt ist, befinden. Die Adresse wird vom Serverbusverwalter für DMA-Operationen zum oder aus dem Speicher in dem anderen Prozessor oder in einem anforderergesteuerten Puffer im Serverspeicher verwendet.

PUFFERVERWALTUNGS-NACHRICHTEN

Die Pufferverwaltung wird zwischen zwei Busverwaltern übergeben. Eine Buseinheit stellt einen fernen Speicher in ihrem Hauptspeicher zur Nutzung und Verwaltung durch die andere Buseinheit bereit. In dieser Ausführungsform verwaltet die Buseinheit 52 Puffer im Hauptspeicher 58, der mit dem Host 56 eng verbunden ist. Der ferne Prozessor 66 der wuseinheit 52 kann den fernen Speicher im Hauptspeicher 58 zu jedem, seinem Bedarf entsprechenden Zweck nutzen. Der ferne Speicher kann von dem fernen Prozessor als eine logische Erweiterung seines eigenen Speichers angesehen werden.
Die Buseinheit 52 erstellt eine Anforderung für einen fernen Speicher mit einer Buseinheitennachricht "Speicheranforderung", die vom Busverwalter 88 gesendet wird. Das Format der Nachricht "Speicheranforderung" ist in Fig. 17 gezeigt. Kurz nach dem normalen Systemstart wird diese Nachricht von einer Buseinheit verwendet, um einen fernen Speicher im Host zu erhalten.
Die Buseinheitennachricht "Speicheranforderung" wird außerdem gesendet, wenn der ferne Prozessor keine weiteren Puffer zur Verfügung hat. Die Länge der angeforderten Puffer kann in einem Feld LÄNGE DER PUFFER angegeben werden. Der lokale Prozessor kann die angeforderte Puffergröße vielleicht nicht bereitstellen, erfüllt jedoch die Anforderung, falls größere Puffer bereitgestellt werden. Kleinere Puffer werden nicht bereitgestellt. Eine Anzahl von RESERVIERT-Feldern sind angezeigt und als Null angegeben. Ein Feld NACHRICHTEN-ID (06) kennzeichnet die Nachricht als eine Buseinheitennachricht "Speicheranforderung" (Speicheranf). Das Feld SPEICHERGRÖSSE ist die Länge des angeforderten Speichers in Byte. In der bevorzugten Ausführungsform umfaßt der Speicher, der in einer einzelnen Nachricht maximal angefordert werden kann, 65535 Bytes. Ein Feld LÄNGE DER PUFFER gibt die Mindestlänge von angeforderten Puffern an. Folglich ist der Puffer, obwohl die angeforderte Gesamtgröße nicht erfüllt ist, auch wenn ein Puffer bereitgestellt wird, mindestens so lang wie der Wert des Feldes LÄNGE DER PUFFER.
Eine Buseinheitennachricht "Speicherliste verfügbar" und ein Speicherlisten-Steuerblock (SLCB) werden vom Busverwalter in der lokalen Buseinheit als Antwort auf eine Buseinheitennachricht "Speicheranforderung" gesendet. Der SLCB stellt eine Liste von Puffern im Speicher der lokalen Buseinheit bereit, die von der fernen Buseinheit verwendet werden kann. Nur ein "Speicherliste verfügbar"/SLCB wird als Antwort auf eine "Speicheranforderung" gesendet und nur als Antwort auf eine "Speicheranforderung".
Das Format der Buseinheitennachricht "Speicherliste verfügbar" ist in Fig. 18 gezeigt. Ein Feld MARKIERUNG kennzeichnet den Typ der Antwort, beispielsweise daß ein Speicher verfügbar ist, Ressourcen nicht verfügbar sind und kein Speicher bereitgestellt ist oder keine Puffer in der angeforderten Größe verfügbar sind und keine als Antwort auf die Anforderung bereitgestellt wurden. Ein Feld NACHRICHTEN-ID (07) kennzeichnet, daß dies eine Buseinheitennachricht "Speicherliste verfügbar" ist. Ein Feld ADRESSE DES SPEICHERLISTEN-STEUERBLOCKS gibt die reale Adresse des SLCBs im Buseinheitenspeicher, der den fernen Speicher enthält, an. Dieses Feld ist nur gültig, falls der Wert des Feldes MARKIERUNG anzeigt, daß ein Speicher verfügbar war. Ein Feld LÄNGE zeigt die Länge des SLCBs im Speicher der lokalen Buseinheit an.
Das SLCB-Format ist in Fig. 19 gezeigt. Ein Feld BUSNUMMER gibt die Busnummer an, unter der diese Buseinheit in der lokalen Buseinheit erscheint. In der bevorzugten Ausführungsform können bis zu acht verschiedene Busse vorhanden sein. Das Feld BUSEINHEIT gibt die Buseinheitennummer der fernen Buseinheit an, zu der dieser SLCB übertragen wird. Die Anzahl der Puffer und deren Längen sind in den nächsten beiden Feldern angegeben. Der Sender in der lokalen Buseinheit ist für die Gewährleistung zuständig, daß dieses Feld mit dem Feld LÄNGE in der Nachricht "Speicherliste verfügbar" übereinstimmt.
Der Busverwalter in der Buseinheit, die den fernen Speicher enthält, verwaltet einen Teil des Hauptspeichers auf der gleichen Buseinheit. Er verfolgt die Puffer im Hauptspeicher laufend und gibt die Steuerung an andere, den Hauptspeicher anfordernde Buseinheiten weiter. Folglich bewerben sich Verbindungen und andere Buseinheiten über den Busverwalter um Puffer in Hauptspeicher.
Ein Feld PUFFERADRESSE wird verwendet, um die Adresse des realen Speichers in der lokalen Buseinheit der Puffer anzugeben. Dies wird so oft wie nötig wiederholt, um die Anzahl der Puffer zu erfüllen, die im Feld ANZAHL DER PUFFER angegeben ist.
Eine Buseinheitennachricht "Speicherliste beendet" wird vom Busverwalter der fernen Buseinheit gesendet, um anzuzeigen, daß die ferne Buseinheit nicht länger Zugriff auf den vom SLCB angegebenen fernen Speicher benötigt. Die Ausgabe des fernen Speichers kann außerdem von der Buseinheit mit Neben-DMA, die einen Speicher für eine andere Buseinheit mit Haupt-DMA verfügbar machte, mit einer Buseinheitennachricht "Speicherliste ausgeben" eingeleitet werden, um anzuzeigen, daß ungenutzte Puffer ausgegeben werden müssen. Die Nachricht "Speicherliste beendet" wird außerdem verwendet, um anzuzeigen, daß die in "Speicherliste ausgeben" angegebene Anforderung nicht erfüllt werden kann.
Das Format der Nachricht "Speicherliste beendet" ist in Fig. 20 angegeben. Ein Feld MARKIERUNG gibt die normale Ausgabe einer Speicherliste oder eine Zurückweisung der "Ausgabe"-Anforderung an. Es kann anzeigen, daß eine normale Ausgabe der gesamten Liste erfolgt, daß eine Ausgabe als Antwort auf eine Nachricht "Speicherliste ausgeben" erfolgt, daß eine Ausgabe eines Puffers einer bestimmten Größe, der in einer Nachricht "Speicherliste ausgeben" angezeigt ist, erfolgt oder daß der angeforderte Speicher gefunden wurde, jedoch zur Nutzung angefordert ist und nicht ausgegeben werden kann.
Das Feld ADRESSE DES SPEICHERLISTEN-STEUERBLOCKS ist die reale Adresse des SLCBs im lokalen Prozessor. Enthält "Speicherliste ausgeben" eine Länge der Puffer und werden die Puffer nicht in der Nachricht "Speicherliste beendet" ausgegeben, enthält ein Feld LÄNGE DER PUFFER die Länge der Puffer, wie in "Speicherliste ausgeben" angegeben.
Das Format der Nachricht "Speicherliste ausgeben" ist in Fig. 21 gezeigt. Der Anforderer kann angeben, daß irgendeine Speicherliste mit der angeforderten Puffergröße ausgegeben wird oder kann eine bestimmte Speicheriiste kennzeichnen, die ausgegeben werden muß. Das Feld MARKIERUNG dieser Buseinheitennachricht zeigt an, ob irgendeine Speicherliste mit der angegebenen Puffergröße oder eine bestimmte Speicherliste ausgegeben werden muß. Die Meldung über die Steuerung der Speicherliste, die von der fernen Buseinheitensteuerung zu der lokalen Buseinheitensteuerung weitergegeben wird, erfolgt, wie oben beschrieben, durch die Buseinheitennachricht "Speicherliste beendet". Das Feld NACHRICHTEN-ID (09) kennzeichnet die Nachricht als eine Nachricht "Speicherliste ausgeben". Das Feld ADRESSE DER ANGEFORDERTEN SPEICHERLISTE gibt die Adresse der auszugebenden Speicherliste an, falls das Feld MARKIERUNG anzeigt, daß eine bestimmte Liste angefordert ist. Ein Feld LÄNGE DER PUFFER gibt die Länge der mit dieser Anforderung auszugebenden Puffer an, falls keine bestimmte Speicherliste angefordert ist.
In Fig. 22 ist eine vereinfachte Version der an Speicherlisten beteiligten Flüsse dargestellt. Eine Anfordererbuseinheit mit Haupt-DMA ist auf der rechten Seite der Figur mit darunter aufgelisteten Nachrichten dargestellt. Eine Serverbuseinheit mit Neben-DMA ist auf der linken Seite der Figur dargestellt. Die Verarbeitungsvorgänge sind beschrieben und als die Schritte 1 bis 6 wie folgt gekennzeichnet:
1. Der Busverwalter im Anfordererprozessor mit Haupt-DMA signalisiert dem Serverprozessor, daß er Puffer benötigt, indem er eine Nachricht "Speicherliste anfordern" sendet.
2. Der Busverwalter im Serverprozessor sendet eine Nachricht, die anzeigt, daß ein Speicherlisten-Steuerblock SLCB für den Anfordererprozessor verfügbar ist.
3. Der ferne Busverwalter überträgt mit DMA den gesamten oder einen Teil des SLCBs in seinen Speicher.
4. Der Busverwalter im Anfordererprozessor verwendet die Puffer, wie gewünscht.
5. Der Busverwalter im Serverprozessor möchte eine Art von Abschluß, wie einen Tagesabschluß, durchführen, oder eine Buseinheit ist über eine Spitzenbelastung hinaus und hat keinen Speicher ausgegeben. Er sendet eine Nachricht "Speicherliste ausgeben" zum Anfordererprozessor.
6. Der Busverwalter im Anfordererprozessor sendet eine Nachricht "Speicherliste beendet", die anzeigt, daß der SLCB nicht länger benötigt wird.
Wenn ein Busverwalter einer Buseinheit, die nur Neben-DMA aufweist, eine Übertragung über den Bus empfängt, überprüft er in Fig. 23 bei 300, um zu bestimmen, ob die Übertragung eine Anforderung ist. Ist dies der Fall, fordert der Busverwalter, wie bei den Blöcken 302, 304 und 306 angezeigt, den Hauptspeicher vom Systemspeicherverwalter an, um die Anforderung unter Verwendung wohlbekannter Speicherverwaltungsverfahren zu erfüllen. Der Busverwalter greift auf den weitergegebenen Speicher zu, um zu kennzeichnen, daß er für die Verwaltung dieses Speichers zuständig ist. Die Verwaltungszuständigkeit umfaßt die Fähigkeit, den Speicher mit einem gewissen Grad an Sicherheit, daß eine andere Buseinheit den Speicher nicht selbständig nutzt, zu lesen und hineinzuschreiben. Er blockt den Speicher anschließend in die angeforderte Anzahl von Blöcken und erstellt den Speicherlisten- Steuerblock, wobei Zeiger zurückgehalten werden, welche die Buseinheit, die den Speicher anfordert, mit der Speicheradresse der weitergegebenen Blöcke verbinden. Der Busverwalter sendet anschließend die Nachricht "Speicherliste verfügbar" zu der anfordernden Buseinheit und fährt mit der Bearbeitung bei 308 fort.
Zurück bei Block 300 wird, falls die Busübertragung keine Speicheranforderung ist, die Übertragung überprüft, um zu bestimmen, ob es eine Nachricht "Speicherliste beendet" bei 310 ist. Ist dies der Fall, wird der gekennzeichnete Speicher zum Systemspeicherverwalter bei 312 ausgegeben, und die Zeiger auf die Buseinheit, welche die Speicherverwaltung ausgibt, werden gelöscht. Die Verarbeitung geht bei 314 weiter. Falls bei Block 310 keine Nachricht "Speicherliste beendet" erfaßt wird, geht die Verarbeitung bei 316 weiter.
Falls vom Busverwalter der Buseinheit, die nur Neben-DMA aufweist, eine Anforderung empfangen wird, die anzeigt, daß der Host selbst ausgegebenen Speicher will, ist der in Fig. 24 angezeigte Fluß bei Block 330 eingetreten. Eine solche Anforderung kann als Ergebnis eines Bedienerbefehls zum Abschließen oder vielleicht durch eine Art von Uhrzeitunterbrechung erzeugt werden. In jedem Fall prüft der Busverwalter nach dem Empfang der Speicherausgabe-Anforderung den Speicher, auf den zugegriffen wird, weil er von einem anderen Busverwalter verwaltet wird, und wählt den auszugebenden Speicher aus. Der Busverwalter kann eine Art Statistik über die Häufigkeit der Nutzung führen, oder die Anforderung kann den Typ der abzuschließenden Einheit angeben. Auf diese Weise ist die Buseinheit bezüglich des angeforderten, auszugebenden Speichers selektiv. Bei 332 wird eine Busnachricht zu der gewünschten Buseinheit gesendet, um den Speicher aus zugeben. Die Buseinheit gibt eine Nachricht "Speicherliste beendet" aus, um zuzustimmen, wie im Fluß in Fig. 23 angezeigt. Die Verarbeitung geht dann bei 334 weiter.
Das Verfahren zur Verwaltung eines fernen Speichers kann außerdem verwendet werden, um die Systemleistung auszugleichen. Falls eine Buseinheit keinen ausreichenden Hauptspeicher aufweist, kann sie Puffer im Hosthauptspeicher zur Nutzung anfordern. Bei ausreichender Busleistung kann die Leistung bei der Buseinheit verbessert werden. Das System kann problemlos die Leistung anderer Buseinheiten verfolgen und denjenigen Buseinheiten, die bei der Beantwortung von Verarbeitungsanforderungen langsam sind, mehr fernen Speicher zuordnen. Die zugeordnete Menge muß durch den möglichen Leistungsabfall des Host ausgeglichen werden, falls ein zu großer Bereich seines Speichers fernverwaltet wird.

ENTGEGENGESETZTER FLUSS

Wie oben erläutert wurde, läuft der normale Fluß von Verarbeitungsanforderungen vom Host 56 zur Ein-/Ausgabesteuereinheit 66. Sie umfassen Verarbeitungsvorgänge wie das Lesen und Schreiben von Daten in sekundäre Speichereinheiten, die mit der Ein-/Ausgabesteuereinheit 66 verbunden sind, oder das Einleiten von Übertragungen über die Ein-/Ausgabesteuereinheit 66. Zu diesem Zweck sind eine Ein-/Ausgabesteuereinheit 66 mit Haupt-DMA und ein Host 56 mit Neben-DMA ideal geeignet. Der Server steuert als Ein-/Ausgabesteuereinheit die Datenübertragung, ohne den Host zu unterbrechen.
Im allgemeinen weist die Ein-/Ausgabesteuereinheit 66 einen Prozeß auf, der eine Verarbeitungsanforderung zum Host sendet. Dies führt zu einem entgegengesetzten Fluß der mit dem Verarbeitungsvorgang verbundenen Daten. Da der Host die Daten nicht mit DMA von der Ein-/Ausgabesteuereinheit erhalten kann, verwendet die Ein-/Ausgabesteuereinheit die fernen Puffer, die im Hosthauptspeicher unter Verwendung der zuvor erläuterten Nachrichten erhalten werden.
Ein Beispiel eines entgegengesetzten Flusses wird nun mit Bezugnahme auf Fig. 25 beschrieben. Eine Anfordererbuseinheit mit Haupt-DMA, die Ein-/Ausgabesteuereinheit 66, führt die auf der rechten Seite der Figur angegebenen Schritte aus, und eine Serverbuseinheit mit Neben-DMA, der Host 56, führt die auf der linken Seite der Figur angegebenen Schritte aus. Die Schritte, die mit 1 bis 10 numeriert sind, werden beschrieben:
1. Der Anfordererprozeß gibt eine Anforderung bei der Prozeß-zu-Prozeß-Verbschnittstelle zu der Prozeß- zu-Prozeß-Einrichtung, der IPCF 74 in Fig. 2 aus.
2. Der Busverwalter 88 erhält einen Puffer von ausreichender Größe im Hauptspeicher 58 des Host und leitet einen Haupt-DMA-Vorgang über die Bushardware 92 ein, um die Anforderung in den fernen Speicher in der Serverspeicher-Buseinheit 50 zu verschieben.
3. Der Anfordererbusverwalter 88 überträgt Daten mit DMA in den Puffer.
4. Der Busverwalter 88 überträgt anschließend den RRCB in die Puffer im Speicher des Servers. Der RRCB verwendet zu diesem Zeitpunkt Adressen in Serverspeicher der Anforderung und Daten, die in den Schritten 2 und 3 mit DMA in den fernen Speicher in der Serverbuseinheit übertragen wurden.
5. Der Busverwalter 88 im Anfordererprozessor 66 sendet eine Buseinheitennachricht "Verarbstart", die anzeigt, daß sich der RRCB und die Daten im Serverspeicher befinden. Zu dem Zeitpunkt, wenn die Nachricht "Verarbstart" gesendet wird, sind alle Daten, die mit dem die Prozeß-zu-Prozeß-Einrichtung verwendenden Prozeß verbunden sind, mit DMA in den Speicher des Servers übertragen worden.
6. Die Anforderung wird von der Prozeß-zu-Prozeß- Einrichtung 72 zum Serverprozeß weitergegeben.
7. Der Serverprozeß fordert die benötigten Daten an, die sich in dem zum Server lokalen Speicher befinden. Der Busverwalter 88 steuert die Puffer noch, der Busverwalter 86 hat jedoch während der Bearbeitung der Nachricht "Verarbstart" Zugriff auf diese Puffer. Der Busverwalter 86 des Serverprozesses überträgt die Daten in einen Bereich des Hauptspeichers 58, auf den der Serverprozeß zugreifen kann.
8. Hat der Serverprozeß den angeforderten Verarbeitungsvorgang beendet, wird die Prozeß-zu-Prozeß-Einrichtung 72 unter Verwendung von IPCF-Verben benachrichtigt.
9. Der Busverwalter 86 im Serverprozessor gibt eine Nachricht "Verarbende" mit der Statusinformation aus. Dies informiert den Busverwalter 88 im Anfordererprozessor 66 über jede Antwort, die vom Busverwalter 86 in die Puffer gestellt wird. Nach dem Abrufen einer solchen Antwort gibt der Busverwalter 88 die Puffer für die weitere Nutzung frei und zeigt dem anfordernden Prozeß an, daß der angeforderte Verarbeitungsvorgang beendet wurde.
10. Die Prozeß-zu-Prozeß-Einrichtung 74 benachrichtigt anschließend den anfordernden Prozeß, daß der Verarbeitungsvorgang beendet wurde.

Umgekehrter Fluß durch Signalnachrichten

Ein Format einer Signal-Buseinheitennachricht ist in Fig. 26 gezeigt. Die Signal-Buseinheitennachricht wird von einem Busverwalter erzeugt und wird verwendet, um kleine Nachrichten zu einem Prozeß in einem anderen Prozessor zu übertragen. Eine Verwendung umfaßt eine Datenübertragung von bis zu 4 Zeichen gleichzeitig. Für den Busverwalter, der das Signal sendet, ist es nicht erforderlich, daß der Empfänger der Signal-Buseinheitennachricht eine Antwort sendet. Es könnte eine Antwort bei einem Protokoll der höheren Ebene zwischen dem Anforderer und einem Serverprozeß vorliegen, in der bevorzugten Ausführungsform wird jedoch vom Busverwalter keine benötigt. Der Sender eines Signals kann nicht garantieren, daß es von der Serverbuseinheit empfangen wird. Für Signalnachrichten gibt es kein Flußsteuerungsverfahren. Es gibt keine Busverwaltereinrichtung, um den Sender zu informieren, daß ein Signal nicht ausgeführt werden kann, weil der empfangende Prozeß beispielsweise keinen Speicher erhalten konnte. Dies ermöglicht Flexibilität, falls keine Antwort benötigt wird. Für die Verwendung einer Signalnachricht ist im Gegensatz zu einer Verarbeitungsanforderung mit weniger Systemaufwand verbunden. Ein RRCB wird nicht benötigt.
Das Signal umfaßt zwei reservierte Bereiche, die in der bevorzugten Ausführungsform Null sind. Der 2X-Feld-Typ wird verwendet, um den Typ der Buseinheitennachricht zu definieren. Die 2 im Feld definiert dies als eine Signal-Buseinheitennachricht. Das X gibt den Inhalt des Feldes BENUTZERDATEN an. Es gibt die folgenden Typen von Signalnachrichten:
20 - Achtung (um den Empfänger zu warnen)
21 - Direktdaten - 1 Byte
22 - Direktdaten - 2 Bytes
23 - Direktdaten - 3 Bytes
24 - Direktdaten - 4 Bytes
25 - Direktfehlerdaten
26 - Direktbenutzerdaten vom Typ 1
27 - Direktbenutzerdaten vom Typ 2
28 - Direktbenutzerdaten vom Typ 3
29 - Direktbenutzerdaten vom Typ 4
2A bis 2F - für zukünftige Nutzung reserviert
Das Feld BENUTZERDATEN der Nachricht enthält benutzerdefinierte Daten, z.B. die Direktdaten. Die Direktdaten im Feld sind bevorzugterweise linksbündig ausgerichtet. Ein Feld ZIEL-CID kennzeichnet den Zielprozeß für diese Buseinheitennachricht.
Eine Variante des Signals wird verwendet, um ein Verfahren zur Umkehrung der Zuständigkeit für die Übertragung von Verarbeitungsanforderungen und der damit verbundenen, von der Buseinheit mit Haupt-DMA stammenden Daten bereitzustellen, anstatt daß sie von der Buseinheit mit Haupt-DMA übertragen werden. Eine andere Form des Signals wird, wie in Fig. 27 gezeigt, als eine Alternative zu einem fernen Speicher verwendet. Es ist eine leicht auszuführende Version von entgegengesetztem Fluß, gewährleistet jedoch nicht dieselben Garantien, welche die Version des entgegengesetzten Flusses mit einem fernen Speichers gewährleistet.
Wenn eine E/A-Buseinheit eine Anforderung zu einem Prozeß vom RAS-Typ (Reliability/Availability/Serviceability, Zuverlässigkeit/Verfügbarkeit/Wartungsfreundlichkeit) in einer Hostbuseinheit einleiten muß, sendet sie eine Signalnachricht mit dem in Fig. 27 angezeigten Format. BENUTZERDATEN ist als ein zwei-Byte- LÄNGEN-Feld definiert, das die Länge eines abzurufenden Datensatzes anzeigt, und als ein zwei-Byte-RELATIVZEIGER. Das Feld RELATIVZEIGER ist ein codierter Wert, der von der E/A-Buseinheit zugewiesen wird, und wird als Protokolleinrichtung verwendet, um eine Signalnachricht mit der als Antwort auf eine von drei Typen von Signalnachrichten erzeugten Verarbeitungsanforderung zu verbinden. Die Typen, die Verarbeitungsanforderungen von E/A-Buseinheiten entsprechen, sind unten definiert:
26 - Anforderung vom Typ 1 - FEHLERDATEN
27 - Anforderung vom Typ 2 - RESSOURCENDATEN
28 - Anforderung vom Typ 3 - TESTDATEN
Andere Typen könnten leicht gekennzeichnet werden.
Der Prozeß vom RAS-Typ wird aufgerufen, um die Typenanforderung von der E/A-Buseinheit abzurufen. Er gibt die Werte der Felder Signal-TYP, RELATIVZEIGER und LÄNGE aus. Die E/A-Buseinheit gibt den gekennzeichneten Typenanforderungsbefehl und die damit verbundenen Daten als Antwort auf die Anforderung aus. Das Format von jeder dieser Typenanforderungen ist so, als ob sie unter Verwendung des vorausgehenden Verfahrens für den entgegengesetzten Fluß oder durch den normalen Fluß gesendet worden wäre.
Ein Beispiel für die Verwendung dieses Verfahrens für den entgegengesetzten Fluß ist das Abrufen von Fehlerdaten. Der Host, der das Signal empfangen hat, ist für das Senden der Verarbeitungsanforderung zum Abrufen der Befehlsbytes und der damit verbundenen Daten zuständig. Die folgenden Verarbeitungsanforderungs-Felder enthalten die gegebenen Signalnachrichtenfelder:
ZIEL - Signal-TYP
ADRESSE - Puffer-RELATIVZEIGER
GETMAX - Signal-LÄNGE
Die E/A-Buseinheit gibt anschließend den nächsten verfügbaren Eintrag in FIFO (First in/First out)-Reihenfolge von derjenigen der angeforderten Warteschlangen für die Prozesse, die den Anforderungen vom Typ 1, 2 oder 3 entspricht.
Das Feld LÄNGE gibt die Länge der Daten an, die der E/A-Bus ausgibt. Die maximale Länge, die je nach dem Typ des gesendeten Signals ausgegeben werden könnte, beträgt jeweils 268, 272 oder 48 für die Anforderung vom Typ 1, 2 und 3 in der bevorzugten Ausführungsform. Die tatsächliche Länge der Verarbeitungsanforderung in der E/A-Buseinheit in Byte zuzüglich der damit verbundenen Daten kann jedoch geringer sein. Die Verarbeitungsanforderung der E/A-Buseinheit gibt die tatsächliche Länge der damit verbundenen Daten an.
Da die Signalnachricht aufgrund von Systemwarteschlangen-Beschränkungen oder Fehlerbedingungen verloren gehen kann, wird eine Mindestgröße der Systemwarteschlange zur Bearbeitung von Nachrichten empfohlen. Mindestens 17 Signale für EN-Anforderungen, 24 für Anforderungen vom Typ 2 und 16 für Anforderungen vom Typ 3 bearbeiten die meisten Situationen ohne Verlust von Signalnachrichten. Diese Anzahlen sind in hohem Maße abhängig vom besonderen Typ der Buseinheiten-Ressourcenunterstützung und sind hier als eine bevorzugte Ausführungsform für eine Buseinheit mit Direktzugriffsspeicher-Steuereinheit dargestellt.
Die gegebenen Anzahlen sind die Anzahlen der Einträge in den E/A-internen Puffern, welche die Verarbeitungsanforderungen der E/A-Buseinheit enthalten. Falls die Einträge nicht aus den Puffern mit der Verarbeitungsanforderung des Hosts gelöscht werden und die Puffer voll sind, wird ein Fehlerdatentyp gesendet. Das Signal RELATIVZEIGER-Wert wird als Überwachungsverfahren verwendet, um zu bestimmen, ob ein Signal verloren gegangen ist. Host- Verarbeitungsanforderungen, die einen nicht erwarteten Relativzeiger-Wert enthalten, zeigen einen Verlust einer Signalnachricht an. Die Signalnachricht wird dann von der E/A-Buseinheit erneut gesendet. Die Antwort-auf die Anforderung des Hosts enthält einen Fehlercode, der anzeigt, daß die Hostbuseinheit die Anforderung löschen muß. Das gleiche Überwachungsverfahren stellt außerdem eine Korrelation zur Handhabung von Ablaufsteuerungsbedingungen bereit, wenn der angeforderte Eintrag bereits gesendet wurde.
Die Host-Verarbeitungsanforderung enthält die folgenden Informationen:
Byte Beschreibung
0 bis 1 Befehlslänge
2 Befehls-Qualifikationsmerkmal
3 Befehlscode = X'23'
4 Anderungswert
Bits 0 bis 1 - Zugriffsmodus = '00'
Bits 2 bis 7 - Reserviert
Adreßfeld ist ein Relativzeiger vom angegebenen Ziel.
5 bis 7 Reserviert
8 bis 15 Adresse: Relativzeiger - Rechtsbündig ausgerichtet mit führenden Nullen
16 bis 23 Ziel Byte 16: Signal-Typ Bytes 17 bis 23: Reserviert
24 bis 27 Aktivierungs-ID = Buseinheitenressourcen-ID
28 bis 31 GETMAX = LÄNGE vom Signal
Wird die Antwort auf die Hostanforderung von der E/A-Buseinheit ausgegeben, enthält sie die folgenden Informationen zur Beschreibung der mit der Anforderung verbundenen Daten:
Byte Beschreibung
0 bis 1 Befehlslänge
2 Befehls-Qualifikationsmerkmal
3 Befehlscode (mit Signal-Typ verbunden)
4 Änderungswert
5 bis (n-1) Befehlstext (n = Befehlslänge)
n-L Daten (L = Länge des Dateneingangs-Deskriptors)

ENTGEGENGESETZTER FLUSS DURCH DMA-ANFORDERUNG

Noch eine weitere Möglichkeit zum Umkehren der Steuerung des Datenflusses ist die Verwendung eines Paares von Buseinheitennachrichten, die in Fig. 28 und Fig. 29 dargestellt sind. Eine Buseinheitennachricht "DMA-Anforderung" (DMA-Anf, Fig. 28) wird von der Serverbuseinheit zum Anforderer gesendet, um einen DMA auf seinen Speicher anzufordern. Eine Buseinheitennachricht "DMA beendet" (Fig. 29) von der Anfordererbuseinheit zeigt an, daß der DMA-Vorgang beendet ist. Die Anfordererbuseinheit, die Buseinheit mit Haupt-DMA), führt einen Dienst für die Serverbuseinheit aus. Der Busverwalter in der Anfordererbuseinheit weiß nicht, welche CID diese besondere Anforderung für Dienst bewirkte.
Ein Beispiel wäre, wenn der Busverwalter in einer Serverbuseinheit eine Buseinheitennachricht "Verarbeitungsstart" (Verarbstart) empfangen würde. Er sendet dann eine Buseinheitennachricht "DMA-Anf", welche die Adresse des RRCBs im Speicher des Anforderers und die Position, an der er im Speicher des Servers plaziert werden muß, angibt. Die Anfordererbuseinheit würde den Dienst ausführen und die andere Buseinheit benachrichtigen, daß der Vorgang durch eine Buseinheitennachricht "DMA beendet" abgeschlossen wurde. Der Busverwalter, der die "DMA-Anf" empfängt, führt den angeforderten Dienst ohne Kenntnis des realen Anforderers des Dienstes aus. Er führt einen Dienst für die andere Bustransporteinrichtung aus.
Die "DMA-Anf" weist die folgenden Felder auf:
RSVD ist reserviert und muß Null sein.
LÄNGE ist die Länge der mit diesem "DMA-Anf"-Vorgang zu übertragenden Daten.-DMA-ID ist die für diese "DMA- Anf" zu verwendende ID (Kennung) und muß in der Buseinheitennachricht "DMA beendet" ausgegeben werden, um diese besondere DMA-Anforderung zu kennzeichnen. Diese Kennzeichnung hat über diese DMA-Anforderung und die Buseinheitennachricht "DMA beendet" hinaus keine Bedeutung.
Typen-ID (0X) wird verwendet, um den Typ der Buseinheitennachricht und die Richtung des DMA festzulegen. Eine "DMA-Anf" hat zwei mögliche hexadezimale Werte:
'03' -- Vom Anfordererprozessor zum Serverprozessor
'04' -- Vom Serverprozessor zum Anfordererprozessor
Die DATENADRESSE im Anfordererprozessor-Feld ist die Startadresse im Anfordererspeicher für die Datenübertragung. Die Richtung der Datenübertragung ist durch das Typenfeld angegeben. Dies könnte die Adresse des RRCBs sein, der von der Buseinheitennachricht "Verarbstart" erhalten wurde, oder die Datenfeldadresse, die von den Inhalten des RRCBs erhalten wurde.
Die DATENADRESSE im Serverprozessor-Feld ist die Startadresse im Serverspeicher für die Datenübertragung. Die Richtung der Datenübertragung ist durch das Typenfeld angegeben.
Hat der Anforderer den angeforderten DMA-Vorgang beendet, benachrichtigt er den Server, daß der Vorgang beendet ist. Dies erfolgt durch das Senden einer Buseinheitennachricht "DMA BEENDET" in Fig. 29. Tritt ein Busfehler auf, wenn der Serverprozessor den angeforderten DMA-Vorgang ausführt, wird eher eine Buseinheitennachricht BUSFEHLERBEDINGUNG als eine Buseinheitennachricht DMA BEENDET ausgegeben.
Die Felder der Buseinheitennachricht DMA BEENDET sind die folgenden:
Ein Feld RESERVIERT muß Null sein.
DMA-ID ist die ID, die in der DMA-Anforderung bereitgestellt wurde, und wird verwendet, um den Anforderer dieser besonderen DMA-Anforderung zu kennzeichnen.
Das Typenfeld (05) wird verwendet, um den Typ der Buseinheitennachricht festzulegen.
Zwei weitere Felder RESERVIERT müssen alle Nullen sein.
Die Folge, die mit einer Buseinheitennachricht "Verarbstart" startete, wird mit einer Buseinheitennachricht VERARBENDE beendet.
Fig. 30 ist ein vereinfachtes Beispiel des Nachrichtenflusses für einen Vorgang ANF SENDEN, der in einer Buseinheit eingeleitet wurde, die keinen Neben-DMA aufweist.
1. Der Serverprozeß, in diesem Fall ein Prozeß in der Hostbuseinheit, erreicht eine Stelle in seiner Verarbeitung, wo er warten möchte.
Er erzeugt ein IPCI W EMPF (WARTESCHLÄNGE EMPFANGEN). (Dieses Beispiel setzt voraus, daß der Server die Verarbeitungsanforderung durch das W EMPF anforderte.) Da keine Anforderungsmeldungen in seiner Eingangswarteschlange vorhanden sind, tritt der Zielprozeß in den Wartezustand ein.
2. Der Anforderer, in diesem Beispiel ein Prozeß im E/A-Prozessor, möchte Daten zum Serverprozeß in einer physischen Einheit senden. Der Anfordererprozeß erzeugt ein IPCI ANF SENDEN bei der IPCI. Der IPCF-Busverwalter adressiert Inf6rmationen von den Listen des Prozesses in einen RRCB.
3. Die Bustransporteinrichtung im E/A-Prozessor leitet den Vorgang auf dem Bus als ein Ergebnis des vom Anforderer ausgegebenen ANF SENDEN ein. Der Busverwalter des E/A-Prozessors sendet eine Buseinheitennachricht "Verarbstart" zum Host.
4. Der Busverwalter im Host sendet eine Buseinheitennachricht DMA-ANF, die anfordert, daß der Busverwalter im E/A-Prozessor einen DMA auf eine durch die Buseinheitennachricht angegebene Position durchführt.
5. Der Busverwalter des E/A-Prozessors führt den angeforderten Vorgang aus, wobei der RRCB vom Speicher des E/A-Prozessors zum Hostspeicher übertragen wird.
6. Der Busverwalter im E/A-Prozessor sendet eine Buseinheitennachricht "DMA beendet" zum Host, die anzeigt, daß der angeforderte DMA- Vorgang beendet worden ist.
7. Der Busverwalter im Host sendet eine Buseinheitennachricht DMA-ANF, die anfordert, daß der Busverwalter im E/A-Prozessor einen DMA- Vorgang ausführt, der an der durch die Buseinheitennachricht angegebenen Position beginnt. Diese befindet sich im Speicher des Hostbusverwalters.
8. Der Busverwalter des E/A-Prozessors führt den angeforderten DMA-Vorgang aus, wobei die Anforderung vom Speicher des E/A-Prozessors zum Hostspeicher übertragen wird.
9. Der Busverwalter im E/A-Prozessor sendet eine Buseinheitennachricht DMA BEENDET, die meldet, daß der angeforderte DMA-Vorgang beendet worden ist. Die obigen 3 Schritte können nicht erforderlich sein, falls die Anforderung weniger als 4 Bytes beträgt, die Direktdaten in einem RRCB sein können.
10. Eine MELDUNG wird über die IPCF zu dem geeigneten Serverprozeß gesendet. Dies erfüllt das ausstehende W EMPF.
11. Der Serverprozeß muß nun ein IPCI DATEN EMPF ausgeben, das angibt, wohin die Daten im Hostspeicher gebracht werden müssen.
12. Der Busverwalter im Host sendet eine Buseinheitennachricht DMA-ANF, die anfordert, daß der Busverwalter im E/A-Prozessor einen DMA- Vorgang an der durch die Buseinheitennachricht angegebenen Position ausführt. Diese Adresse wird durch das bei IPCI ausgegebene DATEN EMPF angegeben.
13. Der Busverwalter im E/A-Prozessor führt den angeforderten DMA-Vorgang aus, wobei die Benutzerdaten vom Speicher des E/A-Prozessors zum Hostspeicher übertragen werden.
14. Der Busverwalter im E/A-Prozessor sendet eine Buseinheitennachricht "DMA beendet", die anzeigt, daß der angeforderte DMA-Vorgang beendet worden ist.
15. Das DATEN EMPF des Servers ist mit den obigen Vorgängen erfüllt.
Die Schritte 12 bis 15 werden so oft wie nötig wiederholt, um alle benötigten Daten zu übertragen.
16. Der Anfordererprozeß, in diesem Fall ein Prozeß im E/A-Prozessor, erreicht eine Stelle in seiner Verarbeitung, wo er warten möchte. Er gibt ein W EMPF aus. Da keine Anforderungen in seiner Eingangswarteschlange vorhanden sind, tritt der Anfordererprozeß in den Wartezustand ein.
17. Der Serverprozeß muß nun ein ANTW SENDEN (ANTWORT SENDEN) mit den Statusinformationen ausgeben.
18. Der Busverwalter im Host sendet eine Buseinheitennachricht VERARBENDE, die anzeigt, daß der angeforderte Vorgang beendet worden ist.
19. Eine MELDUNG wird zur Warteschlange des Anforderers gesendet. Dies erfüllt das W EMPF des Anforderers.
Durch die Verwendung der Verfahren des entgegengesetzten Flusses ist das Ziel, die Übertragungen zwischen Prozessen unabhängig von den Prozessen und transparent für die Prozesse zu halten, erreicht worden. Eigentlich werden die Busverwalter auch verwendet, um die IPCF-Ebenen von Einzelheiten der Übertragung zu isolieren. Die Verwendung von Verbindungsgruppen hat einen verbesserten Grad an Flußsteuerung ermöglicht, um zu garantieren, daß Ressourcen Prozessen zugeordnet werden, um einen garantierten Mindestdienstgrad bereitzustellen.

Claims

1. Eine erste Buseinheit (52) mit Haupt-DMA (direkter Speicherzugriff), verbunden mit einem Bus (54), der Serverbuseinheiten verbindet, die Prozessoren (56) und Speicher (58) aufweisen, von denen mindestens einer Neben-DMA besitzt, wobei die erste Buseinheit (52) folgendes aufweist:

mindestens einen Prozessor (66), der eine Mehrzahl von Prozessen ausführt, wobei die Prozesse Verarbeitungsvorgänge von anderen Prozessen auf anderen Buseinheiten anfordern und Verarbeitungsanforderungen von anderen Prozessen auf anderen Buseinheiten bearbeiten, wobei die Verarbeitungsvorgänge ausführenden Prozesse den mit den ausgeführten Verarbeitungsvorgängen verbundenen Fluß von Datenübertragungen steuern;

einen Busverwalter (88) zum Verbinden der Prozesse mit dem Bus und zum Isolieren der Prozesse von der Kommunikationsverwaltung, wobei der Busverwalter folgendes aufweist:

Mittel zum Empfangen einer ursprünglichen Verarbeitungsanforderung von einem Prozeß auf seiner zugewiesenen Buseinheit, wobei die Verarbeitungsanforderung die mit ihr verbundenen Daten kennzeichnet und eine Serverbuseinheit mit Neben-DMA kennzeichnet, welche die Verarbeitungsanforderung bearbeiten muß;

Mittel zum Erzeugen einer Signalbuseinheit-Nachricht, die repräsentativ für die ursprüngliche Verarbeitungsanforderung ist, wobei die Signalbuseinheit-Nachricht den Prozeß in der ersten Buseinheit, den sie unterbrechen soll, kennzeichnet und außerdem eine Meldung über die Maßnahme, die der unterbrochene Prozeß durchführen muß, bereitstellt;

Mittel zum Senden der Signalbuseinheit-Nachricht zu der in der ursprünglichen Verarbeitungsanforderung gekennzeichneten Buseinheit;

Mittel zum Empfangen einer zweiten Verarbeitungsanforderung von der Serverbuseinheit als Antwort auf die Nachricht, wobei die zweite Verarbeitungsanforderung die gewünschten Hauptspeicherstellen in der Serverbuseinheit anzeigt; und

Mittel zum Senden von Daten zum Hauptspeicher der Serverbuseinheit, die mit der ursprünglichen Verarbeitungsanforderung zu den Hauptspeicherstellen verbunden ist, die in der zweiten, von der Serverbuseinheit unter Verwendung des Haupt-DMAs der ersten Buseinheit empfangenen Verarbeitungsanforderung gekennzeichnet werden.

2. Buseinheit nach Anspruch 1, wobei die Mittel zum Erzeugen der Signalbuseinheit-Nachricht außerdem Mittel zum Einfügen eines Längenwertes in die Nachricht aufweisen, der die Länge der mit der ursprünglichen Verarbeitungsanforderung verbundenen Daten anzeigt.

3. Buseinheit nach Anspruch 1, wobei die Mittel zum Erzeugen einer Signalbuseinheit-Nachricht außerdem folgendes aufweisen:

Mittel zum Erzeugen eines codierten Wertes, der eindeutig repräsentativ für die ursprüngliche Verarbeitungsanforderung ist; und

Mittel zum Aufzeichnen jeder gesendeten Nachricht, so daß die Mittel zum Senden der Nachricht das Signal zurücksenden, falls eine zweite Verarbeitungsanforderung, die den codierten Wert enthält, nicht empfangen wird.

4. Buseinheit nach Anspruch 3, wobei die Mittel zum Senden der Signalbuseinheit-Nachricht die Nachricht zurücksenden, falls eine zweite Verarbeitungsanforderung, die einen unerwarteten codierten Wert enthält, empfangen wird.

5. Buseinheit nach Anspruch 1, die außerdem Mittel aufweisen, um dem Prozeß, der die ursprüngliche Verarbeitungsanforderung aus gibt, anzuzeigen, daß die Anforderung beendet wurde, wenn die Mittel zum Senden von Daten zum Hauptspeicher der Serverbuseinheit alle mit der ursprünglichen Verarbeitungsanforderung verbundenen Daten gesendet haben, wie von der zweiten Verarbeitungsanforderung angefordert wurde.

6. Buseinheit nach Anspruch 5, wobei die Mittel zum Anzeigen dem Prozeß anzeigen, der die ursprüngliche Verarbeitungsanforderung aus gibt, in mit der auf eine normale, beendete Verarbeitungsanforderung erwarteten Antwort übereinstimmenden Weise.

7. Verfahren zum Umkehren der Steuerung der Übertragung von Verarbeitungsanforderungen und damit verbundenen Daten in einem servergesteuerten Datenverarbeitungssystem mit Prozeß-zu-Prozeß-Kommunikation, wobei eine erste Buseinheit (52) Haupt-DMA (direkter Speicherzugriff) aufweist und mit einem Bus (52) verbunden ist, der Serverbuseinheiten verbindet, die Prozessoren (56) und Speicher (58) aufweisen, von denen mindestens einer Neben-DMA besitzt, wobei die erste Buseinheit folgendes aufweist:

einen Busverwalter (88) zum Verbinden der Prozesse mit dem Bus und zum Isolieren der Prozesse von der Kommunikationsverwaltung; wobei das Verfahren die folgenden Schritte umfaßt

a Erzeugen einer ursprünglichen Verarbeitungsanforderung in einem Prozeß, der auf der ersten Buseinheit aktiv ist, wobei die Verarbeitungsanforderung die damit verbundenen Daten kennzeichnet und außerdem eine Serverbuseinheit, welche die Verarbeitungsanforderung bearbeiten muß, kennzeichnet;

b Erzeugen einer Signalbuseinheit-Nachricht, die repräsentativ für die ursprüngliche Verarbeitungsanforderung ist, wobei die Signalbuseinheit-Nachricht den Prozeß in der ersten Buseinheit, den sie unterbrechen soll, kennzeichnet und außerdem eine Meldung der von dem unterbrochenen Prozeß auszuführenden Maßnahme bereitstellt;

c Senden der Buseinheit-Nachricht zu der in der ursprüngl ichen Verarbeitungsanforderung gekennzeichneten Serverbuseinheit;

d Erzeugen einer zweiten Anforderung in Server in Abhängigkeit von der Signalbuseinheit-Nachricht, die von der ersten Buseinheit empfangen wurde, wobei die zweite Anforderung die gewünschten Hauptspeicherstellen im Server anzeigt;

e Senden der zweiten Anforderung zu der ersten Buseinheit; und

f Übertragen der mit der ursprünglichen Verarbeitungsanforderung verbundenen Daten zu den in der zweiten Anforderung gekennzeichneten Hauptspeicherstellen des Servers unter Verwendung des Haupt-DMA der ersten Buseinheit.

8. Verfahren nach Anspruch 7, das außerdem den folgenden Schritt umfaßt:

h Benachrichtigen des Servers, wenn die zugewiesenen Daten in den Hauptspeicher des Servers übertragen wurden.

9. Verfahren nach Anspruch 8, das außerdem den folgenden Schritt umfaßt:

i Benachrichtigen des Prozesses, der die ursprüngliche Verarbeitungsanforderung aus gab, wenn die damit verbundenen Daten in den Hauptspeicher des Servers übertragen wurden.