Aufbau von Betriebssystemen [Reprint 2019 ed.] 9783110843507, 9783110043211

Citation preview

Aufbau von Betriebssystemen von

Paul G. Caspers

Mit 54 Abbildungen

w DE

G Sammlung Göschen Band 7013

Walter de Gruyter Berlin • New York • 1974

Dipl.-lng. Paul G. Caspers ist Mitarbeiter der IBM Deutschland, Entwicklung und Forschung, und Lehrbeauftragter an der Technischen Hochschule Darmstadt

ISBN 3 1 1 0 0 4 3 2 1 1

© Copyright 1974 by Walter de Gruyter Sc Co., vormals G. J. Göschen'sche Verlagshartdlung. J. Guttentag, Verlagsbuchhandlung, Georg Reimer, Karl J. Trübner, Veit& Comp., 1 Berlin 30. Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Ubersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Fotokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Printed in Germany. Sat2 und Druck: Mcrcedes-Druck, 1 Berlin 61 Bindearbeiten: Berliner Buchbinderei Wübben & Co., 1 Berlin 42

Vorwort Betriebssysteme sind heute fester Bestandteil jeder Datenverarbeitungsanlage. Ihre Größe schwankt von ein paar tausend bis zu mehreren Millionen Instruktionen. Entsprechend unterschiedlich ist der Aufbau der einzelnen Systeme. In diesem Band soll nun ihre Struktur unter dem Gesichtspunkt der Implementierung untersucht werden. Dabei werden die theoretischen Grundlagen wie Systemaufbau, Verarbeitungsarten, Datei- und Speicherorganisation, Verteilungsprinzipien für Betriebsmittel, Aufbau von Warteschlangen und dgl. als bekannt vorausgesetzt (siehe z.B. Sammlung Göschen „Neuhold, Grundlagen der Betriebssysteme"). Das Schwergewicht liegt hier darauf, wie sich diese Grundprinzipien mittels bekannter Programmiertechniken wie Listen und Tabellen verwirklichen lassen. Die Beispiele wurden meistens dem Betriebssystem IBM OS/360 nachgebildet. Ihre Aussagen gelten aber nicht nur für dieses System. Dadurch wurde eine geschlossene Darstellung möglich, ohne den Umfang eines Taschenbuches zu sprengen. Dieser Band enthält die wesentlichsten Teile einer Vorlesung, die ich mehrere Jahre lang an der Universität Karlsruhe bzw. der Technischen Hochschule Darmstadt vor Studenten der Informatik gehalten habe. Ausgehend von der Beschreibung einiger spezieller Hardware-Einrichtungen wird die Verarbeitung von Unterbrechungen als Kern der heutigen Betriebssysteme besprochen. Danach wird in erster Linie nach funktionellen Gesichtspunkten der weitere Aufbau untersucht. Dabei beginnen wir mit dem Datenmanagement und der Einund Ausgabesteuerung als weiterem zentralen Teil, der selbst in kleinen Betriebssystemen vorhanden ist. Dies gilt auch für die Ladeprogramme. Den Schluß des Buches bilden Prozeß-, Job- und Systemsteuerung. Das Literaturverzeichnis enthält

4

Vorwort

im allgemeinen nur generelle Hinweise. Weitergehende Literaturstellen sind den Literaturangaben dieser Werke zu entnehmen. Böblingen, im Juni 1973

Paul G. Caspers

Inhalt Vorwort

3

Inhalt

5

Verzeichnis der verwendeten Abkürzungen

7

1. Hardware-Einrichtungen zur Unterstützung der Betriebssysteme 1.1 Die Unterbrechungen 1.2 Das Programmstatuswort 1.3 Generelle Verarbeitungsregeln für Unterbrechungen . . . . 1.4 Der Schutz des Überwachers

9 9 11 12 14

2. Allgemeiner Aufbau der Betriebssysteme 2.1 Die Komponenten eines Betriebssystems 2.2 Die Residenz eines Betriebssystemes 2.3 Die Systemgenerierung 2.4 Konventionen bei der Implementierung 2.5 Die Kommunikation zwischen einzelnen Programmoduln .

15 15 18 21 22 24

3. Die 3.1 3.2 3.3

25 25 29 33

4. Das 4.1 4.2 4.3 4.4

Verarbeitung von Unterbrechungen Der Unterbrechungsverteiler Die Aufgaben der Bedienungsroutinen Implementierungshinweise für die Bedienungsroutinen

Datenmanagement Der Aufbau des Datenmanagements Die Organisation des Trägermediums Der Dateisteuerblock Routinen zur Datenübertragung 4.4.1 Direkte Benutzung eines Kanalprogramms 4.4.2 Übertragen eines Blockes 4.4.3 Bereitstellen eines Satzes 4.5 Routinen für Hilfsfunktionen 4.5.1 Die OPEN-Routine 4.5.2 Die CLOSE-Routine 4.5.3 Die EOV-Routine 4.6 Weitere E/A-Befehle 4.6.1 Deklarative Anweisungen 4.6.2 Imperative Befehle

. .

34 34 36 39 43 43 43 45 48 49 49 52 54 54 54

6

Inhalt

5. Die 5.1 5.2 5.3 5.4 5.5 5.6

Ein-/Ausgabesteuerung Die Start-E/A-Routine Die Prüfroutinen Die E/A-Unterbrechungsroutinen Die Fehlerkorrekturroutinen Die Verwaltung der E/A-Geräte Der Kommunikationsbereich

55 55 58 59 59 62 64

6. Die 6.1 6.2 6.3 6.4 6.5

Prozeßsteuerung Der Prozeßsteuerblock Der Prozeßumschalter Der Aufruf von Programmen Die Speicherplatzverwaltung Die Kommunikation zwischen Prozessen

65 65 66 70 74 78

7. Das 7.1 7.2 7.3 7.4

Laden von Programmen Die Aufgabenstellung Die Ausgabe der Sprachübersetzer Einfache Lader Der Binder

80 80 81 83 83

8. Die 8.1 8.2 8.3

Jobsteuerung Die Ausbaustufen der Jobsteuerung Die Jobsteueranweisungen Der interne Aufbau der Jobsteuerung 8.3.1 Der Eingabe-Leser 8.3.2 Der Prozeßstarter 8.3.3 Der Prozeßbeender 8.3.4 Der Ausgabe-Schreiber

91 91 95 97 97 99 102 102

9. Die Systemsteuerung

103

Literaturverzeichnis

106

Sachregister

108

Verzeichnis der verwendeten Abkürzungen (Die Zahlen in Klammem verweisen auf die Abschnitte, in denen die Abkürzungen zum ersten Mal benutzt werden.)

BM DAK DAKF DCB DEB DEK DEKF DSB E/A EAWS ECB EOB EOF EOFSW EOV ESB ESID EXCP FQE IOB IPL NIP PIOT PQE

Bandmarke (4.2) Dateianfangskennsatz (4.2) Dateianfangskennsatz, Fortsetzung der Datei (4.2) Teil des DSB: data control block (4.3) Teil des DSB: data extent block (4.3) Dateiendekennsatz (4.2) Dateiendekennsatz, Fortsetzung der Datei (4.2) Dateisteuerblock (4.3) Ein-/Ausgabe (4.1) Warteschlange für E/A-Anforderungen (5.1) Teil des DSB: event control block (4.3) Ende des Blockes (end of block) (4.4.3) Ende der Datei (end of file) (4.5.3) Schalter im DSB zur EOV/EOF-Anzeige (4.5) Ende des Stapels (end of volume) (4.5.3) Ereignissteuerblock (6.5) Externe Symbolidentifizierung (7.2) Ausführung des Kanalprogrammes (execute channel program) (4.4.1) Element der Freispeicherliste (free queue element) (6.4) Teil des DSB: input/output block (4.3) Ladevorgang bei Inbetriebnahme des Systems (initial program loading) (2.2) Programm zur Initialisierung des Kerns des Betriebssystems (nucleus initialization program) (2.2) Prozeß-E/A-Tabelle (process input/output table) (8.3.2) Element der Speicheraufteilungsliste (partition queue element) (6.4)

8

PRB PSB PSW SVC TAD TEP TES TVA TXT UCB VF

Verzeichnis der verwendeten Abkürzungen

Steuerblock zur Beschreibung eines Programmoduls (program request block) (6.3) Prozeßsteuerblock (6.1) Programmstatuswort (1.2) Supervisoraufruf (supervisor call) (1.1) Tabelle der Abschnittsdefinitionen (7.2) Tabelle der Eintrittspunkte (7.2) Tabelle der externen Symbole (7.2) Tabelle der zu verschiebenden Adressen (7.2) Text, Programmstück (7.2) Teil des DSB: unit control block (4.3) Verschiebungsfaktor (7.4)

1. Hardware-Einrichtungen zur Unterstützung der Betriebssysteme 1.1 Die Unterbrechungen Damit die Betriebssysteme die ihnen zugedachten Aufgaben der Betriebsmittelverwaltung und der Arbeitsablaufsteuerung der Datenverarbeitungsanlage durchfuhren können, benötigen sie spezielle Funktionen in der Hardware. Die wichtigste ist die „Unterbrechung" (interrupt). Dies ist eine Einrichtung, die es gestattet, den normalen Ablauf eines Prozesses beim Eintreten bestimmter Ereignisse zu unterbrechen und stattdessen einen anderen Prozeß zu starten (Abb. 1.1). Dieser beginnt auf einer fest vorgegebenen Speicherstelle und kann die Anforderungen bedienen, die durch die Unterbrechung gestellt werden. Danach kann der erste Prozeß wieder an der Stelle fortgesetzt werden, an der er unterbrochen wurde.

Laufender Prozeß

Prozeß zur Bedienung der Unterbrechung

Unterbrechung -

Abb. 1.1: Verarbeiten einer Unterbrechung

10

1. Hardware-Einrichtungen zur Unterstützung der Betriebssysteme

Man hat mehrere Klassen von Unterbrechungen entwickelt, die bei verschiedenartigen Ereignissen eintreten. Solche sind z.B. beim IBM-System/360: 1. 2. 3. 4. 5.

Maschinenfehler Programmfehler Supervisoraufruf-Instruktionen Externe Signale Ein-/Ausgabeoperationen

Unterbrechungen der ersten Art werden durchgeführt, wenn ein Fehler in der Hardware der Maschine auftritt (z. B. defekter Schaltkreis, defekte Speicherstelle). Programmfehler zeigen Fehler im Programm an, so daß eine Maschineninstruktion nicht ausgeführt werden kann (z.B. Division durch null, ungültiges Vorzeichen). Die Supervisoraufruf-Instruktion (SVC, Supervisor call instruction) ist eine spezielle Maschineninstruktion, die es dem laufenden Prozeß gestattet, selbst eine Unterbrechung zu erzeugen, um so Dienstleistungen des Überwachers anzufordern. Externe Signale können durch Betätigen des Unterbrecherknopfes an einer Konsole, durch Ablauf eines Zeitgebers oder auch über Datenfernleitungen in das System kommen. Ein-/Ausgabe-Unterbrechungen treten jedesmal auf, wenn eine Ein- oder Ausgabeoperation angestoßen oder beendet wird, um den Prozessor über das Arbeiten des Kanales und des E/A-Gerätes zu benachrichtigen. Dies sind die häufigsten Unterbrechungen. Die Zahl der Klassen hängt von der Hardware ab. Sind es beim IBM-System/360 fünf Klassen, so hat das IBM-System/1800 27 verschiedene. Bei unseren weiteren Betrachtungen wollen wir im wesentlichen das IBM-System/360 als Beispiel wählen. Andere Systeme arbeiten ähnlich. Während der SVC-Befehl vom laufenden Prozeß gegeben wird, geschehen alle anderen Unterbrechungen asynchron zu ihm. Unterbrechungen durch Programmfehler und SVC-Befehl schließen sich gegenseitig aus und können daher nicht gleichzeitig auftreten, wohl aber alle anderen. Deshalb müssen Priori-

1.2 D a s P r o g r a m m s t a t u s w o r t

11

täten vorgegeben werden, in welcher Reihenfolge die Unterbrechungen angezeigt werden sollen, wenn mehrere zur gleichen Zeit auftreten. Eine solche Reihenfolge kann z.B. obige Rangordnung sein. 1.2 Das Programmstatuswort Bei einer Unterbrechung wird die Kontrolle über die Zentraleinheit einem anderen Prozeß übergeben. Bei einem solchen Wechsel zwischen verschiedenen Prozessen wird jedesmal der Zustand der Zentraleinheit verändert. Soll ein durch eine Unterbrechung unterbrochener Prozeß später wieder fortgesetzt werden, so muß erst der Zustand in der Zentraleinheit wiederhergestellt werden, wie er vor der Unterbrechung bestanden hat. Man faßt daher gerne alle Größen, die den Zustand der Zentraleinheit beschreiben, in einem Programmstatuswort (PSW) zusammen. Zu diesen Größen gehören z. B. der Befehlszähler, der Speicherschutzschlüssel (siehe Abschnitt 1.4), Maskierungen für Unterbrechungen (siehe Abschnitt 1.3) und Statusanzeiger wie das Ergebnis einer Vergleichsoperation u. ä. (Abb. 1.2). Für einen laufenden Prozeß steht das PSW in einem internen Register des Prozessors. Tritt eine Unterbrechung ein, so wird es automatisch aus diesem internen Register auf einen definierten Platz des Hauptspeichers abgesetzt und stattdessen ein BitO

7

1115

31 33 35 39

63 Befehlszähler

Maskierungsbits für Kanäle und externe Signale

-Anzeiger für Maschinenzustand - Speicherschutzschlüssel

-Maskierungsbits für Programmfehler - Vergleichsanzeiger - Länge der letzten Maschineninstruktion - C o d e s für Unterbrechungen

A b b . 1.2: P r o g r a m m s t a t u s w o r t des IBM-Systems/360

12

1. Hardware-Einrichtungen zur Unterstützung der Betriebssysteme

Speicherplatz für „alte" PSWs

Unterbrechungsart

Speicherplatz für „ n e u e " PSWs

Abb. 1.3: Austausch der PSWs im IBM-System/360 Dargestellt ist das Eintreten einer SVC-Unterbrechung: 1

Das PSW des lfd. Prozesses wird auf den Platz für alte SVC-PSWs abgespeichert (automatisch)

2

Das PSW für den die Unterbrechung verarbeitenden Prozeß wird von dem Speicherplatz für neue SVC-PSWs in interne Register geladen (automatisch)

3

Nachdem der neue Prozeß die Unterbrechung bedient hat, ladet er mit einer speziellen Instruktion (Load PSW) das PSW des ersten Prozesses vom Speicherplatz für alte SVC-PSWs in das interne Prozessorregister zurück, um den ersten Prozeß wieder fortzusetzen

anderes PSW, das zu dem die Unterbrechung bedienenden Prozeß gehört, in das interne Register geladen. Will man später wieder zu dem alten Prozeß zurückkehren, muß das zu diesem Prozeß gehörige PSW mittels spezieller Instruktionen (z. B. „Load PSW") vom laufenden Prozeß wieder geladen werden (Abb. 1.3). 1.3 Generelle Verarbeitungsregeln für Unterbrechungen Um eine Unterbrechung verarbeiten zu können, muß zunächst verhindert werden, daß eine zweite Unterbrechung zum Minde-

1.3 Generelle Verarbeitungsregeln für Unterbrechungen

13

sten der gleichen Art auftritt, da sonst Information verloren gehen kann. Es gibt daher spezielle Maschineninstruktionen, mit denen man die Möglichkeit, daß Unterbrechungen auftreten können, an- und abschalten kann. Dies bezeichnet man auch als „maskieren". Der jeweilige Zustand wird fiir die einzelnen Unterbrechungsarten in den Maskierungsbits des PSW festgehalten (Abb. 1.2). Wenn eine Unterbrechung aufgetreten ist, maskiert man weitere Unterbrechungen so lange, bis die Information der ersten

Abb. 1.4: Prinzipieller Aufbau einer Unterbrechungsroutine

14

1. Hardware-Einrichtungen zur Unterstützung der Betriebssysteme

Unterbrechung sichergestellt ist (Abb. 1.4). Tritt während dieser Zeit ein anderes Ereignis ein, das eine zweite Unterbrechung bewirkt hätte, so wird diese von der Hardware so lange zurückgehalten, bis das Durchkommen der Unterbrechungen wieder eingeschaltet wird. Nachdem die Information über die zweite Unterbrechung auf die gleiche Weise sichergestellt ist, kann fortgefahren werden, die Unterbrechung zu verarbeiten, die von den beiden die höhere Priorität hat. Um die Leistungsfähigkeit des Systems nicht herabzusetzen, muß das Maskieren von Unterbrechungen so kurz wie eben möglich gehalten werden. 1.4 Schutz des Überwachers Da die Unterbrechungen eine zentrale Rolle im Betriebssystem spielen, müssen die Routinen, die sie bearbeiten, besonders geschützt werden, damit sie nicht absichtlich oder unabsichtlich von den Benutzerprogrammen verändert oder zerstört werden. Sie sind Teil des „Überwachers" (auch „Supervisor" genannt), der den Kern eines Betriebssystems "bildet. Um einen Schutz gewährleisten zu können, hat man Speicherschutzvorrichtungen entwickelt. Diese Einrichtung beruht darauf, daß man den Hauptspeicher in Blöcke einteilt und diesen Schlüssel zuordnet. Instruktionen können nur solche Zellen ansprechen, die in Blöcken liegen, die den gleichen Schlüssel haben wie der Block, zu dem die Instruktion selbst gehört. Andernfalls kann der Versuch, Zellen in einem Block mit anderem Schlüssel anzusprechen, z. B. durch eine Unterbrechung angezeigt werden. Der Speicherschutzschlüssel ist ebenfalls im PSW enthalten. Prozesse können nun dadurch vor gegenseitiger Beeinflussung geschützt werden, daß ihre Programme in Speicherbereiche geladen werden, denen man verschiedene Schlüssel gegeben hat. Für den Überwacher ist ein bestimmter Speicherschutzschlüssel reserviert, der sich dadurch vor den anderen auszeichnet, daß er einen Zugriff zum ganzen Hauptspeicher ohne

2.1 Die Komponenten eines Betriebssystems

15

Rücksicht auf die den anderen Bereichen zugeordneten Schlüssel erlaubt, selbst aber gegen einen solchen Zugriff geschützt ist. Damit der Supervisor nun die Kontrolle über das System behält, darf z.B. nur er die Speicherschutzschlüssel vergeben. Man hat daher spezielle Zustände geschaffen, die sich dadurch unterscheiden, daß in dem einen, dem Problemprogrammstatus, gewisse privilegierte Instruktionen nicht gegeben werden dürfen. Hierzu gehören z.B. Instruktionen, die einen Wechsel des Zustandes bewirken, die die Speicherschutzvorrichtung setzen, die E/A-Operationen ausführen u.ä. Diese Instruktionen dürfen nur gegeben werden, wenn sich das System in dem anderen Zustand, dem Supervisorstatus, befindet, andernfalls wird eine Fehlermeldung erzeugt. Diese beiden Zustände werden wieder im PSW angezeigt. Jede Unterbrechung schaltet das System automatisch vom Problemprogrammstatus in den Supervisorstatus um. Dies geschieht entweder synchron zum Problemprogrammablauf durch eine SVC-Instruktion oder asynchron durch das Auftreten einer anderen Unterbrechung. Vom Supervisorstatus kommt man in den Problemprogrammstatus zurück, indem ein entsprechendes PSW geladen wird.

2. Allgemeiner Aufbau der Betriebssysteme 2.1 Die Komponenten eines Betriebssystems Je nachdem, unter welchen Gesichtspunkten man die Aufgliederung der Betriebssysteme vornimmt, kommt man zu verschiedenen Einteilungen. Sind z. B. die Funktionen des Betriebssystem die charakteristischen Größen, so kann man folgende Komponenten unterscheiden: 1. Die Jobsteuerung (job management): sie überwacht den Ablauf der Jobs. 2. Die Prozeßsteuerung (process management): sie kontrolliert den Ablauf der einzelnen Prozesse.

16

2. Allgemeiner Aufbau der Betriebssysteme

3. Das Datenmanagement (data management): es verwaltet die Datenbestände und übernimmt den Transport der Daten von und zur Zentraleinheit. 4. Die Fehlerbearbeitung (error recovery management): sie versucht die auftretenden Fehler zu beheben. Betrachten wir den Programmaufbau, so teilen wir die Betriebssysteme in: 1. Steuerprogramme und 2. Dienstprogramme ein. Eine weitere verbindliche Unterteilung läßt sich nicht geben, da der Aufbau natürlich von der speziellen Implementierung abhängig ist. Folgende Gliederung möge als Beispiel dienen: 1. Steuerprogramme (control programs): a) Der Überwacher (supervisor) verarbeitet die Unterbrechungen, steuert die Ein- und Ausgabevorgänge, übernimmt Ladefunktionen u.a. Er ist der Kern eines Betriebssystems. b) Die Operator-Kommunikationsroutinen (message interpreter) vermitteln alle Nachrichten zwischen dem System und dem Maschinenbediener. c) Die Daten-Zugriffsroutinen (data access routines) übernehmen den Verkehr zwischen der Zentraleinheit und den peripheren Geräten. d) Die Datenbestandskontrolle (data set control) führt über die im System enthaltenen Dateien Buch. e) Der Jobeinsatzplaner (job scheduler) bereitet die Jobsteueranweisungen für das System auf usw. 2. Dienstprogramme (service programs): a) Die Wartungsprogramme (maintenance programs) werden u. a. für die Erstellung von Programmbibliotheken benötigt.

