Diese Erfindung betrifft im Allgemeinen Kanal-Subsysteme und insbesondere die Integration der Kanal-zu-Kanal-Funktion in einen oder mehrere Kommunikationskanäle einer Rechnerumgebung.

Kanal-zu-Kanal-Adapter wurden lange Zeit als Vorrichtung für die allgemeine Kommunikation zwischen Computersystemen eingesetzt. So waren Kanal-zu-Kanal-Adapter beispielsweise der Hauptmechanismus für den Anschluss eines S/390-Systems (angeboten von International Business Machines Corporation) an andere heterogene Umgebungen wie die IBM Systeme RS/6000 und/oder AS/400. Der Kanal-zu-Kanal-Adapter ist protokollunabhängig und findet vielfältige Anwendung in Bereichen wie beispielsweise der Kopplung von Multiprozessorsystemen und in traditionellen Protokoll-Stacks (z. B. TCP/IP, SNA). Im Allgemeinen wird die Kanal-zu-Kanal-Funktion (Channel-To-Channel, CTC) auf einem eigenständigen Hardwareteil implementiert.

Bei parallelen Kanalschnittstellen wird die CTC-Funktion in einem separaten Gehäuse außerhalb beispielsweise eines CEC (Central Electronic Complex) (angeboten von International Business Machines Corporation) implementiert. In der ESCON-Architektur (Enterprise System Connection) von IBM wurde die CTC-Funktion dahingehend verbessert, dass ein beliebiger ESCON-Kanal als dedizierter Kanal oder als dedizierte CTC-Verbindung für unterschiedliche Mikrocode-Lasten konfiguriert werden kann. Informationen hierzu enthält beispielsweise die IBM Publikation „Enterprise Systems Architecture/390 ESCON Channel-To-Channel Adapter" mit der Publikationsnummer SA22-7203-00 (1996). In allen Fällen ist die „Entität", die die CTC-Funktion bereitstellt, ausschließlich für diesen Zweck vorgesehen. Leider ist die CTC-Konfiguration mit Hilfe eines solchen dedizierten CTC-Kanals für den Kunden mit einem hohen Aufwand an Arbeit und Kosten verbunden. Des Weiteren werden mindestens zwei Kanalpfad-IDs (Channel Path ID, CHPID) benötigt, wenn ein Kunde eine CTC-Kommunikation zwischen zwei logischen Partitionen (Logical Partition, LPAR) wünscht.

Das U.S. Patent 5,652,914 enthält eine Beschreibung, wie zwei logische Partitionen innerhalb eines Computers ohne Rückgriff auf CTC-Hardware miteinander kommunizieren können. Auch diese Lösung benötigt jedoch mindestens zwei Kanalpfad-IDs.

Angesichts des oben Genannten ist für die Bereitstellung der CTC-Funktionalität in einer Rechnerumgebung immer noch ein erweiterter Ansatz erforderlich, um die Kommunikation zwischen Computersystemen zu vereinfachen.

Aufgabe der Erfindung ist es daher, ein verbessertes Verfahren zum Erzeugen einer Kommunikation zwischen Partitionen in einer Rechnerumgebung anzugeben. Diese Aufgabe wird durch die Merkmale des Patentanspruchs 1 und der nebengeordneten Patentansprüche gelöst.

Gemäß dem Patentanspruch 1 wird ein Verfahren zum Erzeugen einer Kommunikation zwischen mindestens einer ersten und einer zweiten logischen Partition, die in einem oder verschiedenen über ein Netzwerk verbundener Computer enthalten sind und die Computer jeweils über mindestens einen Kanal mit einer CTC-Funktion mit dem Computer verbunden sind, angegeben. Das Verfahren umfasst die Schritte: Erzeugen eines internen logischen Pfads zwischen der ersten logischen Partition und einer CTC-Funktion in dem Computer, der die erste Partition enthält, und Erzeugen eines logischen Pfads im Netzwerk, der den internen logischen Pfad mit Hilfe der CTC-Funktion und jeweils einem einzigen Kanal des die zweite logische Partition enthaltenden Computers mit der zweiten logischen Partition verbindet.

Die für die Anwendung des oben beschriebenen Verfahrens geeigneten Systeme und Computerprogrammprodukte werden in der vorliegenden Patentanmeldung ebenfalls beschrieben und in Form von Ansprüchen dargelegt.

