Kompatibilitätsprobleme betreffen nicht nur Verträglichkeiten zwischen Rechnern oder Programmen, sondern auch das organisatorische Umfeld. Zu diesem Ergebnis kommt Professor Dr. August Wilhelm Scheer vom Institut für Wirtschaftsinformatik der Universität des Saarlandes. Eine weitere Schwierigkeit sehen die Mitarbeiter des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation in der technischen Grundausstattung ortsübergreifender Netzwerke: Faktoren wie Übertragungsgeschwindigkeit, Flexibilität und Zuverlässigkeit ließen DDP-Konzepte immer noch sehr schnell an die Grenze des technologisch Machbaren und wirtschaftlich Vertretbaren vorstoßen. Konstatiert Dr. Peter Naumann: "Der DDP-Anwender wird sich damit abfinden müssen, auch in Zukunft zentral und dezentral zwei divergierende Qualitäten unter ein Dach zu bringen und die Integration dieser Komponenten selbst lösen zu müssen." kul

Professor Dr. August-Wilhelm Scheer

Institut für Wirtschaftsinformatik, Universität des Saarlandes, Saarbrücken

Die im Zusammenhang mit der Vernetzung von Rechnern auftretenden Probleme lassen sich auf ver schiedene Ursachen zurückführen. Einerseits sind die von den Herstellern entwickelten Netzkonzeptionen nicht aufeinander abgestimmt, andererseits sind auch technische Fragen auf der Ebene der Verdrahtung nicht durchgängig geregelt. So sind in vielen Fällen bei Mixed-Hardware-Einheiten Protokollumsetzungen erforderlich. Die Aufgabe der Protokollumsetzung ist aber häufig schon bei einem einzigen Hersteller aufwendig, da die verwendeten Protokolle bereits hier einen hohen Komplexitätsgrad erreicht haben. Daneben sind fast immer die Schnittstellen für die Terminalemulation und den Dateitransfer vom und zum Marktführer realisiert.

Die beim Anschluß unterschiedlicher Hardwaresysteme an ein Netz auftretenden Schwierigkeiten lassen sich schon alleine aus der Tatsache ableiten, daß selbst bei einem Hersteller wie IBM ein sehr hoher Aufwand bei derartigen Maßnahmen erforderlich ist. Immerhin wurde die zeitliche Verschiebung der Einführung des bundesweiten Btx-Systems nicht zuletzt hiermit begründet. Trotz des erheblichen Know-hows, das bei IBM auf dem Gebiet der Vernetzung und Protokollumsetzung vorhanden ist, hat die Bundespost mit der Definition des Btx-Dienstes als offenes Netz die Entwickler deutlich gefordert.

Für ein Unternehmen, das sich mit der Entwicklung eines Konzeptes zur verteilten Datenverarbeitung beschäftigt ergeben sich eine Reihe von Problemen, die über das Technische hinausgehen. Einige davon sind grundsätzlicher Natur, da sie das Unternehmen über längere Zeit festlegen und enge Beziehungen zu der Kompatibilität der eingesetzten Systemkomponenten aufweisen.

So ist zunächst die Frage nach der Topologie des Netzes zu stellen. In Abhängigkeit von der Entfernung zwischen zwei Standorten müssen die von der Bundespost angebotenen Übertragungsdienste auf ihre Einsetzbarkeit geprüft werden. Ein weiterer Punkt ist die Auswahl einer konkreten Netzsteuerungssoftware, die sowohl die anzuschließenden Hardwarekomponenten als auch die in Frage kommenden Postdienste unterstützen soll. Einige Hersteller unterstützen beispielsweise den Datex-P-Dienst nicht unmittelbar durch ihr Netzkonzept, vielmehr nehmen Protokollkonverter hardwaremäßig Umsetzungen vor.

Relativ problemlos stellt sich die serielle Übertragung von Dateien dar. Bei einer Anwendung-zu-Anwendung-Verbindung oder einer Terminalemulation mit einem Durchgriff über mehrere Rechner ist hingegen bei den Partnern eine Transparenz bezüglich der verwendeten Steuerzeichen erforderlich.

