Institut für Informatik, Universität Stuttgart.

Auch der vorliegende Beitrag befaßt sich mit dem Programmiersystem, worunter derjenige Teil der zur Hardware gehörigen Ausstattung an Grundprogrammen zu verstehen ist, der - im weitesten Sinne - Benutzeraufträge in eine der Hardware verständliche Form umwandelt. Hier sei auf drei Themen eingegangen, nämlich die, sowohl für Batchjobs, insbesondere aber für interaktiven Betrieb wichtige Texthaltung, den Binder und schließlich auf die "Compilatumgebung", worunter diejenigen Module für Standardaufgaben wie Ein/Ausgabe und Alarmbehandlung zu verstehen sind, die bei der Erstellung lauffähigen Codes vom Binder zu dem vom Compiler eigentlich erzeugten Code hinzugefügt werden.

Texthaltung

- Es sollen vielseitige und leicht handhabbare Funktionen zur Speicherung und zur Manipulation beliebiger Texte, insbesondere für Programme und deren Daten, zur Verfügung stehen (Suchen und Ersetzen von einzelnen Zeichen, Zeilen, Zeichenketten; spalten- und zeilenorientiertes Arbeiten; Korrekturmodi, Umsetzung auf verschiedene Zeichensätze). Diese Funktionen sollen sowohl in einer für batchorientiertes Arbeiten wie in einer für interaktives Arbeiten geeigneten Form (mit gegenseitiger Konsistenz) zur Verfügung stehen.

- Zu einer Urfassung eines Textes sollen Serien von aufeinanderfolgenden Korrektursätzen abgelegt werden können. Es sollen - zum Erstellen verschiedener Textversionen - Korrektursätze nach verschiedenen Regeln zum Urtext hinzugemischt werden können.

- Das Texthaltungssystem muß so konstruiert sein, daß es leicht und schnell und bei Erhaltung seiner vollen Leistungsfähigkeit arg verschiedenste Terminal und Datenstationen angepaßt, werden kann (Zeichenvorrat, Zeichenzahl der Zeilen, Zeilenzahl, Bildschirm oder schreibende Ausgabe, Seitenspeicher im Terminal oder nicht, Funktionstasten etc.).

Binder

- Die Anzahl von Teilcompilaten (beispielsweise Haupt-/Unterprogamme), die der Binder maximal zusammenbinden kann, muß so groß sein, daß der Umfang auch sehr großer Anwenderprogrammpakete hierdurch nicht limitiert ist.

- Es soll etwa möglich sein, daß von zusammenzubindenden Teilcompilaten in einem ersten Bindelauf zuerst n-1 Teilcompilate gebunden werden ("Vormontieren") und dann in einem gesonderten Bindelauf das n-te hinzugebenden wird. Genauso soll es möglich sein, in einem fertiggebundenen Objekt nachträglich eines oder mehrere Teilcompilate gegen andere mit gleichen Schnittstellen auszutauschen ("Modultausch"). Anwendungsbeispiele: Zeitsparendes Auswechseln oder Korrektur von Teilen großer Programmpakete.

- Der Bindelauf soll auch möglich sein, wenn nicht alle Teilcompilate bereitlegen. Für fehlende Teile soll der Binder auf Wunsch Ersatzlösungen vornehmen können wie "Dummy-Teilcompilat verwenden", "Teilcompilat XY aus der Bibliothek einsetzen", "Leerstatement für den Unterprogrammaufruf einsetzen".

- Für große Programmpakete werden auch bei Maschinen mit virtuellem Speicher leistungsfähige Overlay- und Segmentierungstechniken benötigt. Sie sollen sowohl automatisch wirken können wie auch vom Programmierer gesteuert werden können und

- soweit sinnvoll - spracheinheitlich sein.

- Binderlose Maschine: Eigentlich sollte die Maschine so entworfen sein daß die Menge der Teilcompilate bereits lauffähig ist, so daß ein Bindelauf erst gar nicht nötig ist

Compilatumgebung

- Es soll eine bezüglich aller Sprachen einheitliche "Umgebung" für die Compilate existieren: einheitliche Alarmbehandlung, Ein-/Ausgabemoduln, Laufanfags- und endbehandlung Fehlerausgabe beim Lauf, Moduln für interaktiven Verkehr mit laufenden Programmen etc.

- Zur Compilatumgebung gehören auch die Testhilfen. Es gilt - neben der Forderung der Einheitlichkeit für alle Sprachen soweit sinnvoll - alles früher schon zu Testhilfen Gesagte.

- Die Schnittstellen zwischen Compilat und Umgebung sollen nicht nur für alle Sprachen

eines Anlagentyps einheitlich sein, sondern auch gut dokumentiert und dem Rechenzentrum (Systemgruppe) zugänglich sein.

- Insbesondere für Ein-/Ausgabe soll - soweit logisch möglich und sinnvoll - für die Compilate aller Sprachen ein einheitliches Paket verwendet werden, das grafische, formatfreie und formatgebundene Ein-/Ausgabe auf Dateien und direkt von oder zu E/A-Geräten und Terminals ermöglicht.

- Die Schnittstellen zur Alarm- und Fehlerbehandlung bei E/A-Fehlern sollen dem Benutzer auf der Ebene höherer Programmiersprachen zugänglich sein, so daß eine programmierbare Fehlerbehandlung durch den Benutzer selbst möglich ist. Beispiel: Gezieltes Überlesen gestörter Bandblöcke statt dem üblichen Jobabbruch durchs Betriebssystem.

- Das E/A-Paket soll bei E/A-Vorgängen weitgehende Plausibilitätskontrollen der transportierten Daten vornehmen. Die Kontrollen sollen, um die Rechenzeiten bei Produktionsläufen zu verkürzen, gestuft abgeschaltet werden können, und es sollen Optimierungen hinzugefügt werden können.

- Die interne Darstellung aller Daten in der Maschine soll einen internationalen Standardcode und nicht etwa einen firmeneigenen Code verwenden.