Das ehemalige Dorf an der Düssel, auf das Kölner so verächtlich
herabschauen, hat mehrere werbewirksame Beinamen. Es reicht vom Kontor des
Ruhrgebiets zum Mekka des rheinischen Kapitalismus, von der Stadt der Künste zu
Klein-Paris. Ich habe drei Jahre in Düsseldorf gelebt, von Sommer 1959 bis
Sommer 1962. Ich habe dort sehr viel über Rechenzentrumsbetrieb, Wirtschaft und
Stadtleben gelernt, vor allem aber endete dort meine Junggesellenzeit. Also der
Reihe nach.
Nach meiner Diplomprüfung in Bonn bot mir der Professor, der meine
Diplomarbeit betreut hatte, an zu promovieren. Ich sollte den Einsatz von
Computern bei geodätischen Ausgleichsrechnungen untersuchen, ein Thema, das in
der Luft lag. Genau wie nach dem Abitur, als mein Mathe-Lehrer mir vorschlug
Mathe zu studieren, wollte ich mir zunächst die Winde der Praxis um die Nase
wehen lassen. Es ergab sich, dass ein Mitarbeiter des Bonner Geodätischen
Instituts (Gerhard Klietsch), der ebenfalls über den Einsatz elektronischer
Rechner gearbeitet hatte, gerade zur Firma IBM gewechselt hatte. Er vermittelte
mir eine auf sechs Monate befristete Praktikantenstelle im IBM-650-Rechenzentrum
in Sindelfingen bei Stuttgart. Am 15.11.1957 fing ich an. Bereits wenige Wochen
danach wurde ich gefragt, ob ich nicht bleiben wollte. Ohne sehr lange zu
überlegen, sagte ich zu. Damit war meine Karriere als Geodät (fast) zu Ende.
Ich war fortan Programmierer, Rechenzentrums-Leiter, Software-Entwickler, IT-Experte
und schließlich Informatiker. Der Weg dauerte rund 40 Jahre.
Der Teil meiner Laufbahn, den ich hier beschreiben werde, konzentriert
sich auf zwei fachliche Fragen: (1) Was ist das Besondere an der Tätigkeit
eines Programmierers und (2) Wie betreibt man ein Unternehmen namens
Rechenzentrum? Über beides sind viele Bücher geschrieben worden. Ich werde hier
nur die Quintessenz meiner Erfahrungen wiedergeben.
Rechner IBM 650 (Foto IBM)
Der Rechner IBM 650,
den ich bereits in den USA kennengelernt hatte, war ein Dezimalrechner und
besaß einen Trommelspeicher, der 2000
Worte umfasste. Ein Programm, inklusive Konstanten und Tabellen, konnte also
maximal 2000 Maschinen-Instruktionen umfassen. Zunächst programmierten wir
direkt im Maschinencode, gingen aber alsbald auf Assembler über. Dieser hatte
den Vorteil, dass er die Programme um den Faktor 6-7 beschleunigte, indem er
die Instruktionen so auf der rotierenden Trommel platzierte, dass die Zugriffszeiten
minimiert wurden. Dieses ‚Symbolic
Optimal Assembly Program‘ (SOAP) hatten G. Trimble und E. Kubie [2] von der IBM
in Endicott, NY, entwickelt. Für technische-wissenschaftliche
Anwendungen erwies sich ein Interpreter als sehr nützlich. Er stammte von R.
Wollontis [3] aus den Bell Labs in Murray Hill, NJ, der späteren Heimat von
Unix. Ein interpretiertes Programm benötigt etwas mehr Rechenzeit, dafür kann
es leichter getestet und leichter geändert werden als ein assembliertes
Programm.
Ein Programmierer steht vor der Aufgabe, ein gegebenes Problem in Rechenschritte zu zerlegen, diese Schritte als Anweisungen an einen Rechner zu codieren, und sicherzustellen, dass das Problem umfassend, korrekt und zufriedenstellend gelöst ist. Jeder der benutzten Begriffe hat eine Vielzahl von Facetten, auf die hier nicht näher eingegangen wird. Man kann auch sagen, Programmierer müssen gleichzeitig kreativ und pedantisch sein, Eigenschaften, die man normalerweise nicht zusammen anzutreffen vermutet.
Ein Programmierer steht vor der Aufgabe, ein gegebenes Problem in Rechenschritte zu zerlegen, diese Schritte als Anweisungen an einen Rechner zu codieren, und sicherzustellen, dass das Problem umfassend, korrekt und zufriedenstellend gelöst ist. Jeder der benutzten Begriffe hat eine Vielzahl von Facetten, auf die hier nicht näher eingegangen wird. Man kann auch sagen, Programmierer müssen gleichzeitig kreativ und pedantisch sein, Eigenschaften, die man normalerweise nicht zusammen anzutreffen vermutet.
Etwa ein Jahr nach Beginn meiner Tätigkeit in Sindelfingen, wurde mir
die Aufgabe übertragen, das zweite IBM-650-Rechenzentrum der Firma
einzurichten. Als Standort war Düsseldorf ausgewählt worden. Dort hatte die
Firma einen florierenden Lochkartenbetrieb. Ein Teil seiner Kunden kam als
Kunden für das Rechenzentrum in Frage. Außerdem bestand großes Potenzial im
Umland für Neukunden. Unsere Firma befand sich zu dieser Zeit in der Rolle
eines Pioniers, der laufend Neuland betrat.
Nachdem das erste Jahr in der Firma primär meiner fachlichen
Qualifizierung gedient hatte, wuchsen mir jetzt die Aufgaben eines
selbständigen Unternehmers zu. Es begann mit der Anmietung und Einrichtung von
Räumen, dem Einstellen und der Ausbildung von Personal und dem Erlernen von
gesetzlichen und tariflichen Auflagen für den Betrieb eines Rechenzentrums. In
den Geschäftsräumen in der Nähe des Bahnhofs wirkte alsbald ein Team von 10-12
Leuten. Sehr starke Unterstützung fand ich einerseits bei der Installation und
Wartung der Rechner-Hardware, andererseits bei der Akquisition von Aufträgen. Der
technische Außendienst der IBM meisterte die neue technische Herausforderung
mit Bravour, den Vertrieb reizte das zusätzliche Geschäft. Der Einzugsbereich
des Rechenzentrums ging von Koblenz bis Oberhausen, von Aachen bis Dortmund. Die
Wirtschaft der Region boomte. Manchmal musste ich sogar bremsend wirken, wenn
weder die Kapazität der Maschinen noch die Leistungsfähigkeit des Teams die Erwartungen
des Vertriebs erfüllen konnten.
Rechner IBM 7070 (Foto IBM)
In dieser Situation musste ich oft an die Geschichte denken, als ein Fotograf
und ein Verkäufer zusammen auf Safari gingen. In Afrika angekommen, sagt der
Vertriebsmann zum Fotografen. ‚Pack Du schon mal die Kameras aus, ich schaue
derweil nach, ob es hier überhaupt wilde Tiere gibt‘. Nach zehn Minuten stürmt der
Vertreter ins Zelt zurück, hinter ihm ein brüllender Löwe. ‚Hier hast Du
Arbeit. Sieh zu, wie Du damit fertig wirst.‘ Eine vergleichbare Situation ergab
sich für das Rechenzentrum vor allem durch die Hauptspeicherbegrenzung der IBM
650. Ein Fallbeispiel wurde 2003 von Endres [1] so beschrieben:
Bei den meisten Programmen, die wir
schrieben, hatte sich [der Hauptspeicher] nicht als Begrenzung erwiesen, so bei
den statischen Berechnungen für Flächentragwerke, der Umformung von photogrammetrischen
Messdaten oder der Erstellung von Lohnsteuertabellen. Anders wurde es bei der
Berechnung des Wochenlohns für Bauarbeiter. Seither weiß ich, dass Baulohn als
Anwendung besonderen Respekt verdient, und zwar wegen seiner vielen Varianten
und Zuschlagsarten. Es war Anfang 1960, als wir für das IBM-Rechenzentrum in
Düsseldorf den Auftrag gewonnen hatten, für eine Baufirma aus der näheren
Umgebung die Lohnabrechnung durchzuführen. Ein Kollege und ich übernahmen es,
die Umstellung des Baulohns von der Lochkartenabrechnung auf die programmierte
Form der Abrechnung durchzuführen. Der Lohn wurde regelmäßig am Freitag jeder
Woche an einige hundert Mitarbeiter ausgezahlt. Etwa am Dienstag oder Mittwoch
merkten wir, dass wir das Programm nicht bis Freitag fertig bekommen würden,
und dass es aller Voraussicht nach nicht in den Speicher passen würde. Ich
marschierte zum IBM-Niederlassungsleiter, einem respekt-einflößenden, etwas
älteren Herrn, mit dem Ansinnen, doch den Kunden zu überzeugen, diese Woche noch
einmal mittels Lochkarten abzurechnen. Seine Antwort habe ich nicht vergessen.
„Eure Probleme sind zwar interessant, sie gehen mich aber nichts an. Ich denke
nicht daran zum Kunden zu gehen. Ihr habt das Projekt übernommen und den Termin
zugesagt. Entweder läuft Euer Programm am Freitag oder wir schicken die
Bauarbeiter zu Euch und Ihr zahlt von Hand aus“. Natürlich lief unser Programm
am Freitagmorgen und es passte auch in den Speicher. Dass wir in dieser Woche
wenig Zeit zum Schlafen bekamen, brauche ich nicht eigens zu erwähnen.
Nach solchen Erfahrungen war ich natürlich froh, als 1961 dem
Rechenzentrum eine größere Maschine zur Verfügung gestellt wurde. Es war dies
die IBM 7070. Sie hatte
bereits die 5-fache Speicherkapazität der IBM 650 (10 k Worte). Als zusätzliches
Speichermedium verfügte der Rechner über leistungsfähige Magnetbandeinheiten. Leider
war die Maschine etwas zu groß (oder zu teuer), so dass wir sie nicht gleich
voll auslasten konnten. Sie wurde daher bei einem Kunden installiert, der
Thyssen AG, wo wir sie mitbenutzen konnten. Da diese Firma sich gerade ein
neues Hochhaus in bester Lage (am Stadtpark) errichtet hatte, zog meine Gruppe
zur Maschine ins Thyssen-Hochhaus.
Es hat den Beinamen Dreischeibenhaus. Die
Maschine stand im Erdgeschoss, unsere Büros lagen in der vierten Etage.
Thyssen-Hochhaus (Foto Wikipedia)
Was die Programmierung der IBM
7070 anbetraf, so mussten wir fast alles neu lernen. Die wichtigsten Sprachen
waren Autocoder, Commercial Translator und COBOL. Autocoder war der Name
eines Macro-Assemblers der IBM, Commercial Translator (oder COMTRAN) war IBM’s Vorläufer
von COBOL. Mit dem COBOL
Compiler für die IBM 7070, der 1962 verfügbar wurde, war zum ersten Mal ein Software-Werkzeug
vorhanden, das viele Nutzer ansprach. Es entstand alsbald ein intensiver
Gedankenaustausch zwischen allen kommerziellen Großkunden der IBM, wie Allianz,
Bayer, Neckermann und Thyssen. Während meines späteren USA-Aufenthalt lernte
ich einige Entwickler dieser frühen Produkte näher kennen, so Florence Pessin, Roy
Goldfinger und Dick Talmadge.
Der Fortran-Markt
entstand parallel dazu und war wesentlich kleiner. Nutzer aus einigen
technisch-ausgerichteten Firmen oder von Forschungseinrichtungen begleiteten
wir nach Paris. Dort befand sich damals eine IBM 704, der zu seiner Zeit größte
wissenschaftliche Rechner der IBM, der den ersten, von John Backus und
seinen Mitarbeitern entwickelten Fortran Compiler besaß.
So monströs diese Generation
von Maschinen auch wirkte, sie besaß aus Anwendungssicht einen Nachteil, den
wir uns heute kaum noch vorstellen können. Es gab keine Massenspeicher mit
wahlfreiem Zugriff auf einzelne Datensätze. Die Plattenspeicher, die dies
ermöglichten, kamen erst in der darauffolgenden Rechnergeneration voll zum
Einsatz. Eine typische IBM 7070 diente daher mehr als die Hälfte der Zeit als
reine Sortiermaschine. Bei Neckermann in Frankfurt war es vermutlich noch mehr.
Täglich wurden dort alle Bestellungen nach den vorkommenden Artikelnummern
sortiert, dann noch einmal nach Kundennummern. Nur so konnten die Warenentnahme
und der Versand bewerkstelligt werden. Es war dasselbe Verfahren wie zur
Lochkartenzeit, nur wesentlich schneller und sicherer und mit erheblich weniger
Personalaufwand.
Ehe ich die fachlichen Ausführungen beende, noch ein Hinweis auf einige
Erfahrungen eines Rechenzentrumsbetreibers. Für einen Rechner-Hersteller hat
ein Rechenzentrum (RZ) nicht nur die Funktion, Spitzenbelastungen der Anwender
abzufangen. Viel wichtiger ist es, dass potentielle Kunden ihre Anwendungen
entwickeln und testen können, bevor sie selbst einen Rechner installieren. Für
das RZ entsteht ein Dilemma. Wird ein RZ-Kunde profitabel, wird er nicht mehr
lange Kunde sein. Er wird sich ein eigenes RZ zulegen. Bei den heutigen
Kostenrelationen sieht natürlich alles anders aus. Wie jedes Unternehmen so ist
auch ein Rechenzentrum nur zu führen, wenn zwischen mehreren widerstrebenden
Zielen ein Ausgleich geschaffen wird. Einige dieser Ziele sind Profitabilität,
Wettbewerbsfähigkeit, Zuverlässigkeit, Sicherheit, Kunden- und
Mitarbeiterzufriedenheit. Ganz vergessen sind Rechenzentren bis heute nicht.
Sie haben sich virtualisiert und stellen Wolken dar, die auch bei klarem Himmel
vorhanden sind.
Königsallee Stadtgraben (Foto Stadt Düsseldorf)
Düsseldorf
als Stadt hat durchaus einige Reize. Bezogen auf die Zahl ihrer Einwohner hatte
sie 1961 ihr Maximum mit etwa 700.000. Düsseldorf war früher eine Residenz der Herzöge
von Jülich-Berg, dann Sitz des Provinzial-Landtags der preußischen Rheinprovinz,
jetzt ist es Landeshauptstadt von Nordrhein-Westfalen. Noch heute denken
Düsseldorfer gerne an den Kurfürsten Johann Wilhelm (im Volksmund Jan Wellem
genannt) aus dem Hause Wittelsbach, der nach der Zerstörung Heidelbergs 1689
seinen Wohnsitz nach Düsseldorf verlegte.
Da ich Rheinländer bin, hatte ich keine Probleme mich in Düsseldorf
einzuleben. Die gute Stube der Stadt wird von der Königsallee gebildet, liebevoll
,die Kö‘ genannt. Besucher wie Einheimische zieht es in die Altstadt. Die
zünftigen Lokale bieten nicht nur gutes Essen, sondern auch das typische
Düsseldorfer Altbier. Seit den Jahren nach dem zweiten Weltkrieg ist Düsseldorf
Anziehungspunkt für Japaner in Deutschland. Seit 1965 besitzt Düsseldorf eine Universität, die
nach ihrem berühmten Sohn Heinrich Heine benannt ist. Sie ging aus einer
medizinischen Hochschule hervor. Theater und Konzerte, Museen und Galerien,
aber auch das Nachtleben haben mehr als Provinzniveau. Der Karneval konkurriert
mit Köln und Mainz. Holland und seine Badestrände sind nicht weit entfernt.
Persönlich hatte Düsseldorf für mich eine besondere Bedeutung. Ich
lernte hier meine Frau kennen. Kurze Zeit, nachdem wir geheiratet hatten, bot
sich mir die Möglichkeit, nach Nizza auf Abordnung zu gehen. Ich brauchte nicht
sehr lange, um meine frisch angetraute Ehefrau zu überreden, Düsseldorf und dem
Rheinland Adieu zu sagen.
Zusätzliche Referenzen:
- Endres, A.: Professionalität und Verantwortung in der Informatik. Informatik Spektrum 26,4 (2003), 261-2
- Trimble, G.R.: A Brief History of Computing. Memoirs of Living on the Edge. IEEE Annals of the History of Computing 23,3 (July-September 2001), 44-59
- Wolontis-Bell Interpreter. IEEE Annals of the History of Computing 8,1 (January 1986), 74-76
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.