Eine durchgängige Netzkonzeption ohne das Auftreten von Kompatibilitätsproblemen kann derzeit nur bei der Verwendung von Hard- und Systemsoftware eines einzigen Herstellers und auch dann nicht über beliebige Entfernungen, beispielsweise über Ländergrenzen hinweg als realisierbar angesehen werden. Deshalb läßt sich in vielen Großunternehmen die Tendenz feststellen, im DV-Bereich eine Stelle mit der ausschließlichen Zuständigkeit für die Fragen auf allen Ebenen der Vernetzung zu installieren. Diese Stelle steht gleichberechtigt neben der Anwendungsentwicklung und dem Betrieb der Rechenzentren.

Nicht zuletzt ist darauf hinzuweisen, daß ein DDP-Konzept auch eine angepaßte Organisationsstrategie für die Aufbau- und Ablauforganisation der Unternehmung erfordert. Es ist beispielsweise zu regeln, welche Abteilungen oder Betriebsorte für Anlage und Pflege der gemeinsam genutzten Daten zuständig sind, an welchen Orten welche Aufgaben gelöst werden sollen. Hierbei ist sowohl eine Tendenz zur Zentralisierung als auch zur Dezentralisierung denkbar.

So erlaubt die aktuelle Information einer Unternehmenszentrale über Kassenbestände dezentraler Filialen eine zentrale Liquiditätsposition. Andererseits können auch verstärkt Entscheidungen an Filialen delegiert werden, da sich die Zentrale ständig über Abläufe aktuell informieren und bei Bedarf steuernd eingreifen kann. Deshalb betreffen Kompatibilitätsprobleme nicht nur Fragen der Verträglichkeiten zwischen Rechnern, sondern auch zwischen einer alten und einer DDP-geeigneten Unternehmensorganisation.

Dr. Peter Naumann

Nottuln

Nach der Euphorie in Distributed Data Processing (DDP), die in den letzten zwei Jahren durch die Entwicklung auf dem Mini-und Mikrocomputer-Sektor eingetreten ist, läßt sich zur Zeit eine gewisse Ernüchterung feststellen. Schuld daran sind die Probleme, die bei der Verbindung mehrerer Rechner an unterschiedlichen Orten, der sogenannten Vernetzung, auftreten. Sie kommen heute in erster Linie da vor, wo Unternehmen von dem Riesenangebot an Anwendersoftware für Minis und PCs Gebrauch machen und in dezentralen Betriebsstätten derartige Systeme mit dem zugehörigen Computer als Stand-alone-Anwendung realisieren und damit vordergründig dringlichen EDV-Bedarf schnell befriedigen. Denn danach tritt meist unmittelbar die Forderung auf, dieses System in Ein- und Ausgabe sowie Dateizugriffen an den Zentralrechner zu koppeln und das mißlingt sehr häufig. Die Schwierigkeiten liegen heute nur teilweise in der Hardware, meist jedoch in der Software-Inkompatibilität und in zu optimistischen Erwartungen bezüglich Leitungsprozeduren und Netzwerkleistungen.

Hardwareprobleme

Abgesehen davon, daß Hersteller auch Standardschnittstellen wie V.24 in Einzelfällen noch unterschiedlich auslegen, sind Fragen der Hardwarekompatibilität in einem Netzwerk mit Postleitungen (Standleitung, Datex-P, Datex-L) heute kein erstrangiges Problem mehr. Man sollte zwar generell durch Praxistest sicherstellen, ob die Zusage eines Mini- oder Mikrocomputerherstellers auch stimmt, daß sein Produkt "vernetzbar", also an eine Standardschnittstelle anschließbar ist. Dann jedoch kann man die reine Rechner-Hardwarefrage verlassen. Das gilt heute sowohl bei Herstellergleichheit wie auch bei Rechnern verschiedener Anbieter in einem DDP-Netzwerk. Die Meinung, daß es immer Vorteile hat, zentral wie dezentral den gleichen Hersteller zu haben, kann heute als überholt angesehen werden.

Netzwerkprobleme