17

2 . 1 Die K o m p o n e n t e n eines B e t r i e b s s y s t e m s

;

Konsole

Jobeingabe

Externe Speicher

Jobausgabe

Daten

Steueranweisungen

Jobsteuerung EingabeLeser

Ausgabeschreiber

Prozeßstarter

Prozeßbeender

•

Unterbrechungen

J

L

i

Unterbrechungsverteiler

Ir" Operatorkommunikationsroutinen

Speicherplatz Verwaltung^^ Prozeßsteuerung

MaschinenfehlerKorrekturroutinen

ProgrammfehlerKorrekturroutinen SVC

3E

Aufruf von Programmen

p — E/A-Unter? brechungsroutinen/^

V///////A

E/AjSteuerung

> > r^/777 Lader

E/A-FehlerKorrektur-^ routinen

Start-E/A'

1

Verwal-^ tung d e r - ^

'Routinen,

Prozeßumschalter

A b b . 2 . 1 : F u n k t i o n e l l e r Überblick über ein B e t r i e b s s y s t e m HU 2

Datenmanagement

Caspers, Aufbau von Betriebssystemen

2. A l l g e m e i n e r A u f b a u der B e t r i e b s s y s t e m e

18

b) Der Binder (linkage editor) erlaubt, einzelne Programmroutinen zu einem Programm zu verknüpfen. c) Die Vorbereitungsprogramme (initialize disk/ tape) versehen neue Datenträger mit spezifischen Kennsätzen, so daß sie vom System akzeptiert werden können usw. Abb. 2.1 gibt einen funktionellen Überblick über ein Betriebssystem, so wie es in diesem Bande dargestellt wird. 2.2 Die Residenz eines Betriebssystems Die Größe der Betriebssysteme schwankt von ein paar tausend Instruktionen für sehr spezielle Systeme bis zu mehreren Millionen Instruktionen für sehr generelle Systeme. In den meisten Fällen ist es daher aus Kostengründen nicht möglich, das ganze Betriebssystem vollständig im Hauptspeicher zu halten. Hier ist nur Platz für den Kern (nucleus), der in der Hauptsache aus den wichtigsten Routinen des Überwachers und einigen Tabellen besteht. Diese Routinen werden bei Inbetriebnahme des Systems durch den IPL-Vorgang (/nitial .Program Loading in den Speicher geladen und verbleiben dort während des Betriebs (residente Routinen). Der Rest des Betriebssystems, und zwar der weitaus größere Teil, muß auf einen schnellen externen Speicher, z. B. einen Magnetplatten- oder Trommelspeicher, in der sog. Systembibliothek (systems library) abgespeichert werden. Von dort werden solche Routinen, die unverändert laufen können, erst unmittelbar vor ihrer Ausführung in einen reservierten Speicherbereich, den sog. transienten Bereich, geladen. Dieser kann Kern

I tranj Bereich für siente | Steuerblöcke | Bereiche j u n d de'-

I

Bereich für das Betriebssystem

Arbeitsbereiche

Bereich für die Anwendungsprozesse

Abb. 2.2: Aufteilung des Hauptspeichers

2 . 2 Die R e s i d e n z e i n e s B e t r i e b s s y s t e m s

Supervisor Rücksprung

19

? PKT 6 ^

Fortsetzung Unterbrechung des Anwendungsprogramms

•

Supervisor Lade Anwendungsprogr. in AB

Supervisor Rücksprung

• PKT 8 i Beendigung des Anwendungsprogramms

A b b . 2.3: Zyklus eines J o b a b l a u f s AB: Arbeitsbeteich TB: Transienter Bereich

IPL: Initial Program Loading NIP: Nucleus Initialization Program

20

2. A l l g e m e i n e r A u f b a u der B e t r i e b s s y s t e m e

immer wieder benutzt werden, da man eine transiente Routine nach ihrer Ausfuhrung überladen kann. Andere Routinen des Betriebssystems, die zum Ablauf an die Programme eines Prozesses angepaßt werden müssen, z. B. Zugriffsroutinen zu peripheren Geräten, werden zusammen mit diesen Programmen in den Arbeitsbereich des zugehörigen Prozesses geladen. Abb. 2.2 zeigt die Aufteilung des Hauptspeichers. Beim IBM-Betriebssystem DOS/360, einem System mittlerer Größe, umfaßt der Bereich für das Betriebssystem z.B. etwa 6 K Bytes (K = 1024), wenn nur im einfachen Stapelbetrieb gefahren wird. Der Nukleus braucht dann hiervon 4,5 K Bytes, während der transiente Bereich 1,5 K Bytes groß ist. Schließlich gibt es noch Routinen des Betriebssystems, die nur zwischen den Anwendungsprozessen ablaufen, z. B. Routinen RESIDENTER BEREICH

TRANSIENTER BEREICH

ARBEITSBEREICH IPL

PKT 1 PKT 2

Nukleus

NIP

PKT 3

Supervisor

Jobsteuerung

PKT 4

Supervisor

Anwendungsprogramm

PKT 5

Supervisor

Routine A

Anwendungsprogramm

PKT 6

Supervisor

Routine A

A nwendungsprogramm

PKT 7

Supervisor

Routine B

Anwendungsprogramm

PKT 8

Supervisor

Routine B

Anwendungsprogramm

A b b . 2 . 4 : W e c h s e l w e i s e B e n u t z u n g der S p e i c h e r b e r e i c h e P K T 1 , . . . , PKT 8 w e i s e n auf die z u g e h ö r i g e n B l ö c k e i m J o b a b l a u f der A b b . 2 . 2 h i n

2.3 Die Systemgenerierung

21

zur Jobsteuerung. Diese können dann deren Arbeitsbereich benutzen. In Abb. 2.3 ist ein Beispiel für den Zyklus eines Jobablaufs dargestellt. Abb. 2.4 zeigt die zugehörige wechselweise Benutzung der Speicherbereiche. 2.3 Die Systemgenerierung Betriebssysteme, die für eine spezielle Anwendung geschrieben werden, brauchen im allgemeinen nicht mehr modifiziert zu werden. Anders ist es dagegen bei den sehr generellen Systemen, die z.B. die Computer-Hersteller zusammen mit dem Rechner zur Verfügung stellen. Aus wirtschaftlichen Gründen müssen sie an die spezifischen Gegebenheiten einer Installation angepaßt werden. Hierzu gehören nicht nur die vorhandenen Hardware-Einrichtungen, wie das Modell der Zentraleinheit, die Hauptspeichergröße, die eingebauten Zusatzeinrichtungen, die Anzahl und Art der Kanäle, Steuereinheiten und Ein- und Ausgabegeräte, sondern auch die gewünschte Betriebsform, der vorgesehene Betriebsmodus, die mögliche Anzahl paralleler Prozesse, die Größe der Programmbibliotheken, die zu benutzenden Übersetzer usw. Um diese Anpassung zu ermöglichen, wird das Betriebssystem vom Hersteller in einer sehr allgemeinen Form angeliefert, z.B. mit einem kleinen, betriebsfähigen Startersystem und einer Reihe von Assemblierer-Makroinstruktionen. Hiervon gibt es z.B. beim IBM OS/360 über 50Stück. Der Benutzer spezifiziert nun sein gewünschtes System mit solchen definierenden Makroinstruktionen. Damit kann dann mittels des Startersystems das für den Benutzer optimale Betriebssystem generiert werden. Meistens ändern sich im Laufe der Zeit die Anforderungen an das System, z. B. wenn ein neues Ein- oder Ausgabegerät angeschlossen wird. Auch müssen im System enthaltene Fehler behoben werden. Man möchte nun nicht jedesmal das ganze System neu generieren, sondern z.B. nur einzelne Routinen austauschen. Hierzu werden dann häufig spezielle Wartungsprogramme benötigt.

22

2. Allgemeiner Aufbau der Betriebssysteme

2.4 Konventionen bei der Implementierung Da u. U. an der Erstellung eines Betriebssystems sehr viele Programmierer arbeiten, müssen Standards aufgestellt werden, um ein einheitliches System zu erhalten. Zu solchen Konventionen gehören z.B.: — — — — — — — — —

der die das die die die die die die

Aufruf von Unterprogrammen, Benutzung von Registern, Zwischenspeichern von Registern, erlaubten Instruktionsmodifikationen, Größe von Programmsektionen, Verwendung von symbolischen Namen, anzufertigende Dokumentation, Kommentare in den Programmlisten, Form der Nachrichten an den Bediener usw.

Als Beispiel soll nun der Aufruf von Unterprogrammen näher betrachtet werden. Hier muß man sich über die Art und Weise der Parameterübergabe und die Benutzung der Register einigen. So ist beim IBM-System/360 folgender Standard üblich: — Register 15 enthält die Adresse des Ansprungpunktes. Diese kann von Lauf zu Lauf verschieden sein, da Hauptprogramm und Unterprogramm u.U. erst beim Laden zusammengebracht werden und dann nicht sicher ist, daß sie immer die gleiche relative Lage zueinander im Speicher haben. Wie wir noch sehen werden, ist es leichter, eine Adreßkonstante zu ändern, als die Adresse im eigentlichen Sprungbefehl. Deshalb sieht man im Hauptprogramm für den Ansprungspunkt eine Adreßkonstante vor, die man vor dem Sprung in ein Register lädt, so daß der Sprungbefehl selbst nicht zu modifizieren ist. — Register 14 enthält die Rücksprungadresse aus dem Unterprogramm. — Register 13 enthält die Adresse eines Speicherbereiches, in dem die Register zwischengespeichert

2.4 Konventionen bei der Implementierung

23

werden können. Um Speicherplatz zu sparen, ist es zweckmäßig, diesen Zwischenspeicher in den Bereich des aufrufenden Programms zu legen. Da zu einer Zeit jeweils nur ein Unterprogramm gerufen werden kann, kommt man dort mit einem solchen Bereich aus, unabhängig davon, wie oft Unterprogramme aufgerufen werden. — Register 0 und Register 1 können Parameter enthalten, die man an das Unterprogramm übergeben will. Reicht das nicht aus, so enthält Register 1 die Adresse einer Parameterliste. Wie diese aufgebaut ist, ob sie Werte oder Adressen enthält, ist nicht mehr in den Standard miteinbezogen. Programmierer, die höhere Sprachen benutzen, brauchen sich um diese Konvention nicht zu kümmern, da sie in die Übersetzer einzubauen ist. Zur Arbeitserleichterung bei der Benutzung von Assemblierern stellt man Makroinstruktionen zur Verfügung, die bei einem Unterprogrammaufruf das Laden der Register usw. besorgen. Beispiele:

— Aufruf eines Unterprogrammes CALL

SUBR,

(P 1, P 2, P 3 )

Makrobefehl

Name des Unterprogrammes

Parameterliste

— Zwischenspeichern von Registern (im Unterprogramm) SAVE

(RI, R2)

Makrobefehl

Bereich der Register (von — bis), die in den Zwischenspeichern des aufrufenden Programmes zu speichern sind

24

2. Allgemeiner Aufbau der Betriebssysteme

— Rücksprung zum Hauptprogramm RETURN

( R l , RIO)

Makrobefehl

Bereich der Register, die aus dem Zwischenspeicher wieder geladen werden sollen

Die entsprechenden Maschineninstruktionen werden bei der Übersetzung mit in den Code für das Problemprogramm hineingeneriert. Der Aufbau des Zwischenspeicherbereiches für die Register muß natürlich auch genormt sein, wenn Makrobefehle benutzt werden sollen. So besteht er beim IBM-System/360 aus 18 Worten: — Wort 1 enthält Indikatoren u. a. — Wort 2 enthält die Adresse des Zwischenspeichers des Programmes, welches dieses aufrief. Durch diese Kettung läßt sich die Reihenfolge der Unterprogrammaufrufe leicht rückwärts verfolgen, was beim Austesten von großer Bedeutung ist. — Wort 3 bis 18 enthalten die Inhalte der Register 1 3 - 1 5 und 0 - 1 2 . Die Worte 1 und 2 werden vom aufrufenden Programm geladen, die Worte 3—18 vom aufgerufenen. 2.5 Die Kommunikation zwischen einzelnen Programmoduln In einem Betriebssystem muß zwischen den einzelnen Programmoduln sehr viel Information ausgetauscht werden. Dazu bedient man sich standardisierter Übergabestellen (interfaces). Für ihre Ausfuhrung kennt man zwei prinzipiell verschiedene Methoden: 1. Die Kommunikation geschieht über Datenstrukturen, die außerhalb der Moduln liegen. Zu ihnen

3.1 Der Unterbrechungsverteiler

25

zählen Steuerblöcke, Kellerspeicher, Warteschlangen, Tabellen u. dgl. Die einzelnen Moduln können beliebig zu diesen Daten zugreifen und Informationen holen bzw. absetzen. Dazu müssen sie den physikalischen Aufbau und den physikalischen Speicherplatz der Strukturen kennen. 2. Die Kommunikation geschieht direkt von einem Modul zum anderen. Die Information wird innerhalb des Speicherbereiches eines Moduls aufbewahrt und nur auf direkte Anforderung hin an ein anderes abgegeben. Dadurch wird das aufrufende Programm weitgehend unabhängig von der physikalischen Speicherung der betr. Information. Die zweite Methode muß sehr allgemein gestaltet werden. Ihre Implementierung ist daher aufwendig. Beim Betrieb wirkt sich ferner nachteilig aus, daß Information, die von mehreren Moduln benötigt wird, jedem Modul einzeln mitgeteilt werden muß. Bei der ersten Methode dagegen braucht sie nur einmal in der Struktur abgesetzt zu werden und steht dann allen Moduln zur Verfügung. Von Nachteil ist hier aber, daß viele Programme betroffen sind, wenn eine solche Datenstruktur im Laufe der Entwicklung eines Betriebssystems einmal geändert werden muß. Diese Programme sind dann alle nachträglich neu anzupassen. Trotzdem ist die erste Methode heute noch weiter verbreitet. Deshalb soll sie auch unseren folgenden Betrachtungen zugrunde gelegt werden. In der Praxis sind auch Kombinationen beider Methoden verwirklicht worden.

3. Die Verarbeitung von Unterbrechungen 3.1 Der Unterbrechungsverteiler Die Verarbeitung von Unterbrechungen zerfällt in drei voneinander nahezu unabhängige Teile: 1. den Hardware-Mechanismus,

26

3. Die Verarbeitung von Unterbrechungen

2. den Unterbrechungsverteiler (interrupt handler) und 3. die Bedienungsroutinen (service routines). Wenn eine Unterbrechung auftritt, so muß diese analysiert werden. Eine erste grobe Aufteilung wird bereits durch den Hardware-Mechanismus gemacht. Wie wir in Kapitel 1 gesehen haben, unterscheidet man mehrere Klassen von Unterbrechungen. Jede Klasse erlaubt (z.B. durch Austausch von PSWs) eine eigene Routine zur weiteren Bearbeitung aufzusetzen. Um die eigentlichen Bedienungsroutinen anspringen zu können, müssen die Unterbrechungen der einzelnen Klassen weiter aufgegliedert werden, da man im allgemeinen mehrere Unterbrechungsarten in einer Klasse zusammenfaßt. So gibt es bei dem IBM-System/360 z.B. 15 Programmfehler-Unterbrechungen, 256 S VC-Instruktionen und acht verschiedene externe Signale. Die Ein-/Ausgabe-Unterbrechungen müssen sich über die Kanäle und Steuereinheiten bis hin zum verursachenden Gerät verfolgen lassen. Für Maschinenfehler kennt das IBM-System/370 acht Unterklassen, die jede wieder mehrere Arten umfassen. Die Routinen, die diese weitere Aufgliederung vornehmen, faßt man zum Unterbrechungsverteiler zusammen. Die Aufschlüsselung der Unterbrechungen einer Klasse sollte möglichst schnell geschehen. Es muß daher ein Algorithmus gefunden werden, um leicht von der Information, die die Hardware zur Verfügung stellt, auf die zugehörige Bedienungsroutine zu kommen. Da diese Information von Maschinentyp zu Maschinentyp verschieden ist, gibt es keine festen Regeln. Gut benutzen lassen sich Indextabellen und Sprungtabellen. Die S VC-Instruktionen sind z.B. beim IBM-System/360 von 0 bis 255 durchnumeriert. Damit läßt sich leicht eine Indextabelle aufbauen. Wenn diese aus 256 gleichen Elementen besteht, braucht die SVC-Nummer nur mit der Länge eines Elementes multipliziert zu werden, um als Index direkt auf den zugehörigen Tabellenplatz zu verweisen (Abb. 3.1). Dort könnten die Hauptspeicheradresse der Bedienungsroutine oder,

3.1 Der Unterbrechungsverteiler

27

Indextabelle

L: L ä n g e e i n e s Indexelemenles

Abb. 3.1: Aufsuchen der SVC-Routinen mittels Indextabellen

falls sie nicht resident ist, die Adresse in der Bibliothek und ähnliche Angaben stehen. Bei den Ein-/Ausgabeunterbrechungen muß das verursachende Gerät bzw. der zugehörige Steuerblock (siehe Kapitel 4 und 5) gefunden werden. Hier haben wir u. U. drei Parameter, die Adresse des Kanals, die der Steuereinheit und die des Gerätes. Da die Kombinationsmöglichkeiten sehr groß sind, muß man tl. über drei Indexstufen gehen (Abb. 3.2). ies verbraucht viel Speicherplatz. Um das zu vermeiden, kann ...an z.B. eine lineare Tabelle aufbauen und diese sequentiell durchsuchen (Abb. 3.3). Das wiederum kostet Rechenzeit, so daß man die Vor- und Nachteile beider Möglichkeiten gegeneinander abwägen muß. Wie in Abschnitt 1.3 bereits ausgeführt wurde, muß Information über die Unterbrechung sichergestellt werden, ehe man neue Unterbrechungen erlauben kann. Dies muß gleich zu

28

3. Die Verarbeitung von Unterbrechungen Adresse der Steuereinheit

Kanalindex

Index der Steuereinheit

Geräteindex

Abb. 3.2: Aufsuchen des E/A-Steuerblocks mittels Indextabellen Beginn der Verarbeitung geschehen, noch ehe die Aufgliederung innerhalb der Klasse erfolgt. Hier schon brauchen die Unterbrechungen nicht mehr maskiert zu sein.

PSwl

|AK|AS|AG|

" V zum Steuerblock

sequentielles Durchsuchen

AK-AS-AG Adresse des Steuerblockes

Abb. 3.3: Aufsuchen des E/A-Steuerblocks mittels linearer Tabellen (Bezeichnungen siehe Abb. 3.2)

3.2 Die Aufgaben der Bedienungsroutinen

29

3.2 Die Aufgaben der Bedienungsroutinen Die Bedienungsroutinen leisten die eigentliche Arbeit, die durch die Unterbrechung angefordert wurde. Dies kann z.B. sein: — Meldung an einen wartenden Prozeß — Aufruf einer Fehlerkorrektur-Routine — Aufruf eines Benutzer-Unterprogramms — Starten von wartenden Anforderungen — Ausführen von verlangten Dienstleistungen usw. Was im einzelnen zu machen ist, hängt von der jeweiligen Implementierung ab. Folgende Ausfuhrungen können daher nur als Beispiel dienen (Abb. 3.4): 1. Maschinenfehler: Hier muß die Bearbeitung eng mit der Hardware abgestimmt sein. Zur Behebung eines Fehlers hat man im Prinzip zwei Möglichkeiten: — Wiederholung einer Operation (retry) oder — Neukonfiguration (reconfiguration). Im ersten Fall kann man versuchen, die Operation, bei der der Fehler eingetreten ist, zu wiederholen. Falls es sich um einen Fehler handelt, der nur gelegentlich auftritt, kann die Wiederholung erfolgreich sein, und es ist nun möglich, den unterbrochenen Prozeß unbeschadet fortzusetzen. Neukonfiguration läßt sich benutzen, wenn von mehrfach vorhandenen Teilen eines ausfällt. Dieses kann stillgelegt und der Rechner dann mit verminderter Leistung weiterbetrieben werden. Als Beispiel sei eine schadhafte Stelle im Hauptspeicher genannt. Hier ist nur der zugehörige Speicherblock abzuschalten. Der unterbrochene Prozeß muß im allgemeinen neu gestartet werden, es sei denn, man arbeitet mit virtuellem Speicher. Um dem Wartungstechniker Anhaltspunkte für seine Arbeit zu geben, sollte man jeden aufgetretenen Fehler, auch wenn er sich durch Wiederholung beseitigen ließ, in einer speziellen

3. D i e Verarbeitung v o n U n t e r b r e c h u n g e n

30

( S 2 fMaschinen-\/ Programm.fehler )\ fehler )

