Die Verbindung mehrerer verschiedener Hardwaresysteme innerhalb eines Anwendungsgebietes erweist sich immer noch als problembehaftet, wenngleich auch von den Anwendungen her als sinnvoll. Verschiedene Möglichkeiten und Konzepte zur Rechner-Kopplung stehen zur Verfügung. H. Grotzki von der CLS GmbH aus München beschreibt in seinem Beitrag die Verbindung zwischen einem Amdahl-Rechner und einem Prozeßrechner der Digital Equipment Corporation (PDP-11). Diese bereits im Einsatz befindliche direkte Kanalkopplung wurde ohne Emulation irgendwelcher IBM-Einheiten über deren serielle Steuereinheiten realisiert.

Viele Unternehmen verfügen seit längerem über Computer-Parks, bestückt mit Rechnern unterschiedlicher Strukturen. Die "klassischen" Bereiche, kommerzielle DV und technisch-wissenschaftliche DV, existieren immer noch getrennt und werden aus guten Gründen auch noch weiterhin bestehen bleiben.

Technisch-wissenschaftliche Bereiche bedienen sich heute nicht mehr nur der Prozeßrechner als Hilfsmittel zur Bewältigung der vielfältigen Aufgaben, sondern auch der kommerziellen Mainframes - man denke etwa an technische Datenbanken oder komplexe physikalische Berechnungen. Dabei entstanden nicht selten Maschinenparks mit so unterschiedlichen Rechnern wie die von IBM, Amdahl, DEC, CDC, Prime oder HP in einem einzigen Maschinenraum.

Es liegt in der Natur der Sache, daß auf den verschiedenen Rechnern zum großen Teil mit Datenbeständen gearbeitet wird, die überwiegend gleichen Ursprungs sind. Des weiteren laufen auf einem Rechner Programme, von denen Dateien benutzt werden, welche auf einem anderen System erzeugt oder modifiziert wurden.

Aus dieser Forderung heraus ergibt sich der Anspruch, Datenbestände des einen Computers für die Verarbeitung auf einem anderen Rechner, diesem zur Verfügung zu stellen.

Master und Slave

Im Sinne der oben geschilderten Situation ergeben sich verschiedene Anforderungen an ein praxisorientiertes Rechner-Kopplungssystem.

So gibt es immer einen anfordernden Rechner (im folgenden "Master" genannt) und einen angeforderten Rechner (im folgenden "Slave" genannt, siehe Skizze I).

Derjenige Computer ist automatisch Master, von dem aus ein Anwender eine Aktion initiiert (in Skizze I ist dies der Rechner R4). Derjenige Rechner wird Slave, auf dem vom Master aus eine Aktion initiiert wird (in Skizze I ist es Rechner R1).

An einem Terminal (Ti in Skizze I) kann von einem Anwender eine der folgenden Aktionen gestartet werden:

- Einfaches Übertragen einer Datei vom Master auf einen Massenspeicher des Slave.

- Einfacher Transfer einer Datei vom Slave auf den Master.

- Übertragung einer Datei vom Master zum Slave und Verarbeitung der Datei auf dem Slave mit dort vorhandener Software.

- Übertragung einer Datei vom Slave zum Master und Verarbeitung der Datei auf dem Master mit hier vorhandener Software.

Jede Aktion läuft in den drei Phasen: Formulierung der Anforderung durch den Anwender im Dialog mit dem Master, Ausführung der Anforderung durch den beteiligten Master und Slave und Rückmeldung über den Erfolg der Aktion an den Anwender, Protokollierung auf beiden beteiligten Rechnern ab.

Entschiedener Wert sollte darauf gelegt werden, daß das anfordernde Terminal des Masters unmittelbar nach Beendigung des Anforderungsdialoges wieder frei wird ("detached", "deallocated" oder "freed"). Damit soll erreicht werden, daß am Terminal Ti (Skizze I) weiter gearbeitet werden kann, auch wenn die Ausführung einer Aktion sich beispielsweise durch den Slave-Rechner unbeeinflußbar verzögert.

Kommunikationssoftware

Es muß auf allen Rechnern eine Basis-Communicationssoftware (BCS) vorhanden sein. Die BCS sollte in jedem Rechner resident sein und hat nur folgende Aufgaben zu erledigen:

- Übernahme der aktionsrelevanten Parameter von der Basis-Dialog-Software; das sind im wesentlichen

- Source file

- Destination-file

- zu startendes Applikationsprogramm

- Erfolgsmeldungs-device, Protokoll-device

- Lesen und Schreiben der notwendigen Dateien,

- Starten der verlangten Applikationssoftware,

- Bedienung der rechnerspezifischen Interfaces/Channels,

- Erzeugung und Ausgabe der Erfolgsnachricht sowie Protokollierung der Aktionen,

- Bei Multi-user/Multi-tasking-Systemen (MVS, IBM; RSX-11M, DEC) sollten geeignete queueing-Eigenschaften in der BCS vorhanden sein (spooling),

- Überprüfen von Datei-Parametern (vorhanden, in-use, protection) der zum Rechner gehörigen Datei, wenn der Rechner im Slave-Modus arbeitet.

Für jeden Rechner, der Master werden können soll, muß eine Basis-Dialog-Software (BDS) vorhanden sein.

Eigenschaften und Aufgaben der BDS sind:

Die Dialog-Software wird vom Anwender-Terminal aus gestartet. Beim RSX-11M (DEC) geschieht das einfach durch Eintippen des Programm-Namens, wenn der Name ins MCR gelinkt wurde. Beim MVS (Amdahl, IBM) durch Eintippen des Namens einer entsprechend aufbereiteten CLIST (unter TSO oder SPF/TSO-command-feature).

Die BDS übernimmt vom Terminal die Parameter: Source-file, Destination-file, Name des zu startenden Applikationsprogrammes, und Erfolgsmeldungs-device, Protokoll-device.

Syntaxprüfung

Jeder File-name wird auf die für den jeweiligen Rechner vereinbarte Syntax geprüft. Wenn der Source-file auf einer DEC-Maschine mit RSX-11M liegt, so muß der file-name in RSX-Syntax angegeben werden. Und wenn der Destination-file auf Amdahl (oder IBM) mit MVS liegen soll, so ist der file-name dafür in der MVS-Syntax anzugeben.

Das bedeutet, daß die Dialog-Software die Syntax aller am Verbund beteiligten Rechner respektive deren Betriebssysteme kennen muß.

Die Prüfung der dem Master-Rechner zugehörigen Datei-Parameter (vorhanden, in-use, access-protection) wird ebenfalls mit dieser Software durchgeführt. Die zum Slave-Rechner gehörigen Datei-Parameter werden von der BCS des Slave-Rechners abgearbeitet.

Die Parameter werden an die residente BCS transferiert. Es existiert ein Exit zum Betriebssystem mit Freigabe des Terminals für weitere Benutzung nach Beendigung des Dialoges.

Die Bedienung der Interface-Steuersignale des Partner-Rechners darf nicht durch Software in den Rechnern geschehen.

Betrachten wir ein konkretes Beispiel, nämlich die Kopplung einer IBM mit einer PDP-11 oder VAX von DEC. Wir unterstellen, daß keine der üblichen IBM-Steuereinheiten benutzt werden, sondern die physische Kopplung direkt auf den IBM-Channel erfolgt ist. Unter Umgehung eines Channel-Links würde man DEC-seitig ein paralleles Interface vorsehen, so vom Typ DR11 (DMA-Interface mit je 16 Bit I/O und Wechselpuffer-Technik).

Der IBM-Channel hat etwa die Komplexität des Unibus von DEC, ist jedoch erheblich "absturzempfindlicher". Des weiteren - und das ist womöglich noch gravierender - sind Teile der Channel-Funktionen auf ausgesprochen unangenehme Weise mit CPU-Funktionen verknüpft. Stellvertretend für eine ganze Reihe von kritischen Situationen sollen nur zwei Problemkreise angeführt werden.

Wird die PDP-11 aus irgendeinem Grunde abgeschaltet, dann produziert der Channel pausenlos timeouts, wenn er versucht, das DR-11 oder eine dahinterliegende Control-Unit zu adressieren ("Initial Selection"). Damit ist der Channel erst einmal "zu".