Für die Verbindung von Rechnern sind seitens der Bundespost heute drei Alternativen gebräuchlich: Standleitung, Datex-P und Datex-L. Alle drei Alternativen bieten derzeit ein Preis-/Leistungsverhältnis, das eine sorgenfreie DDP-Konzeption nicht ermöglicht. Jedes DDP-Konzept muß heute und sicher auch in der nächsten Zukunft den Datenaustausch minimieren und schon deshalb teilweise mit redundanten Datenbanken arbeiten. An ein reinrassiges Konzept verteilter Datenbanken ist bei dieser Leistungsfähigkeit normalerweise nur dann zu denken, wenn die Datenbank auch nur an einer Stelle benötigt wird. Dadurch werden Software-Kompatibilitätsprobleme verschärft. Auf der anderen Seite wird jedoch mit dem Angebot der Bundespost eine Schnittstellenstandardisierung angeboten, die den Verbund unterschiedlicher Hardware ermöglicht.

Softwareprobleme

Das weitaus größte Problem liegt damit in der Softwarekompatibilität. So immens die Gesamtentwicklung auf dem Mini- und PC-Markt selbst war, in der Softwarekompatibilität zu einem Großrechner im Rahmen eines DDP-Konzeptes hat es wohl mehr Rückschritte als Fortschritte gegeben. Softwaremäßig sind hier inzwischen zwei Welten entstanden, die durch unterschiedliche Zielsetzungen sich eher verselbständigt als einander genähert haben. Diese beiden Welten in DDP miteinander zu verbinden, das überläßt man heute mehr denn je dem Anwender, auch wenn einige Hersteller das Gegenteil behaupten. Um so wichtiger ist jetzt, im Zuge einer EDV-Unternehmensgesamtkonzeption festzulegen, welche EDV-Funktionen in Zukunft in welchem Umfang wo ausgeübt werden, zentral und dezentral. Dazu gehört eine ganz präzise Schnittstellenfestlegung, die die Unzulänglichkeiten der Minis und des Netzwerkes berücksichtigt. Damit lassen sich auch Fehlentscheidungen für Stand-alone-Systeme als Ad-hoc-Lösungen einschränken.

Ein solches Gesamtkonzept, muß mit Inkompatibilitätsproblemen in der Software leben:

Betriebssystem

Mit dem OS/MVS und DB/DC-Software einerseits sowie dem CP/M, dem MS/DOS oder herstellereigenen Betriebssystemen mit Verwaltungs- und Textsoftware für die "Kleinen" stehen sich zwei Welten gegenüber, die sich sicherlich in absehbarer Zeit nicht nähern dürften. Damit sind gleichzeitig zwei völlig getrennte Programmwelten festgeschrieben, zwischen denen als Bindeglied nur Daten auf Leitungswegen transportiert werden können. Dialogtransaktionen, die Programmfunktionen auf beiden Seiten gleichzeitig erfordern, sind nur durch eigenständige Einzelprogramme auf beiden Systemen zu ermöglichen. Das Problem wird durch die Entwicklung auf dem Mini- und PC-Sektor selbst noch verstärkt. Gab es vor einem Jahr noch gewisse Anzeichen einer Standardisierung in Richtung CP/M, so gibt es inzwischen eine zweite Welt mit MS/DOS. Hinzu kommt die eher stärker werdende Tendenz zu herstellereigenen Betriebssystemen, die eine Herstellerunabhängigkeit weiter einschränkt.

Um daraus entstehenden Divergenzproblemen zumindest auf dezentraler Seite auszuweichen, ist man heute nicht nur gezwungen, Betriebssoftware und Programmiersprache für die dezentralen Systeme festzulegen. Darüber hinaus ist es notwendig, sich auf eine Produktlinie eines Herstellers festzulegen, weil nur dadurch Softwarekompatibilität sichergestellt ist und man selbst bei identischer Anwendungssoftware dezentral damit rechnen muß, aufgrund unterschiedlicher Betriebsstättengröße Hardware vom PC aufwärts bis hin zum "Großmini" für mehr als 50 Terminals einzusetzen.

Auch wenn man zwangsläufig den Einsatz eines Großteils der am Markt angebotenen Anwendungssoftware ausschließt, nämlich die für andere Betriebssysteme beziehungsweise Hersteller, erscheint dieser Weg zur Zeit immer noch als das kleinere Übel.

Datenbank