*

Verbieten weiterer Unterbrechungen

*

+

Verbieten weiterer Unterbrechungen

1

Unter \ brechung J

L (Ein /Ausgab^ ^Externe U.) Verbieten weiterer Unterbrechungen

t

Speichere Speichere notwendige notwendige Information Information

Speichere notwendige Information

Erlau neue Unterbrechungen

Erlaube neue Unterbrechungen

*

(

SVC

)

F

Verbieten weiterer Unterbrechungen

•

Speichere notwendige Information

•

Erlaube neue Unterbrechungen

A b b . 3.4: Die Verarbeitung v o n Unterbrechungen Fortsetzung bei -

e i n f a c h e m s e q u e n t i e l l e n Betrieb: u n t e r b r o c h e n e r P r o z e ß Mehrprogrammbetrieb: Prozeßumschalter (siehe Abschnitt 6.2)

3.2 Die Aufgaben der Bedienungsroutinen

31

Datei registrieren. Die dort abgespeicherten Daten können dem Techniker wertvolle Hinweise sein und erhöhen somit indirekt die Zuverlässigkeit und Verfügbarkeit des Rechners. 2. Programmfehler: Diese Fehler beruhen auf falscher Spezifikation oder ungeeignetem Gebrauch von — Instruktionen und - Daten. Zur ersten Gruppe gehören Fehler wie falscher Operationscode, ungültige Adressierung, Verstoß gegen den Speicherschutz u. ä., zur zweiten ungültige Daten, Feldüberlauf, Division durch null usw. Da diese Fehler vom Programmierer verursacht worden sind, kann das Betriebssystem von sich aus nichts zur Behebung tun. Bei der ersten Gruppe muß im allgemeinen der Prozeß abgebrochen und das Programm vom Programmierer korrigiert werden. Für Fehler der zweiten Gruppe lassen sich in vielen Fällen Routinen im jeweiligen Anwendungsprogramm vorsehen, die diese beheben. So kann z.B. ein ungültiges Vorzeichen berichtigt werden u. ä. Das Betriebssystem sollte es daher dem Benutzer erlauben, Unterprogramme zur Verfügung zu stellen, die beim Auftreten eines Programmfehlers angesprungen werden und ihn bearbeiten können. 3. Externe Signale: Diese gehen z. B. von — Zeitgebern oder von - Unterbrecherknöpfen aus. Wurde die Unterbrechung durch den Zeitgeber hervorgerufen, so muß der anfordernde Prozeß bestimmt werden. Dieser muß eine individuelle Bedienungsroutine enthalten, an die vom Unterbrechungsverteiler die Kontrolle weitergegeben wird. Dabei ist es gleichgültig, ob der anfordernde Prozeß zum System selbst gehört oder ein Benutzerprogramm ist. Wurde die Unterbrechung durch Betätigung eines Unterbrechungsknopfes verursacht, so möchte ein Operator einen Befehl

