UNIX und IBM – einer Romanze erster Teil

Dass ich dieses Thema heute aufgreife, hängt damit zusammen, dass nachfolgender Text gerade als Teil eines historischen Rückblicks entstand. Es geht um die Zeit von 1983-1986, also vor rund 30 Jahren. Dennoch ist der Text verständlich, ja sogar teilweise lehrreich. Die darin dargestellten Umstände lassen erkennen, welchen Weg die Firma IBM und damit die ganze Branche inzwischen zurückgelegt hat.

Woher kam 1980 das Interesse für UNIX?

Die Idee der offenen und verteilten Systeme beherrschte schon seit Jahren die Fachdiskussion. Man stellte gerne den Gegensatz heraus zu proprietären und zentralen Systemen. Dabei wurde nicht selten sogar die Evolutionsgeschichte der Arten bemüht, die verteilten Systeme waren die Säugetiere, die zentralen Systeme die Dinosaurier. Neben den PCs war tatsächlich ein neuer Markt von sehr leistungsfähigen Arbeitsplatz-Rechnern (Work Stations) entstanden. Er wurde zunächst von Herstellern wie Apollo und Sun dominiert. Sie bauten ihre Software ausschließlich auf der UNIX-Basis. Bei diesen Arbeitsplatz-Rechnern waren Programm-Entwicklung und graphischer Entwurf (Computer Aided Design, CAD) die primären Anwendungen, um die es ging. IBM hatte dem lange nichts entgegenzusetzen, weder in Hardware noch in Software. Auf der Hardware-Seite kamen die Böblinger S/360-Rechner dem Bedarf am nächsten, bei der Software war es VM mit CMS. Es war außerdem nicht mehr zu übersehen, dass bezüglich der Entwicklung von neuen Werkzeugen und Anwendungen im UNIX-Markt die Musik spielte. IBM selbst hielt sich aus diesem Teil des Geschäfts (wo Firmen so schnell verschwinden, wie sie entstehen) heraus. Wir Böblinger wollten jedoch gerne die Anwendungen, die allerorts entstanden, auf unseren Rechnern haben.

Portierung einer Basis

Um in diesen Bereich so schnell wie möglich Fuß zu fassen, übernahmen wir daher eine UNIX-Implementierung von AT&T für das System/360, die schon mehrere Jahre intern bei AT&T in Benutzung war. Man braucht dieses System ja nur zu portieren, dachten wir, etwas was bekanntlich bei UNIX kein Problem ist. Das macht fast jeder Garagen-Betrieb, der gerade ein paar Chips zusammengebaut hat, um daraus einen Rechner zu machen. 

Unglücklicherweise lief diese Version unter TSS, dem Timesharing-Betriebssystem des Rechners System/360 Model 67, einem Fossil, das längst von IBM aus dem Verkehr gezogen war. Man hätte auf diese Komponente verzichten können, wenn man UNIX unter VM angeboten hätte. Das wolle der Vertrieb aber nicht. Es sollte ein alleinstehendes UNIX sein. Die UNIX-Freaks wollen nicht ein zweites Betriebssystem dazu lernen, hieß es, sondern einfach nur ihre Werkzeuge und Anwendungen nutzen.

Hier lernten wir wieder, dass ein Programm, das bei einem Kunden läuft, noch längst nicht die Ansprüche an verlässliche System-Software erfüllt. Wir erhielten mit dem Code gleichzeitig Listen von Hunderten von bekannten Problemen. Die Dokumentation stimmte nicht mehr mit dem Code überein und die Wartung setzte intime Systemkenntnisse voraus. Auch neuere Geräte, seien es Platten, Bänder, Drucker oder Datenstationen, kannte das System nicht. Die sogenannte Portierung wurde also eher zu einer Restaurierung und Verjüngung. Nachdem man akzeptiert hatte, dass dies mehr als nur 2-3 Mitarbeiterjahre kostete, gingen wir an die Arbeit. Das Projekt verlief natürlich nicht ohne Probleme. Diese ergaben sich notgedrungen, da es nicht leicht war, die vorhandene Produktbasis in Übereinstimmung zu bringen mit den Ansprüchen der Kunden und den eigenen technischen und wirtschaftlichen Anforderungen an ein solides Software-Produkt.  

