Unkonventionelle Feuerwehrübung

Fortschritt durch Rückschritt

Es war im Jahr 1969 als ich frisch verheiratet glücklich in einem kleinen Dorf mit 100 Einwohnern lebte. Mein Gatte unterrichtete dort als Primarlehrer 15 Schüler in einer Gesamtklasse vom 1. bis 6. Schuljahr. Ich besorgte den Haushalt und spielte nebenbei leidenschaftlich Blockflöte. In diese ländliche Idylle platzte eines Tages der Telefonanruf meines ehemaligen Chefs der IBM Zürich. Telefonieren war damals neben der Briefpost die einzige Kommunikationsmöglichkeit über weitere Distanzen. Er fragte mich geradeheraus, ob ich mir vorstellen könnte in Heimarbeit für die IBM zu programmieren. Da wir noch keine Kinder hatten sagte ich zu, obwohl ich keine Ahnung von der gestellten Aufgabe hatte. Wir vereinbarten einen Termin in Zürich um alles besprechen zu können.

Da wurde mir folgende Ausgangslage geschildert: Wie schon beim Kapitel ‚Im Dialog mit dummen Terminals‚ beschrieben, erstellte ich im Jahr 1968 eine Applikation für die Debitorenbuchhaltung der IBM und zwar mit der Assemblersprache. Mitte 1968 wurde von einem 3-köpfigen Team eine Applikation für die Personalabteilung in Angriff genommen. Allerdings sollte PL1 als Programmiersprache zum Einsatz kommen, da sie als neue Wundersprache angepriesen wurde. Das Erstellen des Programmcodes war relativ leicht und vor allem sehr schnell. Nach kurzer Zeit kam die Dialogapplikation zum Einsatz und die Übergabe an die Personalabteilung wurde gefeiert.

Aber dann kam das bitterböse Erwachen: Die Anwender wollten die ersten Personaldaten via Terminal erfassen. Sie mussten aber jeweils bis zu einer Minute auf eine Antwort warten. So konnte man doch nicht arbeiten! Warum hatten denn die Kollegen der Debitorenbuchhaltung so kurze Antwortszeiten von maximal 10 Sekunden? Der Systemprogrammierer analysierte das Problem und stellte fest, dass die PL1-Module aus viel zu vielen und zu komplexen Abläufen bestehen. Er wusste auch, dass eine höhere Programmiersprache wie z.B. PL1, COBOL, FORTRAN und andere zuerst in Assemblersprache aufgeschlüsselt und dann erst in den Maschinencode umgesetzt wird. Die automatische Aufschlüsselung war natürlich sehr komplex, da jede Eventualität dafür abgedeckt werden musste. Deshalb waren auch so lange Antwortszeiten selbstverständlich. Da gab es nur einen Lösungsweg. Die PL1-Programme mussten von Menschenhand respektive menschlicher Intelligenz in Assembler-Code umgeschrieben werden.

Mein ehemaliger Chef wusste, dass die Buchhaltungs-Applikation von mir sehr modular aufgebaut worden ist. Da lag es auf der Hand, dass ich dieses Umsetzen vornehmen sollte vor allem weil viel Arbeit von zu Hause erledigt werden konnte. Folgendes Vorgehen wurde abgemacht. Ich nahm mal einige PL1-Programmlisten sowie ein Stapel leere Codingsheets für Assembler mit nach Hause. Denn die Eingabe für die Programme erfolgte immer noch per Lochkarten via Tape in das System und das Ergebnis der Umwandlung war eine Programmliste auf Endlospapier und das Lademodule in Lochkarten. Die Möglichkeit der Ein- und Ausgabe über Terminals für die Programmentwicklung kam erst einige Jahre später. Also schrieb ich fleissig die Codingsheets mit meinen Assembleranweisungen voll und sandte diese per Post nach Zürich. Dort wurden sie von einer Locherin in Lochkarten getippt. Der Operator konnte damit eine Umwandlung und die erste Version meines Programms als Liste senden; so konnte ich noch die ersten Fehler korrigieren.

Beispiele für eine Ausgabe von „Hallo Welt“ auf dem Drucker:

Von Zeit zu Zeit fuhr ich mit dem Zug am Samstag nach Zürich, wo ein IBM System 360 stand und ich meine Tests machen durfte. Diese Art Heimarbeit machte mir riesig Spass und ich kam recht schnell voran. Nach nicht allzu langer Zeit konnten auch die Angestellten des Personalbüros mit einer speditiven Dialogapplikation arbeiten.

Fortschritt kann Rückschritt sein, das bedeutet
modernes einfaches Verfahren ist nicht immer besser als Altgedientes.