Karl-Heinz Strassemeyer über IBM Mainframes und Linux

Karl-Heinz Strassemeyer war von 1967 bis 2011 als Entwickler im IBM Labor Böblingen tätig. Er begann seine Karriere in der Software-Entwicklung (PL/I Compiler, I/O-Kontrollsysteme), wechselte 1972 in die Mikrocode- und Hardware-Entwicklung. Er hatte maßgeblichen Einfluss auf die Entwicklung der CMOS-Technologie für IBM Prozessoren und die Entwicklung von Linux für IBM Mainframes. Nach 44 Dienstjahren trat er Mitte 2011 in den Ruhestand, und zwar in Alter von 75 Jahren. Er war IBM Distinguihed Engineer und Mitglied der IBM Academy of Technology.  Er ist  Vorsitzender der Linux Solutions Group (Lisog), einem Verein, der Geschäftserfolg mit Linux-basierten Anwendungen fördert. Strassemeyer hat ein Diplom in Physik aus Göttingen und wurde in Karlsruhe zum Dr.-Ing. promoviert. 

 

Bertal Dresen (BD): Zunächst mein Komplement. Dass Sie Ihre Industrietätigkeit glatte zehn Jahre über die normale Pensionsgrenze ausdehnten, ist schon ein Phänomen. Dass die Begeisterung für die Aufgaben dabei eine große Rolle spielte, ist mir klar. Wie beurteilen Sie heute selbst diese Ihre Entscheidung, bzw. diese Möglichkeit? Es hat ja sicher nicht nur Vorteile gebracht? Würden Sie dies andern Kollegen empfehlen, und wenn ja, unter welchen Umständen?

Karl-Heinz Strassemeyer (KHS): Zunächst herzlichen Dank für Ihr Komplement. Wie Sie wissen, habe ich mich während meiner gesamten Berufslaufbahn bei der IBM mit der Gestaltung und Weiterentwicklung der Mainframe-Architektur und speziell mit möglichst effizienten Implementierungen der kleinsten Mainframe-Systeme befasst. Dieses Arbeitsgebiet war unter anderem auch dadurch ausgezeichnet, dass die Mainframes, und insbesondere die kleinen, mehrfach totgesagt wurden. Hier fühlte ich mich berufen, immer wieder dem Trendgeschwätz erfolgreich die normative Kraft des Faktischen entgegenzustellen. Es gab dabei nie genug Mitstreiter, dass ich mich hätte beruhigt zurückziehen können.

Als wir vor 12 Jahren mit Linux auf dem Mainframe begannen, war ich schon im Pensionsalter. Bei so einem spannenden Projekt konnte ich doch nicht einfach aufhören. Sie sehen: Es gab nie eine Entscheidung. Ich habe einfach nur das weitergemacht, was ich für notwendig hielt und dabei sehr viel Freude und Anerkennung erfahren.

Ich bin der IBM sehr dankbar, dass sie mir diese Möglichkeit eröffnet hat. Nachteile habe ich dank meiner Frau, die mich immer unterstützt hat, nicht empfunden. Jetzt werden wir gemeinsam einen freudigen Unruhezustand gestalten. Ich kann jedem Kollegen, der eine ähnliche Möglichkeit hat, nur empfehlen so eine Verjüngungskur beim Schopf zu greifen.

BD: Ihre erste Berufsphase war in der Software-Entwicklung. Den größten Teil verbrachten Sie jedoch in der Hardware-Entwicklung, und hier vorwiegend in der Mikroprogrammierung. Welche generellen Unterschiede sehen Sie in der Arbeitsweise, im Selbstverständnis, dem Berufsethos und in der Anerkennung von Leistungen? Sind diese Unterschiede eher aus der speziellen Situation eines bestimmten Unternehmens zu verstehen, das sowohl Hardware- wie Software-Produkte anbietet, oder sind sie grundsätzlicher Art?

KHS: Die Software-Entwicklung für das Disk Programming System (DPS) für den kleinsten Mainframe (S/360 Model 20) hatte mit der späteren Mikroprogrammierung vieles gemeinsam. Die Anpassung der Software zur effektiven Ausnutzung der Hardware war ein Muss. Standardalgorithmen erwiesen sich oft als logisch korrekt, aber zu langsam. Ich habe auch hier immer meine Aufgabe darin gesehen, in Zusammenarbeit mit der Hardware optimierte Gesamtsysteme zu gestalten. Kollegen, die für richtige (d.h. größere) Mainframes Compiler schrieben, haben mitleidig auf diese unattraktive Arbeit herab geblickt.