32

3. Die Verarbeitung von Unterbrechungen

an das System geben. Es müssen daher die Operator-Kommunikationsroutinen angesprungen werden, die das Kommando annehmen, analysieren und die verlangte Aktion einleiten. 4. Ein- und Ausgabe-Unterbrechungen: Ihre Bedienung wird in Kapitel 5 ausführlich behandelt werden. 5. SVC-Instruktionen: Mit ihnen werden Dienstleistungen des Systems sowohl von Benutzerprogrammen als auch von anderen Teilen des Systems angefordert. Das kann z.B. sein: — Starten und Beenden eines Prozesses — Ausfuhren eines Kanalprogramms — Warten auf ein Ereignis — Signalisieren eines Ereignisses — Laden eines Programmes, einer Phase, oder einer transienten Routine — Beenden eines Jobs — Anforderung und Freigabe von Speicherplatz — Übermittlung einer Nachricht an den Operator — Schreiben eines Prüfpunktes — Setzen und Testen des Zeitgebers. Die Vielfalt der Aufgaben ist sehr groß. So hat das IBM DOS /360 etwa 45 verschiedene SVC-Instruktionen; beim IBM OS /360 sind es über 100 Stück. Weitere kann der Benutzer selbst schreiben. Ein Teil der Bedienungsroutinen muß resident sein, z.B. die Routine zum Starten eines Kanalprogramms und das Ladeprogramm für die transienten Routinen. Diese ließen sich sonst nicht in den Hauptspeicher bringen. Der größere Teil der Bedienungsroutinen kann jedoch transient gehalten werden. Dabei ist darauf zu achten, daß nicht eine transiente Routine während ihres Ablaufs eine zweite transiente Routine aufruft. Dann kommt man nicht mehr mit einem transienten Bereich aus, sondern braucht zwei oder mehr.

3.3 Implementierungshinweise für die Bedienungsroutinen

33

з.3 Implementierungshinweise für die Bedienungsroutinen Die Anforderungen an die Implementierung hängen vom Betriebsmodus ab. Beim rein sequentiellen Betrieb, wie es der einfache Stapelbetrieb ist, können während des Ablaufs der Bedienungsroutinen alle Unterbrechungen oder zumindest die der gleichen Klasse unterdrückt werden. Die Routinen müssen dann so geschrieben sein, daß sie seriell wiederbenutzbar sind. Von Vorteil ist dabei die relativ einfache Codierung, von Nachteil die Sperrzeit für neue Unterbrechungen. Dadurch können и. U. zeitabhängige Geräte nicht oder nur mit Einschränkungen bedient werden. Anders ist es beim Mehrprogrammbetrieb. Hier muß das Maskieren der Unterbrechungen so kurz wie möglich gehalten werden. Nur während der Behandlung der Maschinenfehler sind alle weiteren Unterbrechungen zu verbieten, da sonst während ihres Bearbeitens neue Maschinenfehler auftreten könnten. Bei den anderen Routinen genügt es, neue Unterbrechungen so lange zu sperren, bis die zugehörige Information sichergestellt ist. Das verlangt, daß die Routinen dann entweder reentrant geschrieben sind, oder daß bei seriell wiederbenutzbaren Routinen Warteschlangen angelegt werden. Der benötigte Codieraufwand ist im Einzelfall gegeneinander abzuwägen. Hat man sich für Warteschlangen entschieden, so gibt es für deren Abarbeitung zwei Möglichkeiten: 1. Sie erhalten die gleiche Priorität wie der Supervisor, d. h. sie werden vorrangig bearbeitet. Dies hat den Vorteil der einfachen Steuerung, jedoch blockiert eine Bedienungsroutine, die einen Prozeß niederer Priorität bedient, das System und damit andere Prozesse, die eine höhere Priorität haben. 2. Die Bedienungsroutine erhält die gleiche Priorität wie der anfordernde Prozeß. Dadurch werden obige Nachteile vermieden, doch ist der Programmieraufwand gerößer, da die SVC-Routine als selbständiger Prozeß in die Schlange der anderen Prozesse eingereiht werden muß. 3 Caspers, Aufbau von Betriebssystemen