Wie bereits erwähnt, wird in dieser Patentanmeldung eine Technik für die Implementierung von CTC-Kommunikationsverbindungen in einer Rechnerumgebung vorgestellt, die die Konnektivitätsoptionen eines Kunden erheblich erweitert. Dies wird durch die Integration einer CTC-Funktion in einen oder mehrere Kanäle einer Rechnerumgebung erreicht, wobei jeder Kanal zudem eine Kanalfunktion umfasst. In der Praxis wird eine Arbeitseinheit an die CTC- oder die Kanalfunktion übertragen. Dies ist abhängig vom Typ der Arbeitseinheit, d. h. davon, ob die Arbeitseinheit selbst von einer Kanalfunktion oder einer Steuerungseinheit stammt. Mit Hilfe der in der vorliegenden Erfindung beschriebenen Technik können zwischen zwei beliebigen Systemen, die über mindestens einen Kanal mit dem Netz verbundenen sind, CTC-Verbindungen ohne zusätzliche Kosten installiert werden. Vielen der größten Computeranwender gehen buchstäblich die verfügbaren Kanalpfade aus, sodass die Bereitstellung einer dedizierten CTC-Funktion üblicherweise kostspielig ist, da dies zum einen mit dem Verbrauch der sehr begrenzt vorhandenen Kanalpfad-IDs und zum anderen mit hohen Hardwarekosten verbunden ist. Hinzu kommt außerdem, dass ein Kunde normalerweise ein Paar redundante CTC-Verbindungen benötigt. Dank der vorliegenden Erfindung ist es jedoch nicht mehr erforderlich, dass der Kunde der CTC-Funktion Kanalpfadressourcen (CHPIDs) zuweist.

Des Weiteren erleichtert das in der vorliegenden Patentanmeldung beschriebene Merkmal der Autokonfiguration die anwenderdefinierte Konfiguration der CTC-Verbindung erheblich. Der Kunde gibt lediglich eine CTC-Steuerungseinheit an mindestens einem Ende der Verbindung an, und die Autokonfiguration führt automatisch „insgeheim" einen Lastausgleich durch. Zusätzlich wird zur Konfiguration der Kommunikation zwischen logischen Partitionen (LPAR) durch eine einzige CHPID eine Funktion bereitgestellt, die die Konnektivitätsoptionen vor allem bei Systemen der unteren Preisklasse verbessert, die möglicherweise eine geringere Anzahl verfügbarer Kanäle besitzen. Obwohl die in dieser Patentanmeldung dargestellten Kozepte nur auf Glasfaserverbindungen der FICON-Verbindungstechnik (Fibre Connection, FICON) Bezug nehmen (FICON-Kanäle werden von International Business Machines Corporation angeboten), können sie genauso auf andere Typen von Systemkommunikationskanälen angewandt werden.

Zusätzliche Leistungsmerkmale und Vorteile werden mit Hilfe der Techniken der vorliegenden Erfindung realisiert. Weitere Ausführungsarten und vorteilhafte Ausgestaltungen der Erfindung werden in dieser Patentanmeldung detailliert beschrieben und als Gegenstand der Patentansprüche angesehen.

Die oben beschriebenen Ziele, Vorteile und Leistungsmerkmale der vorliegenden Erfindung sowie weitere vorteilhafte Ausgestaltungen lassen sich anhand der nachfolgenden detaillierten Beschreibung bestimmter bevorzugter Ausführungen der Erfindung und unter Bezugnahme auf die im Anhang befindlichen Zeichnungen besser verstehen.

1 stellt eine Ausführungsart eines Kanals dar, der gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung über eine Kanalfunktion und eine integrierte CTC-Funktion verfügt;

2 ist eine detailliertere Zeichnung des Kanals aus 1, in der eine Logik dargestellt ist, die gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung festlegt, ob eine Arbeitseinheit (je nach Typ der Arbeitseinheit) an die Kanalfunktion oder die CTC-Funktion im Kanal weitergeleitet wird;

3 ist ein Blockdiagramm für eine Ausführungsart einer Rechnerumgebung, worin gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung jeweils zwei Kanäle (z. B. von verschiedenen Computersystemen) über eine integrierte CTC-Funktion verfügen;

4 ist ein Blockdiagramm für eine Ausführungsart einer Kommunikation zwischen zwei Partitionen, bei der gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung eine integrierte CTC-Funktion zum Einsatz kommt;

5 ist ein Ablaufdiagramm für eine Ausführungsart zur automatischen Konfigurierung einer CTC-Verbindung gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung;

6 ist ein Beispiel für eine gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung stattfindende Kommunikation auf Geräteebene zwischen einem Kanal A auf einem ersten System und einem Kanal B auf einem zweiten System mit Hilfe der CTC-Funktion von Kanal A.