Das Produkt war, wie in der Abbildung überspitzt dargestellt, für IBM nicht ganz leicht zu positionieren. Diejenigen Bereiche der Firma, die dieses Produkt für wichtig hielten,  überschütteten uns mit Forderungen bezüglich der Geräte oder Gerätefunktionen, die auch noch unterstützt werden sollten. Die es nicht für wichtig hielten, blockierten uns, indem sie die Software-Funktionen, für die sie verantwortlich waren, nur zögerlich bereitstellten oder anpassten. Ein sehr großer Teil unserer Bemühungen bezog sich nicht auf das UNIX-System im engeren Sinne, sondern auf jedwede Form von Hilfsprogrammen, die für die Verteilung, Installation und Wartung benötigt wurden. Ein Beispiel waren die Diagnostik-Programme, an die der technische Außendienst gewohnt war und auf die er nicht verzichten konnte, es sei denn wir hätten enorme Ausbildungs- und Wartungskosten in Kauf genommen. Die Ankündigung des Produkts versetzte IBM in die Lage, sich bei einigen Ausschreibungen im öffentlichen Bereich zu beteiligen, bei denen UNIX verlangt wurde. Bei den klassischen Vertriebsbereichen entstand die Notwendigkeit, das Produkt abzugrenzen gegenüber dem Einsatzbereich von traditionellen IBM-Produkten.  

Einige technische Schwierigkeiten

Welche technischen Schwierigkeiten sich für dieses Produkt ergaben, soll am Beispiel des Bildschirm-Anschlusses erläutert werden. Beim System/370 war es üblich, Endgeräte entweder über eine externe Steuereinheit (z.B. IBM 2750) oder über einen internen Anschluss (ICA) anzuschließen. Außerdem wurden die Daten zwischen Rechner und den klassischen IBM Bildschirmen (etwa vom Typ IBM 3270) grundsätzlich zeilenweise nach einem IBM-internen Protokoll übertragen. In der UNIX-Welt waren Datenstationen üblich, die im Byte-Mode betrieben wurden und dem Start/Stop-Protokoll genügten (sogenannte ASCII-Terminals). Der Byte-Mode bedeutet, dass jedes Zeichen einzeln an den Rechner übertragen wird. Daher ist das UNIX-System von Grund auf darauf ausgelegt, im Dialog mit Nutzern auf einzelne Zeichen zu reagieren. Wir benötigten also ASCII-Terminals und eine Kontrolleinheit, die im Start/Stop-Mode arbeitete. In der internen Entwicklung konnten wir für diesen Zweck ein anderes IBM/System vorschalten, um damit die Terminals zu betreiben, nämlich die Serie/1. Dieses System kostete zwar nur etwa ein Viertel unseres Systems, verlangte aber sehr viel Spezialkenntnisse, um seine Software zu betreiben. Auch gab es ein eigenes, allerdings nicht strategisches UNIX-System für die Serie/1, mit dem Kunden hätten auskommen können. Wir ließen deshalb eine eigene nicht freiprogrammierbare Box (IBM 7171) entwickeln, mittels der wir ASCII-Terminals im Start/Stop-Mode anschließen konnten.

Neuer Spieler im Block

Da dies der erste groß angekündigte Einstieg von IBM in den UNIX-Markt war, rief das Projekt eine Vielzahl bis dahin unbekannter Partner auf den Plan. War einer der Gründe, warum wir in UNIX einstiegen, leichter an Anwendungen zu kommen, so waren wir doch überrascht über die Art, wie dies geschah. Fast jede Woche erhielten wir einen Anruf von einer amerikanischen Software-Firma, die uns ein Werkzeug oder eine Anwendung anbot. Wir dürften sie haben, am liebsten gegen einen festen Preis, wir sollten aber dafür den weltweiten Vertrieb und vor allem die Wartung übernehmen. Sie als Fünf-Mann-Unternehmen seien dafür zu klein. Es gab aber auch mehrere Ereignisse, die bewiesen wie schwer es IBM in diesem Markt haben würde. Einige seien erwähnt.  