34

4. Das Datenmanagement

Sind die Bedienungsroutinen sehr kurz, lohnt sich oft der Aufwand für Warteschlangen nicht, da die Verlustzeiten zu groß werden. Derartige Routinen schreibt man seriell wiederbenutzbar und sperrt während ihres ganzen Ablaufs neue Unterbrechungen. Sie können allerdings selbst auch keine neuen Unterbrechungen z. B. durch SVC-Instruktionen erzeugen. Noch schärfere Anforderungen als der Mehrprogrammbetrieb stellt der Echtzeitbetrieb. Dort dürfen nur ganz kurze Programmstücke maskiert laufen.

4. Das Datenmanagement 4.1 Der Aufbau des Datenmanagements Wie schon der Name „Datenverarbeitungsanlage" sagt, ist es ihre Aufgabe, Daten zu verarbeiten. Diese müssen als Eingabeinformation in den Rechner eingelesen, dort gespeichert und ausgewertet und schließlich als Ausgabeinformation wieder ausgeschrieben werden. Der Verkehr mit den Daten und ihre Verwaltung ist also ein Hauptproblem bei der Anwendung von Rechenanlagen. Da jeder Benutzer hiervon betroffen ist, hat man schon Mitte der fünfziger Jahre die ersten Standardprogramme entwickelt, die Vorläufer der heutigen Datenverwaltungssysteme sind. Moderne Datenmanagementsysteme übernehmen folgende Aufgaben: — Durchführung und Steuerung von Datenübertragungen — Sicherung und Verwaltung von Datenträgern und Dateien — Zuordnung von E/A-Geräten zu Programmen — Verknüpfung von Programmen und Daten. Um dies lösen zu können, müssen nicht nur die eigentlichen Datenübertragungsoperationen, sondern auch die Organisationsmethoden für die Daten und die Zugriffsmöglichkeiten zu

35

4.1 Der Aufbau des Datenmanagements

ihnen mit in das Betriebssystem einbezogen werden. Beides soll im Rahmen dieses Bandes nicht erörtert werden. Es sei dazu auf die entsprechende Literatur verwiesen, in der Organisationen wie sequentielle, index-sequentielle, gestreut gespeicherte usw. beschrieben sind. Wir wollen hier nur die Grundvorgänge der Ein- und Ausgabe (abgekürzt: E/A) untersuchen. Aus diesen lassen sich die Operationen für die verschiedenen Organisationsformen zusammensetzen. In der Praxis hat es sich als zweckmäßig erwiesen, den Komplex der Datenübertragung selbst noch weiter aufzugliedern. Da ist einmal die Ein-jAusgabesteuerung, die immer Teil des Supervisors ist und die physikalische Ausführung der Ein- und Ausgabeoperationen überwacht („physikalische E/A-Routinen"). Sie wird in Kapitel 5 näher betrachtet. Daneben gibt es Routinen, die die Verbindung zwischen dem Problemprogramm und der E/A-Steuerung herstellen und o f t als „logische E/A-Routinen" bezeichnet werden. Mit ihnen wollen wir uns in diesem Kapitel beschäftigen. Die logischen E/A-Routinen können im Speicherbereich des Problemprogramms liegen, aber auch Teil des Supervisors sein. Was zweckmäßiger ist, hängt vom System ab. Haben wir ein solches, an das lauter gleichartige E/A-Geräte, z. B. Magnetbandeinheiten, angeschlossen sind, wird man die Routinen in den Supervisor integrieren. In den Arbeitsbereich des Problemprogramms werden sie dagegen zwecks Speicherplatzersparnis

Betriebssystem Systembereich

Programm 1 Programm 2 Programm 3 Arbeitsbereich

Bereich für gemeinsam benutzbare E/A- und andere Routinen

Abb. 4.1: Die Aufteilung des Hauptspeichers bei einem System mit Mehrprogrammbetrieb

36

4. Das Datenmanagement

dann aufgenommen, wenn viele verschiedenartige E/A-Geräte unterstützt werden. Beim Mehrprogrammbetrieb kann es günstig sein, die Routinen von mehr als einem Prozeß benutzen zu lassen. Dann muß man ihnen einen eigenen Bereich im Hauptspeicher zuordnen (Abb. 4.1). Sie müssen wieder entweder reentrant geschrieben sein oder über Warteschlangen angesprungen werden. Für unsere Betrachtungen soll der Ort der Speicherung nicht weiter berücksichtigt werden, da er ohne Einfluß auf den logischen Ablauf ist.

4.2 Die Organisation des Trägermediums Als Stapel (volume) wird die Datenmenge bezeichnet, die physikalisch auf einmal mit dem Trägermedium in ein E/A-Gerät geladen werden kann. Dies ist bei Magnetbandeinheiten eine Bandrolle, bei Magnetplattenspeichern ein Plattenstapel usw. Eine Datei fällt nun nicht immer mit der Datenmenge eines Stapels zusammen. Sie kann sich über mehrere Stapel erstrekken, ein Stapel kann aber auch mehrere Dateien aufnehmen. Um Zuordnung zwischen Dateien und dem Stapel machen zu können, muß jeder Stapel außer den eigentlichen Dateien noch Daten enthalten, die seine Organisation beschreiben. Man unterscheidet zwei Arten solcher „Kennsätze" (auch „Etikette" genannt), die natürlich innerhalb eines Betriebssystems genormt sein müssen. a) Stapelkennsatz

(volume label):

Der Stapelkennsatz ist meist an einer festen Stelle untergebracht (z. B. bei Magnetplatten auf Zylinder 0, Spur 0; bei Magnetbändern als erster Block). Er dient zu seiner Identifizierung und enthält Angaben wie — Nummer oder Name des Stapels — Name des Besitzers — Adresse des Stapelinhaltsverzeichnisses (bei Speichern mit direktem Zugriff)

4.2 Die Organisation des Trägermediums

37

— Beschreibung des Stapels (z.B. Anzahl der Zylinder und Spuren) — Anzahl und Adresse der noch verfügbaren Ersatzspuren (bei Speichern mit direktem Zugriff) — u.a. b) Dateikennsatz (file label): Mit diesen Kennsätzen wird jede Datei im einzelnen beschrieben. Dazu dienen Angaben wie — Name der Datei — Organisationsform der Datei (z. B. sequentiell, direkt) — Block- und Satzformat (z. B. fest, variabel) — Block- und Satzlänge — Schutzangaben — Erstellungsdatum — Aufbewahrungsfrist oder -datum — Trägerfolgenummer (wenn sich die Datei über mehrere Stapel erstreckt) — Ordnungsnummer (wenn sich mehrere Dateien auf einem Stapel befinden) — Lage der Datei bzw. ihrer Teile (extents) auf einem Stapel mit direktem Zugriff — Anzahl der Blöcke der Datei — u. ä. Bei Trägermedien, die nur eine sequentielle Speicherung gestatten (z. B. Magnetband), sind die Dateikennsätze unmittelbar bei der Datei abgespeichert. Dabei stehen die beschreibenden Angaben vor der Datei, Prüfinformation wie Anzahl der Blöcke, hinter der Datei. Man unterscheidet daher Anfangsund Endkennsätze. Erstreckt sich eine Datei über mehrere Stapel, so muß jeder für sich durch ein Paar Kennsätze abgeschlossen sein, da sonst keine Sicherheitsprüfungen durchgeführt werden können. Diese Kennsätze sind besonders zu kennzeichnen (Abb. 4.2).

38

4. Das Datenmanagement Eine Datei auf einer B a n d r o l l e : | SK |BM|DAK|BM|

Daten

[32222 ¡32!

M e h r e r e D a t e i e n a u f einer B a n d r o l l e : | SK |BM|DAKl|BMjDatenl[BM|DEKl^M|DAK2|BM|Daten2|BM}DEK2}BM|Bl^\ Eine D a t e i auf m e h r e r e n R o l l e n : Daten

| B M | D E K F 1|BM|BM| }

| SK | B M ] D A K F l|BM|

Daten (Forts.)

|BM]DEKF 2|BM|BMj /

| SK | B M | D A K F 2 | B M |

Daten (Forts.)

|BM| D E K

| SK |BM| DAK

|BM|

|BM|BMj\

Abb. 4.2: Beziehung zwischen Dateien und ihrer Speicherung auf Magnetband SK: Stapelkennsatz DAK: Dateianfangskennsatz DEK: Dateiendekennsatz D A K F : Dateianfangskennsatz mit Kennzeichnung, daß Datei hier fortgesetzt wird DEKF: Dateiendekennsatz mit Kennzeichnung, daß Datei auf einer anderen Bandrolle fortgesetzt wird BM: Bandmarke

Bei Speichern mit direktem Zugriff (z. B. Magnetplatten) faßt man die Dateikennsätze aller Dateien des Stapels in einem besonderen Bereich zusammen, dem Stapelinhaltsverzeichnis (volume table of contents) (Abb. 4.3). Die Kennsätze braucht man beim Verknüpfen der Dateien mit den Programmen. Dabei können Parameter für die Verarbeitung (z.B. Organisationsform, Blocklänge), für Sicherheitsprüfungen (z.B. Aufbewahrungsfrist) entnommen werden. Daneben ermöglichen die Kennsätze aber auch, daß eine vollständige Datenbestandsverwaltung vom Betriebssystem her gemacht wird. Hierzu gehört einmal die Vergabe von Platz auf den Datenträgern an die Dateien (der Benutzer spezifiziert nur die ungefähre Anzahl der Sätze seiner Datei und deren Länge), zum anderen kann der Bediener vom System informiert werden, wann welcher Stapel zu montieren ist. (Der Benutzer gebraucht in seinem Programm nur den Namen der Datei,

4.3 Der Dateisteuerblock Satz 1

39

Satz 2

Abb. 4.3: Speicherung einer Datei auf einem Plattenspeicher SK: DK: SIV: AB:

Stapelkennsatz Dateikennsatz Stapelinhaltsverzeichnis Speicherabschnitt der Datei 1

nicht die Nummer des Stapels). Diese zuletzt genannten Dienstleistungen sind allerdings bis jetzt nur bei großen Systemen realisiert worden. 4.3 Der Dateisteuerblock In einem Anwendungsprogramm werden im allgemeinen mehrere E/A-Befehle für die gleiche Datei gegeben. Auch werden häufig mehrere gleiche Geräte benutzt. Deshalb ist es zweckmäßig, die zugehörigen E/A-Routinen nur einmal als geschlossenes Unterprogramm aufzunehmen. Beim Aufruf werden die für diesen Aufruf typischen Parameter dem Unterprogramm in einer Liste, dem Dateisteuerblock DSB (data control block), übergeben. Folgende Information kann im DSB enthalten sein:

— Grundinformation: Dateiname

40

4. Das Datenmanagement

Dateiorganisation (sequentiell, index-sequentiell,...) Dateizustand (geöffnet, geschlossen, . . .) Satzformat und -länge Angaben zur Pufferung (Adresse der Puffer, Größe der Puffer, Adresse des Arbeitsbereiches, . . .) Adresse des Kanalprogrammes bzw. das Kanalprogramm selbst Angaben über den Kanalzustand (beschäftigt, fertig, . . .) Kennsatzinformation (Aufbewahrungsfrist, . . .) Anzahl Plattenbereiche, (Anfangs-, Endadresse, . . . ) Kanal- und Geräteadresse Gerätename und -typ Geräteparameter (Bitdichte, Code, . . .) Datenträgerkennzeichnung Verweisung auf Fehler- und Dateiendebehandlung.