In gewissem Sinne ist Hardware immer Gesamtsystem-Entwurf. Software dagegen ist Auslieferung attraktiver Komponenten. Überspitzt habe ich diesen Unterschied immer als ‚System Design‘ versus ‚Line Item Administration‘ charakterisiert. Ich denke, dieser Unterschied liegt in der Natur der Sache. Teilweise Verschmelzungen dieses Unterschieds sind zu beobachten. So gibt es inzwischen auch viel ‚Line Item Administration‘ im Mikrocode-Umfeld. Der Vorteil des Systemansatzes ist, dass schon bei der Erstauslieferung die Gesamtlösung zur Verfügung steht – eventuell mit etwas Verspätung. Die Auslieferung einzelner ‚Line items‘ ermöglicht eine frühe Sichtbarkeit von Teillösungen im Markt, wobei das Systemkonzept erst allmählich klar wird.

BD: Sie haben den Übergang von IBM Prozessoren von der bipolaren auf die CMOS-Technologie erlebt und mitgeprägt. Können Sie mir in einfachen Worten erklären, um was es da ging? Warum muss man diese Entscheidung im Nachhinein als richtig anerkennen?

KHS: Die bipolare Technologie war damals im Sättigungsbereich ihrer Wachstumskurve angekommen, während die CMOS-Technologie am Anfang einer neuen Wachstumskurve es gerade ermöglichte, kleine Prozessoren auf einem Chip zu bauen. Die RISC-Technologie wurde hierfür geradezu passend erfunden. Die Mainframe-Architektur sollte dann auf RISC-Chips emuliert werden. Wir in Böblingen haben immer die kleinsten Mainframes gebaut. Sie waren auch die kosten-empfindlichsten. Für diese Aufgabe war uns klar, dass es eine direkte Implementierung der Mainframe-Architektur auf einem CMOS-Chip geben muss, um die Architektur nachhaltig konkurrenzfähig zu halten. Dafür haben wir extra kleine Schaltkreise entworfen und mit einer ersten 1-Mips-Implementierung bewiesen, dass die Mainframe-Architektur auf CMOS direkt implementiert werden kann. In der Chefetage von IBM wurde dies für unmöglich gehalten.

Dieser erste Chipset (Capitol genannt) wurde der Prozessor eines Kleinsystems, das kostengünstiger war als die vorhandenen Systeme auf Emulationsbasis. Er musste sich jedoch als Serviceprozessor in den bipolaren Mainframes verstecken, bis das Technologiewachstum von CMOS die zukünftige CMOS-Mainframe-Linie plausibel machte. Die Tatsache, dass die IBM kurz vor Chapter 11 stand, half. Ein System mit 24 Chips war bezahlbar, eines mit 6000 Chips nicht. Ich denke, diese Entwicklung war entscheidend für das Fortbestehen der IBM Mainframe-Linie. So wurde der erfolgreichste Gewinngenerator der IBM vital und zukunftsfähig gehalten. Heute stammt etwa die Hälfte des IBM Gewinns aus Geschäftstätigkeit, die auf Mainframe-Systemen basiert. Nebenbei: Diese Entwicklung hat auch das Böblinger IBM Labor am Leben gehalten.

BD: Es gab nach dem Eintritt von Louis Gerstner in die Firma IBM ab 1993 sehr starke Bestrebungen, die Entwicklungsaufgaben zu konsolidieren. Auf der Software-Seite sollen aus etwa 30 Produktlinien vier übrig geblieben sein. Sie haben primär die Hardware-Seite erlebt. Was lässt sich aus dem zeitlichen Abstand von etwa 20 Jahren heute über diese Bestrebungen sagen? Was waren die entscheidenden Fakten und Argumente?

KHS: Im Mainframe-Hardware-Umfeld war der Konsolidierung von anfangs fünf verschiedenen System- und Prozessor-Design-Points [unterschiedliche Entwürfe, die benötigt werden, um einen vorgegebenen Leistungsbereich abzudecken] eine natürliche Folge wachsender Leistungsfähigkeit der Technologie. So haben wir seit der fünften CMOS-Generation, etwa 1998, ein globales Entwicklungs-Team [zwischen Böblingen und Poughkeepsie, NY], das Architektur-Entwicklung, Prozessor Design und System Design vorantreibt. Hier sorgte die notwendige effiziente Ausnutzung verbesserter Technologieoptionen für die zeitweilig sehr langsame Konvergenz von Meinungsverschiedenheiten. Ich habe diesen Trend immer den Regeln der Physik und der Ökonomie zugeschrieben. Gerstners Einfluss mag da geholfen haben, dass diese Regeln erkannt wurden.

BD: Sie hatten sich für die Einführung von Linux auf IBM Mainframes sehr engagiert. Was waren die grundsätzlichen Überlegungen? Welche Vorteile wurden erwartet? Sind diese eingetreten? Wo traten ernsthafte Probleme auf? Was bestimmte den Projekterfolg? 

KHS: Nachdem es den Mainframes gelungen war, den drohenden Technologietod zu vermeiden, wurde zu den Zeiten der ‚Distributed Systems‘ mit Unix-Anwendungen den Mainframes das Ende aufgrund fehlender Unterstützung moderner Anwendungen vorhergesagt. Die Pläne der IBM, Unix System Services ins z/OS zu integrieren, waren sehr teuer und langwierig. Das Ergebnis war für einen Unix-Kunden nur schwerfällig benutzbar. Hier bot sich Linux als offenes Betriebssystem aus verschiedenen Gründen an. Es war so entworfen, dass es unterschiedliche Hardware einfach unterstützen konnte. Unsere Implementierung im Open-Source-Stil kam zügig voran. Anwendungen von anderen Plattformen konnten unverändert portiert werden.