− Da wir nicht ganz so sicher waren, ob alle unsere Kunden mit der Programmiersprache C glücklich würden, versuchten wir auch einen COBOL-Übersetzer zu bekommen. Die zuständigen IBM-Gruppen gaben uns entweder aus Kapazitäts- oder aus Kompetenzgründen einen Korb. Wir gingen daraufhin zu einer externen Firma, die solche Produkte im UNIX- und dem beginnenden PC-Markt verkaufte. Die Verhandlungen mit dieser Firma liefen zunächst ganz gut, bis die Frage der Anzahl der Lizenzen aufkam. „Wie viele Tausend wollt ihr haben?“ fragte man. „Vielleicht 1200 oder 1400 Stück“ war unsere Antwort. „Wie bitte“, hieß es dann, „warum stehlt ihr uns eigentlich unsere Zeit? Wir dachten, es ginge auch bei Ihnen um eine Größenordnung, wie wir sie von PC- oder Arbeitsplatzrechnern gewohnt sind, also 20.000 aufwärts“. Wir kamen noch aus einer anderen Welt. 

− Es gab eine größere Ausschreibung für UNIX-Systeme im Verteidigungsbereich. Wir entschieden uns mitzubieten. Beim ersten Vergleich schnitten wir schlecht ab, lagen unter "ferner liefen", bekamen aber eine zweite Chance. Dafür erhielten wir die Anwendung (Benchmarks) des Kunden, um uns für einen "Best and Final"-Vergleich vorzubereiten. Wir setzten die besten Analytiker der Firma und die umfassendsten Messwerkzeuge ein, um alle Pfadlängen der Anwendung zu vermessen und anschließend zu verbessern. Das Ergebnis war, dass wir bei dem endgültigen Vergleich zwar bezüglich Funktion und Durchsatz die beste Lösung besaßen, insgesamt aber nur zweitbester Anbieter wurden. Die Preise für die IBM Lösung lagen wesentlich über denen eines Anbieters mit verteilten Mikroprozessoren, die er aus Standard-Komponenten zusammenbaute. Unsere Hardware kostete das Vielfache. 

− Um den akademischen Markt besser kennen zu lernen, überredeten wir eine amerikanische Universität, ihr bisheriges UNIX-System durch unser System zu ersetzen. Die Installation lief glatt und wir waren relativ schnell in Produktion. Plötzlich wurden wir von Hunderten von Fehlerberichten überschüttet. Selbst Mitarbeiter aus der Entwicklung vor Ort erreichten nicht, dass der Berg kleiner wurde. Die Mitarbeiter des Rechenzentrums und die Studenten der Universität berichteten weiter über Probleme. Auf die Frage, ob das alles Probleme seien, die nur bei unserem System aufträten, erhielten wir die Antwort: „Es sind auch die Probleme in UNIX dabei, die wir seit Jahren kennen. Nur machte es bei den früheren Herstellern wenig Sinn sie zu melden. Bei IBM stellen wir jedoch andere Anforderungen“. Kein Wunder, dass unser lokaler technischer Außendienst mit diesem System nicht viel zu tun haben wollte. 

Ernsthaftes Regierungsgeschäft