— Organisationsabhängige Information: Als Beispiel möge dienen: a) sequentielle Organisation: Blockungsfaktor Satzzeiger innerhalb des Blocks b) direkte Organisation: Schlüssellänge Position des Schlüssels im Satz Suchbereich Die obigen Angaben stellen nur eine Auswahl aus den vorhandenen Möglichkeiten dar. Bedingt durch die verschiedenartigen E/A-Geräte und die unterschiedlichen Organisationsformen ist die Vielfalt sehr groß. Der Platz für den DSB liegt im allgemeinen im Arbeitsbereich des Problemprogramms und kann von diesem oder vom Betriebssystem bereitgestellt werden. Da der DSB jeweils den aktuellen Zustand der Datei beschreibt, ändern sich Eintragungen während des Betriebs. Die Anfangseintragungen werden gemacht

4.3 Der Dateisteuerblock

41

a) zur Übersetzungszeit (aus deklarativen Anweisungen des Programms) b) wenn der Job in das System geladen wird (aus Jobsteuerangaben (siehe Kapitel 8) c) zur Ausführungszeit aus Dateikennsatz (wenn Datei eröffnet wird). Je mehr Eintragungen zur Lade- und Objektzeit erlaubt sind, desto unabhängiger ist das Programm von speziellen E/AGeräten und Dateien, desto flexibler muß aber auch der DSB sein. Dadurch kann man gezwungen werden, ihn in mehrere Unterblöcke aufzuteilen. Das wurde z.B. beim IBM OS/360 gemacht, wo man zu folgenden sechs Teilen kam (Abb. 4.4): 1. Der DCB (data control block) enthält die Grundinformation wie Dateiname, Organisationsform, Satzformat, Angaben über Puffer usw. Er wird vom Problemprogramm erstellt. 2. Der IOB (Input/output block) enthält alle Informationen, die der Supervisor braucht, um eine E/A-Operation einzuleiten, z. B. Adresse des Kanalprogramms, Anzahl der Plattenspeicherbereiche, Blockzähler u. a. Er wird von den logischen E/ARoutinen, in Sonderfällen vom Problemprogramm, erstellt. 3. Das Kanalprogramm wird ebenfalls nur in Sonderfällen vom Benutzer, gewöhnlich jedoch vom System bereitgestellt. 4. Der DEB (data extent block) enthält alle Angaben über die Plattenbereiche (z. B. Anfangs- und Endadresse, Zahl der belegten Spuren). Er wird beim Eröffnen der Datei erstellt und liegt im Systembereich. 5. Der UCB (unit control block) enthält alle Angaben über die E/A-Einheit (z.B. Kanal- und Geräteadresse, Gerätetyp). Er wird bei der Systemgenerierung erstellt und liegt ebenfalls im Systembereich.

42

4. Das Datenmanagement

6. Der ECB (event control block) enthält Schalter, die über den Stand der E/A-Operation Auskunft geben (z. B. Operation beendet, Befehl gegeben u. ä.). Er wird teils vom Problemprogramm, teils von logischen E/A-Routinen erstellt. Alle diese Blöcke sind miteinander verkettet. IOB

ECB

Abb. 4.4: E/A-Steuerblöcke des IBM OS/360 Bezeichnungen siehe Text A (x): Adresse von x

4.4 Routinen zur Datenübertragung

43

4.4 Routinen zur Datenübertragung 4.4.1 Direkte Benutzung eines Kanalprogramms Dies ist die Programmierstufe, die dem Benutzer am wenigsten Unterstützung bietet. Sie wird im allgemeinen nur in Ausnahmefällen benutzt. Der Programmierer selbst muß nämlich das Kanalprogramm bereitstellen, das Ende des E/A-Vorganges abtesten und auf Fehler prüfen. Das Betriebssystem stellt nur Instruktionen zur Verfügung, die die Verbindung zur E/ASteuerung des Supervisors herstellen. Zweckmäßigerweise greift man auch hier auf den Dateisteuerblock zurück, da, wie wir noch sehen werden, die höheren E/A-Routinen ebenfalls diese Befehle in Anspruch nehmen. Es werden folgende Instruktionen benötigt: - Start des Kanalprogramms (EXCP: execute Channel program) (Abb. 4.5). - Synchronisation zwischen Problem- und Kanalprogramm (WAIT). Hiermit wird dem Betriebssystem mitgeteilt, daß das Problemprogramm nicht fortgesetzt werden kann, bis das Ende der E/AOperation erreicht ist. - Prüfung auf fehlerfreien Ablauf der E/A-Operation (CHECK). 4.4.2 Übertragen eines Blockes Ein Block ist die Datenmenge, die durch eine einzige physikalische E/A-Operation von oder zum E/A-Gerät transportiert wird. Ein solcher Block wird nun jeweüs durch einen Befehl dieser Programmierstufe (READ/WRITE) übertragen. Zum Unterschied zur vorhergehenden Stufe braucht der Benutzer das Kanalprogramm nicht mehr selbst zu schreiben, sondern es wird durch das Betriebssystem bereitgestellt. Aus den Makroinstruktionen wird im Problemprogramm ein Sprung in ein Unterprogramm generiert, das die logische E/ARoutine bildet. Abb. 4.6 zeigt ihr Ablaufdiagramm. Aus ihm

44

4. Das Datenmanagement

Abb. 4.5: Ablauf einer EXCP-Instruktion

ist ersichtlich, daß im Verlauf der READ/WRITE-Routine ein EXCP-Befehl gegeben wird. Man greift also auf die Programme der niederen Stufe zurück. Der Benutzer muß selbst auf das Ende der E/A-Operation und auf Fehler testen. Dazu kann er wieder die Befehle WAIT und CHECK verwenden. Auch das überlappte Arbeiten von Zentraleinheit und Kanälen ist selbst zu programmieren. Der Gebrauch von Unterprogrammen erlaubt gewisse Freizügigkeiten bei der Benutzung der E/A-Geräte. So kann man z. B. von den physikalischen Geräteadressen unabhängig werden und selbst Geräte verschiedenen Typs, aber der gleichen Klasse

4.4 Routinen zur Datenübertragung

45

Abb. 4.6: READ/WRITE-Routine

(für sequentielle Verarbeitung, für direkten Zugriff) gegeneinander austauschen, ohne die Befehle im Problemprogramm direkt ändern zu müssen. 4.4.3 Bereitstellen

eines Satzes

Ein Block enthält gewöhnlich zum effektiveren Arbeiten mehrere gleichartige Sätze (records), in denen logisch zusammengehörige Datenfelder vereinigt sind. Die Befehle dieser Stufe (GET/PUT) holen die einzelnen Sätze aus dem Block heraus bzw. speichern sie in ihn ein und stoßen bei Bedarf eine E/AOperation an. Aus diesen Makroinstruktionen wird im Problemprogramm wieder ein Sprung in die logischen E/A-Routinen generiert.

46

4. Das Datenmanagement

Abb. 4.7: GET-Routine für das Arbeiten ohne Überlappung EOB: Ende des Blockes (end of block)

Da die E/A-Übertragung jetzt vollständig vom System überwacht wird, ist es möglich, daß auch das überlappte Arbeiten von Zentraleinheit und E/A-Geräten von ihm gesteuert wird. Es gibt verschiedene Verfahrensstufen.

4.4 Routinen zur Datenübertragung

47

Abb. 4.8: GET-Routine für das Arbeiten mit einem Arbeitsbereich RECAD: Feld im DSB, das die Adresse des Satzes im Eingabebereich enthält EOBAD: Feld im DSB, das die Adresse des Endes des Blockes enthält BUFAD: Feld im DSB, das die Adresse des Eingabebereiches enthält BLKL: Länge des Blockes LRECL: Länge des Satzes

a) Arbeiten ohne jegliche Puffer: Hier ist natürlich keine Überlappung möglich. Die Sätze können unmittelbar im E/A-Bereich verarbeitet werden. Dazu hinterläßt die GET/PUT-Routine die Anfangsadresse des Satzes z . B . in einem Register (Abb. 4.7).

48

4. Das Datenmanagement

b) Benutzen eines Arbeitsbereiches: Die Sätze werden nicht mehr im E/A-Bereich verarbeitet, sondern in einen Arbeitsbereich, der gerade einen Satz aufnehmen kann, übertragen. Dadurch läßt sich die Verarbeitung des letzten (bei Ausgabe: des ersten) Satzes eines Blockes mit der Ein-/ Ausgabe eines Blockes überlappen. Abb. 4.8 stellt das Blockdiagramm einer entsprechenden GET-Routine dar. c) Arbeiten mit Puffern: Wird ein zusätzlicher Bereich benutzt, der einen ganzen Block fassen kann, so läßt sich die Verarbeitungszeit für einen ganzen Block mit der E/A-Zeit für einen Block überlappen. In einem Bereich werden die Sätze verarbeitet, während zur gleichen Zeit der andere Puffer gefüllt bzw. geleert wird. Man braucht sich nun nicht auf zwei Puffer zu beschränken, sondern kann auch drei und mehr benutzen. Das bringt allerdings nur Vorteile, wenn die Verarbeitungszeit für die einzelnen Sätze sehr unterschiedlich ist. Da gleichzeitig mehrere E/AOperationen laufen können, müssen mehrere Kanalprogramme vorhanden sein. Der DSB ist entsprechend zu erweitern. So kann man, wie schon in Abb. 4.4 dargestellt, diesen Teil als IOB-Block abtrennen und diese Blöcke dann zu einem Ring verketten. Im DCB ist die Adresse des gerade aktuellen IOBs enthalten. Diese muß von der EOB-Routine weitergeschaltet werden. Um in den richtigen Zyklus zu kommen, sind zu Beginn der Arbeit einige Puffer zu füllen. Dies besorgt die sog. OPEN-Routine (siehe Abschnitt 4.5). 4.5 Routinen für Hilfsfunktionen Wie wir bereits im letzten Abschnitt gesehen haben, sind vorbereitende Arbeiten durchzuführen, ehe der eigentliche Verarbeitungszyklus begonnen werden kann. Ähnliches gilt für das Ende. Man braucht daher spezielle Routinen, die diese Hilfsfunktionen ausführen: OPEN zur Eröffnung einer Datei vor der ersten E/A-Operation

4.5 Routinen fiir Hilfsfunktionen

49

CLOSE zum Abschließen einer Datei nach der letzten E/A-Operation EOV (end-of-volume) beim Erreichen des Endes eines Datenträgers. 4.5.1 Die OPEN-Routine Die OPEN-Routine übernimmt folgende Aufgaben: — Sie stellt sicher, daß die richtigen Stapel montiert sind, indem sie die Dateikennsätze prüft und, bei Ausgabedateien, neue schreibt. — Sie ergänzt den DSB mit Informationen aus den Parametern des OPEN-Befehls, den zugehörigen Jobsteueranweisungen und dem Dateikennsatz (bei Eingabedateien). — Sie ladet die erforderlichen logischen E/A-Routinen (wenn sie nicht bereits im Programm vorhanden sind), ordnet gegebenenfalls Puffer zu und füllt diese. Diese Arbeiten sind komplex und sehr von der Implementierung abhängig. Deshalb sollen sie hier nicht in Einzelheiten besprochen werden. Als Beispiel zeigen die Abbildungen zu diesen und den beiden folgenden Abschnitten Routinen für die Behandlung von Dateien auf Magnetband. Diese Routinen können sowohl bei Eingabe- als auch bei Ausgabedateien angesprungen werden. Dabei ist im wesentlichen nur die Kennsatzverarbeitung vereinfacht dargestellt. Abb. 4.9 gibt eine OPENRoutine wieder. 4.5.2 Die

CLOSE-Routine

Von der CLOSE-Routine werden folgende Aufgaben angeführt: — Sie leert gegebenenfalls die Puffer und gibt sie und die logischen E/A-Routinen frei (wenn sie nicht fest im Programm enthalten sind). — Sie stellt im DSB den Anfangszustand wieder her. 4 Caspers, Aufbau von Betriebssystemen

