Schiff Ahoi, IBM!

Nachdem mir die Firma im letzten Jahr sieben Monate Sonderurlaub gewährt hatte, kehre ich anschließend wieder frohgemut zurück. Ich will die Zäsur nutzen, um mit etwas ganz Neuem zu beginnen und wechsle deshalb auch bereitwillig von z/Linux in das z/VSE Projekt.

Meine anfänglich große Motivation weicht dann aber bald der nagenden Frage, ob die Zeit mit der IBM jetzt nicht endgültig für mich abgelaufen ist. Einige Wochen lang quälen mich die Gedanken über eine mögliche Trennung und die Entscheidung fällt mir wirklich nicht leicht –  schließlich verbinden mich immerhin 21 Jahre mit der amerikanischen Lady.

Aus lauter Verzweiflung überlege ich zwischenzeitlich sogar, ob ich nicht einfach wie in dem Buch The Dice Man, den Würfeln mein Schicksal überlassen sollte.

Am Ende entscheide ich aber dann doch selbst und Mitte Dezember gehe ich entschlossen ins Büro meines Chefs, um ihm feierlich meine Kündigung zu überreichen:

Eine große Veränderung für mich und auf alle Fälle einen ausführlichen Beitrag wert!

An Bord der IBM

Meine Geschichte beginnt im zweiten Halbjahr 1997 in Erlangen: Ich habe die Diplomarbeit gerade hinter mich gebracht und meine Freundin Constance studiert aktuell Sonderpädagogik in Ludwigsburg – deshalb suche ich im Großraum Stuttgart nach einem Job:

Ich bewerbe mich auf eine Anzeige von IBM und bekomme tatsächlich auch eine Einladung. Ich selbst hatte von der Firma mal OS/2 Warp installiert und nutze davon immerhin noch den Bootloader, um auf meinem 486er zwischen Linux und Windows zu wechseln.

Also reise ich mit dem Zug nach Böblingen und fahre anschließend die letzten Meter (zum ersten Mal in meinem Leben) mit dem Taxi zum Entwicklungslabor. Nach fünf langen Bewerbungsgesprächen in unterschiedlichen Abteilungen werde ich am Ende des Tages gefragt, ob ich denn irgendwelche Präferenzen hätte. Daraufhin erwidere ich, dass ich mir so ziemlich alles vorstellen könne, Hauptsache ich bekomme eine Stelle bei der großen IBM.

Auf der Rückfahrt zum Bahnhof stelle ich schließlich noch verwundert fest, dass die Böblinger Stadtkirche von der Firma Kibri jahrelang meine H0 Eisenbahn zuhause schmückte:

Wieder zurück in Erlangen, erhalte ich ein paar Tage später die Zusage von „Big Blue“:

Als ich am Freitag, den 2. Januar 1998 bei meiner zukünftigen Arbeitsstelle eintreffe, ist außer meinem Projektleiter kaum jemand anwesend. Die vielen leeren Gänge kommen mir vor, wie ein unübersichtliches verwinkeltes Labyrinth, …

… und deshalb bin ich auch sehr froh, dass ich zur Ausweisstelle begleitet werde.

Von OS/390 zu “Linux auf dem Mainframe”

Mein erstes Projekt ist PE/390, eine MPI Implementierung, welche ein kleines IBM Team von AIX auf das Unix von OS/390 portiert hat. Wir machen dem Projektnamen alle Ehre, als gleich unser erster offizieller Patch “PE” geht. So bezeichnet man bei der IBM eine Lösung, die sofort wieder ein neues Problem einführt.

Im anschließenden System Automation Projekt gehen mein alter Kollege und ich den umgekehrten Weg, als wir versuchen, die OS/390 Software auf Unix anzuwenden. Das bereitet uns ziemliches Kopfzerbrechen – trotzdem verlieren wir dabei aber nie die Hoffnung, dass am Ende schon irgendwie alles gut wird:

Um meine „Visibility“ zu steigern, beruft mich meine „Secondlinerin“ in die Jury des internen „Ideale“-Wettbewerbs, wo für unseren Bereich das gerade gegründete “Linux auf dem Mainframe” Projekt antritt. Zum Glück bin ich von „unseren“ Leuten so überzeugt, dass ich guten Gewissens dazu beitragen kann, dass „wir“ schließlich den Wettbewerb gewinnen:

Ich fühle mich irgendwie noch zu jung, um in meinem aktuellen OS/390 Projekt alt zu werden und bewerbe mich deshalb anschließend selbst bei dem etwas moderneren Linux Projekt.

Dort erwartet mich ein junges Team, wo sich begabte Entwickler weitgehend unbehelligt vom Management und Abseits von Prozessen austoben dürfen. Einer davon nimmt mich netterweise an die Hand und übergibt mir zwei Aufgaben: Eine Kernel-Tracing Komponente und ein Assembler-Programm für ein „stand-alone dump“ Werkzeug. Beides wird benötigt, um Probleme mit dem Linux Betriebssystem besser analysieren zu können.

Ordnung muss sein

