Dialog-Programmierung: Der Bildschirm regt zum Spielen an

03.02.1978

Noch vor wenigen Jahren waren sich EDV-Chefs nicht darüber klar, ob ihre als Individualisten bekannten Systemspezialisten die "interaktive" Software-Entwicklung der von niemandem kontrollierbaren "Bleistift-und-Schablonen-Methode" vorziehen würden: Die Akzeptanz der "vertikalen" Programmierung am Bildschirm schien ungewiß. Heute liegt klar auf der Hand: Dialog-Programmierung erhöht die Effektivität und Produktivität der

Software-Erstellung. Räumliche Distanzen müssen nicht mehr überwunden werden, um Testzeit vom RZ-Leiter zu erbitten. Für den Bildschirm ist das Rechenzentrum jederzeit frei. Das kann aber auch Nachteile bringen. Ein Anwender, der hier nicht genannt werden will: "Nicht nur die Effektivität ist gestiegen, mehr noch der Spieltrieb der Programmierer." Die Dialog-Programmierung mit TSO habe in seinem Fall dazu geführt, daß der IBM-Großrechner allein durch diese Anwendung-komplett zu sei . . .

Drei Anwender berichten über ihre Erfahrungen. hö

Rolf Natzke

Geschäftsführer der HDV und Leiter der Organisation Vereins- und Westbank, Hamburg

Im Jahre 1972/73 wurde in unserem Haus bereits ein Remote-Batch-Terminal eingesetzt, mit dem wir die Programmierung an den Großrechner "angebunden" haben. Die

Programme sowie entsprechende Änderungen wurden damals über Lochkarten erfaßt und via Leitung an den Zentralrechner gegeben. Die Umwandlungslisten sowie Testergebnisse

konnten über den Drucker des Remote-Batch-Terminals zur Verfügung gestellt werden. Diese Anwendung konnte man zwar nicht als interaktive Programmierung bezeichnen, aber unser Bestreben ging bereits in diese Richtung. Mit entsprechenden Marktuntersuchungen haben wir dann auch sehr frühzeitig begonnen. Zu dieser Zeit bot sich für IBM-Benutzer jedoch nur TSO an. In unserem Fall aber hätte der Einsatz von TSO eine erhebliche Steigerung der Rechnerleistung erforderlich gemacht. Im Jahre 1976 wurde erstmals ein System (Hard- und Software) für die interaktive Programm-Erstellung angeboten. Nachdem wir uns mit diesem neuen Instrument näher befaßt hatten, sind wir zu dem Schluß gekommen, das Remote-Batch-Terminal durch dieses System abzulösen und die Vorteile einer interaktiven Programmentwicklung zu benutzen. Allerdings gab es zu dieser Zeit

noch nicht die Möglichkeit eines interaktiven Tests, wie TSO es bietet. Im Mai 1977 wurden zwei dieser Rechner zur interaktiven Programmierung installiert mit insgesamt 16 Bildschirmen, an denen etwa 34 Benutzer arbeiteten. Da dieses System von den Programmierern sehr schnell akzeptiert wurde und unsere Mitarbeiter mehr daran arbeiteten, als wir ursprünglich erwarteten, gab es Engpässe im Speicher der Klein-Rechner. Im Herbst 77 wurde auf 20 Plätze erweitert und die Speicherkapazität und die Geschwindigkeit des Rechners erhöht.

Heute sind wir mit zwei Leitungen an den Zentralrechner angeschlossen (IBM 370/158). Unser Ziel ist, in den nächsten zwölf bis 14 Monaten jeden Arbeitsplatz in der Programmierung mit einem Bildschirm auszurüsten: Mit dem Hardware-Hersteller haben wir uns heute dahingehend geeinigt, diese Programmier-Systeme auch TSO-fähig zu machen, so daß die Prozeduren 3780 für das Remote-Batch-Terminal uns 3270 für die TSO-Funktion konkurrierend laufen. Damit hätten wir die elegante Art der Programmentwicklung mit TSO als Dialog-Testsystem parallel zur Verfügung haben und dennoch die Probleme, die TSO bei der Programmentwicklung macht, vermieden.

Martin Steils

Leiter der Programmierung im Rechenzentrum der Firma PERSTA Stahl-Armaturenwerke GmbH KG, Warstein

In unserem Hause ist eine IBM 370/138 mit 512 K, 27 Datensichtgeräten und der erforderlichen Platten- und Bandkapazität installiert. Unser Ziel, die Obliegenheiten der Fachabteilung effizient abzuwickeln, haben wir für die Bereiche Vertrieb, Konstruktion, Buchhaltung und Kalkulation durch Anwendungen im Dialogverkehr bereits verwirklicht. Um auch in der Programmierung einen höheren Wirkungsgrad zu erzielen, haben wir im Frühjahr 1977 direkt nach Vorstellung des Terminal-Online-Programmiersystems ADVOR 790 (TOP) spontan die Installation durchgeführt. Einen Leistungsvergleich mit eventuell zu dieser Zeit vorhandenen Dialog-Programmiersystemen anderer Anbieter haben wir nicht unternommen, denn seit Jahren benutzen wir ein Quellenbibliotheksverwaltungssystem ADVOR 710 (QBV) und haben so durch den Einsatz beider Pakete ein Tandemsystem als Handwerkszeug des Programmierers gefunden, mit dem sich sämtliche Anforderungen, die eine leistungsfähige Programmierabteilung stellt, abdecken lassen. Wir benutzen die Online-Programmierung hauptsächlich für