Diese Erfindung betrifft im Allgemeinen das Implementieren von CTC-Verbindungen innerhalb einer Rechnerumgebung, um dadurch die Konnektivitätsoptionen eines Kunden erheblich zu verbessern. Die Rechnerumgebung kann beispielsweise auf einer oder mehreren ES/390-Architekturen (Enterprise Systems Architecture, ESA) von International Business Machines Corporation, Armonk, New York basieren. Die ES/390-Architektur wird in der IBM Publikation „Enterprise Systems Architecture/390 Principles of Operation" mit der Publikationsnummer SA22-7201-06 (Juli 1999) beschrieben, die durch Bezugnahme in ihrer Gesamtheit Bestandteil der vorliegenden Patentanmeldung ist. Ein Beispiel für eine auf der ES/390-Architektur basierende Rechnerumgebung ist der 9672 Parallel Enterprise Server von International Business Machines Corporation. Des Weiteren kann die Rechnerumgebung beispielsweise mindestens einen CEC (Central Electronic Complex) mit einer oder mehreren logischen Partitionen (LPAR) sowie mit einem odere mehreren Kanälen umfassen.

1 stellt eine Ausführungsart eines Kanals 100 dar, der gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung über eine CTC-Funktion verfügt. Ein Beispiel für eine herkömmliche CTC-Funktion ist in der oben genannten IBM Publikation „Enterprise Systems Architecture/390 ESCON Channel-to-Channel Adapter" mit der Publikationsnummer SA22-7203-00 (1996) beschrieben, die durch Bezugnahme in ihrer Gesamtheit Bestandteil dieser Patentanmeldung ist. Ein Beispiel für einen Kanal ist ein FICON-Kanal von International Business Machines Corporation. Ein Beispiel für einen FICON-Kanal ist im Handbuch „IBM S/390 FICON Implementation Guide" mit der IBM Publikationsnummer SG24-5169-00 (November 1999) beschrieben, das durch Bezugnahme in seiner Gesamtheit Bestandteil dieser Patentanmeldung ist.