Mit Interesse verfolge ich, wie aus dem etwas chaotischen Skunk Works Stoßtrupp ein geordnetes IBM Projekt wird: Management und Planer versuchen, der Sache irgendwie Form zu geben und die freiheitsliebenden Entwickler kämpfen erbittert – aber am Ende doch erfolglos – gegen die drohende „Prozesslawine“.

Auch ich werde beauftragt, die Transformation zu unterstützen und definiere einen Prozess für die Servicearbeiten. Als großes Vorbild dient mir dabei natürlich mein altes – sehr stramm organisiertes – OS/390 Projekt. Das Ergebnis existiert heute noch und einige meiner Kollegen werden beim Lesen dieser Zeilen sicherlich nicht _nur_ Dankbarkeit dafür empfinden.

Um Statistiken für das Management zu generieren, schreibe ich längere Zeit an einem Programm, welches die Zahlen automatisch aus unserem Quellcode-Versionsverwaltungssystem extrahiert. Allerdings bin ich mir am Ende nicht mehr sicher, ob ich dabei unter dem Strich auch tatsächlich Arbeit eingespart habe:

Zumindest lerne ich dabei ein wenig Perl, wobei ich es aber nie zu der Meisterschaft meines zeitweiligen Bürokollegen bringe, der später das geniale “srv” Service-Tool entwickelt, bei dem ich immerhin noch die “next-steps” beisteuern durfte.

Verstehe die Dinge

Durch die Arbeit am Linux Betriebssystem Kernel eröffnet sich mir so langsam ein tieferes Verständnis für die Funktionsweise von modernen Computersystemen und erst nach der Bekanntschaft mit diversen Gerätetreibern, wird mir irgendwann bewusst, wie Input/Output „wirklich“ funktioniert.

Die nächste Stufe der Bewusstheit erreiche ich durch das Vermitteln meines Wissens an der Dualen Hochschule Stuttgart, wo ich, zusammen mit einem Kollegen, Betriebssystem-Vorlesungen halte. Nach dem Weg zurück von der konkreten Implementierung zu den dahinterliegenden Konzepten kommt mir plötzlich vieles fast banal und trivial vor.

Ich frage mich, warum es so lange dauern konnte, die im Grunde einfachen Dinge zu erfassen. Um wirklich verstehen zu können, brauchte ich wohl erst den intensiven Kontakt mit der Realität.

Suche die Perfektion

Auch was das Programmieren angeht, lerne ich über die Jahre so einiges dazu. Sicher auch durch das Open Source Prinzip gefördert, wo jeder öffentlich sehen kann, was man alles so „verbrochen“ hat, besteht im Linux Projekt eine hohe Motivation, perfekte Programme zu entwickeln. Einige unserer Gerätetreiber werden deshalb gleich mehrfach neu geschrieben.

Auch ich selbst bin immer auf der Suche nach der besten Lösung und fühle oft schmerzhaft das Spannungsfeld von sich manchmal gegenseitig widersprechenden Kriterien, wie zum Beispiel der Kürze eines Programms, der Verständlichkeit und des gewünschten Release-Datums. Am Ende bedeutet Perfektion für mich schließlich, passend zur jeweiligen Situation eine akzeptable Balance zu finden.

Auf alle Fälle bin ich immer bemüht, mein Bestes zu geben, auch wenn manche meiner Kollegen gelegentlich zweifeln, ob das gut genug ist – insbesondere mit kritischem Blick auf meine ipl.c Kreation.

Beherrsche die Komplexität

Als ich irgendwann das „Gefühl“ bekomme, mein Linux Umfeld so einigermaßen im Griff zu haben, steige ich im Stack etwas auf, um „höhere“ Konzepte kennenzulernen und widme mich dem neuen Thema „Linux Container“.

Dort erwartet mich eine zunehmende Komplexität, die jetzt endgültig kein einzelner Menschen mehr komplett überblicken kann. Millionen Zeilen Programmcode machen es immer wichtiger, Abstrahieren bzw. „Glauben“ zu können, was sicher nicht zu meinen ausgeprägtesten Stärken gehört.

Die vielen Ebenen und Kapselungen machen es zudem irgendwann beinahe unmöglich, Probleme zu analysieren. Das führt am Ende dazu, dass man schon gar nicht mehr versucht, herauszubekommen, wo das Problem eigentlich liegt. Zum neuen Paradigma wird es, einfach neu zu starten und zu hoffen, dass dabei keine Daten zu verloren oder verfälscht werden:

Der komplette Gegenentwurf zum IBM Mainframe, bei dem man traditionell bemüht ist, Fehler bereits in den untersten Schichten zu beheben und Neustarts so weit wie möglich zu vermeiden.

Etwas Abwechslung schadet nicht

Im Jahr 2007 darf ich das Labor zum ersten Mal Richtung USA verlassen. Ziel ist eine z/VM Konferenz bei unserem Schwesterlabor in Endicott, welches übrigens auch als Geburtstätte der IBM gilt. Ich halte meinen ersten öffentlichen Vortrag auf Englisch über das “Dumpen” unter Linux und zusammen mit zwei Kollegen nutze ich anschließend noch die Gelegenheit, die Niagarafälle an der kanadischen Grenze zu besuchen:

Im Jahr darauf geht es auf die z/VSE WAVV Konferenz in Chattanooga mit anschließendem Besuch bei der Saturn V Rakete im Space & Rocket Center Huntsville Alabama:

Von der LinuxCon 2012 Barcelona sind mir besonders die tollen Musiker vom Park Güell in schöner Erinnerung geblieben:

Im Jahr 2013 darf ich zum “Enterprise End User Summit”, welcher sehr prestigeträchtig direkt in der New York Stock Exchange abgehalten wird:

Düsseldorf 2014 ist sicherlich ein weiterer Höhepunkt und mein Vortrag “First Failure Data Capture for Linux” landet sogar auf YouTube:

Außerdem darf ich noch “Kernel Event Tracing on the Mainframe” präsentieren und selbst meine BoF wird akzeptiert, die ich dann zusammen mit meinem Namensvetter von IBM moderiere.

Im nachfolgenden Jahr besuche ich die “LinuxCon Europe” in Dublin, wo zufälligerweise gerade das Spiel “Irland gegen Deutschland” im Aviva Stadium ausgetragen wird:

Schließlich schaffe ich es 2016 auf die “IBM Interconnect” in Las Vegas, die mit über 25.000 Besuchern meine bisher größte Veranstaltung ist. Passend dazu gibt “Sir Elton John” für die IBM auch noch ein Konzert in der riesigen MGM Arena:

Interessanterweise treffe ich dann gleich im nächsten Jahr sein Alter Ego auf dem “Open Source Summit” bei den Universal Studios in Hollywood:

Außerdem freue mich auch jedes Mal wieder aus Neue, wenn ich auf der IBM Ausstellungsfläche sein darf, wo die geballte Mainframe Power arbeitet:

Den interessierten Besuchern wird hier äußerst professionell die Stärke unserer Technologie vor Augen geführt.

Das Beste immer zum Schluss

Die Kern-Mannschaft unseres Linux Projekts bleibt über 15 Jahre stabil und mit der Zeit wird das Team ein bisschen zur zweiten Familie für mich.

Hier ein Blick hinüber zu meinem lieben Kollegen, mit dem ich über viele Jahre lang in unserem schönen Kellerbüro zusammensitzen durfte:

Zum morgendlichen Ritual gehört der Gang ins Nachbarzimmer, wo die Kaffeemaschine steht, die einen ganz besonderen Namen trägt:

Ich nutze die Gelegenheit oft zum Smalltalk – selbst wenn ich dafür die Programmierer erst aus tiefen meditativen Zuständen herausreißen muss:

Auch der für das Team reservierte Tischkicker bietet uns immer wieder Gelegenheit, den Kopf frei zu bekommen:

Dank meiner langjährigen Erfahrung beim FC Zöschingen darf ich bei den “echten” Fußballspielen auf unseren jährlichen Hauptabeitlungsfesten meist die ehrenvolle Kapitänsrolle übernehmen und kann unsere Mannschaft einmal sogar zum zweiten Platz führen:

Apropos Sport: Mein erster Teamleiter bei IBM hat mich zum Laufen gebracht und seit seinem Abgang schicke ich jetzt in Vertretung immer Mittags um 11:30 über Sametime ein “Auf gehts!” an die “Running Software” Blue-Group. Dann geht es zum Joggen auf einer der zahlreichen Routen rund um das Labor – die Bedingungen sind hier wirklich optimal dafür:

Über die Jahre hinweg entwickelt die Laufgruppe eine sehr spezielle Diskussionskultur, wobei Herumalbern und das sich gegenseitige Necken ganz entscheidende Elemente darstellen:

Weite Wege durfte ich auch als kampfstarker und sehr trinkfester Arrou durch die Rollenspiel-Welt von Lorakis gehen, …

… natürlich immer in Begleitung meiner treuen Mitstreiter Telkin, Eshi und “Drogo”:

Auch wenn mir die ein oder andere Sitzung manchmal etwas lang vorkam, werde ich die “Helden von Krahorst” trotzdem immer in guter Erinnerung behalten.

Gemeinsam mit dem alten und dem neuen (Rollenspiel-)Meister waren dann auch alle Mann ganz “real” auf der Doppel-Abschiedsfeier, welche ich zusammen mit einem – ebenfalls von Bord gehenden – Teammitglied ausrichten durfte:

Ganz im Sinne der Rede meines Kollegen verabschiede ich mich jetzt ebenfalls mit einem lachenden und einem weinenden Auge von unserer Firma.

Ich bedanke mich bei allen, mit denen ich die letzten 21 Jahre zusammenarbeiten durfte und wünsche der verbleibenden Mannschaft alles Gute …

… mit der sicherlich immer noch sehr seetüchtigen großen IBM!

Schiff Ahoi!
Michael Holzheu

PS: Wie immer an dieser Stelle – hier ein Video zum Blog: https://youtu.be/Pr_EqNOILfY