Bei dem erwähnten „Best and Final“ Test für IX/370 wurde mehrere Tage lang rund um die Uhr gearbeitet, um die Ansprüche des potentiellen Kunden zu erfüllen. Mehrere Mitarbeiter aus Böblingen waren vor Ort, die von zuhause aus Unterstützung bekamen. Dabei kam uns der Zeitunterschied zwischen Amerika und Deutschland entgegen. Trat in Houston abends ein Problem auf, hatte wir meistens keine Mühe am nächsten Morgen (amerikanischer Zeit) eine Lösung anzubieten. Obwohl der Auftrag nicht gewonnen wurde, erntete das Böblinger Team sehr viel Lob für seine technische Kompetenz. „Das hatten wir den Böblingern nicht zugetraut“ meinte bei der Abschlussbesprechung  der Vizepräsident der Federal Systems Division (FSD) von IBM, die den Kunden betreute.

Europäische Hochschulpartner

Das UNIX-Projekt eröffnete uns einige neue Möglichkeiten, mit europäischen Hochschulen zusammenzuarbeiten. Beispiele dafür waren die Universität Zürich (Prof. Lutz Richter) und die Universität Karlsruhe (Prof. Gerhard Goos). Eine weitere Kooperation ergab sich wesentlich später mit dem Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI) in Saarbrücken (Prof. Wolfgang Wahlster). Alle drei Kooperationen wurden mit erheblichem gegenseitigem Nutzen durchgeführt. Voraussetzung dafür war, dass wir die jeweiligen Aufgaben im Rahmen eines aktuellen Projektes definierten und dass der Partner bereit war, unsere Leistungsmaßstäbe zu akzeptieren.

Erfahrungsbilanz

Bei den anderen Böblinger Software-Produkten hatte es sich um Produkte gehandelt, bei denen IBM Marktführer war und deren Einsatzbereich primär bei industriellen Kunden lag. Bei IX/370 befanden sich die typischen Kunden im Ausbildungs-, Forschungs- und Verteidigungsbereich. Wir gerieten an sie über Ausschreibungen. Dabei wurden oft sehr konkrete Forderungen gestellt, die wir erfüllen mussten, wollten wir uns an der Ausschreibung überhaupt beteiligen. Auf der anderen Seite war es jetzt möglich, auf eine Vielzahl im Markt vorhandener Programme und Komponenten zurückzugreifen, um die Wünsche eines Anwenders abzudecken. Wir bewegten uns von einem Entwickler, der sich vorwiegend um selbsterstellte Programme kümmerte, hin zu einem Integrator, der in der Lage sein musste, flexibel und schnell auf einzelne Anfragen und Aufträge zu reagieren. Als Teil des Projekts hatten wir mehr Unteraufträge an andere Firmen vergeben als je zuvor. Es waren über 20 Firmen. Für diese Aufgabe wurden eigentlich andere Kompetenzen gefordert als wir bisher benötigt hatten. 

Ein anderer wesentlicher Unterschied war, dass jetzt externe Gruppen bestimmten, welche Funktionen Teil des Systems werden mussten. So hatten wir uns z. B. gerade auf die UNIX-Version 5.2 eingeschossen, da brachte AT&T die Version 5.3 heraus. Mit 5.2 war von da ab kein Blumentopf mehr zu gewinnen. Später wurde das Gesetz des Handelns von Normierungsgremien, Nutzergruppen oder einzelnen Mitbewerbern bestimmt. IBM, die in der Rolle des Marktführers groß geworden war, wurde zum Mitläufer, der nur noch reagieren konnte. Die bereitzuhaltende Entwicklungskapazität war nicht mehr nach oben zu begrenzen. In einem Labor, das noch mehrere andere Aufgaben hat, ist dies keine erfreuliche Situation. Kein Wunder, dass ein sehr angesehener IBM-Manager der alten Schule unsere UNIX-Verantwortung als „Krebs-Geschwür“ ansah, das man besser loswürde. Das taten wir dann bald auch. 

Fortsetzung der Geschichte

Ein anderes Labor der IBM, das in Austin, TX, ging das UNIX-Geschäft später mit speziell zugeschnittener Hardware an (RS/6000) und war erfolgreicher. Auch die späteren Böblinger LINUX-Aktivitäten liefen unter anderen Bedingungen ab.