So sollten und konnten Kunden, die zunehmend Unix-Anwendungen einsetzen wollten, davon abgebracht werden auf andere Hardware-Plattformen zu migrieren. Die im Mainframe inzwischen implementierte Hypersocket-Technologie für effektive interne Kommunikation ermöglichte integrierte Lösungen aus z/OS- und Linux-Komponenten. VM erlaubte die Konsolidierung vieler (einige 100) Intel-Systeme auf dem Mainframe. Linux auf dem Mainframe wurde so zum besten Linux im Markt,  indem es die bewährten Stärken des Mainframes (Zuverlässigkeit und Virtualisie­rungs­­technologie) mit dem offenen Linux-Umfeld zusammenführte. Die Rechnung ging auf: In Japan installierte eine Großbank den derzeit größten Mainframe für eine Linux-only-Installation. Die IBM implementierte intern dieses Server-Konsolidierungskonzept mit erheblichen Einsparungen. Etwa 1/4 der Rechenleistung auf dem Mainframe wird heute von Linux-Anwendungen verbraucht.

Die Tatsache, dass die Mainframes für Datenverarbeitung und nicht für schnelles Rechnen optimiert waren, hat dazu geführt, dass es Anwendungen gab, die auf Intel-Prozessoren doppelt so schnell liefen als auf dem Mainframe. Das erzeugte gelegentlich Probleme. Heute sind die Mainframe-Prozessoren für rechenintensive Anwendungen konkurrenzfähig.

BD: Der Erfolg von Linux ist zweifellos auf die von der Linux-Community praktizierte Entwicklungsmethodik zurückzuführen. Was hat Sie, mit der IBM-Erfahrung im Hinterkopf, besonders beeindruckt? Was lässt sich davon auf industrielle Entwickler-Teams übertragen?

HKS: Die offene, interessen-getriebene Entwicklungskultur, die die Intelligenz aller Gutwilligen ergebnis-orientiert integriert, ermöglicht maximale Effizienz, verglichen mit der prozess- und zeitplan-orientierten Entwicklungskultur in der IBM. Diese Kultur wurde deutlich demonstriert, als einer unserer Mitarbeiter zum geplanten Zeitpunkt seinen Code nicht freigab. Begründung: „Ich kann damit noch keine Ehre einlegen.“ Ich weiß nicht, wie man plan-getriebene industrielle Entwicklungs-Teams so organisieren kann, dass der Entwickler mit seinem Code Ehre einlegen möchte. Bei wem sollte er überhaupt Ehre einlegen wollen? [Diese Frage werde ich in einem späteren Beitrag zu beantworten versuchen]   

                       

BD: Wie sie wissen, hatte ich fünf Jahre meiner Karriere dem Thema Unix auf IBM-Systemen gewidmet. Wir hatten 1985 ein Produkt im Markt, IX/370 genannt. Während wir schon bei der Entwicklung mit vielen ungewohnten Problemen zu kämpfen hatten, ging es nach der Freigabe erst richtig los. Als Beispiel: Ein Kunde überflutete uns in einer Woche mit Hunderten von Problemen, die er von früheren Unix-Systemen her kannte. Nur hatte er niemanden gefunden, der sich der Probleme annehmen wollte, und hoffte jetzt, dass IBM dies täte. Warum liefen die Dinge bei Linux anders? Was hat sich seither im Markt, also in der Sichtweise der Nutzer geändert?

KHS: Als Sie in Böblingen IX/370 entwickelt haben, war ich als Assistent des zuständigen Direktors für Entwicklung im Headquarter [in White Plains, NY] tätig. Daher weiß ich, dass der Gegenwind, Unix auf dem totgesagten Mainframe zu implementieren, sehr groß war. Um Unix, das anwender-getriebene System auf dem zentralen Mainframe, der Anwender nur nach gebührender Prüfung zulässt, zum Durchbruch zu verhelfen, hätte es Architektur-Erweiterungen bedurft. Diese konnten wir nicht durchsetzen, da der notwendige Kundendruck ausblieb. Schwierige Kunden und schwierige IBM Executives gibt es immer. Die hatten wir bei Linux auch. Sie wurden glücklicherweise von Erfolgsmeldungen aus anderen Kundensituationen kompensiert. Der letzte einflussreiche Executive im Mainframe Marketing, der Linux auf dem Mainframe für einen Fehler hielt, wurde erst kürzlich einem ungefährlichen Job zugeführt.

BD: Vielen Dank, Herr Strassemeyer, für diesen Einblick in Ihre Entwickler-Erfahrungen in der Informatik-Industrie und die gewohnt klaren Worte.