Das liegt daran, daß ein bestimmtes Channel-Signal ("Select Out") am DR-11 zwar ankommt, aber nicht durchgeschleift werden kann, wie es sein müßte. Das Problem ist etwa vergleichbar der Situation am DEC-Unibus, wenn zwischen zwei belegten Slots eine Lücke ist und die Signale "Bus Grant" nicht mit einer Grant-continuity-Karte weitergegeben werden.

Noch kritischer wird es, wenn das DR-11 sich zwar meldet, aber aus irgendeinem Grunde nach erfolgter "Initial Selection" eine vorgeschriebene Meldung an den Channel nicht erfolgt (der "Initial Status"): Die komplette IBM bleibt schlicht stehen, bis der "Initial Status" gesendet wird. Der Gründe gibt es viele, die dazu führen können, wenn die Antwort der PDP-Software erfolgen soll. Beispielsweise ist die entsprechende task ausgeswappt, weil vergessen wurde, sie zu fixen. Oder ein anderes Programm reißt die CPU extrem lange an sich (privilegierte tasks können das sehr gut!), oder es läuft gerade ein DMA-transfer im burst-mode über den Unibus.

Diese beiden Fälle (und es gibt -zig) sollen als abschreckendes Beispiel genügen. Des weiteren ist klar, daß - wenn alles funktionieren würde - erhebliche CPU-Zeit DEC-seitig gebunden wäre.

Es soll noch erwähnt werden, daß bei direkter Kopplung weitere erhebliche Probleme auftreten, wenn mehr als zwei unterschiedliche Rechner im Verbund arbeiten sollen. Darauf näher einzugehen, würde den Rahmen des Artikels jedoch bei weitem sprengen.

Die Implementierung der BCS (Basis-Communication-Software) sollte keinerlei Eingriff in ein Betriebssystem erfordern.

Die Gründe für diese Förderung liegen auf der Hand:

- Die Folgen der Veränderung des I/O-Supervisors des MVS (Amdahl und IBM) wären nicht ohne weiteres vorhersehbar.

- Ein Release-update würde jedesmal den Aufwand der Änderung des betroffenen Supervisors bedeuten.

- Selbst wenn ein veränderter Supervisor in einer vorhandenen Release

"wasserdicht" ausgetestet würde, so wären in einer neuen Release Instabilitäten oder gar schwere Störungen des gesamten Betriebs nicht auszuschließen, weil eventuell vom Hersteller Änderungen, die das I/O-System betreffen, vorgenommen wurden.

Das Gleiche gilt sinngemäß für die meisten anderen Betriebssysteme (natürlich auch anderer Hersteller).

Um nicht-kommunikationsspezifische Probleme zu vermeiden, sollte man andererseits so hardwarenah wie möglich programmieren.