- Information über aktuelle Programmstände,

- schnelle und sichere Programmerstellung oder Änderung durch Verbindung von Einzelstatements und Programmbauteilen

- Überleitung von Compile/Link/Catal-Läufen zum Rechner

- Überleitung von Testläufen

- Überwachung der Ausführung durch Anzeige der Power-Queues und aller Partitions mit der Anzahl der Start-I/O's auf die peripheren Geräte

- Kontrolle der Ergebnisse durch Anzeige der POWER-LST-Ausgaben und

- Anzeige der Verzeichnisse der Quellenbibliotheken.

Für das Rechenzentrum ist die Anzeige der Partitions mit den ausführenden Phasen, dem Verbrauch von CPU-Sekunden, der Anzahl der Start-I/O's und der durchschnittlichen Patingrate ein oft wichtiges Kontrollinstrument. Für besonders interessant, möglich erst durch diese Anwendung, halten wir die langfristige Lösungsvorstellung zur Steuerung des Maschinenraums: Alle Job-Streams werden in der so verwalteten

Quellenbibliotheks-Verwaltungs-Datei gespeichert und von der Arbeitsvorbereitung

über Bildschirm der Produktion übergeben. Änderungen oder Modifikationen der Jobs lassen sich zu dieser Zeit noch durch Überschreiben am Bildschirm ermöglichen. Damit würden wir dann den letzten Schritt zum karten- und steuerkartenlosen System getan haben.

Insgesamt sehen wir durch den Einsatz des Terminal-Online-Programmiersystems eine größere Effizienz des Programmierers und dadurch für diesen eine erhöhte Motivation.

Daß man noch symbolische Programme in Lochkartenschränken aufbewahrt und zur Änderung oder Listung entnimmt, ist für uns nicht mehr vorstellbar. Außerdem wäre damit kaum Schutz vor Mißbrauch oder Verlust gewährleistet.

Rainer Glomb

Systemprogrammierung und Systementwicklung Rheinisch Bergische Druckerei- und Verlags GmbH Düsseldorf

Unternehmen, die ein TP-System mit viel Komfort für ihre Sachbearbeiter eingesetzt haben, wissen, welchen Vorteil ein gutes System bringen kann. Bei einer effizienten Online-Anwendung kann eine Leistungssteigerung bis zu 50 Prozent erreicht werden. Es stellt sich die Frage, warum kein: Online-System für die Programmierung. Diesem Trend folgend gibt es heute einige Software-Häuser, die entsprechende Programmpakete anbieten. Für uns kam nur die Online-Programmierung in Frage, die folgende Voraussetzungen hatte:

1. Online-Programmierung

2. Online-Programmverwaltung

3. Online-Umwandlung und Test mit Batch-Partition

4. Online-Bibliotheks- und Dokumentationsverwaltung

5. Online-History-Verwaltung aller Programmversionen.

Nach mehreren Tests haben wir ein Produkt gefunden, das unseren Wünschen entsprach. Die Installation war problemlos, das Handling des Terminals war nach kurzer Zeit jedem Programmierer geläufig. Zudem wurde ihnen der Vorteil einer interaktiven Programmierung gegenüber der konventionellen Software-Erstellung klar: Er kann wieder im Open-Shop-Betrieb arbeiten und hatte seinen eigenen Leser sowie Drucker (Terminals) zur Verfügung. Die Verständigungsschwierigkeiten, die bei Testläufen oft zwischen Programmierer und Rechenzentrum entstehen, gibt es nicht mehr. Unsere nächste Entscheidung war, das TP-System auch in der Arbeitsvorbereitung einzusetzen: Die AV überarbeitet Job-Streams und stellt' sie durch "Submit to Batch" der IBM 370/135-Anlage (unter Power/VS) in die Reader-Queue. Weitere Bildschirme im Maschinenraum geben dem Operator jetzt die Möglichkeit, durch einen Befehl den Job-Stream in einer optimalen Priorität oder Partition laufen zu lassen. Ein weiterer Vorteil ergibt sich durch ein Terminal im Rechenzentrum: Da wir keinen speziellen Partition-Balancer einsetzen, kann sich der Operator die I/Os der einzelnen Partitions anzeigen lassen und gegebenenfalls in die Priorität einweisen, um einen optimalen Job-Ablauf zu erreichen. Eine genaue Kostenrechnung dieses Systems ist schwierig: Eine größere Maschinenbelastung - allein schon durch die Systemverwaltung der Terminals und der intensiveren Testläufe - steht die erhöhte. Effektivität der Programmierer gegenüber. Selbst wenn die Kosten heute noch für den einzelnen Anwender zu hoch sind, muß man die Situation in der Zukunft sehen.