50

4. Das Datenmanagement

BM

^datei

Abb. 4.9: OPEN-Routine für Dateien auf Magnetband EOFSW: Schalter im DSB; an: EOF aus: EOV Anfangsbedingung: an DAK(F): wenn EOFSW an: DAK aus: DAKF

4.5 Routinen für Hilfsfunktionen

Abb. 4.10: CLOSE-Routine für Dateien auf Magnetband (DEK, DEKF: siehe Abb. 4.2)

4. Das Datenmanagement

52

— Sie ergänzt die Dateikennsätze und schreibt neue Ende-Kennsätze (bei Ausgabedaten auf Magnetband). - Sie disponiert über die Stapel, wobei sie nicht nur Anweisungen an den Bediener gibt, sondern z. B. Magnetbänder auch richtig positioniert. Abb. 4.10 zeigt eine CLOSE-Routine.

4.5.3 Die EOV-Routine Diese Routine dient dazu, die Verarbeitung einer Datei, die aus mehreren Stapeln besteht, zu ermöglichen. Sie wird angesprungen, wenn beim Lesen oder Schreiben eine Bedingung für das Ende der Datei (EOF) oder des Datenträgers (EOV) erkannt wird. Dies ist z. B. bei Magnetband eine Bandmarke oder Reflektormarke. Dann muß im Problemprogramm bei Eingabedateien ein EOV-Befehl, bei Ausgabedateien ein FEOVBefehl (force end-of-volume) gegeben werden. Bei Benutzung der READ/WRITE-Befehle hat der Programmierer diese Instruktionen zu geben, während sie in den GET/PUT-Routinen bereits enthalten sind. Dazu sind die GET-Routinen der Abb. 4.7 und 4.8 an der Stelle A durch die in Abb. 4.11 dargestellten Funktionen zu erweitem. Abb. 4.12 zeigt dann eine EOV-Routine.

Abb. 4.11: Erweiterung der GET-Routine Einfügen am Punkt

der Abb. 4.8 und 4.9

Das Lesen der Bandmarke BM ist Bedingung für EOF oder EOV

4.5 Routinen für Hilfsfunktionen

(RETURN) Abb. 4 . 1 2 : EOV-Routine

53

54

4. Das Datenmanagement

4.6 Weitere E/A-Befehle 4.6.1 Deklarative

Anweisungen

Zur Erstellung des DSB werden deklarative Anweisungen benötigt, die die logischen Größen der Datei beschreiben. Dies kann z.B. in Form von Schlüsselwort-Makroinstruktionen im Problemprogramm geschehen. Als Parameter sind u. a. zu spezifizieren: Dateiname, Zugriffsmethode mit Organisationsform und Zugriffsart, Datensatzformat (fest, variabel, unbekannt, geblockt, ungeblockt, Druckersatz), Block- und Satzlänge, Länge und Position des Schlüssels, Angaben zur Pufferung, Beschreibung des Gerätes (Typ, symbolische Adresse, Wechseleinheit), programmierungstechnische Anweisungen usw. 4.6.2 Imperative

Befehle

Die in den Abschnitten 4.4 und 4.5 genannten Befehle reichen in der Praxis nicht aus, ein Datenmanagementsystem zu betreiben. Es sind weitere Instruktionen nötig zur — Datenübertragung, um z.B. bei geblockten Sätzen die Bearbeitung eines Blockes vorzeitig abzubrechen (TRUNC, RELSE), einen Ausgabesatz aus einem Eingabebereich zu schreiben (PUTX) oder bei index-sequentieller Organisation der Datei Grenzen für die sequentielle Verarbeitung zu setzen (SETL, ESETL) usw. — Steuerung spezieller Gerätefunktionen wie Ablagefachauswahl und Druckervorschub (CNTRL), Rücksetzen des Magnetbandes um einen Block (BSP), Test auf Seitenende beim Drucker (PRTOV) usw. — Verwaltung von Puffern wie Aufbau und Freigabe von Pufferbereichen (BUILD, GETPOOL, FREEPOOL), Zuteilung von einzelnen Puffern zu einer Datei (GETBUF, FREEBUF) usw. Diese Aufstellung ist keineswegs vollständig.

5.1 Die Start-E/A-Routine

55

Die Befehle und die zugehörigen Routinen sollen hier nicht im Einzelnen betrachtet werden, da ihr Aufbau sehr von der Implementierung des Gesamtsystems, den möglichen Organisationsformen der Dateien und den vorhandenen E/A-Geräten abhängig ist. Um die Zahl der Routinen möglichst klein zu halten, müssen sie so untergliedert werden, daß man dateiund/oder organisationsunabhängige Teile zu Unterprogrammen zusammenfaßt, die sich dann von mehreren Befehlen benutzen lassen. 5. Die Ein-/Ausgabesteuerung 5.1 Die Start-E/A-Routine Wie wir in Kapitel 4 gesehen haben, wird zur physikalischen Ausfuhrung einer E/A-Operation der Supervisor mittels SVCInstruktionen angesprungen. Diese erzeugen zunächst eine Unterbrechung. Der Unterbrechungsverteiler analysiert sie und ruft dann die entsprechende Bedienungsroutine auf (siehe Kapitel 3). Durch den EXCP-Befehl wird so die Start-E/ARoutine angesprungen (Abb. 4.5). Diese versucht, sofort die angeforderte E/A-Operation einzuleiten. Dies ist nicht immer gleich möglich, nämlich dann nicht, wenn das betreffende Gerät und/oder der Kanal mit einer früheren Operation des gleichen oder eines anderen Prozesses noch beschäftigt ist. Um die weitere Verarbeitung nun nicht zu blockieren, muß die Anforderung in eine Warteschlange EAWS eingereiht werden (Abb. 5.1). Die Schalter C und W werden für die Synchronisation benötigt (siehe Abschnitt 5.2). Für die Organisation der EAWS sind nicht nur das Betriebssystem, sondern auch die Gegebenheiten der Hardware maßgebend. Ist ein System z.B. mit Selektorkanälen ausgestattet, so können zwar mehrere Geräte an einen Kanal angeschlossen, doch immer nur jeweils eines bedient werden. Es bietet sich daher an, die Warteschlangen pro Kanal aufzubauen.

56

5. Die Ein-/Ausgabesteuerung

Abb. 5.1: Die Start-E/A-Routine

Da ein Gerät mehrere Dateien enthalten kann, reicht es nicht aus, bei einer Unterbrechung nur das Gerät zu identifizieren, sondern man muß die zugehörige Datei finden. Deshalb verkettet man zweckmäßigerweise die Dateisteuerblöcke miteinander. Man reiht sie allerdings nicht direkt in der EAWS ein, sondern schaltet Anforderungselemente vor, da ja pro Datei (d.h. pro DSB) mehrere E/A-Aufträge gleichzeitig gegeben sein können (Abb. 5.2).

57

5.1 Die Start-E/A-Routine Verar beitungsangaben

Liste der freien Tabellenplätze

Tabelle der Anforderungselemente

DateiSteuerblöcke

Abb. 5.2: Aufbau der Kanalwarteschlangen (gezeigt nur für einen Kanal einschl. Freispeicherliste)

Mit den Anforderungselementen bildet man pro Kanal eine lineare Liste. Das erste Element weist auf den DSB der Datei hin, mit der gerade ein Datenaustausch stattfindet. Das letzte Element gehört zu dem Auftrag, der zuletzt gegeben wurde. Ist die Liste leer, liegt keine Anforderung vor. Ist ein Auftrag fertig bearbeitet, wird das zugehörige Element, das ja als erstes in der Schlange steht, aus dieser entfernt. Das Abarbeiten der Warteschlange braucht nicht immer nach der FIFO-Methode zu geschehen. Man kann auch mit anderen Strategien, z. B. mit Prioritäten arbeiten. Diese können extern zugeordnet (z.B. per Gerät oder gemäß der Priorität des rufenden Programmes), aber auch intern generiert werden (z.B. um minimale Armbewegungen bei Plattenspeichern zu erreichen). Auf diese Strategien soll im Rahmen dieses Bandes nicht näher eingegangen werden.

58

5. Die Ein-/Ausgabesteuerung

Nicht in allen Fällen braucht man die EAWS per Kanal aufzubauen. Unter Umständen kann es günstiger sein, die EAWS per Gerät zu bilden. Dies kann zu einfacheren Routinen führen. Um eine optimale Auslastung des Systems und der E/A-Geräte zu erreichen, kann manchmal ein Gerät an mehrere Kanäle angeschlossen werden. Ist ein Kanal gerade besetzt, dann kann das Gerät über einen anderen bedient werden. Die Anforderungselemente für solche E/A-Einheiten müssen in die EAWS aller zugeordneten Kanäle eingereiht werden. Hat ein Kanal die Ausführung der Operation übernommen, so sind die zugehörigen Anforderungen aus den EAWS aller anderen Kanäle zu entfernen. Anstatt für jeden physikalischen Datenpfad eine EAWS aufzubauen, kann man „logische" Kanäle einrichten, in denen jeweils die relevanten physikalischen Pfade zusammengefaßt sind. Die Anforderungen für ein Gerät sind dann nur wieder in einer EAWS, doch müssen beim Freiwerden eines physikalischen Kanals die zu ihm gehörigen logischen Kanäle nach einem wartenden Auftrag durchsucht werden. Auf die Vor- und Nachteile aller dieser Methoden kann hier nicht näher eingegangen werden. 5.2 Die Synchronisationsroutinen Da Hauptprogramm und E/A-Operation unabhängig voneinander ablaufen, muß Synchronisation zwischen beiden hergestellt werden können. Die dazu notwendigen Befehle (z.B. WAIT) hatten wir in Abschnitt 4.4 kennengelernt. Die Kommunikation kann z. B. über zwei Schalter C und W im ECB geschehen. Beide sind in ihrer Anfangsstellung 0. Der Schalter C wird auf „ 1 " gesetzt, wenn die E/A-Operation beendet ist. Der Schalter W wird angemacht, wenn ein WAIT gegeben wurde und der Prozeß blockiert werden muß, da die E/A-Operation noch nicht fertig abgelaufen ist (Abb. 5.3). Durch die beiden Schalter lassen sich alle auftretenden Möglichkeiten beschreiben.

5.4 Die Fehlerkorrekturroutinen

59

5.3 Die E/A-Unterbrechungsroutinen Die Beendigung einer E/A-Operation wird durch eine Unterbrechung angezeigt. Dadurch werden Routinen angesprungen, die prüfen, ob Fehlerkorrekturen nötig sind, und die eine neue E/A-Operation starten (Abb. 5.4). 5.4 Die Fehlerkorrekturroutinen Treten bei der E/A-Operation Fehler System durch Indikatoren angezeigt. mehrere Indikatoren gesetzt werden: wahre Fehlerursache an, die anderen

auf, so werden diese im Nun können gleichzeitig einer von ihnen gibt die nur sekundäre Effekte.

60

5. Die Ein-/Ausgabesteuerung

Abb. 5.4: Die E/A-Unterbrechungsroutine

Deshalb müssen die Fehlerbedingungen in einer vorgegebenen Reihenfolge geprüft werden. Beim IBM-System/360 ist diese Reihenfolge folgende: 1. Fehler im Kanal 2. Fehler in der Verbindung zwischen Kanal und Steuereinheit

5.4 Die Fehlerkorrekturroutinen

Abb. 5.5: Fehlerkorrekturroutine für Bandlesen WZ: Zähler für einfache Wiederholung SZ: Zähler für Wiederholungen mit mehrfachem Zurücksetzen

61

62

5. Die Ein-/Ausgabesteuerung