IBM-seitig sollte man sich eigene Kanalprogramme schreiben (etwa unter Verwendung des Macro's EXCP), welches dann vom I/O-Supervisor systemkonform an den betreffenden Channel übergeben wird.

Lösungen und deren Nachteile

DEC-seitig sollten nach Möglichkeit Standard-QIO's entsprechend vorhandener Driver eingesetzt werden. Allerdings kann man hier (unter Beachtung der notwendigen Sorgfalt) durchaus privilegiert arbeiten und das jeweilige Interface direkt adressieren. Je nach Interface kann das sogar erforderlich sein.

Auf die Nachteile einer Kopplung Channel-Draht-Interface wurde bereits eingegangen. Ein anderes Verfahren wird in der Praxis des öfteren angetroffen, wenn es sich um Ankopplungen an IBM (oder Amdahl) handelt: Der Partnerrechner wird schlicht über eine serielle Schnittstelle mit einer RJE-Leitung der IBM (Amdahl) verbunden.

Wenn nun von einem DEC-Rechner eine Datei nach IBM geschickt und dort auf eine Platte geschrieben werden soll, so wird per Software DEC-seitig ein RJE-kompatibler Job-Stream zusammengestellt und als komplettes Paket über die serielle RJE-Leitung zum mainframe geschickt. Das geht noch verhältnismäßig reibungslos. Was aber geschieht im mainframe, etwa unter MVS? Der ankommende Job-Stream wird erst einmal in die RJE-queue gestellt und zu einem Zeitpunkt gestartet, der wesentlich von der Auslastung der CPU abhängig ist.

Jeder RJE-Benutzer weiß, was das bezüglich der Gesamtverweilzeit bedeuten kann und bei einem gut ausgelasteten Rechner in der Regel auch bedeutet: es kann ohne weiteres eine halbe Stunde oder eine ganze Stunde vergehen, bis der Job anläuft, einige Sekunden bis wenige Minuten aktiv ist und dann auch beendet ist.

Das ganze Verfahren kann zwar - je nach Applikation - zufriedenstellend sein. Es gibt jedoch eine Reihe von Situationen, durch die unter Umständen die Implementierung anderer Kopplungsmethoden mehr als wünschenswert wird.

Der Bildschirm kann DEC-seitig (über den der DEC-Rechner veranlaßt wird, den RJE-Stream abzuschicken) blockiert sein, bis nach langer Zeit die RJE-Abschlußmeldung kommt. Befand sich im RJE-Stream ein Formalfehler, so erfährt man auch dies, unter Umständen jedoch erst nach einer Stunde.

Da senderseitig sinnvollerweise ein time-out vorgesehen werden sollte (ungefähr eine halbe Stunde), kommt es dazu, daß ein Job zwar main-frame-seitig korrekt ankommt und auch abläuft; das wird DEC-seitig natürlich nicht mehr wahrgenommen: time-out.

Es gibt noch mehr Probleme bei dieser Art der Kopplung, aber auch hier wollen wir uns auf die Aufzählung der obigen Punkte beschränken.

Entsprechend den oben genannten Anforderungen wurde ein Computer-Link-System entwickelt (CLS). Die wesentlichen Merkmale des CLS lassen sich so zusammenfassen:

- Es können Daten in beide Richtungen ausgetauscht werden.

- Es kann bitseriell, 8-bit-parallel sowie 16-bit-parallel übertragen werden.

- Für parallel-Übertragung stehen vier unterschiedliche Geschwindigkeiten zur Verfügung:

LS (low speed) 5 kByte/sec

ST (standard) 10 kByte/sec

HS (high speed) 600 kByte/sec

UHS (ultra high speed) 1,4 Mbyte/ sec

- Selbst bei UHS sind Entfernungen bis zu mehreren hundert Metern möglich.

- Bei Verbindung von zwei Rechnern wird nur eine CLS-Einheit benötigt. In diesem Fall ,versteht das Computer-Link auf der einen Seite das Interface des Rechners I, auf der anderen dasjenige des Rechners II.

- Bei Verbindung von mehr als zwei Rechnern wird ein Parallel-Bus-System verwendet.

RAM als Wechselpuffer

Das Computer-Link selbst besteht im wesentlichen aus einem Rechner mit einer speziell entwickelten Software. Jedes Link enthält - abgesehen von einigen trickreichen Spezialschaltungen - zwei ganz normale RAM-Speicher, die als Wechselpuffer arbeiten.

Die Software ist als "real-time-double-task-system" realisiert. Für jede der beiden Seiten des Links existiert eine autonome Software (Interfacetasks), die jedoch nichts voneinander "wissen". Sie sind logisch vollkommen entkoppelt.

Die eigentliche kommunikative Koordinierungsarbeit wird vom dritten, wichtigsten Teil der Software, dem Kommunikations-Supervisor (KOSUP), realisiert. Komplexe Interrupt-Strukturen in Verbindung mit variablen Zustandstabellen haben die strenge logische Entkopplung der Interface-tasks ermöglicht.

Der Aufbau des Links nach genanntem Muster macht deutlich, daß die Verbindung selbst mit einem neuen Interface-Typ, der heute noch nicht auf dem Markt ist, ohne Rückwirkung auf andere Systemteile vorgenommen werden kann, und das auf relativ einfache Weise.

Durch die Software-Struktur des Computer-Links sind natürlich einige Regeln bezüglich des Aufbaus der BCS (Basis-Communication-Software) vorgegeben. Sie beziehen sich im wesentlichen auf den Telegrammaufbau, das heißt, die Klassifizierung beziehungsweise die Interpretation von Informationen, die nicht zur eigentlichen Nutzinformation gehören. Die BCS in den beteiligten Partnerrechnern wird demgemäß zur CL-Hardware dazugeliefert.

Dem Anwender steht es dann frei, ob er seine eigentliche Applikation selbst schreibt oder durch Lieferanten des CLS schreiben läßt.

Realisierte Installation

Eine Pilotinstallation befindet sich seit September '82 in der Erprobung. Es wurden zwei extrem unterschiedliche Rechner miteinander verbunden: Amdahl 470/V7 mit DEC PDP-11/34.

Wie bereits erwähnt, ist bei zwei Rechnern nur ein CL notwendig, was sich natürlich kostengünstig bemerkbar macht.

Im folgenden soll auf einige Einzelheiten der Pilotinstallation eingegangen werden.

Amdahl: Das Amdahlsystem läuft unter dem IBM-Betriebssystem MVS. Der Kanal ist ein Selector-Kanal mit einer Transfer-Kapazität von 1,8 MB/sec. Die Basis-Communication-Software (BCS) ist in Assembler geschrieben.

Es werden speziell für diesen Zweck geschriebene Kanalprogramme eingesetzt. Die Kanalprogramme werden über EXCP an den I/O-Supervisor übergeben. Die privilegierten Maschinenbefehle TEST I/O, START I/O oder HALT I/O werden somit ganz sicher MVS-konform aufgesetzt. Die ankommenden Telegramme werden selektiert nach Steuerinformationen und eigentlichen Nutzinformationen (Datei-Segmente). Die Dateisegmente werden auf Platte geschrieben und stehen hier für jede beliebige Applikations-Software zur Verfügung.

Der Zugriff zur Zieldatei erfolgt mit QSAM (Queued sequential access-method). Jede andere Methode ist möglich. Die GET/PUT-Macros werden im move-mode verwendet. Für zeitkritischere Anwendungen kann der locate-mode verwendet werden.

Die zu übertragenden Satzlängen betragen 128 Byte minimal und 32 KByte maximal. Bei weniger als 128 Byte wird das Verhältnis Nutztdaten/ Steuerdaten zu ungünstig. Je kürzer die Satzlänge ist, desto mehr START I/O-Befehle sind auszuführen, das bedeutet letztlich eine höhere CPU-Belastung. Das obere Limit 32KB ist einfach durch die Struktur der CCW's (Channel-Command-Words) gegeben.

Die Entfernung zwischen Channel und Computer-Link beträgt 18 Meter. Die Übertragung erfolgt in beiden Richtungen.

DEC (PDP-11)

Das vorhandene Betriebssystem ist RSX-11M. Es wurde zunächst eine serielle Leitung zum CL gelegt (300 baud bis 9600 baud). Das verwendete Interface war ein DZ-11 (16-Kanal-Multiplexer). Der driver dazu ist ein Standard DEC-driver.

Zur Zeit besteht eine parallele Verbindung. Das Interface ist ein DRU-11 (16-Bit-paralleles DMA-Interface mit 2 maximal 64KB großen Wechselpuffern im main-memory). Der driver ist ein Spezial-driver. Die Übertragungskapazität beträgt zirka 800 KByte/sec. Die Entfernung zwischen dem Interface DRU-11 und dem Computer-Link beträgt 15 Meter. Entfernungen bis 600 Meter sind erprobt. Dafür sind Spezialkabel mit Spezialübertragungs-Hardware erforderlich.

Die Basis-Software besteht aus BCS (Basis Communication Software) und BDS (Basis Dialog Software).

Bei einem Dauertest wurden mit elf Sekunden CPU-Zeit seitens der Amdahl zirka 12 Giga-Byte absolut fehlerfrei übertragen. Weitere Versuche haben gezeigt, daß die effektiven Übertragungszeiten nicht meßbar abhängig sind von der augenblicklichen Gesamtbelastung der CPU, was allerdings aufgrund der Channel-Struktur und der entsprechenden Software zu erwarten war.

Bei der seriellen DEC-Ankopplung wurden zeitweise Lichtleiter eingesetzt. Die Stabilität der verwendeten Bausteine erwies sich im Dauertest als nicht ausreichend.