Kanal 100, der im vorliegenden Dokument auch als Kanalpfad-ID (Channel Path Identifier, CHPID) bezeichnet wird, umfasst eine herkömmliche Kanalfunktion 110, die sowohl mit Systemschnittstellen als auch mit einem Gerätetreiber 130 verbunden ist, der wiederum an eine Glasfaserverbindung (nicht dargestellt) angeschlossen ist. Die Architektur einer herkömmlichen Kanalfunktion ist in der oben genannten IBM Publikation „Enterprise Systems Architecture/390 Principles of Operation" mit der IBM Publikationsnummer SA22-7201-06 (Juli 1999) beschrieben. Parallele Kanäle sowie ESCON- und FICON-Kanäle von IBM entsprechen alle der in der genannten Publikation beschriebenen grundlegenden Kanalstruktur. Gemäß der vorliegenden Erfindung umfasst der Kanal 100 zudem eine integrierte CTC-Funktion 140, die über entsprechende Verbindungen mit der Kanalfunktion 110 und dem Gerätetreiber 130 kommuniziert. Die CTC-Funktion 140 fungiert als duale Steuerungseinheit, die sowohl für den lokalen („inneren") als auch für einen externen („äußeren") Kanal auf der anderen Seite des Glasfasernetzes eine Steuerungseinheitsfunktion bereitstellt. Es ist zu beachten, dass in dieser Ausführungsart die CTC-Funktion weder auf Speicher- noch auf Systemvorrichtungen zugreift.

Der Kanal sendet und empfängt Informationseinheiten (Information Units, IUs) (in diesem Dokument auch als Arbeitseinheiten bezeichnet) über eine Kanalschnittstelle, indem Übertragungssteuerungsblöcke (Transmit Control Blocks, TCBs) und Empfangssteuerungsblöcke (Receive Control Blocks, RCBs) an den Gerätetreiber gesendet und von diesem zurückgesendet werden. Für ausgehende Informationseinheiten, die für den lokalen CTC-Kanal vorgesehen sind, erstellt die gesamte Hauptleitungsfunktion des Kanals nach wie vor TCBs und nimmt die Unterschiede zwischen CTC-Datenverkehr und Verkehr ohne CTC-Funktion nicht wahr. Mit Hilfe einer Routing-Funktion an der Treiberschnittstelle werden die ausgehenden Informationseinheiten entweder zum Aufbau eines Nicht-CTC-Datenverkehrs an den Treiber gesendet, oder die Informationseinheiten werden je nach Konfiguration des logischen Pfads an die CTC-Funktion gesendet (siehe 3). Für den größten Teil des CTC-Datenverkehrs muss die CTC-Funktion lediglich den Dateikopf der Fibre Channel-Schicht 4 (FC-4) neu erstellen, um durch das Vornehmen der notwendigen Änderungen dem fernen Kanal den Anschein zu geben, dass die Informationseinheit aus den Nutzinformationen einer Steuerungseinheit der Informationseinheit hervorging. Wenn die CTC-Funktion bereit ist, die Informationseinheit an den externen Kanal zu senden, kann die CTC-Funktion einfach denselben von dem Kanal empfangenen TCB an den Treiber weiterleiten.

Alle von einem FICON-Kanal gesendeten Informationseinheiten weisen im Dateikopf der Fibre Channel-Schicht 2 (FC-2) einen Code TYPE auf, der auf den Wert 0x1B gesetzt ist, während alle von einer FICON-Steuerungseinheit gesendeten Informationseinheiten einen Code TYPE mit dem Wert 0x1C aufweisen. Dadurch kann der Treiber ankommende Informationseinheiten problemlos entweder zur Kanalfunktion oder zur CTC-Funktion transportieren. Viele Fibre Channel PCI-Adapterkarten bieten Hardware-Assistenten, mit deren Hilfe sich der Datentransport anhand des Typencodes schnell und effizient durchführen lässt. Hinsichtlich der ausgehenden Informationseinheiten muss die CTC-Funktion den FC-4-Dateikopf lediglich neu erstellen und anschließend die Informationseinheiten mit Hilfe desselben RCBs an die Kanalfunktion weiterleiten, der vom Treiber empfangen wurde. Wiederum erkennt der Kanal nicht, dass es sich bei der Quelle des Datenverkehrs um die Schnittstelle der lokalen CTC-Verbindung und nicht um die FICON-Schnittstelle handelt.

2 stellt eine Ausführungsart des Arbeitseinheitsflusses innerhalb eines FICON-Kanals dar, in den gemäß den Prinzipien der vorliegenden Erfindung eine CTC-Funktion integriert ist. Ein TCB aus der Kanalfunktion 110 wird von einer Schnittstellenlogik 210 dahingehend überprüft, ob eine Zielrichtung des TCBs als Verbindung zur CTC-Funktion konfiguriert ist. Ist dies nicht der Fall, wird der TCB einfach an den Gerätetreiber 130 weitergeleitet, wo die Daten an eine Fibre Channel-Verbindung 200 ausgegeben werden. Ist die CTC-Verbindung als Zielrichtung definiert, wird der TCB an die CTC-Funktion 140 weitergeleitet. Die CTC-Funktion 140 kann hierauf durch die Ausgabe desselben TCBs an den Gerätetreiber 130, durch die Ausgabe eines anderen oder eines geänderten TCBs an den Gerätetreiber 130 oder durch die Ausgabe eines Antwort-RCBs an die Kanalfunktion 110 reagieren.

Wie bereits erwähnt, verfügt die CTC-Funktion 140 über eine duale Kommunikationssteuerungseinheit. Über den Gerätetreiber 130 werden als RCB empfangene Arbeitseinheiten je nach Typ der Arbeitseinheit umgeleitet 220. Die Arbeitseinheit wird an die CTC-Funktion weitergeleitet, wenn es sich um den Typ „1B" handelt, da, wie bereits erwähnt, der Typ 1B signalisiert, dass die Einheit aus einem Kanal stammt und deshalb zur CTC-Funktion 140 geleitet wird. Handelt es sich stattdessen um eine Einheit des Typs „1C", stammt der empfangene Steuerungsblock aus einer Steuerungseinheit, die für die Kanalfunktion 110 bestimmt sein muss. Die CTC-Funktion 140 kann auf den empfangenen RCB durch Weiterleiten desselben RCBs an die Kanalfunktion 110, durch Weiterleiten eines anderen oder eines geänderten RCBs an die Kanalfunktion 110 oder durch Rücksenden eines TCBs an den Gerätetreiber 130 reagieren.

3 stellt eine Ausführungsart einer Rechnerumgebung mit der allgemeinen Bezeichnung 300 dar, worin ein erstes Computersystem mit einer ersten Kanalpfad-ID 310 und ein zweites Computersystem mit einer zweiten Kanalpfad-ID 320 über ein Vermittlungsnetz (Switching Network, SW) 330 miteinander verbunden sein sollen. Jeder Kanal bzw. jede Kanalpfad-ID (CHPID) enthält, wie oben beschrieben, neben einer integrierten CTC-Funktion 350 bzw. 370 eine herkömmliche Kanalfunktion 340 bzw. 360. Die CTC-Funktion 350 bzw. 370 umfasst wiederum eine Steuerungseinheit, die der Koordinierung der Kommunikation zwischen den Kanalfunktionen innerhalb der verschiedenen Kanäle dient.

In einer FICON-Architektur erfordert die auf Geräteebene stattfindende Kommunikation zwischen einem Kanal und einer Steuerungseinheit, dass zwischen diesen ein „logischer Pfad" erzeugt wird. Im Fall einer CTC-Kommunikation kommunizieren jeweils zwei Kanäle mit der dualen CTC-Steuerungseinheit, sodass zwei logische Pfade für den Aufbau einer vollständigen CTC-Verbindung benötigt werden. Ein lokaler logischer Pfad wird über eine interne Verbindung zwischen der Kanalfunktion und der CTC-Funktion derselben CHPID erzeugt. Dieser Pfad 345 wird in 3 als Teil der CHPID A dargestellt. Der ferne logische Pfad wird über eine Fibre Channel-Verbindung erzeugt. Wie aus 3 ersichtlich ist, verbindet dieser Pfad 355 die beiden CHPIDs durch das Vermittlungsnetz hindurch.

Für die gegebene Struktur und Funktion der vorliegenden Erfindung sind Mittel zur automatischen Festlegung des lokalen logischen Pfads und des fernen logischen Pfads in einer beliebigen gegebenen CTC-Verbindung wünschenswert. Andernfalls muss der Kunde die Konfiguration des logischen Pfads durchführen. Da die CTC-Funktion eine Rechenlast für den Mikroprozessor auf der Kanalkarte darstellt, sind weiterhin Mittel wünschenswert, die einen Lastausgleich bewirken, sodass die CTC-Last beispielsweise gleichmäßig auf alle Kanalpfade innerhalb des Komplexes verteilt wird. Das CTC-Verbindungsverfahren sollte es darüber hinaus ermöglichen, dass sich ein CTC-fähiger Kanalpfad korrekt selbst konfiguriert, wenn er als nicht CTC-fähiger Kanal definiert wird. Alle der oben genannten Anforderungen werden durch eine automatisierte Technik zur Konfigurierung der logischen Pfade gemäß der vorliegenden Erfindung erfüllt, die nachfolgend in Zusammenhang mit 5 beschrieben wird.

Zunächst wird jedoch auf 4 Bezug genommen, die ein Paar logischer Pfade für eine Kommunikation zwischen Partitionen gemäß einer vorteilhaften Ausgestaltung der vorliegenden Erfindung darstellt. Diese Rechnerumgebung 400 umfasst einen Host-Kanal 410 und ein Vermittlungsnetz (Switching Network, SW) 420. Der Host-Kanal 410 umfasst wiederum eine integrierte CTC-Funktion 430 und eine Kanalfunktion, deren verschiedene Images als LPAR 1 440 und LPAR 2 450 gekennzeichnet sind. Ziel dieses Aspekts der vorliegenden Erfindung ist es, eine LPAR-zu-LPAR-Kommunikation mit Hilfe von CTC-Protokollen und eines einzigen physischen Kanalpfads herzustellen.

Die in der vorliegenden Patentanmeldung genannten Regeln zur Erzeugung logischer Pfade lassen sich auch auf die Kommunikation zwischen Partitionen (LPAR-zu-LPAR) anwenden, bei der nur eine einzige CHPID genutzt wird. Wie nachfolgend im Zusammenhang mit 5 beschrieben wird, kann die in 4 dargestellte Beispielkonfiguration wie folgt erzeugt werden: LPAR 2 gibt eine Anweisung zur Erzeugung eines logischen Pfads (Establish Logical Path, ELP) aus, die über das FICON-Netz gesendet wird, und da die ID des Ziel-N_Ports mit der ID des Quell-N_Ports identisch ist, wird die Meldung an den sendenden N_Port „zurückgeschickt" und an LPAR 1 weitergeleitet. (N_Port ist ein Begriff des Fibre Channel Standards, der im Grunde einen Port innerhalb eines Knotens einer Kanalverbindung bezeichnet. Jeder Port verfügt über einen Empfänger und einen Sender. Knoten, N_Ports und N_Port-ID sind Begriffe, die in dem Dokument „Fibre Channel-Physical and Signaling Interface (FC-PH)" des amerikanischen Normungsgremiums ANSI (American National Standards Institute) definiert werden.

Die in der ELP-Anweisung angegebene Anzahl lokaler logischer Pfade soll der Anzahl der über die CHPID erzeugten Pfade entsprechen. Ebenso sollen die IDs des Quell- und des Ziel-N_Ports identisch sein, sodass die LPAR-IDs verglichen werden. Da die Partition LPAR 1 die niedrigere ID aufweist, sendet sie die Aufforderung, die Verbindung nicht zu erzeugen (Link Reject), woraufhin eine Protokollfehlermeldung zurückgesendet wird. Die Aufforderung wird wiederum an denselben N_Port „zurückgeschickt" und von LPAR 2 empfangen. Nach dem Empfang der Link Reject erzeugt LPAR 2 den logischen Pfad 455. Wenn LPAR 1 seine ELP-Anweisung ausgibt, wird diese über das Netz an LPAR 2 weitergeleitet. LPAR 2 erkennt, dass der lokale Pfad bereits mit LPAR 1 erzeugt wurde, sodass LPAR 2 eine entsprechende Meldung (Logical Path Established, LPE) an LPAR 1 zurücksendet und dadurch den fernen logischen Pfad 445 erzeugt.

Es gilt zu beachten, dass laut Definition für eine Kommunikation zwischen Partitionen die lokale CTC-Funktion immer verwendet wird, sodass ein Lastausgleich nicht erforderlich ist. Hätten für das oben genannte Beispiel andere Bedingungen gegolten, sodass nach der Verarbeitung der ELP-Anweisung durch LPAR 1 weniger lokale logische Pfade erzeugt worden wären als nach dem Senden der ELP-Anweisung durch LPAR 2 vorhanden waren, hätte LPAR 1 eine LPE-Meldung an LPAR2 gesendet und dadurch den fernen logischen Pfad erzeugt. Wenn anschließend LPAR 1 eine ELP-Anweisung ausgegeben hätte, wäre dadurch der lokale logische Pfad erzeugt worden. Entscheidend ist, dass die Regeln unabhängig von den bei der Ausgabe der ELP-Anweisungen herrschenden Bedingungen sicherstellen, dass die beiden benötigten Pfade erzeugt werden.

Die logischen Pfade legen den Transport von Informationseinheiten der Geräteebene fest. Die gesamte auf Geräteebene anfallende Datenmenge für den lokalen logischen Pfad wird über die interne Verbindung transportiert, und die gesamte Datenmenge wird auf dem fernen logischen Pfad zum FICON-Gerätetreiber weitergeleitet, um von dort über das Fibre Channel-Netz übertragen zu werden. Ein Beispiel für verschiedene Datentransfers auf Geräteebene enthält 6.

Wie aus der nachfolgend beschriebenen 5 ersichtlich ist, werden während der Initialisierung keine Angaben darüber gemacht, welcher von zwei Kanälen in zwei verschiedenen Systemen die CTC-Funktion für die CTC-Verbindung bereitstellen wird. Ein Kanal sendet ELP-Informationseinheiten an alle in seiner Konfiguration definierten logischen Steuerungseinheiten. Dabei spielt es keine Rolle, ob es sich um CTC-Steuerungseinheiten oder um andere Typen handelt 500. Bei Steuerungseinheiten, die in der Konfiguration als CTC-Steuerungseinheiten definiert sind, enthält die ELP-Informationseinheit (in einer Ausführungsart) jedoch ein Bit, das den Sender als CTC-fähig kennzeichnet, sowie ein Zählerfeld, das die Gesamtzahl der lokalen logischen CTC-Pfade angibt, die aktuell auf dem Kanalpfad erzeugt werden. Im Fall von CTC-Verbindungen werden diese ELP-Informationseinheiten von den Zielkanalpfaden empfangen. An dem empfangenden Kanal wird geprüft, ob der empfangende Kanal CTC-fähig ist 510.

Ist der Kanal, der eine ELP-Anweisung empfängt, nicht in der Lage, eine CTC-Funktion bereitzustellen, gibt er eine Link-Reject-Meldung aus, wobei auf jede ELP-Anweisung mit einer Protokollfehlermeldung reagiert wird 520. Wenn der CTC-fähige Kanal, der die ELP-Anweisung gesendet hat, die Link-Reject-Meldung empfängt, erkennt er, dass er die CTC-Funktion bereitstellen muss. Der Kanal erzeugt daher den lokalen logischen Pfad und wartet so lange, bis der nicht CTC-fähige Kanal eine ELP-Anweisung sendet, um den fernen logischen Pfad zu erzeugen 530.

Als Alternative könnte der nicht CTC-fähige Kanal seine ELP-Anweisung als Erster senden. In diesem Fall prüft der empfangende Kanal das die CTC-Fähigkeit signalisierende Bit in der empfangenen ELP-Anweisung, erkennt, dass dieses deaktiviert ist, und sendet eine LPE-Meldung zur Erzeugung des fernen logischen Pfads. Wird die ELP-Anweisung vom lokalen System ausgegeben, wird erkannt, dass der ferne logische Pfad erzeugt werden soll. Deshalb wird das Senden der ELP-Anweisung an das ferne System unterdrückt, und der lokale logische Pfad wird intern erzeugt. Die Situation des „Kreuzverkehrs", in der beide Seiten ihre ELP-Anweisung gleichzeitig senden, lässt sich durch die Festlegung meistern, dass beide Seiten unabhängig von der jeweils anderen Seite die oben vorgeschriebenen Schritte durchlaufen.

Unter der Voraussetzung, dass der empfangende Kanal CTC-fähig ist, ermittelt der empfangende Kanal, ob für diese CTC-Verbindung noch eine Rückmeldung auf eine ELP-Anweisung aussteht, die aus dem empfangenden Kanal stammt 540. Ist dies der Fall, wird die in der ELP-Anweisung gesendete Anzahl als aktuelle Anzahl des empfangenden Kanals verwendet 550. Der empfangende Kanal setzt den selbstregulierenden Aspekt dieser Erfindung mit der Ermittlung fort, ob die Anzahl der am empfangenden Kanal erzeugten lokalen logischen Pfade geringer ist als die durch den sendenden Kanal angegebene Anzahl 560. Ist dies der Fall, stellt der empfangende Kanal die CTC-Funktion bereit 610. Der empfangende Kanal sendet eine LPE-Rückmeldung, um den fernen logischen Pfad zu erzeugen. Gibt das lokale System eine ELP-Anweisung aus, wird erkannt, dass der ferne logische Pfad erzeugt werden soll. Deshalb wird das Senden der ELP-Anweisung an das ferne System unterdrückt, und der lokale logische Pfad wird erzeugt.

Ist die Anzahl der logischen Pfade größer als die mit der ELP-Anweisung empfangene Anzahl, stellt der sendende Kanal die CTC-Funktion bereit, sodass eine Link-Reject-Rückmeldung erzeugt wird 520. Nach dem Empfang der Link-Reject-Rückmeldung wird der lokale logische Pfad am sendenden Kanal erzeugt und wartet auf eine ELP-Anweisung vom fernen Kanal. Wenn die ELP-Anweisung später vom fernen Kanal empfangen wird, ist der lokale logische Pfad bereits erzeugt. Deshalb ignoriert der erste Kanal das in der ELP-Anweisung enthaltene Zählerfeld für die Anzahl der logischen Pfade und sendet eine LPE-Meldung zurück, wodurch der ferne Pfad erzeugt wird.

Wird eine ELP-Anweisung empfangen und ist die mit der ELP-Anweisung empfangene Anzahl der lokalen logischen Pfade identisch mit der Anzahl der am Empfänger erzeugten lokalen logischen Pfade 570, wird die N_Port-ID des Systems, das die ELP-Anweisung gesendet hat, mit der N_Port-ID des lokalen Systems verglichen 580. Sind die IDs nicht identisch, stellt das System mit der numerisch größeren N_Port-ID die CTC-Funktion bereit. Es verhält sich folglich so, als ob es über weniger als die oben vorgeschriebene Anzahl logischer Pfade verfügte. Sind die N_Port-IDs der beiden Systeme jedoch identisch 590, wie dies bei einer Kommunikation zwischen Partitionen der Fall ist (oben. beschrieben), werden die Partitions-IDs verglichen 600, und die Partition mit der numerisch größeren ID stellt die CTC-Funktion bereit 520, 610.

Es besteht außerdem die Möglichkeit, dass zwei CTC-fähige Kanäle sich gleichzeitig ELP-Anweisungen senden. Als einzige zusätzliche Regel erfordert dieser Fall, dass jeder Kanal den Wert für die mit jeder ELP-Anweisung gesendeten Anzahl der erzeugten lokalen logischen Pfade beibehält bis er eine Rückmeldung auf die ELP-Anweisung empfängt. Empfängt ein CTC-fähiger Kanal in Erwartung der Rückmeldung auf eine ELP-Anweisung eine ELP-Anweisung von demselben N_Port und derselben Partitions-ID, an die er die ELP-Anweisung gesendet hat, führt der Kanal einen Vergleich der Anzahl logischer Pfade anhand des mit der ELP-Anweisung gesendeten Werts durch, nicht aber anhand der Anzahl der aktuell erzeugten Pfade im Kanal, die sich seit der Übertragung der ursprünglichen ELP-Anweisung geändert haben könnte.

6 zeigt den Sequenzfluss für ein CTC-Programm, das aus 3 Kanalbefehlswörtern (Channel Command Words, CCWs) besteht: eine Lesen-Schreiben-Lesen-Kette auf Kanal A (CH A) und eine entsprechende Schreiben-Lesen-Schreiben-Kette auf Kanal B (CH B). (Es ist zu beachten, dass diese Kette nur zur Veranschaulichung von Konzepten gewählt wurde.) In diesem Beispiel löst CH A die Operation aus und gibt die 4 Sequenzen aus, die für die Kette benötigt werden. Da es sich bei CH A um den lokalen logischen Pfad handelt, werden alle diese Sequenzen an das CTC-Element auf CH A gesendet und von diesem aufgereiht. Da der logische Pfad CH B verfügbar ist, wird an CH A ein entsprechender Befehl zurückgesendet, und durch CTC A wird ein Status „Achtung" (Attention) erzeugt, der über die FICON-Verbindung an CH B gesendet wird. CH B akzeptiert den Status, und CH A erkennt dies an. Der Status „Attention" bewirkt, dass das Programm hinter CH B das entsprechende Kanalprogramm erzeugt. CH B gibt die entsprechenden Sequenzen über die FICON-Verbindung an CH A aus. Da diese Sequenzen als Typ 1B (TYPE 1B) gesendet werden, transportiert die Hardware bzw. der Treiber die RCBs zur CTC-Funktion, die die RCBs an ihrer externen Seite aufreiht.

Beim Empfang der ersten Befehls-Informationseinheit verfügt CTC A auf beiden Seiten über Befehle, die sich entsprechen, sodass CTC A mit Hilfe des eigenen Steuerungseinheitstyps 1C (TYPE 1C) eine an CH B gerichtete Befehlsmeldung erzeugt. Die für CCW #4 an der externen Seite bereitgestellten Daten sind die Daten für CCW #1 (Lesen) an der internen Seite, sodass die CTC-Funktion die FC-4-Dateiköpfe in den Informationseinheiten neu erstellt und an den internen Kanal weiterleitet. Da die Anzahlen übereinstimmen, kann die CTC-Funktion die Verkettung nun mit dem nächsten Befehlspaar fortsetzen. Bei diesem stimmen die Schreibdaten für CCW #2 mit den entsprechenden Lesedaten für CCW #5 überein, sodass CTC A die Dateiköpfe neu erstellt und die TCBs an den Treiber weiterleitet, die von dort aus an CH B gesendet werden. Die Verkettung erfolgt, wenn alle Daten gesendet wurden und wenn der Prozess für das dritte CCW-Paar (#3<-#6) wiederholt wird.

Wurden alle Daten für das dritte CCW-Paar gesendet, ist die Kette vollständig. Anschließend erzeugt CTC A den Status CE-DE und erstellt Status-Informationseinheiten, die an beide Seiten gesendet werden. Wenn beide Seiten den Status anerkennen, ist die Operation abgeschlossen.

Die vorliegende Erfindung lässt sich beispielsweise auf ein Computerprogrammprodukt (z. B. auf ein oder mehrere Computerprogramme) anwenden, die beispielsweise computergeeignete Medien umfassen. In diese Medien ist beispielsweise ein für den Computer lesbarer Programmcode zur Bereitstellung und Vereinfachung der Funktionen der vorliegenden Erfindung integriert. Die Computerprogrammprodukte können Teil des Computersystems sein oder separat verkauft werden.

Zusätzlich kann mindestens eine maschinenlesbare Programmspeichervorrichtung bereitgestellt werden, in die zur Ausführung der Funktionen der vorliegenden Erfindung mindestens ein Programm mit Befehlen fest integriert ist, die für die Maschine ausführbar sind.

Die in der vorliegenden Patentanmeldung dargestellten Ablaufdiagramme dienen als Beispiele. Die Diagramme oder die Schritte (oder Operationen), die in der vorliegenden Patentanmeldung beschrieben werden, können variiert werden, ohne dass vom Sinn der Erfindung abgewichen wird. In bestimmten Fällen können die Schritte beispielsweise in einer anderen Reihenfolge ausgeführt werden, oder es können Schritte hinzugefügt, gelöscht oder modifiziert werden. Alle diese Variationen werden gemäß der im Anhang befindlichen Ansprüche als Teil des Umfangs der vorliegenden Erfindung betrachtet.

Obwohl die Erfindung in der vorliegenden Patentanmeldung gemäß bestimmter bevorzugter Ausführungsarten detailliert beschrieben wurde, können durch den Fachmann viele Modifikationen und Änderungen an ihr vorgenommen werden. Infolgedessen sollen die im Anhang befindlichen Ansprüche alle Modifikationen und Änderungen einschließen, die dem tatsächlichen Sinn und Geltungsbereich der Erfindung entsprechen.