Das Preis/Leistungs-Verhältnis der von der Post angebotenen Netzwerksalternativen zwingt, wie dargestellt, zu redundanter Datenführung, wenn die Daten von mehr als einer Stelle häufig verwendet werden. Dadurch wird man mit den Unterschieden der Datenbankverwaltung mit IMS oder anderen DB-Systemen auf dem Großrechner zu den Datenverwaltungssystemen auf Minis voll konfrontiert. Hierin liegt zweifellos eines der ganz großen Kompatibilitätsprobleme, dessen Lösung heute einen unverhältnismäßig hohen Entwicklungsaufwand erfordert.

Programmiersprache

Während der Pionierphase von DDP galt es als "in", fiir die Vorrechner die gleiche Sprache wie für den Großrechnern zu verwenden, um keine zweite Programmiersprache ins Haus zu bekommen und die l'arallelentwicklung gleicher Programme für Host und dezentralen Rechner zu vermeiden. Das war überwiegend Cobol. In der Zwischenzeit hat man damit leidvolle Erfahrungen gesammelt. Für die Programmierung eines Minis gelten für Programmstruktur, die I/Os, Entwicklung und Test ganz andere Gesetze. Cobol war im Endeffekt nicht mehr gleich Cobol, so daß sich trotz einheitlicher Programmiersprache im Laufe der Zeit unterschiedliche Programmiergruppen für Host-und Vorrechnerprogrammierung herausbildeten. Inzwischen hat sich herausgestellt, daß die Welt der Minis und PCs eine Welt des Basic, Pascal oder artverwandter Programmiersprachen geworden ist, mit arteigenen Werkzeugen für Programmierunterstützung etc. Hier wie bei der Betriebssoftware stehen sich damit zwei Welten gegenüber, die heute keineswegs aufeinanderzustreben.

Zusammenfassend läßt sich deshalb sagen:

Hardwarekompatibilität als reine Verträglichkeit in einem DDP-Verbund wird sicher in Zukunft nicht mehr das Problem darstellen, wenn man die Schnittstellenkompatibilität vorher sorgfältig testet. Das

gilt genauso, wenn unterschiedliche Hersteller in einem Netzwerk zum Einsatz kommen.

Das Preis/Leistungs-Verhältnis der von der Bundespost angebotenen Netzwerkalternativen settzt in Zukunft einge Restriktionen für ein DDP-Konzept, die durch Softwareentwicklung ausgeglichen werden müssen. Die standardisierten Schnittstellen erlauben jedoch die Verträglichkeit auch unterschiedlicher Hardware im Netzwerk.

Dafür müssen wir im gesamten Softwarebereich damit leben, daß in einem DDP-Konzept zwei Welten aufeinanderstoßen: einerseits Großrechner, andererseits Minis und PCs. Dies gilt für Betriebssoftware wie auch für Programmiersprachen und Anwendungsprogramme. Die darin liegenden Gegensätze werden sich in Zukunft eher noch verschärfen, da auf dem Mini- und PC-Markt vom Hersteller auch weiterhin durchweg andere Zielsetzungen verfolgt werden als auf dem Großrechnermarkt. Der DDP-Anwender wird sich damit abfinden müssen, auch in Zukunft zentral und dezentral zwei divergierende Qualitäten unter ein Dach bringen und die Integration dieser Komponenten selbst lösen zu müssen. Für das EDV-Management eine neue und sehr anspruchsvolle Herausforderung.

M. Bergmann, H.-D. Litke und P. Maciejewski

Mitarbeiter des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation, Stuttgart

Mit der Dezentralisierung der Datenverarbeitung ist der Gedanke naheliegend, eine Verbindung zwischen Computern der unterschiedlichsten Hersteller aufzubauen und damit die Gesamtheit aller angebotenen

Dienstleistungen allen Benutzern zur Verfügung zu stellen.

Die gewünschte Zusammenschaltung zu einem größeren Datenverbund (Global Networks) geschieht durch Remote Networks (Netze mit größerer geographischer Ausdehnung) und Local Area Networks (LAN). Neben der Wahl geeigneter Übertragungsmedien (hohe Bandbreite, rascher Netzzugang, schnelle Nachrichtenübertragung) sind die Netztopologie (Star, Ring, Bus) sowie die Netzprotokolle festzulegen.

