Im Dialog mit dummen Terminals

Wie löse ich die Aufgabe, wenn das Terminal als Lochkarte definiert ist?

Man stelle sich folgende Situation vor. Es sollte eine Dialog-Applikation entwickelt werden für die IBM Debitorenbuchhaltung. Das Programm muss auf dem IBM System 360 laufen und als Programmiersprache steht der berühmte Assembler zur Verfügung. Die 4 sogenannt „dummen“ Terminals stehen in einem andern Gebäude als das System und es gibt über das Telefonnetz eine ständige Verbindung, die beim Start des Systems automatisch hergestellt wird. Und nicht zu vergessen, der Programmierer hat fürs Programmieren KEIN Terminal! Die Eingabe des Programms erfolgt – wie bis anhin nicht anders bekannt – über die Lochkarten und die Ausgabe über den Drucker, der jeweils eine Programmliste auf Endlospapier und das Testergebnis auf einem Dumpauszug (bis 100 Seiten gross und ebenfalls auf Endlospapier) ausspuckt.

Diese tolle Aufgabe wurde mir im Jahr 1968 übertragen. Als erstes durfte ich mit meinem Chef und unserem Systemprogrammierer den Swissair Hauptsitz besuchen. Dort wurden gerade die Vorbereitungen für das Installieren des IBM-Flug-Reservations-System PARS gemacht. Ich sah zum ersten Mal in meinem Leben ein Terminal und man demonstrierte mir das Erfassen der Reservation am Bildschirm. Es war kein Dialog, sondern man konnte einfach nur Eingaben machen. Dann konnte man eine Liste über erfolgte Reservationen ansehen. Allerdings beeindruckte mich das ganze gewaltig.

Dumme Terminals sind solche, die eine begrenzte Anzahl von Steuercodes (CR, LF usw.) interpretieren, jedoch keine speziellen Escape-Sequenzen verarbeiten können, also Funktionen wie das Löschen einer Zeile, das Löschen des Bildschirms oder das Steuern der Cursorposition ausführen.

Leider stand damals noch keine Systemkomponente fürs Polling der Display Stations (wie später z.B. mit CICS) zur Verfügung und das Terminal war als Lochkarte definiert. So kam mir die Idee, eine eigene einfache Codierung für Lesen, Schreiben, Vergleichen und Speichern der Felder zu entwickeln.

Nachdem das Aussehen der einzelnen Bildschirmseiten zusammen mit der Buchhaltungsabteilung definiert waren, durften die Input-/Output- Befehle von dem mir zugewiesenen Juniorprogrammierer auf Lochformulare geschrieben werden. Damit das ganze ins System 360 gefüttert werden konnte, musste ich jetzt noch einen Interpreter erstellen. Dabei durfte ich die Hilfe des Systemprogrammierers anfordern. Vor allem mussten wir ein eigenes Polling-System aufbauen. Das tönt viel komplizierter als es in meinem Programm anzusehen war. Es war einfach ein endloser Loop (Schlaufe) in welcher der Lesebefehl für die entsprechende Anzahl Terminals ausgeführt werden musste.
Somit konnte ich in relativ kurzer Zeit (für Analyse, Konzeptaufbau, Entwicklung und Test max. 6 Monate) eine gut funktionierende Dialog-Applikation erstellen.

Es scheint, dass auch der Programmunterhalt recht einfach war, denn die mehr als 100 Module überlebten 3 Systemwechsel. Im Jahre 1993 erhielt ich eine Gratulation zum 25. Geburtstag dieser Applikation mit der Mitteilung, dass sie immer noch läuft und die Buchhaltung noch nicht auf sie verzichten wolle.

Auch Dummheit – wenn’s dann bei Terminals ist –
kann manchmal eine Erleichterung sein.