3. Fehler bei der Gültigkeitsprüfung im Kanal 4. Fehler an der E/A-Einheit a) Gerätefehler b) Eingriff des Operators ist erforderlich c) Datenfehler d) Kanal wurde überrannt e) Ungültiges Kanalkommando 5. Fehler im Kanalprogramm 6. Speicherschutzfehler 7. Ausnahmebedingung am Gerät 8. Falsche Datenlänge Die Korrekturmöglichkeiten sind sehr mannigfaltig und natürlich von den einzelnen Geräten abhängig. Sie können hier nicht im einzelnen besprochen werden. Abb. 5.5 zeigt als Beispiel eine Routine, die beim Lesen von Magnetbändern angesprungen wird, wenn ein Datenfehler auftritt. Es wird versucht, den Block 100x zu lesen, ehe der Job abgebrochen wird. Da es für den Wartungstechniker sehr wichtig ist, die Störanfälligkeit der Geräte zu kennen, sammelt man gerne dafür interessante Daten wie z.B. die Zahl der Anspränge der Fehlerroutinen, die Anzahl der Störsätze usw. Da die gleichen E/ARoutinen für mehrere Geräteeinheiten benutzt werden, müssen diese statistischen Daten getrennt von den Routinen in einer Tabelle gesammelt werden, deren Elemente (Fehlerblocks) direkt den E/A-Einheiten zugeordnet sind. 5.5 Die Verwaltung der E/A-Geräte Da die E/A-Routinen allgemeingültig gehalten sein müssen, können sie keine aktuellen Geräteadressen enthalten, da diese von Installation zu Installation verschieden sein können. Auch sollen ja mehrere Geräte von einer Routine bedient werden. Deshalb faßt man die „physikalische" Information in einer Tabelle zusammen, deren Elemente die UCBs bilden (siehe Abschnitt 4.3). Jeder Block enthält - Kanal- und Geräteadresse — Typenname (z. B. Magnetband, Kartenleser, Drucker)

5 . 5 Die V e r w a l t u n g der E / A - G e r ä t e

63

— Allgemeine und typenbezogene Attribute (z. B. Bitdichte) — Adresse des zugehörigen Fehlerblocks — Hinweis auf Kanalwarteschlange — Name der Fehlerkorrekturroutine — weitere Arbeitsspalten usw. Um gleichartige Geräte innerhalb eines Systems zur Programmlaufzeit leicht gegeneinander austauschen zu können, hat man „logische" Gerätenamen eingeführt. Diese sind in einem Betriebssystem fest vorgegeben, z . B . TAPE, P R I N T E R (als Name einer Geräteklasse), 2 3 1 1 (als Name eines bestimmten Gerätetypes). Um die Zuordnung zwischen den symbolischen Gerätenamen und den physikalischen Einheiten machen zu können, baut man wieder eine Tabelle (Tabelle der Gerätenamen) auf, die pro logischem Namen einen Eintrag enthält. Dieser verweist auf den zugehörigen Abschnitt der UCBTabelle (Abb. 5.6). Die Tabelle der Gerätenamen wird bei der Systemgenerierung erstellt. Tabelle der Gerätenamen

UCB-Tabelle

A b b . 5 . 6 : Tabellen zur E / A - G e r ä t e v e r w a l t u n g

Fehlerstatistik

64

5. Die Ein-/Ausgabesteuerung

Mittels dieser Tabellen kann nun das Betriebssystem die Verwaltung der E/A-Geräte durchführen. Dazu gehören z. B. die Beantwortung von Existenz- und Belegtanfragen, die Belegung und Freigabe von Geräten, Veränderungen des Gerätevorrates usw. Die Tabelle der Gerätenamen wird z.B. von der Jobsteuerung benützt. Die UCB-Tabelle dient dazu, bei einer Unterbrechung, bei der die physikalische Geräteadresse anfällt, den zugehörigen Dateisteuerblock zu finden, um die richtige Unterbrechungsbehandlung einleiten zu können. 5.6 Der Kommunikationsbereich Da das Betriebssystem und damit auch der Supervisor durch die Systemgenerierung an die individuelle Installation angepaßt wird, stehen alle Tabellen nicht auf festen Plätzen. Um nun leicht Zugriff zu ihnen zu haben, sind ihre Anfangsadressen in einem Kommunikationsbereich (communication vector table) zusammengefaßt. Dieser hat einen festen Aufbau und wird durch die Systemgenerierung nicht verändert. Er ist Teil des Nukleus. Seine Anfangsadresse wird bei dessen Initialisierung auf einen festen Speicherplatz geladen. Außer den Adressen für Tabellen und interne Routinen (z.B. Laderoutine) enthält der Kommunikationsbereich Angaben wie — Anfangsadresse des Problemprogrammbereichs — Höchste Speicheradresse — Tagesdatum — Feld für den Benutzer (zur Weitergabe von Information, die beim Aufsetzen des Jobs für das Problemprogramm bereitgestellt wurde) — Angaben zur Maschinenkonfiguration (z. B. Speicherschutzeinrichtung, Gleitkommaeinrichtung, Kanalumschaltung) — Angaben zur Betriebssystemkonfiguration (z. B. Ausbaustufe, Betriebsmodus, Versionsnummer des Systems).

6.1 Der Prozeßsteuerblock

65

Information aus dem Kommunikationsbereich wird von sehr vielen Routinen des Betriebssystems benutzt. Er ist daher wesentlicher Bestandteil eines solchen. 6. Die Prozeßsteuerung 6.1 Der Prozeßsteuerblock In einem System laufen abwechselnd verschiedene Prozesse ab. Bei einem einfachen sequentiellen Stapelbetrieb sind dies der Supervisor und das Problemprogramm, beim Mehrprogrammbetrieb die Routinen des Betriebssystems und mehrere Anwendungsprogramme. Die Prozesse konkurrieren nun um die Benutzung der Betriebsmittel. Daher muß man über alle Komponenten des Systems (Hardware und Software) Buch fuhren, damit der Supervisor zur Ausführung seiner Dienstleistungen immer genaue Kenntnis des jeweiligen Zustandes des Systems hat. Da die Betriebsmittel von den Prozessen angefordert werden, führt man die Verwaltung auf der Ebene der Prozesse aus. Dazu faßt man die für sie charakteristischen Daten wieder in Listen zusammen, den Prozeßsteuerblöcken (PSB). Der PSB ist Ausgangspunkt für alle Informationen über einen Prozeß. Folgende wichtige Parameter können in ihm enthalten sein: — Der Hauptspeicherbedarf — Die Anfangsadresse des Speicherbereiches — Der Speicherschutzschlüssel — Die geladenen Programme — Der Bedarf an E/A-Geräten — Ein Hinweis auf die Liste der zugehörigen Dateien (Adresse der Liste der DSBs) — Der vorgegebene Zeitbedarf — Die aufgelaufene Rechenzeit — Die Priorität (bei Mehrprogrammbetrieb) — Der Entstehungszeitpunkt (bei Mehrprogrammbetrieb) 5 Caspers, Aufbau von Betriebssystemen

66

6. Die Prozeßsteuerung

— Zwischenspeicherbereiche für Register, PSW und dg!. — Verschiedene Schalter zur Anzeige, z.B. — Prozeß aktiv/inaktiv — Register geladen/zwischengespeichert — u.ä. Diese Daten stehen nun im PSB selbst oder in anderen Steuerblöcken, die an den PSB über ihre Adresse angekettet sind (siehe Abschnitt 6.3 und 6.4). Für jeden Prozeß wird vor seinem Start ein PSB vom Betriebssystem erstellt. Dabei greift es auf Information zurück, die von der Jobsteuerung gegeben wird (siehe Kapitel 8). Einige Parameter werden direkt übernommen (z.B. Priorität, Zeitbedarf), aus anderen werden indirekt Einträge erzeugt (z.B. Adresse des Speicherbereiches, Liste der Dateien). Da die PSBs wesentlich für das Arbeiten des gesamten Systems sind, darf nur der Supervisor Zugriff zu ihnen haben. Sie müssen daher in einem Speicherbereich aufgebaut werden, der den gleichen Speicherschutzschlüssel wie er hat. Dies ist im Bereich für das Betriebssystem der Abschnitt für Steuerblöcke (Abb. 2.1). 6.2 Der Prozeßumschalter (process dispatcher) Der Prozeßumschalter wird beim Mehrprogrammbetrieb notwendig, um die Zeit der Zentraleinheit an die einzelnen Prozesse gemäß ihrer Priorität (internen oder externen Kriterien) zu verteilen. Dazu wird aus ihnen eine Warteschlange gebildet. Elemente der Warteschlange sind die PSBs. Sie sind im allgemeinen nur vorwärts gekettet. Am Kopf der Schlange stehen die Prozesse mit der höchsten Dringlichkeitsstufe, am Ende die mit der niedrigsten. Da zwischen den Prozessen des Betriebssystems und der Problemprogramme kein prinzipieller Unterschied besteht, nimmt man einen Teil von ihnen fest in die Warteschlange mit auf, um eine einheitliche Behandlung zu erreichen (Abb. 6.1). Die Anfangsadresse der Warteschlange

6.2 Der Prozeßumschalter (process dispatcher)

67

Kommunikationsbereich im Supervisor

Priorität

Abb. 6.1: Prozeßwarteschlange (beim IBM OS/360)

wird auf einem festen Speicherplatz im Kommunikationsbereich des Supervisors festgehalten. Auf einem anderen Platz steht die Adresse des PSBs des laufenden Prozesses. Die Prozesse in der Warteschlange können drei Zustände haben: Sie können entweder rechenbereit oder momentan blockiert sein. Bei den rechenbereiten kann man noch unterscheiden, ob sie gerade ausgeführt werden oder warten. Entsprechende Schalter müssen in den PSB aufgenommen werden. Der Prozeßumschalter wird jedesmal angesprungen, wenn der Supervisor eine Unterbrechungsverarbeitung beendet hat

68

6. Die Prozeßsteuerung

(Abb. 3.4). Nur in Sonderfällen wird nämlich das Programm, das unterbrochen wurde, direkt fortgesetzt. Im allgemeinen soll eine Auswahl unter den wartenden Prozessen getroffen werden. Dazu durchsucht der Prozeßumschalter die Prozeßwarteschlange und wählt nach einem vorgegebenen Algorithmus den nächsten rechenbereiten Prozeß aus. Dies kann ein anderer Prozeß als der unterbrochene sein, da durch die Verarbeitung der Unterbrechung ein Prozeß höherer Dringlichkeit rechenbereit geworden sein kann. Abb. 6.2 zeigt ein Blockdiagramm für einen Prozeßumschalter. Für die Auswahl des nächsten Prozesses kennt man prinzipiell zwei verschiedene Strategien: 1. Umschaltung wird durch Ereignisse angestoßen (event driven), 2. Umschaltungen sind zeitlich bedingt (time driven). Bei der ersten Strategie soll die Warteschlange so abgearbeitet werden, daß stets der rechenbereite Prozeß mit der höchsten Priorität Rechenzeit zugeteilt bekommt. Die Warteschlange ist eine lineare Liste, bei der die Prozesse nach geringer werdender Priorität geordnet sind (Abb. 6.1). Bei gleicher Priorität stehen die jüngeren Prozesse hinter den älteren. Bei der zweiten Strategie sollen alle Prozesse gleichmäßig vorangetrieben werden, d.h. die verfügbare Rechenzeit ist gleichmäßig auf die wartenden Prozesse zu verteilen. Dazu teilt man einem rechenbereiten Prozeß eine gewisse Zeit zu. Wenn der Prozeß sich nicht früher blockiert oder beendet, wird nach deren Ablauf zum nächsten rechenbereiten Prozeß umgeschaltet und diesem eine Zeitscheibe zugewiesen usw. (time slicing). Die Warteschlange miiB dabei eine Ringstruktur haben. Ein neuer Prozeß wird in die Warteschlange unmittelbar vor dem laufenden Prozeß eingereiht, so daß alle älteren Prozesse noch einmal bedient werden, ehe der neue zum Zuge kommt (RoundRobin-Methode). Die Vor- und Nachteile der beiden Auswahlstrategien sollen im Rahmen dieses Bandes nicht weiter erörtert werden. Es sei dazu auf die entsprechende Literatur hingewiesen.

6.2 Der Porzeßumschalter (process dispatcher)

^ ja

Lade Register aus PSB zurück

69

-»(RETURN)

I n u r für Systeme mit Prioritäten

(Wartezustande ja

Gehe zum nächstfolgenden Element der Warteschi.

Schalte auf Ring der nächsten Priorität um

nur für Systeme mit kombinierter Auswahlstrategie

J

^frozèb\ n -