Die Vielzahl von unterschiedlichen Konzepten für Rechnernetze hat die verschiedensten Zugriffsmethoden entstehen lassen. Die gebräuchlichsten sind: herkömmliche Techniken, wie Frequenzmultiplex, Zeitmultiplex und Polling (Abrufbetrieb) und neuere Techniken, wie Ring- und Buskonzepte mit "Token Ring", "Token Bus" beziehungsweise "CSMA-CD" als Zulassungsprotokolle. Grundsätzlich sind alle Kombinationen von Übertragungsmedium, Topologie und Zugriffsmethode denkbar. Praktikabel und sinnvoll sind jedoch nur wenige.

Die Vielzahl von unterschiedlichen Konzepten für Rechnernetze hat eine verstärkte Standardisierungsbewegung zu "De-facto"-Standards hervorgerufen. So X.25 oder, als Beispiel aus der Industrie, SNA. Technische Vergleiche und Bewertungen sind wegen der Begriffsvielfalt und unterschiedlicher Modellvorstellungen schwierig.

Die bedeutendste Standardisierung wurde mit dem ISO-Referenzmodell für offene Kommunikationssysteme (Open Systems Architecture) gemacht. Neben anderen Institutionen (ANSI, ECMA) hat hierbei vor allem das im Februar 1980 gegründete Gremium IEEE 802 einen großen und richtungsweisenden Einfluß. Der Schwerpunkt der Arbeitsgruppe lag bisher auf den beiden unteren Ebenen des 7stufigen ISO-Referenzmodells:

1 Physical Level (zum Beispiel RS 422A)

2 Data-Link-Level (zum Beispiel Motorola ADLC)

3 Network-Level (zum Beispiel Paketvermittlung)

4 Transport-Level mit Ende-Protokollen

5 Session-Level ist verantwortlich für die Abbildung netzwerkorientierter Adressen

6 Presentation-Level transformiert die Daten von einem Format in das andere

7 Application-Level

Zur Zeit existieren auf den beiden untersten Ebenen zwei Standards:

Token passing: ein Token ist ein auf dem Ring zirkulierendes Signal, das von den angeschlossenen Stationen als Sendeberechtigung interpretiert wird. Ist eine Station nicht sendewillig oder hat sie eine eigene Übertragung gerade beendet, dann leitet sie ein Token an den Ringnachfolger weiter Verfahren zur expliziten Zugriffssteuerung gibt es vor allem bei IBM/Texas Instruments.

CSMA/CD (Carrier Sense Multiple Access with Collision Detection): Ein Bus ist ein allen Netzstationen zugängliches Übertragungsmedium, das im allgemeinen einen passiven Nachrichtentransport vornimmt; dies bedeutet, daß jede Sendung ohne jegliche Aktion der Nichtbetroffenen alle ihre Adressaten erreicht und daß Verzögerungszeiten pro angeschlossener Station entfallen. Ethernet ist ein Beispiel für diesen Mehrfachzugriff mit Kollisionserkennung.

Betrachten wir zum Vergleich die Remote Networks mit paketvermittelnden Netzen: Obwohl diese öffentliche Netze meist eine Übertragung mit virtueller Verbindung (X.25) vorschreiben, ist es den Kommunikationssubsystemen möglich, andere Übermittlungstechniken zu verwenden; vermutlich tun die meisten dies auch.

Von zentraler Bedeutung lùr die Kopplung von Local Area Networks untereinander sowie mit Remote Networks dürfte eine weitergehende Standardisierung sein, wobei in der Zukunft noch eine Menge Probleme wie Performance, Aufbau und Einschalten eines Gateway-Verbundes, sowie eindeutige Adressierung im gesamten Netzwerk (Global Network) zu lösen sind.

Es bleibt festzuhalten, daß sich sowohl die Standardisierungsorganisationen als auch die Hersteller sich über der Vereinheitlichung der Netzwerk-Protokolle einig sind. Zwar ist zur Zeit die technische Grundausstattung zur Realisierung eines ortsübergreifenden Netzwerkes gegeben, jedoch stößt man im Bereich der Datengeschwindigkeit, der Flexibilität (Anschließen und entkoppeln beliebiger Stationen/LAN's) und der Zuverlässigkeit schnell an die Grenzen des derzeit technologisch Machbaren.