---------------------------------------------------------------- | SOFTWARE- | Entwicklung nutzereigener | MOS | | DOKUMENTATION | Driver |-----------| |-----------------| Anleitung fuer den | | | 11/87 | Systemprogrammierer | OMOS 2.0 | ---------------------------------------------------------------- Programmtechnische Anleitung fuer den Systemprogrammierer Beschreibung Teil 3 Entwicklung nutzereigener Driver MGS K 1600 VEB Robotron-Vertrieb Berlin Dok.-Nr. C 8063-0437-1M2031 Die vorliegende Software-Dokumentation, Anleitung fuer den Systemprogrammierer, Teil 3: "Entwicklung nutzereigener Driver", entspricht dem Stand von 11/87. Nachdruck, jegliche Vervielfaeltigung oder Auszuege daraus sind unzulaessig. Die Ausarbeitung erfolgte durch ein Kollektiv des VEB Robotron- Vertrieb Berlin. Im Interesse einer staendigen Weiterentwicklung werden alle Leser gebeten, Hinweise zur Verbesserung dem Herausgeber mitzuteilen. Herausgeber: VEB Robotron-Vertrieb Berlin Mohrenstr. 62 Berlin 1086 (C) Kombinat Robotron 1987 Kurzreferat Mit Teil 3 der "Anleitung fuer den Systemprogrammierer" soll der Nutzer des Betriebssystems OMOS 1630 in die Lage versetzt werden, Driver fuer dieses Betriebssystem zu schreiben, auszutesten und in das Betriebssystem einzubinden. Der Teil 3 der "Anleitung fuer den Systemprogrammierer" enthaelt dazu detaillierte Angaben ueber den Aufbau und die Funktionen der Driver. Anhand eines Beispiels (Lochbandstanzer) ist die Programmierung eines Drivers und die zugehoerige Datenbasis, in einem weiteren Kapitel das Austesten und Einbinden des Drivers, dargestellt. Fuer das Verstaendnis der vorliegenden Schrift ist die Kenntnis der Teile 1 und 2 der Anleitung fuer den Systemprogrammierer, der Teile 1 und 3 der Anleitung fuer den Programmierer und der An- leitung fuer den Bediener zu empfehlen. Inhaltsverzeichnis ------------------ Seite 1. Einfuehrung 6 1.1. Stellung der Driver im BS OMOS 1630 6 1.2. Funktionen eines Drivers 6 2. Konzeption der Geraetebedienung im BS OMOS 1630 7 2.1. Struktur eines Drivers 7 2.1.1. Allgemeines 7 2.1.2. E/A-Initiator 7 2.1.3. Geraeteinterruptbehandlung 8 2.1.4. E/A-Abbruch 9 2.1.5. Geraetefehlerabbruch 9 2.1.6. Netzausfallbehandlung 10 2.1.6.1. Allgemeines 10 2.1.6.2. Aufruf bei Netzwiederkehr 10 2.1.6.3. Aufruf bei Systemanlauf 11 2.1.6.4. Aufruf beim Laden eines ladbaren Drivers 11 2.2. Datenbasis des Drivers 11 2.2.1. Allgemeines 11 2.2.2. E/A-Paket 11 2.2.3. Geraetetyp-Steuerblock (DCB) 15 2.2.4. Statussteuerblock (SCB) 19 2.2.5. Geraetesteuerblock (UCB) 23 2.2.6. Initialisierungsblock (CIB) fuer die Anschluss- steuereinheit 30 2.2.7. Geraeteinterruptvektor 31 2.2.8. Tabelle der Eintrittspunkte eines Drivers (DDT) 32 2.2.9. Zusammenhang zwischen DCB, UCB und SCB 32 3. Forderungen des Betriebssystem OMOS 1630 an die Driver 34 3.1. Prioritaetsforderungen 34 3.2. Forderungen an den Quellcode des Drivers und seiner Datenbasis 35 4. Verfuegbare Exekutiveleistungen 37 4.1. Adresspruefung eines Puffers $ACHKB/$ACHCK 37 4.2. Zuteilen eines Hauptspeicherpuffers $ALOCB 37 4.3. Einordnen eines Programms oder eines Programmteils in die Zeit-Warteschlange $CLINS 38 4.4. Freigeben eines Hauptspeicherpuffers $DEACB 40 4.5. Ausgabe von Geraetemitteilungen $DVMSG 40 4.6. Ausloesen des Fork-Prozesses durch $FORK 41 4.7. Ausloesen des Fork-Prozesses durch $FORK1 42 4.8. Bereitstellen eines Bytes vom Nutzerpuffer $GTBYT 43 4.9. Holen eines Wortes vom Nutzerpuffer $GTWRD 43 4.10. Aufrufen des naechsten E/A-Pakets in der Warteschlange $GTPKT 43 4.11. Interruptrettungsroutine $INTSV 44 4.12. Interruptmakro INTSV$ 46 4.13. Abspeichern eines Bytes im Nutzerpuffer $PTBYT 47 4.14. Abspeichern eines Wortes im Nutzerpuffer $PTWRD 47 4.15. Prioritaetsabhaengiges Einordnen in eine Warteschlange $QINSP 47 4.16. Abschliessen der Interruptbehandlung $INTXT 48 4.17. Abschluss einer E/A-Anforderung $IOALT/$IODON 48 4.18. Beendigung einer E/A-Anforderung $IOFIN 49 3 Seite 4.19. Umwandeln einer virtuellen 16-bit-Adresse in eine Bezugsbasis $RELOC 49 4.20. Initialisieren eines Datenkanals einer Anschlusssteuereinheit AIS $IFSSI 50 5. Programmieren und Einbinden eines Drivers 51 5.1. Einleitung 51 5.2. Programmieren der Datenbasis und der Driverquelle 51 5.2.1. Anschlusssteuereinheit 52 5.2.2. Datenbasis 52 5.2.2.1. Erarbeitung einer residenten Datenbasis 52 5.2.2.2. Programmieren der Datenbasis 54 5.2.3. Driverquelle 55 5.2.3.1. Erarbeitung der Driverquelle 55 5.2.3.2. Programmieren der Driverquelle 56 5.2.4. Vorschriften fuer ladbare Datenbasen 59 5.2.5. Behandlung spezieller Nutzerpuffer 59 5.3. Einbinden eines Drivers 61 5.3.1. Generieren eines residenten Drivers 61 5.3.2. Einbinden eines ladbaren Drivers 61 5.3.2.1. Einbinden bei der Systemgenerierung 61 5.3.2.2. Einbinden in ein fertiges System 61 5.4. Laden eines ladbaren Drivers 63 6. Test des Drivers 64 6.1. Einleitung 64 6.2. Testhilfen 64 6.2.1. Exekutiven-Stack- und -Registerauszug 64 6.2.2. Exekutive-Testhilfe XDT 65 6.2.3. Panic-dump-Routine 67 6.2.4. Unterstuetzungsroutine fuer das Abbruchanalyseprogramm CDA 1630 (OMEX) 69 6.3. Fehlersuche 69 7. Korrektur und Wiedereinbinden eines Drivers 75 7.1. Allgemeines 75 7.2. Residente Driver und residente Datenbasen 75 7.3. Ladbare Driver und ladbare Datenbasen 75 Abkuerzungsverzeichnis 77 Sachwortverzeichnis 80 4 Bildverzeichnis --------------- Seite 1: E/A-Paket 12 2: Geraetetypsteuerblock (DCB) 16 3: Statussteuerblock (SCB) 20 4: Geraetesteuerblock (UCB) 23 5: Initialisierungsblock (CIB) 31 6: Klassifizierung der Driver 51 7: Beispiel eines Speicherauszugs bei Systemabbruch 68 8: Aufbau eines Taskkopfes 71 9: Stackaufbau 1 - interne SST-Fehler 72 10: Stackaufbau 2 - unnormale SST-Fehler 73 11: Stackaufbau 3 - nach RTI-Befehl 74 Tabellenverzeichnis ------------------- Seite 1: Standard-Funktionscodes 13 2: Funktionscodes fuer einen Lochbandstanzer 18 3: E/A-Funktionen fuer einen Lochbandstanzer 53 4: Fehlerursachen bei XDT 64 5 1. Einfuehrung -------------- 1.1. Stellung der Driver im BS OMOS 1630 ---------------------------------------- Die peripheren Geraete werden bei dem Mikrorechnergeraetesystem MGS K 1630 ueber Anschlusssteuereinheiten, die bestimmte Inter- faces realisieren, an die Rechner angeschlossen. Fuer die Ansteuerung der einzelnen Interfaces werden vom Be- triebssystem OMOS 1630 Driver benutzt. Diese Driver nehmen in der Hierarchie des E/A-Systems des OMOS 1630 die unterste Ebene ein. Zum Driver gehoeren eine Anzahl von Datenfeldern, Datenbasis des Drivers genannt, die die fuer die Ein-/Ausgabeoperationen wich- tigen Informationen enthalten und der Kommunikation zwischen Driver und Exekutive dienen. Driver und ihre Datenbasen koennen resident oder ladbar sein. Ein residenter Driver und seine Datenbasis sind permanente Be- standteile der Exekutive. Das Arbeiten mit ladbaren Drivern ist eine Generierungsoption. Im Betriebssystem OMOS 1630 werden gewoehnlich alle Driver der im System enthaltenen Geraete als ladbare Driver mit ladbarer Datenbasis aufgebaut. Ladbare Driver koennen mit ihrer Datenbasis bei Bedarf mittels MCR-Kommando (LOAD) geladen und damit dem System verfuegbar ge- macht werden. 1.2. Funktionen eines Drivers ----------------------------- Fuer die Realisierung von E/A-Operationen hat ein Driver folgende Funktionen zu erfuellen: - Einleiten der von der Exekutive geforderten E/A-Operationen - Empfangen und Behandeln von Geraeteinterrupts - Abbrechen von laufenden E/A-Operationen - Reagieren auf Geraetefehler - Reagieren auf Netzausfall 6 2. Konzeption der Geraetebedienung im BS OMOS 1630 -------------------------------------------------- 2.1. Struktur eines Drivers --------------------------- 2.1.1. Allgemeines ------------------ Jeder Driver ist zur Realisierung seiner Funktionen aus fuenf Teilen zusammengesetzt, in die ueber jeweils einen speziellen Eintrittspunkt von der Exekutive her oder ueber einen Geraetein- terrupt eingetreten werden kann. Diese Programmteile heissen entsprechend ihren Funktionen: - E/A-Initiator - E/A-Abbruch - Geraetefehlerabbruch - Netzausfallbehandlung - Geraeteinterruptbehandlung Die Eintrittspunkte der ersten vier genannten Driverteile sind in der Tabelle der Eintrittspunkte eines Drivers (DDT) zusammenge- fasst (siehe Abschnitt 2.2.7.). 2.1.2. E/A-Initiator -------------------- Dieser Driverteil wird von der Exekutive zur Einleitung einer E/A-Funktion aktiviert. Dem Driver werden beim Ansprung folgende Informationen ueber die Register mitgeteilt: - falls die E/A-Warteschlange besetzt ist: R1: Anfangsadresse des E/A-Pakets R4: Anfangsadresse des Statussteuerblocks (SCB) R5: Anfangsadresse des Geraetesteuerblocks (UCB) - falls die E/A-Warteschlange leer ist: R5: Anfangsadresse des Geraetesteuerblocks (UCB) Der Driver ueberprueft anhand seiner Datenbasis, die er mit Hilfe o.g. Registerinformationen erreichen kann, die Sinnfaelligkeit der Parameter der Exekutive-Anweisung und die E/A-Bereitschaft des betreffenden E/A-Geraetes. Die Register der Anschlusssteuer- einheit werden entsprechend der geforderten Uebertragungsfunktion eingestellt und die Uebertragung der ersten Dateneinheit begon- nen. Der Driver wird anschliessend mit einem Befehl RETURN bzw. RTS PC verlassen. Am Anfang des Initiatorteils ist die UBC-Adresse (Inhalt von R5) in einem speziellen Block von Rettungsstellen (pro AS 1) AS- gerecht abzulegen.Dieser Block ist im Driver zu vereinbaren und muss die Anfangsadresse CNTBL haben (siehe dazu Abschnitt 4.12.). 7 Der Driver ist innerhalb seines Initiatorteils voll unterbrechbar (Prioritaet PR0). 2.1.3. Geraeteinterruptbehandlung --------------------------------- Erfolgt nach der Einleitung der E/A-Operation durch den E/A- Initiatorteil oder nach Ausfuehrung einer Uebertragungsoperation vom Geraet aus eine Unterbrechung des laufenden Programms, so wird ueber den Geraeteinterruptvektor (siehe Abschnitt 2.2.6.) der Driverteil Geraeteinterruptbehandlung aktiviert. Unabhaengig von der Ursache des Interrupts erfolgt dessen Bearbeitung durch den Driver unter der Hardwareprioritaet 7 und ist deshalb nicht unterbrechbar. Falls die Bearbeitung des Interrupts laenger als 100 Mikrosekun- den dauert, muss vom Driver dafuer gesorgt werden, dass hoeher- wertige Interruptursachen die Exekutive erreichen. Im Driver muss an dieser Stelle die Interruptrettungsroutine $INTSV gerufen werden. $INTSV ermoeglicht die Verarbeitung hoehe- rer externer Interrupts durch Veraenderung der Hardwarepriori- taet. Ladbare Driver in einem System mit Adresszuweisung duerfen $INTSV nicht direkt rufen. An dieser Stelle muss der INTSV$-Makro ver- wendet werden. Alle anderen Driver koennen entweder den INTSV$-Makro oder den direkten Ruf nach der $INTSV-Routine enthalten (siehe auch Ab- schnitt 4.11.). Die Hardwareprioritaet wird auf die Prioritaet der Interrupt- quelle herabgesetzt (PR4 bis PR6). Die Register R4 und R5 werden dem Driver als frei verfuegbare Register zur Verfuegung gestellt. Ein Driver soll normalerweise keine anderen Register verwenden. Standardmaessig enthalten R4 die SCB- und R5 die UCB-Adresse. Diese Adressen werden auch nach Verlassen der Interruptrettungs- routine ($INTSV oder INTSV$) dem Driver in den genannten Regi- stern zur Verfuegung gestellt. Wenn weitere Register (R0...R3) verwendet werden, muss im Driver selbst fuer die Rettung und die Wiederherstellung der Registerin- halte gesorgt werden. Die durch die Interruptrettungsroutine eingestellte Hardwarepri- oritaet darf nur etwa 500 Mikrosekunden lang aufrecht erhalten werden. Danach muss das Systemunterprogramm $FORK gerufen werden (siehe auch Abschnitt 4.6.). Nach Abarbeitung der $FORK-Routine ist die Hardwareprioritaet Null eingestellt, d.h. der Driver ist nun voll unterbrechbar. Es koennen nun alle Register (R0...R5) beliebig verwendet werden, wobei die vom Driver eingestellten Werte in R4 und R5 gesondert gerettet werden. Die Aufgabe des Geraeteinterrupt-Behandlungsteil des Drivers ist folgende: Der Driver ueberprueft anhand des Geraetestatus die ordnungsge- maesse Ausfuehrung der letzten Uebertragungsoperation und leitet die Uebertragung der naechsten Dateneinheit ein oder beendet nach Uebertragung der letzten Dateneinheit die E/A-Anforderung der Exekutive. Stehen weitere E/A-Anforderungen fuer diesen Driver in der E/A-Warteschlange, so wird der E/A-Initiatorteil des Drivers zur Einleitung der naechsten E/A-Operation erneut gestartet. Ist die Warteschlange leer, wird der Driver mit dem Befehl RETURN oder RTS PC verlassen. 8 Bei fehlerhafter Ausfuehrung der aktuellen Uebertragungsoperation wird eine Fehlermitteilung an die Exekutive uebergeben und je nach Fehlerursache die E/A-Operation beendet oder wiederholt. 2.1.4. E/A-Abbruch ------------------ Bei Ausfuehrung einer Funktion IO.KIL wird der o.g. Driverteil aktiviert. Vom Driver muss der Abbruch von bereits eingeleiteten E/A-Ope- rationen realisiert werden. Zur Ausfuehrung der Abbruchfunktion werden diesem Driverteil beim Beginn die folgenden Informationen in den u.a. Registern ueber- geben: R0: Anfangsadresse des aktuellen E/A-Pakets R1: Anfangsadresse des Tasksteuerblocks (TCB) der aktuellen Task R3: Index (Nummer*2) der Anschlusssteuereinheit R4: Anfangsadresse des Statussteuerblocks (SCB) R5: Anfangsadresse des Geraetesteuerblocks (UCB) In diesem Driverteil wird ein zu vereinbarendes Bit als Abbruch- bit in das Kenndatenwort CW2 des Geraetesteuerblocks (UCB) ein- getragen. Der Driver wird dann mit RETURN bzw. RTS PC verlassen. Das Abbruchbit wird nach Wiedereintritt in den Driver, im Inter- ruptbehandlungsteil bzw. nach Weiterschalten der Geraetewarte- schlange im Driver-Initiatorteil ausgewertet und durch Aufruf des Systemunterprogramms $IODON die laufende bzw. neu zu startende E/A-Operation sofort als beendet erklaert. 2.1.5. Geraetefehlerabbruch --------------------------- Bei der Einleitung der E/A-Operation im E/A-Initiatorteil des Drivers wird ein Time-out-Zaehler, der zur programmtechnischen Zeitueberwachung der E/A-Geraete dient, mit einem bestimmten Wert eingestellt (siehe auch Abschnitt 2.2.4.). Dieser Zaehler wird in bestimmten Zeitintervallen (im Normal- fall jede Sekunde um 1) verringert. Nach jedem Interrupt wird der Zaehler wieder mit seinem Anfangswert eingestellt. Ist der Time-out-Zaehler wegen des Ausbleibens von Geraeteinter- rupts Null geworden, wird der Driver-Geraetefehlerabbruchteil von der Exekutive aus gestartet. Zur Behandlung der Geraetefehlermeldung werden dem Driver folgen- de Informationen in den u.a. Registern uebergeben: R0: E/A-Statuscode (IE.DNR Geraet nicht bereit) R2: Adresse des Geraetestatusregisters R3: Index der Anschlusssteuereinheit R4: Anfangsadresse des Statussteuerblocks (SCB) R5: Anfangsadresse des Geraetesteuerblocks (UCB) 9 Nach Auswerten des aktuellen Geraetestatus wird das betreffende E/A-Geraet als defekt deklariert und der Exekutive eine Fehler- mitteilung uebergeben. Die E/A-Operation kann dann beendet wer- den. Im allgemeinen wird, wenn im Initiatorteil des Drivers ein WAIT- Bit (Warten auf Bereitschaft des E/A-Geraetes) im Kenndatenwort CW2 des Geraetesteuerblocks (UCB) gesetzt worden war, auf die Bereitschaft des Geraetes gewartet. Dabei wird in bestimmten Zeitabstaenden, bis das Geraet wieder bereit ist, eine Fehlermit- teilung auf dem Bediengeraet mit Hilfe des Systemunterprogramms $DVMSG (Aufruf durch CALLR $DVMSG oder JMP $DVMSG, siehe auch Abschnitt 4.4.) ausgegeben. 2.1.6. Netzausfallbehandlung ---------------------------- 2.1.6.1. Allgemeines -------------------- Dieser Driverteil wird von der Exekutive bei folgenden drei Ur- sachen aktiviert: - bei Netzwiederkehr - beim Systemanlauf - beim Laden eines ladbaren Drivers durch das MCR-Kommando LOAD Dem Driver werden von der Exekutive bzw. vom MCR-Kommando LOAD beim Beginn folgende Informationen in den angegebenen Registern uebergeben: R3: Index der Anschlusssteuereinheit R4: Anfangsadresse des Statussteuerblocks (SCB) R5: Anfangsadresse des Geraetesteuerblocks (UCB) 2.1.6.2. Aufruf bei Netzwiederkehr ---------------------------------- Bei Netzausfall gehen die Informationen im Hauptspeicher norma- lerweise verloren, wenn der Speicher nicht Datenerhalt durch Akku-Modul ermoeglicht. Ist der Rechner mit einem solchen Spei- cher ausgeruestet, wird von der Exekutive bei Netzwiederkehr dieser Driverteil aktiviert. Ist die Anschlusssteuereinheit, die der betreffende Driver be- dient, aus Schaltkreisen aufgebaut, die initialisiert werden muessen, um arbeitsfaehig zu sein (U834, U857 u.a.), muss diese Initialisierung bei Netzwiederkehr durchgefuehrt werden, da die Zustaende durch den Netzausfall verloren gegangen sind. Anschliessend wird der Driverteil mit RETURN bzw. RTS PC verlas- sen. 10 2.1.6.3. Aufruf bei Systemanlauf -------------------------------- Beim Systemanlauf muss bei allen Anschlusssteuerungen, die mit zu initialisierenden Schaltkreisen ausgeruestet sind, die Initiali- sierung vorgenommen werden. Deshalb wird jeder Driver bei diesem Eintrittspunkt vom Systemanlaufprogramm gestartet. Nach der Ini- tialisierung der Anschlusssteuereinheit wird der Driver ueber RETURN bzw. RTS PC verlassen. 2.1.6.4. Aufruf beim Laden eines ladbaren Drivers ------------------------------------------------- Ein ladbarer Driver wird, bevor er genutzt werden kann, mit dem MCR-Kommando LOA in den Arbeitsspeicher geladen. Die Initiali- sierung der bedienten Anschlusssteuereinheit kann erst, nachdem der Driver im Arbeitsspeicher steht, vorgenommen werden. Deshalb wird der Driver vom Kommando LOA aus an dieser Stelle aufgeru- fen. Die Initialisierung wird vorgenommen und der Driver ueber RETURN bzw. RTS PC wieder verlassen. 2.2. Datenbasis des Drivers --------------------------- 2.2.1. Allgemeines ------------------ Zur Realisierung seiner E/A-Funktionen und zur Kommunikation mit der Exekutive und anderen Teilen des Steuerprogramms korrespon- diert der Driver mit einer Anzahl von Datenfeldern, die "Daten- basis des Drivers" genannt werden. Diese Datenbasis besteht aus bzw. korrespondiert mit den folgen- den Datenfeldern: - E/A-Paket - Geraetetypsteuerblock (DCB) - Statussteuerblock (SCB) - Geraetesteuerblock (UCB) - Initialisierungsblock (CIB) fuer die Anschlusssteuereinheit - Geraeteinterruptvektor - Tabelle der Eintrittspunkte eines Drivers 2.2.2. E/A-Paket ---------------- Das E/A-Paket wird, nachdem eine Task eine E/A-Anforderung ausge- sendet und die Exekutive eine Reihe von Pruefungen auf die Sinn- faelligkeit der Parameter des Anweisungsparameterblockes (DPB) der betreffenden QIO$-Anweisung ausgefuehrt hat, von der Exekuti- ve als Datenfeld im dynamischen Speicher aufgebaut. Die Exekutive reiht das E/A-Paket in eine geraetespezifische, nach Prioritaeten geordnete E/A-Warteschlange ein. Die Informa- tionen des E/A-Pakets werden von der Exekutive aus den Parametern des DPB aufgebaut. 11 |-------------------------------------------| I.LNK | Verbindung zum naechsten E/A-Paket | 0 |-------------------------------------------| I.PRI | EFN | Prioritaet | 2 I.EFN | | |-------------------------------------------| I.TCB | TCB-Adresse der rufenden Task | 4 |-------------------------------------------| I.LN2 | Adresse des 2. LUT-Wortes | 6 |-------------------------------------------| I.UCB | Adresse des UCB | 10 |-------------------------------------------| I.FCN | Funktionscode | Modifikation | 12 |-------------------------------------------| I.IOSB| Virtuelle Adresse des E/A-Statusblocks | 14 |-------------------------------------------| | | 16 |-------------------------------------------| | | 20 |-------------------------------------------| I.AST | Virtuelle Adresse der AST-Routine | 22 |-------------------------------------------| I.PRM | | 24 | Geraeteparameter | | | 26 | | | | 30 | | | | 32 | | | | 34 | | | | 36 | | | | 40 | | | | 42 |-------------------------------------------| Bild 1 E/A-Paket Erlaeuterungen -------------- I.LNK: ----- Dieses Wort enthaelt die I.LNK-Adresse des naechsten E/A-Pakets in der Warteschlange. Eine Null kennzeichnet das letzte oder einzige E/A-Paket einer Warteschlange. I.EFN: ----- Dieses Byte enthaelt die Ereignisflag-Nummer, die in der QIO$- Anweisung angegeben wurde. 12 I.PRI: ----- Dieses Byte enthaelt die Prioritaet der die E/A-Anforderung aus- sendenden Task (entnommen aus dem Tasksteuerblock der betreffen- den Task). I.TCB: ----- Dieses Wort enthaelt die Anfangsadresse des Tasksteuerblocks der rufenden Task. I.LN2: ----- Dieses Wort enthaelt die Adresse des jeweils zweiten Wortes der LUN-Zuordnung des Geraetes in der Tabelle der logischen Geraete- nummern (LUT) im Taskkopf der rufenden Task (vergleiche: Anlei- tung fuer den Programmierer, Teil 3: "E/A-System") Fuer dateistrukturierte Geraete enthaelt dieses Wort fuer den schnelleren Zugriff zu eroeffneten Dateien die Adresse des jewei- ligen Fensterblocks (siehe auch Anleitung fuer den Programmierer, Teil 4). I.UCB: ----- Dieses Wort enthaelt die Anfangsadresse des UCB der Geraeteein- heit, mit der die E/A-Anforderung realisiert wird. Ist die E/A- Anforderung mit dem MCR-Kommando REDIRECT auf ein anderes Geraet umgeschaltet worden, so enthaelt dieses Wort die Anfangsadresse des UCB des Geraetes, auf das umgeschaltet wurde. I.FCN: ----- Dieses Wort enthaelt den E/A-Funktionscode. Das hoeherwertige Byte ist gleich der Bitnummer eines Maskenwortes, das bei der Zuordnung der Funktionen zu Funktionsklassen verwendet wird. Die moeglichen Standard-Funktionscodes sind in der folgenden Tabelle angegeben: Tabelle 1 Standard-Funktionscodes Bit- Masken- Symbol Bedeutung Nr. wert ----------------------------------------------------------------- 0 1 IO.KIL E/A abbrechen 1 2 IO.WLB Schreiben eines logischen Blockes 2 4 IO.RLB Lesen eines logischen Blockes 3 10 IO.ATT Geraet an eine Task anschliessen 4 20 IO.DET Geraet von einer Task trennen 5 40 ) 6 100 ) nicht verwendet 7 200 ) 13 Tabelle 1 (Fortsetzung) Bit- Masken- Symbol Bedeutung Nr. wert ----------------------------------------------------------------- 8 400 nicht verwendet 9 1000 IO.FNA Dateisuchen im Verzeichnis 10 2000 IO.ULK Unlock Block 11 4000 IO.RNA Loeschen einer Dateieintragung aus dem Verzeichnis 12 10000 IO.ENA Eintragen einer Datei in das Verzeichnis 13 20000 IO.ACR Bereitmachen einer Datei fuer Lesen 14 40000 IO.ACW Bereitmachen einer Datei fuer Lesen, Schreiben 15 100000 IO.ACE Bereitmachen einer Datei fuer Lesen, Schreiben und Erweitern 16 1 IO.DAC Sperren einer Datei 17 2 IO.RVB Lesen eines virtuellen Blockes 18 4 IO.WVB Schreiben eines virtuellen Blockes 19 10 IO.EXT Erweitern einer Datei 20 20 IO.CRE Erstellen einer Datei 21 40 IO.DEL Markieren einer Datei fuer Loeschen 22 100 IO.RAT Lesen von Dateiparametern 23 200 IO.WAT Schreiben von Dateiparametern 24 400 IO.ACP ACP Control . . ) . . ) nicht verwendet . . ) 31 100000 ) Die Bit-Nr. des Funktionscodes wird von der Exekutive in das hoeherwertige Byte des o.g. Wortes eingetragen. Das niederwertige Byte enthaelt einen geraetespezifischen Sub- funktionscode (siehe Anleitung fuer den Programmierer, Teil 3: "E/A-System"). 14 I.IOSB: ------- Mit diesem Symbol werden drei Worte des E/A-Pakets mit den rela- tiven Adressen 14, 16 und 20 erreicht. I.IOSB enthaelt die virtuelle Adresse des E/A-Statusblocks (IOSB), falls er gefordert wird, ansonsten ist das Wort Null. I.IOSB+2 und I.IOSB+4 enthalten die Doppelwortadresse des E/A- Statusblocks, und zwar enthaelt I.IOSB+2 die Nummer des 32-Wort- Blockes, in dem der E/A-Statusblock steht. Diese Blocknummer leitet sich aus dem zur Verfuegung stehenden physischen Adressraum her, der aus aufeinanderfolgend numerierten 32-Wort-Bloecken besteht. Beispiel: Beginnt der E/A-Statusblock mit der Adresse 3210 (oktal), so ist seine Blocknummer 32. I.IOSB+4 ist wie folgt aufgebaut: bit 0... 5: Adresse innerhalb des Blocks. Im o.g. Beispiel ist diese Adresse 10 (oktal). bit 6...12: Null bit 13...16: 6 Dieser Wert ist konstant. Er gibt die Adresse des Adresseitenregisters 6 (APR6) an. I.AST: ------ Dieses Wort enthaelt die virtuelle Adresse der AST-Behandlungs- routine. Falls keine angegeben ist, enthaelt dieses Wort eine Null. I.PRM: ------ Ueber das Symbol I.PRM kann ein Datenfeld erreicht werden, das geraeteabhaengige Parameter enthaelt. Diese Parameter enthalten die Informationen der letzten sechs Plaetze des Anweisungsparame- terblockes. Wenn die E/A-Funktion eine Uebertragungsfunktion darstellt, wird die Pufferadresse (der erste geraeteabhaengige Parameter im DPB) in ein aequivalentes Adressdoppelwort uebersetzt. Daher wird der geraeteabhaengige Parameter n auf die Adresse I.PRM+(2*(n-1))+2 eingetragen. Dabei wird vorausgesetzt, dass fuer den zweiten geraeteabhaengigen Parameter n=2 ist. 2.2.3. Geraetetyp-Steuerblock (DCB) ----------------------------------- Der Geraetetyp-Steuerblock ist in der Datenbasis einzurichten. Erbeschreibt die statischen Charakteristika der Anschluss- steuereinheiten und der von diesen bedienten Geraeteeinheiten. Der DCB enthaelt Informationen ueber den Geraetenamen, die Gerae- tenummern, die Lage der zugeordneten UCB, die Lage der DDT und Funktionsmasken, die die ausfuehrbaren Funktionen der Geraete beschreiben. Fuer jeden Geraetetyp gibt es einen DCB. Alle DCB im Betriebs- system sind miteinander ueber Verbindungszellen verbunden. 15 Der Kopf dieser DCB-Kette wird von der Zelle $DEVHD gebildet, die im System-Commonbereich (SYSCM) liegt. Diese Zelle enthaelt die Adresse des ersten DCB der DCB-Kette. |---------------------------------------------------| D.LNK | Verbindungszelle zum naechsten DCB | 0 |---------------------------------------------------| D.UCB | Verbindungszelle zum ersten UCB | 2 |---------------------------------------------------| D.NAM | Generierter Geraetename | 4 |---------------------------------------------------| D.UNIT | Hoechste Geraete-Nr. | Niedrigste Geraete-Nr. | 6 |---------------------------------------------------| D.UCBL | Laenge des UCB | 10 |---------------------------------------------------| D.DSP |Adresse der Tabelle der Eintrittspunkte des Drivers| 12 |---------------------------------------------------| D.MSK | Legale Funktionsmaske bit 0...15 | 14 |---------------------------------------------------| | Steuerfunktionsmaske bit 0...15 | 16 |---------------------------------------------------| | NOP-Funktionsmaske bit 0...15 | 20 |---------------------------------------------------| | ACP-Funktionsmaske bit 0...15 | 22 |---------------------------------------------------| | Legale Funktionsmaske bit 16...31 | 24 |---------------------------------------------------| | Steuerfunktionsmaske bit 16...31 | 26 |---------------------------------------------------| | NOP-Funktionsmaske bit 16...31 | 30 |---------------------------------------------------| | ACP-Funktionsmaske bit 16...31 | 32 |---------------------------------------------------| D.PCB | Adresse des Partitionssteuerblocks | 34 |---------------------------------------------------| Bild 2 Geraetetypsteuerblock (DCB) Erlaeuterungen -------------- D.LNK: ------ Dieses Wort ist die Verbindungszelle zum naechsten DCB der DCB- Kette. Es enthaelt die Adresse des naechsten DCB. Ist der betref- fende DCB der letzte oder einzige der Kette, enthaelt dieses Wort eine Null. Im Quellprogramm der Datenbasis ist dieses Wort mit dem Wert Null zu initialisieren. D.UCB: ------ Dieses Wort ist mit der Adresse des U.DCB-Feldes des ersten bzw. einzigen UCB, der dem jeweiligen DCB zugeordnet ist, zu initialisieren. Die zugehoerigen UCB stehen in einem zusammenhaengenden Speicher- bereich und haben alle die gleiche Laenge. 16 D.NAM: ------ Das Wort ist mit dem generierten symbolischen Geraetenamen zu initialisieren. Er besteht aus zwei KOI-7-Zeichen. D.UNIT: ------- Diese beiden Bytes sind mit der niedrigsten und der hoechsten Geraeteeinheitennummer der von dem jeweiligen DCB gesteuerten Geraete zu initialisieren. D.UCBL: ------- In dieses Wort ist die Laenge (in Bytes) eines zugehoerigen UCB einzutragen. Der UCB kann fuer jede Driverart (ladbar oder resi- dent) oder fuer jeden Geraetetyp verschieden lang sein. Alle UCB, die zu einem DCB gehoeren, muessen gleich lang sein. Besitzt der UCB einen Praefix, geht dieser in die Laenge des UCB ein. D.DSP: ------ Bei residenten Drivern ist in dieses Wort die Adresse der "Tabel- le der Eintrittspunkte des Drivers" (DDT) (siehe Abschnitt 2.2.) einzutragen. Die symbolische Adresse der Tabelle muss die Form $xxTBL besitzen (xx ist der in D.NAM eingetragene symbolische Geraetename). Bei ladbaren Drivern ist hier als Anfangswert eine Null einzutragen. Beim Laden des Drivers traegt in diesem Fall die Exekutive die entsprechende Tabellenadresse ein. D.MSK: ------ In diese 8 Worte sind die Funktionsmasken fuer das Geraet einzutragen. Diese Funktionsmasken ergeben sich aus der Disjunktion aller Maskenwerte, die den betreffenden Funktionen zugeordnet sind (siehe Tabelle 1). Die 8 Maskenworte gliedern sich in 2 Gruppen von je 4 Worten. Die Worte der ersten Gruppe enthalten die Funktionsmaskenbits Nr. 0 bis 15 und die Worte der zweiten Gruppe die Funktionsmaskenbits Nr. 16 bis 31 (siehe Abschnitt I.FCN in 2.2.2.). Die Masken haben folgende Bedeutung: - Legale Funktionsmaske Die legale Funktionsmaske enthaelt die Disjunktion der Maskenwerte aller zulaessigen Funktionen. Die Exekutive prueft anhand dieser Funktionsmaske die aufgerufene E/A-Funktion auf Zulaessigkeit und weist sie gegebenenfalls zurueck. - Steuerfunktionsmaske Die Exekutive fuehrt bei den Funktionen dieser Funktionsmaske keine Pruefung der geraetespezifischen Parameter durch. Diese werden ohne Pruefung sofort vom Anweisungsparameterblock in das E/A-Paket uebernommen. Zur Ausfuehrung der Steuerfunktionen wird der Driver aktiviert. 17 - NOP-Funktionsmaske Eine Funktion, die fuer ein bestimmtes Geraet als NOP (not operated) gekennzeichnet ist, wird bei ihrer Anforderung von der Exekutive sofort als erfolgreich beendet deklariert. Der Driver wird nicht aktiviert. Die NOP-Funktionsmaske enthaelt die Bits solcher Funktionen. - ACP-Funktionsmaske Ein zulaessiger Funktionscode, der weder Steuerfunktion noch eine NOP-Funktion ist, ist entweder eine Transferfunktion oder eine Funktion, die eine Zusatzsteuerroutine (ACP) erfordert. Die letzteren sind in dieser Maske beschrieben. Im folgenden wird an einem Beispiel der Aufbau der Funktionsmas- ken dargestellt. Beispiel: Der Driver fuer einen Lochbandstanzer erlaubt die folgenden Funk- tionen: Tabelle 2 Funktionscodes fuer einen Lochbandstanzer Funktion Masken- Bitbereich Bedeutung wert ----------------------------------------------------------------- IO.KIL 000001 0...15 E/A abbrechen IO.WLB 000002 0...15 Schreiben eines logischen Blocks IO.ATT 000010 0...15 Geraet an eine Task anschliessen IO.DET 000020 0...15 Geraet von einer Task trennen IO.ACW 040000 0...15 Bereitmachen einer Datei fuer Lesen, Schreiben IO.ACE 100000 0...15 Bereitmachen einer Datei fuer Le- sen, Schreiben und Erweitern IO.DAC 000001 16...31 Sperren einer Datei (2.Wort) IO.WVB 000004 16...31 Schreiben eines virtuellen (2.Wort) Blocks ----------------------------------------------------------------- IO.WLB ist die einzige Transferfunktion, die unterstuetzt wird. IO.ATT und IO.DET sind Steuerfunktionen. IO.ACW, IO.ACE, IO.DAC sind NOP-Funktionen. IO.WVB ist eine ACP-Funktion. 18 Die acht Maskenworte haben dann den folgenden Aufbau: D.MSK: .WORD 140033 ;Legale Funktionsmaske (bit 0...15) .WORD 30 ;Steuerfunktionsmaske (bit 0...15) .WORD 140000 ;"NOP"-Funktionsmaske (bit 0...15) .WORD 0 ;ACP-Funktionsmaske (bit 0...15) .WORD 5 ;Legale Funktionsmaske (bit 16...31) .WORD 0 ;Steuerfunktionsmaske (bit 16...31) .WORD 1 ;NOP-Funktionsmaske (bit 16...31) .WORD 4 ;ACP-Funktionsmaske (bit 16...31) (siehe auch Abschnitt 5.2.2.1.) D.PCB: ------ Dieses Wort ist im DCB nur enthalten, wenn der Driver ein ladba- rer ist. Es ist mit Null zu vereinbaren und enthaelt nach dem Laden des ladbaren Drivers die Adresse des Partitionssteuerblocks (PCB). Der Partitionssteuerblock beschreibt die Partition, in der sich der ladbare Driver befindet. Zusammen mit D.DSP kann die Exekutive anhand von D.PCB bestimmen, ob ein Driver ein ladbarer oder ein residenter ist, und wenn er ein ladbarer ist, ob er sich im Hauptspeicher befindet oder nicht. Folgende Kombinationen sind moeglich: D.PCB | D.DSP=0 | D.DSP ungleich 0 --------|---------------|------------------ |ladbarer Driver| residenter =0 | nicht im | Driver | Speicher | --------|---------------|--------------- ungleich| nicht |ladbarer Driver 0 | moeglich | im Speicher | | --------|---------------|--------------- 2.2.4. Statussteuerblock (SCB) ------------------------------ Der Statussteuerblock (SCB) beschreibt den Status einer An- schlusssteuereinheit. Fuer jede Anschlusssteuereinheit ist ein SCB einzurichten. Er enthaelt Informationen, die fuer die Steue- rung der Anschlusssteuereinheiten und fuer die Parallelarbeit der angeschlossenen Geraete wichtig sind. Die meisten der Informationen werden dynamisch waehrend der E/A-Abarbeitung veraendert. 19 |-----------------------------------------| S.RCNT1)Offset zum 1. |Anzahl der bei Fehler zu | S.ROFF |Geraeteregister| kopierenden Register | |-----------------------------------------| S.BMSV1)Geretteter Zeiger der aktiven Bit-Map | |zum Error-Massage-Block | |-----------------------------------------| S.BMSK1)Aktive Bit-Maske der Geraete E/A | |-----------------------------------------| S.LHD | | 0 | Geraetewarteschlangenkopf | | | 2 |-----------------------------------------| S.PRI | Vektoradresse/4 | Geraeteprioritaet | 4 S.VCT | | | |-----------------------------------------| S.CTM | Zeitausfallzaehler | 6 S.ITM |Initialisierungswert| aktueller Wert | |-----------------------------------------| S.CON | AS-Status | Nummer der AS | 10 S.STS | | | |-----------------------------------------| S.CSR | CSR-Adresse | 12 | | |-----------------------------------------| S.PKT | Adresse des aktuellen E/A-Paketes | 14 | | |-----------------------------------------| S.FRK | Verbindungswort fuer die | 16 | FORK-Warteschlange | |-----------------------------------------| | Geretteter Inhalt von PC | 20 | | |-----------------------------------------| | Geretteter Inhalt von R5 | 22 | | |-----------------------------------------| | Geretteter Inhalt von R4 | 24 | | |-----------------------------------------| | Basisadresse der Driverpartition | 26 | | |-----------------------------------------| 1) Diese Offsets existieren nur bei Massen-Speichergeraeten (DV.MSD im UCB gesetzt) in Systemen mit Error-logging. Bild 3 Statussteuerblock (SCB) Erlaeuterungen: --------------- S.RCNT: (genutzt fuer Error-logging bei Massen-Speichergeraeten) ------- Anzahl der bei aufgetretenem Fehler zu kopierenden Register. S.ROFF: ( s.o. ) ------- Offset zum 1. Geraeteregister 20 S.BMSV: ( s.o. ) ------- Dieser Offset enthaelt den geretteten Zeiger der aktiven Bit-Map zum Error-Massage-Block. S.BMSK: ( s.o. ) ------- Dieser Offset enthaelt die aktive Bit-Maske der Geraete E/A. S.LHD: ------ Die zwei Worte, die mit dem Symbol S.LHD erreicht werden, bilden den Geraetewarteschlangenkopf. Das erste Wort enthaelt die Adresse des ersten E/A-Pakets der Warteschlange, und das zweite Wort enthaelt die Adresse des letz- ten E/A-Pakets der Warteschlange. Ist die Warteschlange leer, so ist das erste Wort Null und das zweite Wort enthaelt die Adresse des ersten Wortes. Mit diesen beiden Werten ist S.LHD im Quellprogramm der Datenbasis zu initialisieren. S.PRI: ------ In dieses Byte ist die Prioritaet des Geraetes einzutragen. S.VCT: ------ In dieses Byte ist die durch 4 dividierte Adresse des Interrupt- vektors einzutragen . Diese Information wird bei ladbaren Drivern vom MCR-Kommando LOAD in Verbindung mit den Driversymbolen $xxINT, $xxINP und $xxOUT (siehe Abschnitt 3.2.) zum Initialisie- ren des Geraeteinterruptvektors benutzt. S.CTM: ------ Dieses Byte enthaelt den Time-out-Zaehler des Geraetes (siehe Abschnitt 2.1.5.). Der Zaehler wird von der Exekutive fuer die programmtechnische Zeitueberwachung der Geraete benutzt. Der Zaehler ist bei der Einleitung einer Datenuebertragung auf seinen Grundwert, der im Byte S.ITM angegeben ist, einzustellen. Vom Uhrprogramm wird der Zaehler nach jeder Sekunde um 1 verrin- gert. Wird auf diese Weise durch Ausbleiben eines Geraeteinter- rupts der Zaehler zu Null, wird das betreffende Geraet als defekt angesehen und der Driver von der Exekutive an seinem Geraetefehler-Eintrittspunkt aktiviert. Wird der Time-out-Wert geloescht, wird der Geraetefehler-Eintrittspunkt nicht aktiviert. Es ist zu beachten, dass fuer eine zuverlaessige Handhabung der Anfangswert mindestens 2 betragen muss. S.ITM: ------ Dieses Byte enthaelt den Grundwert der softwaremaessigen Zeitue- berwachung. Dieser Grundwert ist beim Programmieren der Datenba- sis des Drivers anzugeben. Der Grundwert wird in Sekunden angege- ben. Er kann einen Wert zwischen 2 und 255 (dezimal) annehmen. Beim Wert Null erfolgt keine Zeitueberwachung. 21 S.CON: ------ In dieses Byte ist die mit 2 multiplizierte Nummer (Index) der Anschlusssteuereinheit einzutragen. Dieses Byte wird von Drivern benutzt, die mehr als eine Anschlusssteuereinheit bedienen (Multicontrollerdriver, siehe auch 5.1.3.2.). S.STS: ------ Dieses Byte signalisiert den Besetztstatus der Anschlusssteuer- einheit. Ist diese Information Null, bedeutet das, dass die Anschlusssteuereinheit nicht besetzt ist. Jede andere Informa- tion bedeutet, dass die Anschlusssteuereinheit besetzt ist. Das Byte wird von dem Systemunterprogramm $GTPKT ausgewertet bzw. gesetzt und vom Systemunterprogramm $IODON zurueckgesetzt (siehe Abschnitt 4.10. bzw. 4.17.). Im Quellprogrammcode ist S.STS mit dem Wert Null zu initialisieren. S.CSR: ------ Dieses Wort ist im Quellprogramm mit der Adresse des Steuer- und Statusregisters der Anschlusssteuereinheit zu initialisieren. Ueber diese Adresse erreicht der Driver die fuer die E/A- Abarbeitung notwendigen Register wie Datenpufferregister und Steuer-/Statusregister. S.PKT: ------ In diesem Wort wird von der Exekutive die Adresse des laufenden E/A-Pakets, das durch das Systemunterprogramm $GTPKT aufgerufen wurde, eingetragen. Im Quellprogrammcode ist es mit Null zu initialisieren. S.FRK: ------ Die 4 Worte, die im Quellprogramm zu vereinbaren sind und ueber das Offset S.FRK erreicht werden, werden als sogenannter "Fork- Speicher" benutzt. Aufgrund von Prioritaetsforderungen der Exekutive muss ein Driver nach etwa 500 Mikrosekunden voll unter- brechbar sein. Dieser Zustand wird durch das Aufrufen des Systemunterprogramms $FORK erreicht. $FORK richtet diesen "Fork- Speicher" ein, d.h. der "Fork-Speicher" wird ueber sein erstes Wort, das Fork-Verbindungswort, in eine "Fork-Warteschlange" eingegliedert und der aktuelle Zustand der Register PC, R5 und R4 in dieser Reihenfolge in den drei naechsten Worten des "Fork- Speichers" gespeichert. Die weitere Abarbeitung des Drivers wird nun ueber die Fork-Warteschlange gesteuert. Der gerettete Zustand der o.g. Register wird wieder zurueckgespeichert, wenn der Driver ueber den Fork-Prozess wieder weiterarbeitet. Der "Fork-Speicher" wird auf fuenf Worte erweitert, wenn die Generierungsoption "Einbinden ladbarer Driver" ausgewaehlt worden ist. Das fuenfte Wort enthaelt dann die Basisadresse der Partition, in der der Driver arbeitet. 22 2.2.5. Geraetesteuerblock (UCB) ------------------------------- Fuer jede Geraeteeinheit, die vom System bedient wird, ist ein Geraetesteuerblock (UCB) einzurichten. Ein Geraetesteuerblock enthaelt spezielle Informationen, die die Geraeteeinheit betreffen. Benutzt und modifiziert wird der UCB von der Exeku- tive und dem Driver. Alle UCB, die einem DCB zugeordnet sind, befinden sich in aufein- anderfolgenden Speicherbereichen. Sie koennen fuer geraetespezi- fische Parameter beliebig erweitert werden, muessen aber fuer einen DCB alle die gleiche Laenge haben. Vom UCB aus ist es moeglich, zu den meisten Datenfeldern der Datenbasis eines Drivers zuzugreifen. Deshalb laden die meisten Driver das Register R5 mit der Adresse des entsprechenden UCB.  23 |-----------------------------------| ----- | | | U.IOC4) |--------Anzahl der E/A-------------| | | | | |-----------------------------------| | U.ERSL4)|Hard-Error-Grenze|Soft-Error-Grenze| | U.ERHL4)| | | |-----------------------------------| -> siehe U.ERSC4)| Hard-Error-Zahl | Soft-Error-Zahl| | 5) U.ERHC4)| | | |-----------------------------------| | U.MUP3) | Multiuser-flags und CLI-Zeiger | -6 | |-----------------------------------| | U.LUIC2)| Angemeldeter UIC | -4 | |-----------------------------------| ----- U.OWN1) |Terminal-UCB-Adresse d.Eigentuemers| -2 |-----------------------------------| U.DCB | Adresse des zugehoerigen DCB | 0 |-----------------------------------| U.RED | Zeiger zum wirksamen UCB | 2 |-----------------------------------| U.CTL | Geraetestatus | Steuerbits | 4 U.STS |-----------------------------------| U.UNIT | Geraetestatus |phys. Geraete-Nr.| 6 U.ST2 |-----------------------------------| U.CW1 | Kenndatenwort 1 | 10 |-----------------------------------| U.CW2 | Kenndatenwort 2 | 12 |-----------------------------------| U.CW3 | Kenndatenwort 3 | 14 |-----------------------------------| U.CW4 | Kenndatenwort 4 | 16 |-----------------------------------| U.SCB | Adresse des Statussteuerblocks | 20 |-----------------------------------| U.ATT | TCB-Adresse der rufenden Task | 22 |-----------------------------------| U.BUF | Pufferinformationen | 24 |-----------------------------------| U.BUF+2 | Pufferadresse | 26 |-----------------------------------| U.CNT | Bytezaehler | 30 |-----------------------------------| | | 32 | Geraeteabhaengige Parameter | |-----------------------------------| 1.) Dieser Offset existiert nur in Multiuser-Systemen 2.) Diese Offsets existieren nur fuer Terminals (Bit DV.TTY gesetzt) in Multiuser-Systemen. 3.) Dieser Offset existiert nur fuer Terminals (Bit DV.TTY gesetzt) in Multiuser-Systemen, durch alternative CLI-Unter- stuetzung. In Multiuser-Systemen mit alternativer CLI-Unter- stuetzung hat der Offset den Namen U.CLI. 4.) Diese Offsets erscheinen nur fuer Massen-Speichergeraete (DV.MSD-Bit gesetzt) in Systemen, die Error-logging verwenden. 5.) Diese Offsets sind geraeteabhaengig. Bild 4 Geraetesteuerblock (UCB)  24 Erlaeuterungen: -------------- U.IOC: ------ Die Gesamtzahl der QIO's, die zum Geraet gesendet werden. ( Nur fuer Massenspeichergeraete in Systemen, die Error-logging verwenden). U.ERSL: ------- Dieser Offset enthaelt die maximale Anzahl der Soft-Errors, die die Fehlerregistrierung fuer ein Geraet aufzeichnen wird. Beachte, dass die Fehlerregistrierung stoppt, wenn eine der angegebenen Grenzen ueberschritten wird (U.ERHL oder U.ERSL). (Nur fuer Massenspeichergeraete; DV.MSD-Bit gesetzt, in Systemen mit Error-logging). U.ERHL: ------- Dieser Offset enthaelt die maximale Anzahl der Hard-Errors, die die Fehlerregistrierung fuer ein Geraet aufzeichnen wird. Beachte, dass die Fehlerregistrierung stoppt, wenn eine der angegebenen Grenzen ueberschritten wird (U.ERHL oder U.ERSL). (Nur fuer Massenspeichergeraete; DV.MSD-Bit gesetzt, in Systemen mit Error-logging). U.ERSC: ------- Dieser Offset enthaelt die Gesamtzahl der aufgezeichneten Soft- Errors. (Nur fuer Massenspeichergeraete; DV.MSD-Bit gesetzt, in Systemen mit Error-logging). U.ERHC: ------- Dieser Offset enthaelt die Gesamtzahl der aufgezeichneten Hard- Errors. (Nur fuer Massenspeichergeraete; DV.MSD-Bit gesetzt, in Systemen mit Error-logging). Beachte: Die folgenden symbolischen Namen U.MUP und U.CLI verweisen zu demselben absoluten Offset; die Verwendung des Offsets von Systemkonfiguration. U.MUP: ------ Dieser Offset existiert fuer Systeme ohne alternative CLI- Unterstuetzung, aber mit eingeschlossenem Multiuser-Schutz: Multiuser-Schutz-Flag-Wort. U.CLI: ------ Nur fuer Terminal-UCB's und nur in Multiuser-Systemen, welche die alternative CLI-Unterstuetzung einschliessen: Die Bits 1 bis 4 enthalten einen Index zu einer Tabelle, welche die Adresse des CLI-Parser-Blocks (CPB) fuer den laufenden CLI enthaelt; die verbleibenden Bits werden fuer andere terminal- spezifische Eigenschaften benutzt:  25 UM.OVR - Override CLI-Indicator UM.CLI - CLI-Indicator UM.DSB - Terminal abgeschaltet, da CLI eliminiert wurde UM.NBR - No Broadcoast U.LUIC: ------- Dieses Wort enthaelt der UCB nur bei Terminaldrivern in einem Mehrnutzersystem. Dann enthaelt dieses Wort den Nutzer- identifikationscode (UIC) des fuer dieses Terminal angemeldeten Nutzers. U.OWN: ------ Dieses Wort enthaelt der UCB nur in Mehrnutzersystemen. Es enthaelt die UCB-Adresse des Nutzerterminals. U.DCB: ------ Dieses Wort muss die Adresse des uebergeordneten DCB enthalten. U.RED: ------ Wird mit dem MCR-Kommando REDIRECT eine Geraeteumschaltung vorge- nommen, so enthaelt dieses Wort die Adresse des UCB des Geraetes auf das umgeschaltet wurde. Ansonsten enthaelt es die eigene UCB- Adresse. Mit dieser Adresse ist das Wort im Quellprogramm zu initialisieren. U.CTL: ------ Dieses Byte enthaelt bestimmte Steuerbits. Zusammen mit den Funk- tionsmasken im DCB steuern diese den Ablauf der E/A-Anweisung. Die Steuerbits sind bei der Programmierung der Datenbasis zu setzen. Die einzelnen Steuerbits werden bei der Programmierung symbolisch angegeben. Ihre Symbole und deren Bedeutung werden im folgenden erlaeutert: - UC.ALG (=200(oktal)) Bei gesetztem Bit fordert der Driver einen wortbegrenzten Da- tenpuffer. Ansonsten kann er bytebegrenzt sein. - UC.ATT (=10(oktal)) Entschluesselt das Systemunterprogramm $GTPKT eine QIO$- Anweisung mit IO.ATT bzw. IO.DET, so wird bei gesetztem Steuerbit der Driver zur Ausfuehrung einer speziellen Behandlung dieser Anweisung aktiviert. Ist das Steuerbit nicht gesetzt, fuehrt die Exekutive die QIO$-Anweisung ohne den Driver aus. - UC.KIL (=4) Bei gesetztem Steuerbit wird der Driver bei einer E/A-Abbruch- anweisung aufgerufen, auch, wenn keine E/A-Operation aktiv ist.  26 - UC.QUE (=40(oktal)) Bei gesetztem Steuerbit wird der Driver von der Warteschlangen- organisation aufgerufen, bevor das entsprechende E/A-Paket in die Warteschlange eingereiht ist. Der Driver ist in diesem Fall fuer die ordnungsgemaesse Verwaltung des E/A-Pakets selbst verantwortlich. - UC.PWF (=20(oktal)) Ist das Geraet on-line, wird bei gesetztem Steuerbit der Driver an seinem Netzausfall-Eintrittspunkt bei den unter Abschnitt 2.1.6. genannten Bedingungen aktiviert. - UC.NPR (=100(oktal)) Das NPR-Geraetebit wird gesetzt, wenn es sich um ein DMA-Ge- raet handelt. Dieses Bit bestimmt das Format von U.BUF. (Details sind der Beschreibung von U.BUF zu entnehmen.) - UC.LGH (=3) Diese zwei Steuerbits bestimmen die zulaessigen Werte des Byte- zaehlers. 00 - Jeder Pufferwert ist gueltig. 01 - Der Puffer ist wortbegrenzt. 10 - (ungueltige Kombination) 11 - Der Puffer ist doppelwortbegrenzt. U.STS: ------ In dieses Byte traegt die Exekutive geraetaabhaengige Status- informationen ein. Die einzelnen Bits koennen mit Hilfe von globalen Symbolen ausgewertet werden. Sie haben folgende Bedeutung: - US.BSY (=200(oktal)): Geraet arbeitet - US.MNT (=100(oktal)): Geraet ist nicht eingegliedert - US.FOR (= 40(oktal)): Das Format des Datentraegers und/oder der Zusatzsteuerroutine (ACP) entspricht nicht dem OMOS-Standard - US.MDM (= 20(oktal)): Geraet ist fuer Ausgliedern markiert Ungenutzte Bits sind fuer das System reserviert. Die verwendeten Bits gelten nur fuer Datentraeger, die in das Da- teisystem OMOS eingegliedert werden koennen. Im Quellprogramm ist das Byte mit US.MNT zu initialisieren. U.UNIT: ------- In diesem Byte ist der Geraeteeinheit im Quellprogrammcode bezueglich der Anschlusssteuereinheit, beginnend mit Null, eine laufende Geraetenummer zuzuordnen. Wird von der jeweiligen Anschlusssteuereinheit nur ein Geraet bedient, ist der Inhalt dieses Bytes Null.  27 U.ST2: ------ Dieses Byte ist im Quellprogramm mit zusaetzlichen Statusinformationen zu initialisieren. Die Symbole und die Bedeu- tung der einzelnen Bits sind folgende: - US.OFL (=1): Geraet ist off-line, (Es ist nicht in der Konfiguration des Rechners vorhanden) - US.RED (=2): Geraet kann nicht mit REDIRECT umadres- siert werden. - US.PUB (=4): Das Geraet ist nicht einem bestimmten Nut- zer zugeordnet. - US.UMD (=10(oktal)): Der Driver ist fuer die Unterstuetzung von Geraetetestprogrammen ausgelegt. U.CW1: ------ Dieses Wort ist das erste von 4 Kenndatenworten, die geraetespe- zifische Informationen enthalten und die im Quellprogrammcode entsprechend den Gegebenheiten zu initialisieren sind. Die einzelnen Bits haben die folgenden Symbole und bedeuten: DV.REC (= 1): Satzorientiertes Geraet DV.CCL (= 2): Vorschubgesteuertes Geraet DV.TTY (= 4): Bediengeraet DV.DIR (= 10): Dateistrukturiertes Geraet DV.SDI (= 20): Geraet mit einem einzigen Verzeichnis DV.SQD (= 40): Geraet fuer sequentiellen Zugriff DV.UMD (= 200): Unterstuetzung von Nutzer-Geraetetestprogr. DV.SWL (= 1000): Geraet ist softwaremaessig schreibgeschuetzt DV.PSE (= 10000): Pseudogeraet DV.F11 (= 40000): Geraet ist eingliederbar fuer Dateiformat FM16 DV.MNT (= 100000): Geraet ist eingliederbar ins Dateiformat FM16 Bei der Programmierung der Datenbasis koennen die Informationen fuer das Kenndatenwort CW1 der Anleitung fuer den Programmierer, Teil 3: "E/A-System", aus den Beschreibungen der einzelnen Driver entnommen werden (Informationen des GET-LUN-Makros).  28 U.CW2 und U.CW3: ---------------- Die Kenndatenworte U.CW2 und U.CW3 sind entsprechend den geraetetechnischen Gegebenheiten zu initialisieren oder koennen als Arbeitsspeicher verwendet werden. Bei Drivern fuer block- strukturierte Geraete enthalten CW2 und CW3 als Doppelwort die gesamte Anzahl der physischen 256-Wort-Bloecke auf dem betreffen- den Geraet (das niederwertige Byte ist in U.CW3). Diese Kennworte duerfen bei blockstrukturierten Geraeten vom Driver waehrend der Abarbeitung einer E/A-Anforderung nicht ver- aendert werden. U.CW4: ------ Dieses Kenndatenwort ist im Quellprogramm mit der Standardpuf- fergroesse des Geraetes in Bytes zu initialisieren. Durch das MCR-Kommando SET /BUF kann dieser Wert veraendert werden. U.SCB: ------ In dieses Wort ist im Quellprogrammcode die Adresse des Status- steuerblocks (SCB) fuer das betreffende Geraet einzutragen. U.ATT: ------ Wird durch eine QIO$-Anweisung mit IO.ATT das dem UCB zugehoe- rige Geraet an eine Task angeschlossen, stellt die Exekutive in diesem Wort die Adresse des Tasksteuerblocks der jeweiligen Task zur Verfuegung. U.BUF und U.BUF+2: ------------------ Die zwei zusammenhaengenden Worte U.BUF und U.BUF+2 dienen der Kommunikation zwischen dem Systemunterprogramm $GTPKT und dem Driver und sind im Quellprogramm mit Null zu initialisieren. Beinhaltet die aktuelle Operation keinen Transfer, werden von $GTPKT in U.BUF , U.BUF+2 und U.CNT die ersten drei geraetespezifischen Parameter (ab I.PRM) des E/A-Pakets eingetragen. Der Inhalt von U.BUF und U.BUF+2 wird durch das UC.NPR-Bit bestimmt. Bei gesetztem UC.NPR-Bit (DMA-Geraet) beinhalten diese Worte die folgenden Informationen: U.BUF: bit 0 = GO-Bit bit 1- 3 = Funktionscode bit 4- 5 = Speichererweiterungsbits (bit 16 und 17 der Pufferadresse) bit 6 = Interrupt-Erlaubnisbit bit 7-15 = Null Das GO-Bit, der Funktionscode und das Interrupt-Erlaubnis- bit sind vom Driver zu setzen. Es ist zu beachten, dass dadurch keine Operation ausgeloest wird. Dazu ist die Uebermittling in das CSR erforderlich. U.BUF+2: bit 0-15 = niederwertige 16 bit der physischen Adresse Fuer Nicht-DMA-Geraete (UC.NPR-Bit=0) sind die Inhalte von U.BUF und U.BUF+2 identisch mit denen von I.IOSB+2 und I.IOSB+4 des E/A-Pakets.  29 U.CNT: ------ U.CNT ist im Quellprogrammcode mit Null zu initialisieren. Beinhaltet die aktuelle Operation einen Transfer, wird von $GTPKT der Bytezaehler eingetragen. Benutzt der Driver fuer die Kommunikation mit dem Puffer Systemunterprogramme (z.B. $GTWRD), so aktualisieren diese U.CNT. Bei DMA-Geraeten findet keine Aktualisierung von U.CNT statt. 2.2.6. Initialisierungsblock (CIB) fuer die Anschlusssteuereinheit ------------------------------------------- Eine Reihe der in den Rechnern des MGS K 1630 eingesetzten An- schlusssteuereinheiten benoetigen eine Initialisierung, die vom OMEX 1630 beim Systemanlauf oder automatischer Fortsetzung nach Netzausfall vorgenommen wird, wenn entsprechende Initialisi- erungsbloecke fuer die Anschlusssteuereinheiten (CIB) vereinbart werden. Mittels des zugehoerigen CIB werden beim Anlauf die zur Initiali- sierung der Anschlusssteuereinheit erforderlichen Ausgaben auf die Adressen 77760, 77762 und 77764 und (nur fuer die Anschluss- steuereinheit AIS) auch die Initialisierung der Zeitkanaele 0 bis 2 ausgefuehrt. Die Informationen ueber die erforderlichen Initialisierungsdaten sind der Rechner-Betriebsdokumentation zu entnehmen. Der erste CIB der Datenbasis muss mit der Vereinbarung der globa- len Marke $xxCIB:: beginnen. (xx=Geraetesymbol) Bei Drivern mit einer residenten Datenbasis muss zusaetzlich der erste CIB mit der globalen Marke $USRCI beginnen. Es gibt zwei Typen von CIB. Der allgemeine CIB ist wie folgt aufgebaut: ---------------------------------------------- | Adresse des naechsten CIB | 0 |--------------------------------------------| | Information fuer Adr. 777760 (Kennung) | 2 |--------------------------------------------| | Information fuer Adr. 777762 (Geraeteadr.) | 4 |--------------------------------------------| | Information fuer Adr. 777764 (Vektoradr.) | 6 ----------------------------------------------  30 Der CIB fuer AIS ist wie folgt aufgebaut. ---------------------------------------------- | Adresse des naechsten CIB | 0 |--------------------------------------------| | Information fuer Adr. 777760 (Kennung) | 2 |--------------------------------------------| | Information fuer Adr. 777762 (Geraeteadr.) | 4 |--------------------------------------------| | 177777 | 6 |--------------------------------------------| | Betriebsart-Steuerwort Zeitkanal 0 | 10 |--------------------------------------------| | Zeitkonstante Zeitkanal 0 | 12 |--------------------------------------------| | Betriebsart-Steuerwort Zeitkanal 1 | 14 |--------------------------------------------| | Zeitkonstante Zeitkanal 1 | 16 |--------------------------------------------| | Betriebsart-Steuerwort Zeitkanal 2 | 20 |--------------------------------------------| | Zeitkonstante Zeitkanal 2 | 22 ---------------------------------------------- Bild 5 Initialisierungsblock (CIB) Fuer jede zu initialisierende Anschlusssteuereinheit, die mit dem betreffenden Driver bedient wird, ist ein CIB vorzusehen. Die CIB sind ueber Verbindungszellen (jeweils die erste Zelle des CIB) zu einer Kette verbunden. Im letzten CIB ist als Abschlusskennzeichnung der Kette der CIB im ersten Wort anstelle der Adresse des naechsten CIB der Wert 0 zu vereinbaren. 2.2.7. Der Geraeteinterruptvektor --------------------------------- Geraeteinterruptsignale erreichen ueber einen Geraeteinterrupt- vektor den Interruptbehandlungsteil des Drivers. Dieser Geraete- interruptvektor liegt fuer jedes Geraet auf einer fest zugeord- neten Adresse. Er besteht aus zwei aufeinanderfolgenden Worten: - Wort 1 enthaelt die Startadresse des Interruptbehandlungsteils des Drivers. - Wort 2 enthaelt die Prioritaet, unter der das Interruptbehand- lungsprogramm laeuft (immer PR7), und die Nummer der Anschluss- steuereinheit. In der Datenbasis eines residenten Drivers ist der Geraeteinter- ruptvektor zu programmieren. Bei ladbaren Drivern wird der Vektor dynamisch durch das MCR- Kommando LOAD vereinbart. Durch das MCR-Kommando UNLOAD wird die Vektorvereinbarung rueck- gaengig gemacht.  31 2.2.8. Tabelle der Eintrittspunkte eines Drivers (DDT) ------------------------------------------------------ Von den fuenf Programmteilen eines Drivers werden vier von der Exekutive aus aufgerufen . Es handelt sich um die Driverteile: - E/A-Initiator - E/A-Abbruchbehandlung - Geraetefehlerabbruch - Netzfehlerbehandlung Die Adressen der Eintrittspunkte dieser vier Programmteile sind in einer Tabelle in o.a. Reihenfolge zusammengefasst. Diese Ta- belle wird "Tabelle der Eintrittspunkte eines Drivers" (DDT) genannt und ist Teil des Drivers (siehe 2.2.3., D.DSP). 2.2.9. Zusammenhang zwischen DCB, UCB und SCB --------------------------------------------- Fuer einen Driver koennen die Datenfelder DCB, UCB und SCB je nach Geraeteanzahl und der Moeglichkeit der Parallelarbeit in verschiedenen Varianten zusammengestellt werden. Einige Beispiele sollen das erlaeutern: 1.Beispiel |------DCB------| | | | | | | UCB UCB UCB | | | | | | SCB SCB SCB Jede Geraeteeinheit ist an eine Anschlusssteuereinheit ange- schlossen. Dadurch ist eine Parallelarbeit aller drei Geraeteein- heiten moeglich. Z.B. 3 Drucker an 3 Anschlusssteuereinheiten 2.Beispiel |------DCB------| | | | | | | UCB UCB UCB | | | | | | |----->SCB<-----| Alle drei Geraeteeinheiten sind an eine Anschlusssteuereinheit angeschlossen. Eine Parallelarbeit der drei Geraeteeinheiten ist nicht moeglich. Z.B. 3 Magnetbandgeraete an einer Anschlusssteuereinheit  32 3.Beispiel |---------DCB---------| | | | | | | | | UCB UCB UCB UCB \ / \ / \ / \ / \ / \ / SCB SCB Jeweils zwei Geraeteeinheiten sind an eine Anschlusssteuereinheit angeschlossen. Es koennen zwei Geraeteeinheiten, von jeder An- schlusssteuereinheit eine, parallel arbeiten. Z.B. je zwei Kassettenmagnetbandgeraete an je einer Anschluss- steuereinheit.  33 3. Forderungen des Betriebssystem OMOS 1630 an die Driver --------------------------------------------------------- 3.1. Prioritaetsforderungen --------------------------- Geraeteinterrupts werden im Driver nach dem Aufruf des Driver- Interruptbehandlungsteils mit der Prioritaet 7 (PR7) bearbeitet. Das bedeutet, dass das Interruptbehandlungsprogramm durch andere Geraeteinterrupts nicht unterbrechbar ist. Dieser Zustand der Nichtunterbrechbarkeit darf im Betriebssystem OMOS 1630 nicht laenger als 100 Mikrosekunden dauern. Ist in dieser Zeit der Interrupt behandelt, treten keine Komplikationen auf. Dauert die Interruptbehandlung laenger, muessen vom Driver Massnahmen er- griffen werden, durch die die Moeglichkeit geschaffen wird, dass auch andere Geraeteinterrupts behandelt werden koennen. Das wird durch die Ausloesung des sogenannten "Fork-Prozesses" erreicht. Zunaechst kann mittels des Systemunterprogramms $INTSV bzw. des Makros INTSV$ die Prioritaet der Interruptbehandlung auf die Prioritaet der Interruptquelle (siehe Abschnitt 2.2.4., S.PRI) herabgesetzt werden. Die Bearbeitungszeit unter dieser Prioritaet darf im OMOS 1630 500 Mikrosekunden nicht ueberschreiten. Ist sie groesser, wird mit dem Ruf des Systemunterprogramms $FORK ein Fork-Prozess ausgeloest. Die weitere Bearbeitung des Interrupts wird dann mit der Priori- taet 0 (PR0) durchgefuehrt. Sie kann durch alle weiteren auftre- tenden Geraeteinterrupts unterbrochen werden. Waehrend der Abarbeitung des $FORK werden die Registerinhalte von R4 und R5 und der PC in den Fork-Speicher gerettet. Fuer diesen FORK-Speicher ist im SCB des Geraetes Platz reser- viert. Die erste Zelle des Fork-Speichers wird als Verbindungs- zelle fuer den Aufbau der Fork-Warteschlange benutzt. Der Kopf der Warteschlange befindet sich im System-COMMON-Bereich (SYSCM). Das Betriebssystem baut diese Warteschlange nach dem FIFO-Prinzip ab. Zur Abarbeitung kommt jeweils die Interruptbehandlungsrou- tine, deren Fork-Speicher im Kopf der Fork-Warteschlange steht. Erhaelt die Interruptroutine die Steuerung, werden automatisch die Register PC, R4 und R5 wieder mit den geretteten Werten aus dem Fork-Speicher geladen, die Fork-Warteschlange wird weiter- geschaltet und die Abarbeitung der Interruptbehandlungsroutine mit dem Befehl nach dem CALL $FORK mit der Prioritaet PR0 fortgesetzt. Auf der Ebene der FORK-Prozesses sind alle Register verfuegbar. Beim Ausloesen des FORK-Prozesses (CALL $FORK, siehe auch Ab- schnitt 4.6.) ist dafuer zu sorgen, dass in der Zeit vom Aufruf des $FORK bis zum Weiterschalten der FORK-Schlange und dem An- sprung der Weiterbearbeitung des Programms kein Interrupt von der Anschlusssteuereinheit, die dem aktuellen SCB zugeordnet ist, ausgeloest wird. Damit wird ein Ueberschreiben des FORK- Blocks verhindert. Ein Programm, das unter der Steuerung des Fork-Prozesses laeuft, nimmt einen Zwischenstatus zwischen einer reinen Interruptroutine und einer gewoehnlichen Task ein. Seine Abarbeitung wird wie folgt gesteuert:  34 a) Vorrangmaessig am hoechsten stehen die Interruptroutinen, die den Systemstack als Rettungspuffer benutzen. Sie koennen nur durch Forderungen hoeherer Prioritaet unterbrochen werden. b) Ist nach Abarbeitung einer solchen, unter a) genannten Inter- ruptbehandlungsroutine der Systemstack leer, d.h. steht keine weitere dieser Routinen zur Verarbeitung an, so wird als naechstes die Routine abgearbeitet, deren Fork-Speicher- Adresse im Kopf der Fork-Warteschlange steht. c) Sind sowohl der Systemstack als auch die Fork-Warteschlange leer, wird die Task mit der hoechsten Prioritaet abgearbeitet. 3.2. Forderungen an den Quellcode des Drivers und seiner Datenbasis -------------------------------------------------------- Beim Programmieren des Drivers und seiner Datenbasis sind fuer den Quellcode folgende Vorschriften einzuhalten: - Folgende globale Symbole muessen enthalten sein: (xx ist das zwei KOI-7-Zeichen umfassende Geraetemnemonik) $xxTBL:: Adresse der DDT $xxINT:: Adresse des Eintrittspunkts des Driver-Interrupt- behandlungsteils bei Nichtvollduplex-Geraeten $xxINP:: ) Adresse von Ein- und Ausgabe-Interrupt- ) eintrittspunkten bei Drivern $xxOUT:: ) fuer Vollduplexgeraete Nur fuer ladbare Datenbasen: $xxDAT:: Anfangsadresse der Datenbasis $xxEND:: Endeadresse der Datenbasis sowie nur fuer residente Datenbasen: $USRTB:: Anfang der Datenbasis (Beginn DCB) $USRCI:: Anfang der CIB bei residenter Datenbasis (Symbol entfaellt, wenn keine nutzereigenen CIB definiert werden) $xxCIB:: Anfang der CIB-Kette bei nutzereigenem Driver - Innerhalb der Quellen des Drivers und der Datenbasis sind fuer folgende Eintrittspunkte die folgenden lokalen Symbole zu ver- wenden: xxINI: Adresse des Eintrittspunkts des Initiatorteils des Drivers xxCAN: Adresse des Eintrittspunkts des E/A-Abbruchteils des Drivers  35 xxOUT: Adresse des Eintrittspunkts des Geraeteausfall-Be- handlungsteils des Drivers xxPWF: Adresse des Eintrittspunkts des Netzausfall-Behand- lungsteils des Drivers - Liegt ein ladbarer Driver vor, muss die Quelle oder die Systemdatei OMXMC.MAC das Symbol LD$xx enthalten. - Liegt ein residenter Driver vor, muss die Datenbasis den Interruptvektor als ASECT enthalten. - Fuer die Adressierung der Datenbasis vom Driver aus sind die festgelegten Symboldefinitionen der Datei [1,1]EXEMC.MLB zu verwenden. - Die Datenfelder der Datenbasis sind in der folgenden Reihenfol- ge im Quellcode anzuordnen: DCB, UCB, SCB sowie -falls vorhanden - CIB. - Weiterhin sind fuer eine ladbare Datenbasis folgende Festlegungen zu beachten: . Im DCB ist die Zelle D.DSP (Adresse der Tabelle der Eintrittspunkte des Drivers) mit Null zu initialisieren (siehe Abschnitt 2.2.3.).Die Adresse wird erst beim Laden des Drivers eingetragen. . Der DCB ist um den Parameter D.PCB zu erweitern (Adresse des Partitionsteuerblocks, siehe Abschnitt 2.2.3.). . Der Interruptvektor des Geraets wird beim MCR-Kommando LOA aufgebaut. Er erscheint nicht in der Datenbasis. . Der SCB eines ladbaren Drivers hat einen auf 5 Plaetze erweiterten FORK-Speicher. Das fuenfte Wort enthaelt die Bezugsadresse der Partition, in der der Driver arbeitet. . Es ist kein CIB notwendig. Die Anschlusssteuereinheit muss bereits vor LOA initialisiert sein. - Kommentare sollten mit ";;;" beginnen, wenn der Befehl mit der Prioritaet PR4 oder einer hoeheren Prioritaet ausgefuehrt wird.  36 4. Verfuegbare Exekutiveleistungen ---------------------------------- Von der Exekutive werden verschiedene Systemunterprogramme zur Verfuegung gestellt, mit denen viele Driverfunktionen ausgefuehrt werden koennen. Diese Systemunterprogramme werden im Driver durch: CALL $name (name = Makroname) aufgerufen. 4.1. Adresspruefung eines Puffers $ACHKB/$ACHCK ----------------------------------------------- Mit diesem Unterprogramm wird ueberprueft, ob der Datenpuffer im Adressbereich der zugehoerigen Task liegt. Aufruf: CALL $ACHKB Adresspruefung bei Bytebegrenzung CALL $ACHCK Adresspruefung bei Wortbegrenzung Eingabeparameter: R0: Anfangsadresse des zu pruefenden Datenpuffers R1: Laenge des zu pruefenden Pufferbereichs in Bytes Ausgabeparameter: C = 1 Adressfehler erkannt (Puffer liegt ganz oder teilweise ausser- halb des Adressbereiches der Task) C = 0 Adresse akzeptiert Die Register R0 und R3 werden nicht zerstoert. 4.2. Zuteilen eines Hauptspeicherpuffers $ALOCB ----------------------------------------------- $ALOCB wird aufgerufen, um einen Puffer im dynamischen Speicher- bereich der Exekutive zuzuweisen. Die Laenge des zugeordneten Puffers ist ein Vielfaches von 4 Bytes. Aufruf: CALL $ALOCB Eingabeparameter: R1: Groesse des Puffers in Bytes  37 Ausgabeparameter: C = 1: Es ist kein Puffer verfuegbar C = 0: Es ist ein Puffer zugeteilt R0: Anfangsadresse des zugeordneten Puffers R1: Laenge des zugeordneten Puffers 4.3. Einordnen eines Programms oder eines Programmteils in die Zeit-Warteschlange $CLINS ------------------------------------------------------- $CLINS wird benutzt, um einen Programmteil oder ein Programm zeitweilig von der Bearbeitung zu suspendieren. Nach einer ein- stellbaren Zeit wird das Programm an einer zu bezeichnenden Adresse fortgesetzt bzw. gestartet. Durch $CLINS wird ein Infor- mationsblock benutzt, der vom Nutzer zur Verfuegung gestellt werden muss. Bei Drivern wird dieser Block an den SCB angehaengt und beginnt mit dem Offset S.xxCK (xx=Geraetesymbol, S.xxCK muss im SCB definiert werden). Dieser Informationsblock beinhaltet alle noetigen Informationen fuer das Einordnen in die Zeit-Warteschlange. Je nach Typ der Anforderung ist dieser Informationsblock unterschiedlich aufge- baut. Es werden folgende Anforderungstypen unterschieden: C.MRKT = 0 Anforderung zur Deklarierung eines signifikanten Ereignisses C.SCHD = 2 Anforderung von einer Task mit periodischer Wieder- holung C.SSHT = 4 Einzelanforderung von einer Task ohne periodischer Wiederholung C.SYST = 6 Einzelanforderung von einem systeminternen Pro- grammteil (z.B. Driver) C.SYTK = 8. Einzelanforderung von einer systemeigenen Task aus C.CSTP = 10. Stop-Bit loeschen (Bedingung fuer Shuffling) Fuer alle Anforderungstypen ist der erste Teil des Informations- blocks gleich und kann ueber die angegebenen Offset-Adressen erreicht werden:  38 Offset ------------------------------------- C.LNK | Verbindungszelle fuer die Zeit- | | warteschlange | 0 |-----------------------------------| C.RQT | Anforderungstyp | 2 |-----------------------------------| C.EFN | Ereignisflagnummer (nur bei An- | | forderungstyp C.MRKT) | 4 |-----------------------------------| C.TCB | TCB-Adresse oder bei Drivern | | UCB-Adresse | 6 |-----------------------------------| | Absolutzeit (hoeherwertiger Teil) | 10 C.TIM |-----------------------------------| | Absolutzeit (niederwertiger Teil) | 12 ------------------------------------- Der sich anschliessende Blockteil ist anforderungstypabhaengig: Anforderungstyp C.MRKT ---------------------- ------------------------------------------- C.AST | AST-Adresse | C.TIM+ 4 |-----------------------------------------| C.SRC | Flag-Maskenwort fuer die "BIS"-Quelle | C.TIM+ 6 |-----------------------------------------| C.DST | Adresse des "BIS"-Zieles | C.TIM+10 ------------------------------------------- Anforderungstyp C.SCHD ---------------------- ------------------------------------------- C.RST | periodische Intervallzeit in Uhr-Takten | C.TIM+ 4 | (bei 50 Hz 1 Uhrtakt = 20 Millisekunden)| |-----------------------------------------| | | C.TIM+ 6 |-----------------------------------------| C.UIC | UIC | C.TIM+10 ------------------------------------------- Anforderungstyp C.SSHT ---------------------- ------------------------------------------- | | C.TIM+ 4 |-----------------------------------------| | | C.TIM+ 6 |-----------------------------------------| C.UIC | UIC | C.TIM+10 -------------------------------------------  39 Anforderungstyp C.SYST und C.SYTK --------------------------------- ------------------------------------------- C.SUB | Adresse des zu startenden Programmteils | C.TIM+ 4 |-----------------------------------------| C.AR5 | Virtuelle Basisadresse (APR5) | C.TIM+ 6 |-----------------------------------------| | nicht verwendet | C.TIM+10 ------------------------------------------- Aufruf: CALL $CLINS Eingabeparameter: R0: Anfangsadresse des Informationsblockes (bei Drivern = S.xxCK) R1: Hoeherwertiger Teil der Absolutzeit R2: Niederwertiger Teil der Absolutzeit (Die Zeit ist in Uhr-Takten anzugeben) R4: Anforderungstyp R5: TCB-Adresse bzw. bei Drivern UCB-Adresse Vor dem Aufruf ist ausserdem die Adresse des zu startenden Pro- grammteils (bei Drivern als globale Adresse $xxCLK zu vereinba- ren) in C.SUB einzutragen. Ausgabeparameter: Die Anforderung ist in die Zeit-Warteschlange eingetragen. Bemerkung: Beim Start des Programmteils wird in R4 die Adresse des Informa- tionsblocks uebergeben. Mit Hilfe dieser Adresse ist es moeglich, bei Drivern die UCB-Adresse aus dem Informationsblock zu erhalten und die Register R4 und R5 mit den notwendigen Werten zu laden. 4.4. Freigeben eines Hauptspeicherpuffers $DEACB ------------------------------------------------ $DEACB wird benutzt um einen mit $ALOCB zugewiesenen Puffer wie- der aus dem dynamischen Speicherbereich freizugeben: Aufruf: CALL $DEACB Eingabeparameter: R0: Anfangsadresse des freizugebenden Puffers R1: Groesse des Puffers in Bytes Ausgabeparameter: Der Bereich ist freigegeben. 4.5. Ausgabe von Geraetemitteilungen $DVMSG ------------------------------------------- $DVMSG wird aufgerufen, um der Mitteilungsroutine fuer Taskab- bruch eine Mitteilung ueber eine fehlerhafte E/A-Operation zu uebergeben. Aufruf: CALL $DVMSG  40 Eingabeparameter: R0: Nachrichtencode Als Nachrichtencode ist der numerische Wert zu verwenden, der den unten angegebenen Symbolen vom Betriebssystem mittels Direktzuweisung zugeordnet wird. R5: Adresse des UCB Ausgabeparameter: Von $DVMSG wird ein vier Worte langer Block erstellt, der im zweiten und dritten Wort die Parameter, die in R0 und R5 uebergeben wurden, enthaelt. Dieser Block ist in die Warteschlange fuer die Mitteilungsroutine fuer Taskabbruch eingeordnet. Ist keine Mitteilungsroutine fuer Taskabbruch installiert oder wurde kein Block aufgebaut, wird die Nachrichtenanforderung ignoriert. Als Eingabeparameter fuer R0 koennen fuer Driver nur die folgenden zwei Symbole verwendet werden, die in einem MOV-Befehl mit direkter Adressierung spezifiziert werden koennen: T.NDNR - Geraet nicht bereit T.NDSE - Anwahlfehler Nach Anweisen der o.g. Nachrichtencodes werden folgende Mittei- lungen auf dem Bediengeraet ausgegeben: - bei T.NDNR *** xxn: -- NOT READY - bei T.NDSE *** xxn: -- SELECT ERROR wobei: xx = Geraetesymbol n = Geraetenummer 4.6. Ausloesen des Fork-Prozesses durch $FORK --------------------------------------------- $FORK wird benutzt, um den Fork-Prozess innerhalb einer Inter- ruptbehandlungsroutine auszuloesen (siehe Abschnitt 3.1.). Aufruf: CALL $FORK Eingabeparameter: R5: Anfangsadresse des UCB Ausgabeparameter: R4 und R5 sind im Fork-Speicher des SCB geret- tet. Der Fork-Speicher ist in die Fork-Warte- schlange eingeordnet. Es wird danach automatisch zu $INTXT verzweigt.  41 Bemerkungen: - $FORK kann nicht gerufen werden, wenn $INTSV vorher nicht ge- rufen wurde. - Der laufende Time-out-Zaehler im SCB (siehe Abschnitt 2.2.4.) wird geloescht. - Das Loeschen des Time-out-Zaehlers im SCB kann durch zwei Mass- nahmen verhindert werden: a) Ausfuehrung der Zeitueberwachungsfunktion durch Eintragen in die Uhrwarteschlange b) Aufruf von $FORK1 statt $FORK - Der Driver darf bei Aufruf von $FORK keine Informationen im Stack haben. - In der Zeit vom Aufruf des $FORK bis zur Weiterarbeit des Pro- gramms muss dafuer gesorgt werden, dass keine Interrupts von der Anschlusssteuereinheit ausgeloest werden, die dem aktuellen SCB zugeordnet ist, um ein Ueberschreiben des FORK-Blockes zu verhindern. 4.7. Ausloesen des Fork-Prozesses durch $FORK1 ---------------------------------------------- $FORK1 wird vom Driver zur Ausloesung des Fork-Prozesses (siehe Abschnitt 3.1.) gerufen. Im Gegensatz zu $FORK wird bei seiner Abarbeitung der Time-out-Zaehler nicht geloescht. Aufruf: CALL $FORK1 Eingabeparameter: R4: Adresse des vierten Wortes des Fork-Spei- chers im SCB Ausgabeparameter: R5 wird im Fork-Speicher gerettet und dieser in die Fork-Warteschlange eingereiht. Danach wird zu $INTXT verzweigt. Bemerkungen: - Bei ladbaren Drivern wird im SCB ein fuenf Worte langer Fork- Speicher benoetigt (siehe Abschnitt 2.2.4.). - Wenn ein 5-Worte-Fork-Speicher benoetigt wird, muss der Driver das fuenfte Wort mit der Basisadresse (32-Wortblock-Nr.) der Driverpartition beschreiben. - Der Driver darf bei Aufruf von $FORK1 keine Informationen im Stack haben.  42 4.8. Bereitstellen eines Bytes vom Nutzerpuffer $GTBYT ------------------------------------------------------ $GTBYT wird benutzt zur Eingabe des aktuellen Bytes vom Nutzer- puffer in den Stack. Dabei werden die Worte U.BUF und U.BUF+2 des UCB (siehe Abschnitt 2.2.5.) genutzt und aktualisiert. Aufruf: CALL $GTBYT Eingabeparameter: R5: Adresse des UCB Ausgabeparameter: Das aktuelle Byte ist vom Nutzerpuffer in den Stack gebracht worden. Die naechste Byteadresse ist eingestellt. R0 ... R5 werden waehrend der Abarbeitung von $GTBYT nicht veraendert. 4.9. Holen eines Wortes vom Nutzerpuffer $GTWRD ----------------------------------------------- Die Routine wird wahlweise (Generierungsoption) in das Betriebssystem eingefuegt. $GTWRD wird zur Eingabe des aktuellen Wortes vom Nutzerpuffer auf den Stack gerufen. Dabei werden die Worte U.BUF und U.BUF+2 des UCB (siehe Abschnitt 2.2.5.) genutzt und aktualisiert. Aufruf: CALL $GTWRD Eingabeparameter: R5: Adresse des UCB Ausgabeparameter: Das aktuelle Wort ist vom Anwenderpuffer in den Stack transportiert worden. Die Adresse des naechsten Wortes ist fuer die naechste Trans- feroperation eingestellt. R0 und R5 werden waehrend der Abarbeitung nicht veraendert. 4.10. Aufrufen des naechsten E/A-Pakets in der Warte- schlange $GTPKT ----------------------------------------------------- $GTPKT wird von den Drivern gerufen, um die naechste E/A-Anforde- rung aus der Warteschlange auszureihen und dem Driver bereitzustellen. Steht eine E/A-Anforderung an und ist die Anschlusssteuereinheit zu einer Uebertragung bereit, so wird das im Kopf der Warte- schlange stehende E/A-Paket fuer die Ausfuehrung der E/A-Anfor- derung verfuegbar gemacht. Die Parameter fuer U.BUF, U.BUF+2 und U.CNT im UCB werden aus dem E/A-Paket in den UCB uebernommen, das S.STS-Bit im SCB gesetzt und zum rufenden Programm zurueckge- kehrt.  43 Aufruf: CALL $GTPKT Eingabeparameter: R5: Anfangsadresse des UCB Ausgabeparameter: C = 1 Es steht kein E/A-Paket in der Warte- schlange, oder die Anschlusssteuereinheit ist besetzt. C = 0 Das E/A-Paket ist ordnungsgemaess aus der Warteschlange ausgereiht worden. R1: Adresse des E/A-Paketes R2: Nummer des Geraets an der Anschluss- steuereinheit R3: Index der Anschlusssteuereinheit R4: Anfangsadresse des SCB R5: Anfangsadresse des UCB Bemerkungen: Wird vom $GTPKT eine QIO$-Anweisung mit IO.ATT bzw. IO.DET entschluesselt, so wird bei gesetztem UC.ATT-Steuerbit (siehe Abschnitt 2.2.5.) der Driver zu einer speziellen Behandlung dieser Anweisung aktiviert. Ist das Steuerbit nicht gesetzt, wird die Anweisung ohne den Driver ausgefuehrt. 4.11. Interruptrettungsroutine $INTSV ------------------------------------- $INTSV muss von der Interruptbedienroutine gerufen werden, wenn die Behandlung eines Interrupts laenger als 100 Mikrosekunden dauert (siehe Abschnitt 3.1.). Der Algorithmus dieses Unterpro- gramms sieht wie folgt aus:  44 |------| |$INTSV| |------| | |- Inhalt R5 und R4 in | den laufenden Stack | |- $STKDP:= $STKDP-1 | |- $STKDP = 0? | nein |.----------------------| |_ | |ja | |- Retten des aktuellen | | Stackpointers | | | |- Setzen des System- | | Stackpointers | | | |<----------------------| | |- Laden der im Aufruf | spezifizierten Prioritaet | | |------| |RETURN| |------| $STKDP ist der sogenannte Stacktiefenindikator. $STKDP ist Null beim Uebergang vom Nutzerstack zum Systemstack. Die Interruptbehandlungsroutine darf den durch $INTSV eingestell- ten Zustand nur durch Aufruf des Unterprogramms $FORK, durch einen Sprung zu $INTXT oder durch Ausfuehrung eines RETURN beenden. Aufruf: CALL $INTSV,PRn n = 0...7 (Prioritaet) Eingabeparameter: 4(SP) = PS-Wort-Inhalt 2(SP) = PC-Inhalt 0(SP) = Inhalt von R5 bei Aufruf JSR R5, $INTSV 0(R5) = neue Prioritaet (PRn) Ausgabeparameter: R5 und R4 sind in den aktuellen Stack abgelegt worden, und die Bearbeitung des Interrupts wird unter der angegebenen und eingestellten Prio- ritaet weitergefuehrt.  45 Bemerkungen: R4 und R5 werden beim Verlassen der Routine wiederhergestellt. Ein ladbarer Driver darf $INTSV nicht direkt aufrufen (siehe Abschnitt 4.12.). 4.12. Interruptmakro INTSV$ --------------------------- Der Aufruf der unter Abschnitt 4.11. beschriebenen Routine $INTSV ist in der o.g. Form von einem ladbaren Driver aus nicht zulaessig. Der in $INTSV durchgefuehrte Rettevorgang muss beim Eintritt in den Driver in einem solchen Fall schon ausgefuehrt sein. Bei ladbaren Drivern wird durch das MCR-Kommando LOAD im dynamischen Speicher ein sogenannter Interruptsteuerblock (ICB) aufgebaut, der bei einer zu bearbeitenden Unterbrechung die Steuerung erhaelt, die Routine $INTSV aufruft und folgende zusaetzliche Handlungen ausfuehrt: - Retten der Adresszuweisung des APR5 - Laden der Adresszuweisung des Drivers ins APR5 - Start des Drivers - Wiederherstellen der Adresszuweisung nach dem Ruecksprung Die Interruptvektoren zeigen in diesem Fall nicht auf den Inter- rupteintrittspunkt des Drivers, sondern auf diesen ICB. Die Driver sind jedoch im allgemeinen fuer alle auftretenden Faelle zu entwickeln. Es ist deshalb dringend anzuraten, in Drivern den Makro INTSV$ zu verwenden. Der Makro INTSV$ ist ein universelles Programm. Er kann bei ladbaren und residenten Drivern verwendet werden. Das wird dadurch erreicht, dass sein Quellcode durch eine bedingte Assemblierung allen Erfordernissen angepasst wird. Aufruf: INTV$ xx,pri,nctlr[,pssave,ucbsave] wobei: xx: 2 Zeichen umfassendes Geraetesymbol pri: Geraeteprioritaet (wie bei $INTSV) nctlr: Anzahl der Anschlusssteuereinheiten, die der Driver bedient pssave: Wahlparameter, gibt die Adresse eines Speicher- platzes im Driver an, auf dem der Inhalt des Prozessorstatuswortes gerettet wird. Das Prozes- sorstatuswort enthaelt beim Aufruf INTSV$ den Inhalt des zweiten Worts des Interrupvektors. Falls pssave nicht im Aufruf definiert ist, muss im Driver eine Rettungszelle mit der Adresse TEMP zur Verfuegung gestellt werden, auf die INTSV$ zugreifen kann. ucbsave: Wahlparameter, gibt die Anfangsadresse eines Blocks im Driver an, der die UCB-Adressen der unterbrechenden Geraete enthalten. Ist UCBSAVE nicht angegeben, muss der im Driver bereitge- stellte Block die Anfangsadresse CNTBL haben.  46 Ausgabeparameter: R4: Index der Anschlusssteuereinheit (nur, wenn nctlr groesser als 1 ist) R5: UCB-Adresse 4.13. Abspeichern eines Bytes im Nutzerpuffer $PTBYT ---------------------------------------------------- $PTBYT kann gerufen werden, um ein Byte vom Stack auf die naech- ste Position im Nutzerpuffer zu transportieren. Aufruf: CALL $PTBYT Eingabeparameter: R5: Anfangsadresse des UCB Vor dem Aufruf des Unterprogramms ist das abzuspeichernde Byte in den Stack zu transportieren. Ausgabeparameter: Das Byte ist im Nutzerpuffer abgespeichert und aus dem Stack entfernt. Durch Nutzung der Parameter U.BUF und U.BUF+2 im UCB wird die naechste Abspeicheradresse im Nutzerpuffer festgelegt. 4.14. Abspeichern eines Wortes im Nutzerpuffer $PTWRD ----------------------------------------------------- Die Routine wird wahlweise (Generierungsoption) in das Betriebssystem eingefuegt. $PTWRD kann gerufen werden, um ein Wort vom Stack auf den Nutzer- puffer zu transportieren. Dabei werden die Worte U.BUF und U.BUF+2 des UCB (siehe Abschnitt 2.2.5.) genutzt und aktualisiert. Aufruf: CALL $PTWRD Eingabeparameter: R5: Anfangsadresse des UCB Vor dem Aufruf des Unterprogramms ist das abzuspeichernde Wort in den Stack zu transpor- tieren. Ausgabeparameter: Das Wort ist im Nutzerpuffer abgespeichert und aus dem Stack entfernt. Die naechste Abspei- cheradresse im Nutzerpuffer wird in U.BUF und U.BUF+2 bereitgestellt. Registerinhalte werden nicht veraendert. 4.15. Prioritaetsabhaengiges Einordnen in eine Warte- schlange $QINSP ----------------------------------------------------- Bei gesetztem Steuerbit UC.QUE unter der Adresse U.CTL im UCB (siehe Abschnitt 2.2.5.) wird der Driver von der Warteschlangen- organisation aufgerufen, bevor das E/A-Paket in die Warteschlange eingereiht ist. Der Driver ist in diesem Fall selbst fuer die ordnungsgemaesse Verwaltung des E/A-Pakets verantwortlich. Die Einreihung in die Warteschlange kann vom Driver aus durch den Ruf von $QINSP erfolgen.  47 Aufruf: CALL $QINSP Eingabeparameter: R0: Adresse des Geraetewarteschlangenkopfes S.LHD aus dem SCB (siehe Abschnitt 2.2.4.) R1: Adresse des E/A-Pakets Ausgabeparameter: Das E/A-Paket ist in die Warteschlange einge- reiht worden. Die Register R0 und R1 werden nicht zerstoert. 4.16. Abschliessen der Interruptbehandlung $INTXT ------------------------------------------------- Zum Abschliessen eines Interruptbehandlungsprogramms kann vom Driver-Interruptbehandlungsteil $INTXT benutzt werden. Aufruf: JMP $INTXT Eingabeparameter: 06(SP): aktuelles PS zum Zeitpunkt des Interrupts 04(SP): aktueller PC zum Zeitpunkt des Interrupts 02(SP): Inhalt von R5 00(SP): Inhalt von R4 Die angegebenen Parameter werden bei einer Unterbrechung automa- tisch vom Betriebssystem eingestellt. Ausgabeparameter: R4 und R5 werden wiederhergestellt. Danach wird die Interruptbehandlungsroutine mittels RTI verlassen. 4.17. Abschluss einer E/A-Anforderung $IOALT/$IODON --------------------------------------------------- Bei Beendigung einer E/A-Anforderung koennen $IOALT oder $IODON vom Driver gerufen werden. Das Geraet und die Anschlusssteuerein- heit werden freigegeben und anschliessend die Steuerung an $IOFIN uebergeben. Aufruf: CALL $IOALT (alternativer Eintrittspunkt) Dieser Eintrittspunkt ist zu verwenden, wenn das zweite E/A-Statuswort den Wert Null erhalten soll. CALL $IODON  48 Eingabeparameter: R0: 1. E/A-Statuswort R1: 2. E/A-Statuswort (nur bei Aufruf von $IODON R2: Anfangs- und Endzaehler bei Geraeten, deren Driver fuer die Programme der Fehlerregi- strierung ausgelegt sind. R5: Anfangsadresse des UCB Ausgabeparameter: R3: Adresse des aktuellen E/A-Pakets R4: ist zerstoert 4.18. Beendigung einer E/A-Anforderung $IOFIN --------------------------------------------- $IOFIN wird selten von einem Driver aufgerufen. Sein Aufruf er- folgt meist von $IOALT bzw. $IODON aus. Ein Driver, der von der Warteschlangenorganisation aufgrund des gesetzten Steuerbits UC.QUE im UCB (siehe Abschnitt 2.2.5.) ge- rufen wurde, ruft $IOFIN auf, wenn er einen Fehler in den E/A- Parametern findet. Aufruf: CALL $IOFIN Eingabeparameter: R0: 1. E/A-Statuswort R1: 2. E/A-Statuswort R3: Anfangsadresse des E/A-Pakets R5: Anfangsadresse des UCB Ausgabeparameter: Folgende Aktionen werden von $IOFIN ausgefuehrt: - Der E/A-Status wird in den Statusblock gespeichert (falls er gewuenscht wurde) - Der E/A-Anforderungszaehler wird erniedrigt. - Ist TS.CKR im TCB der Task gesetzt, wird dieses Bit geloescht und die Auslagerung der Task aktiviert. - Ist eine AST-Routine spezifiziert worden, so erfolgt deren Einreihung in die AST-Warteschlange. Ansonsten wird das E/A- Paket aus der Warteschlange entfernt. - Ein signifikantes Ereignis wird deklariert. R4 wird zerstoert. 4.19. Umwandeln einer virtuellen 16-bit-Adresse in eine Bezugsbasis $RELOC ------------------------------------------------------- Mit $RELOC wird eine virtuelle 16-bit-Adresse in ein Adressdoppelwort umgewandelt, das die Benutzung von 18-bit- Adressen gestattet. Das erste Wort enthaelt die Nummer des 32- Worte-Blocks. Das zweite Wort beinhaltet die relative Adresse in diesem Block und verweist auf APR6. $RELOC wird meist von Drivern genutzt, die wegen des gesetzten  49 Steuerbits UC.QUE im U.CTL des UCB (siehe Abschnitt 2.2.5.) von der Warteschlangenorganisation vor dem Einreihen des E/A-Pakets in die Warteschlange und damit vor Umwandlung der Pufferadresse aufgerufen werden. Aufruf: CALL $RELOC Eingabeparameter: R0: umzuwandelnde virtuelle Adresse Ausgabeparameter: R1: Nummer des 32-Worte-Blocks R2: Adresse innerhalb des Blocks plus 14000 (oktal), Verweis auf APR6 R0 und R3 werden nicht zerstoert. 4.20. Initialisieren eines Datenkanals einer Anschluss- steuereinheit AIS $IFSSI ------------------------------------------------------- Mit Hilfe dieses Systemunterprogramms kann die Initialisierung eines Datenkanals einer beliebigen Anschlusssteuereinheit AIS vorgenommen werden. Diese Initialisierung macht den jeweiligen Datenkanal betriebsfaehig. Dieses Unterprogramm muss im Netzaus- fall-Behandlungsteil des Drivers angesprungen werden. Es wird dann bei Systemanlauf, waehrend des Ladevorgangs durch das MCR- Kommando LOAD und bei Netzwiederkehr nach Netzausfall abgearbei- tet. Aufruf: CALL $IFSSI Eingabeparameter: R4: SCB-Adresse R5: UCB-Adresse R0: Wert fuer Schreibregister SR3 R1: Wert fuer Schreibregister SR5 R2: Wert fuer Schreibregister SR1 R3: Wert fuer Schreibregister SR4 Ausgabeparameter: C=0: Der Datenkanal der AIS ist initialisiert. C=1: Geraet ist off-line, keine Initialisierung R4: CSR-Adresse R2,R3 und R4 sind unveraendert.  50 5. Programmieren und Einbinden eines Drivers -------------------------------------------- 5.1. Einleitung --------------- Das Programmieren des Drivers und seiner Datenbasis sowie das Einbinden des Drivers in das BS OMOS 1630 erfolgt abhaengig von der Klassisfizierung des Drivers. Residente Driver haben stets eine residente Datenbasis, wogegen ladbare Driver ueber eine residente oder eine ladbare Datenbasis verfuegen koennen. Driver / | / | / | / | / | / | / | ladbar resident / | | / | | / | | / | | / | | residente ladbare residente Datenbasis Datenbasis Datenbasis Bild 6 Klassifizierung der Driver Da residente Driver bzw. Datenbasen einen festen Bestandteil des BS OMOS 1630 darstellen, ist fuer das Einbinden solcher Driver stets eine Neugenerierung (mindestens Stufe 2) notwendig. Nur ladbare Driver mit ladbarer Datenbasis lassen sich nachtraeglich mit dem MCR-Kommando LOAD in das System einfuegen, so dass fuer Entwicklung und Test nutzereigener Driver diese stets ladbar zu konzipieren sind. 5.2. Programmieren der Datenbasis und der Driverquelle ------------------------------------------------------ Im folgenden wird an einem Beispiel die Prozedur der Programmierung und des Einbindens von nutzereigenen Drivern vorgestellt. Erzeugt werden soll ein residenter Driver mit residenter Daten- basis, der einen Lochbandstanzer bedient. Ausserdem wird auf die Unterschiede zu ladbaren Drivern mit ladbarer bzw. residenter Datenbasis und auf Besonderheiten bei der Arbeit mit speziellen Nutzerpuffern hingewiesen.  51 5.2.1. Anschlusssteuereinheit (AS) ---------------------------------- Da ein Driver die physische Bedienung der Anschlusssteuereinheit uebernimmt, ist die genaue Kenntnis ueber die AS und die daran angeschlossenen Geraete notwendig. Der Lochbandstanzer laesst sich ueber eine Anschlusssteuereinheit mit parallelem Interface (IFSP) an den Rechner K1630 an- schliessen. Sie enthaelt zwei fuer den Programmierer wichtige Register: - Steuer- und Statusregister (CSR) - Datenpufferregister Diese Register befinden sich auf benachbarten Adressen im Bereich der Geraeteregister (IOPAGE, oberhalb 160000 oktal) und koennen ueber das Offset S.CSR im SCB erreicht werden. Das CSR-Register ermoeglicht die Steuerung der AS und liefert aktuelle Statusmeldungen zur laufenden E/A-Operation. Das sind z.B. - Bit 6 (Wertigkeit 100) Interrupt erlaubt - Bit 7 (Wertigkeit 100000) Fehler aufgetreten Nach Eintragen des zu stanzenden Zeichens in das Datenpufferregister uebertraegt die AS das Byte an den Stanzer und antwortet mit einem Interrupt, der die Bearbeitung des naechsten Zeichens oder die Beendigung der Operation einleitet. Voraussetzung fuer die Nutzung einer Anschlusssteuereinheit des Rechners K1630 ist ihre Initialisierung, die fuer alle bei der Systemgenerierung angegebenen AS zum Zeitpunkt des Systemanlaufs durchgefuehrt wird. Dabei arbeitet die Routine INITL die Kette der Initialisierungsbloecke (vgl. 2.2.6.) ab und traegt die dort programmierten Werte (Interruptvektor und CSR-Register-Adresse) in die betreffende AS ein. Erfordert das periphere Geraet, fuer das der Driver entwickelt werden soll, eine AS, die sich noch nicht im System befindet, kann deren Initialisierung ohne Wiederholung der Generierung auf folgende Weise durchgefuehrt werden: . durch eine privilegierte Task, . durch den Bediener, z.B. mit OPE, XDT, Konsol- Emulator-Routine, . durch Erweiterung der CIB-Kette im Plattenabbild des Systems z. B. mit ZAP. 5.2.2. Datenbasis ----------------- 5.2.2.1. Erarbeitung einer residenten Datenbasis ------------------------------------------------ Residente Datenbasen nutzereigener Driver erhalten stets den Namen USRTB und werden in die Kette residenter Datenbasen aus der bei der Systemgenerierung aufgebauten Datei SYSTB.MAC eingefuegt und sind somit ein permanenter Bestandteil der Exekutive. Die drei Datenfelder DCB, UCB und SCB und, falls benoetigt, CIB besitzen eine definierte Struktur und sind anhand der Beschreibungen (siehe 2.2.) in der angegebenen Reihenfolge zu programmieren. Ausserdem sind im Quellcode einer residenten Datenbasis der Aufbau des Interruptvektors vorzusehen und die erste Adresse des DCB als globales Symbol mit $USRTB zu  52 markieren. Sollen mehrere Driver mit residenten Datenbasen eingebunden werden, sind alle Datenbasen im Modul USRTB zusammen- zufassen und die Marke $USRTB auf die erste DCB-Adresse zu setzen. Die beim Programmieren verwendeten Symbole, Offsets und Defini- tionen sind am Anfang der Quelldatei durch entsprechende Rufe der Makro-Bibliothek (Zeilen 4 bis 7 im Beispiel) bzw. durch lokale Direktzuweisungen zu vereinbaren. Wird die Aufloesung von Symbolen noch nicht vom Assembler benoetigt, entnimmt der Task- bilder die fehlenden Definitionen aus den Objektmodul- bibliotheken. Besondere Beachtung soll der Aufbau der Funktionsmasken (Zeilen 21 bis 28 des Beispiels) im DCB finden (vgl. 2.2.3.), welche aus den fuer den Driver relevanten E/A-Funktionen gebildet werden. Tabelle 3 E/A-Funktionen fuer einen Lochbandstanzer Funktionscode Funktion ---------------------------------------------------- KIL Abbruch einer E/A-Funktion WLB Schreiben eines logischen Blockes ATT Geraet an eine Task anschliessen DET Geraet von einer Task trennen ACW Bereitmachen einer Datei fuer Lesen ACE Bereitmachen einer Datei fuer Lesen, Schreiben und Erweitern DAC Sperren einer Datei WVB Schreiben eines virtuellen Blockes ---------------------------------------------------- Eine KIL-Funktion muss stets vorhanden sein, und WLB ist die einzige Transferfunktion. ATT und DET sind Steuerfunktionen.Die drei ATT/DET-Funktionen ACW, ACE und DAC werden zur FCS- und RMS- Kompatibilitaet zugelassen, aber vom Driver nicht bearbeitet, also "NOP" (keine Operation) gesetzt. Ebenfalls zugelassen ist die Funktion WVB. Da diese durch die QIO$-Anweisung in WLB umge- wandelt wird, erfolgt die Eintragung in die ACP-Funktionsmaske. Die Maskenwerte aller zugelassenen Funktionen sind in Tabelle 2 (Abschnitt 2.2.3.) zusammengefasst, woraus nun leicht die ent- sprechenden Funktionsmasken durch Disjunktion gebildet werden koennen. Veraenderungen, die sich durch Verwendung einer ladbaren Datenbasis fuer ladbare Driver ergeben, sind im Abschnitt 5.1.4. dargestellt.  53 5.2.2.2. Programmieren der Datenbasis ------------------------------------- 001 .TITLE USRTB 002 .IDENT /01/ 003 ;STEUERBLOECKE FUER LOCHBANDSTANZER-DRIVER 004 ;MACRO LIBRARY-RUFE 005 .MCALL DEVDF$, HWDDF$ 006 DEVDF$ ;DEFINIERE DCB-OFFSETS 007 HWDDF$ ;DEFINIERE HARDWAREREGISTER 008 009 ;DATENBASIS DES GERAETEDRIVERS FUER EINEN LOCHBANDSTANZER 010 ; 011 ;GERAETETYPSTEUERBLOCK DCB 012 ; 013 $$USRTB:: 014 PPDCB:.WORD 0 ;VERBINDUNGSZELLE ZUM NAECHSTEN DCB 015 .WORD .PP0 ;ZEIGER ZUM 1. UCB 016 .ASCII /PP/ ;CODE DES GERAETENAMENS 017 .BYTE 0,0 ;NIEDRIGSTE UND HOECHSTE GERAETE- 018 ;NUMMER 019 .WORD PPND-PPST;LAENGE DES UCB IN BYTES 020 .WORD $PPTBL ;ADRESSE DER DDT IM DRIVER 021 .WORD 140033 ;LEGALE FUNKTIONSMASKE (BIT 0...15) 022 .WORD 30 ;STEUERFUNKTIONSMASKE (BIT 0...15) 023 .WORD 140000 ;"NOP"-FUNKTIONSMASKE (BIT 0...15) 024 .WORD 0 ;ACP-FUNKTIONSMASKE (BIT 0...15) 025 .WORD 5 ;LEGALE FUNKTIONSMASKE (BIT 16...31) 026 .WORD 0 ;STEUERFUNKTIONSMASKE (BIT 16...31) 027 .WORD 1 ;"NOP"-FUNKTIONSMASKE (BIT 16...31) 028 .WORD 4 ;ACP-FUNKTIONSMASKE (BIT 16...31) 029 ; 030 ;GERAETESTEUERBLOCK UCB 031 ; 032 .PP0:: 033 PPST=. 034 .WORD PPDCB ;ADRESSE DES DCB 035 .WORD .-2 ;ZEIGER ZUM UMADRESSIERTEN UCB 036 .BYTE UC.ATT!UC.PWF,0;STEUERBITS, GERAETESTATUS 037 .BYTE 0,0 ;PHYSISCHE GERAETENUMMER, GERAETE- 038 ;STATUS 039 .WORD DV.REC ;KENNDATENWORT 1 (SATZORIENTIERTES 040 ;GERAET) 041 .WORD 0 ;KENNDATENWORT 2 042 .WORD 0 ;KENNDATENWORT 3 043 .WORD 64. ;KENNDATENWORT 4 (STANDARDPUFFER- 044 ;GROESSE) 045 .WORD PPSCB ;ADRESSE DES STATUSSTEUERBLOCKES 046 .WORD 0 ;TCB-ADRESSE DER ANGESCHLOSSENEN 047 ;TASK 048 .BLKW 1 ;BASISADRESSE DES PUFFERS DER 049 ;AKTUELLEN TASK 050 .BLKW 1 ;PUFFERADRESSE DER AKTUELLEN TASK 051 .BLKW 1 ;BYTEZAEHLER 052 053 PPND=. 054 ; 055 ;STATUSSTEUERBLOCK SCB  54 056 ; 057 PPSCB: .WORD 0 ;GERAETEWARTESCHLANGENKOPF, ADRESSE 058 ;1. E/A-PAKET 059 .WORD .-2 ;ZEIGER ZUM LETZTEN E/A-PAKET 060 .BYTE PR4,74/4;GERAETEPRIORITAET, VEKTORADRESSE/4 061 .BYTE 0,4 ;TIME-OUT-ZAEHLER (LAUFENDER WERT, 062 ;INITIALISIERENDER WERT) 063 .BYTE 0,0 ;NUMMER (INDEX) DER ANSCHLUSS- 064 ;STEUEREINHEIT (0=FREI,1=BESETZT) 065 .WORD 177554 ;ADRESSE DES GERAETESTATUSREGISTERS 066 .BLKW 1 ;ADRESSE DES AKTUELLEN E/A-PAKEts 067 .BLKW 4 ;FORK-SPEICHER 068 ; 069 ;INTERRUPT-VEKTOR 070 ; 071 .ASECT 072 .= 74 ;PLATZ IN DER INTERRUPT-TABELLE 073 .WORD $PPINT ;ADRESSE DES DRIVERINTERRUPTTEILES 074 .WORD PR7!0 ;PRIORITAET DER INTERRUPTQUELLE PR7, 075 ;AS-NR. 076 .PSECT 077 .END 5.2.3. Driverquelle ------------------- 5.2.3.1. Erarbeitung der Driverquelle ------------------------------------- Der im folgenden gezeigte Driver ist ein typisches Beispiel fuer einen Driver im System OMOS 1630. Nach diesem Schema koennen Driver fuer andere Geraete entwickelt werden. Der Driver gliedert sich in die unter Abschnitt 2.1. beschriebe- nen Teile: - E/A-Initiatorteil - Geraeteinterruptbehandlung - E/A-Abbruch - Geraetefehlerabbruch - Netzausfallbehandlung Er akzeptiert die in der Datenbasis in den Funktionsmasken des DCB praezisierten E/A-Funktionen. Vom Driver selbst werden nur die E/A-Funktionen "Schreiben eines logischen Blockes", "Anschliessen eines E/A-Geraetes an eine Task" und "Trennen eines E/A-Geraetes von einer Task" bedient. Die Funktionen Anschliessen und Trennen von einer Task ergeben das Stanzen von 170 NUL-Informationen. Der Driver benutzt die folgenden Systemunterprogramme (siehe Abschnitt 4.): - $INTXT (Interruptabschluss) - $GTPKT (Aufrufen E/A-Paket) - $GTBYT (Byte holen) - $DVMSG (Ausgabe von Fehlermitteilungen)  55 - $FORK (Ausloesen des Fork-Prozesses) $INTSV wird indirekt ueber INTSV$ aufgerufen (siehe Abschnitt 4.11. und 4.12.). Kommentare, die mit ";;;" beginnen, kennzeich- nen, dass die Programmausfuehrung an dieser Stelle auf einer Prioritaetsebene laeuft, die groesser oder gleich 4 ist. Ein E/A-Abbruch mit der Funktion IO.KIL wird nach Setzen des "ABORT"-bits im UCB wie ein Geraete-Time-out durch die Geraetefehler-Abbruchroutine behandelt. Beachtet werden sollte die Einhaltung definierter Namen von Adressen und Symbolen, die mit anderen Dateien und Moduln korrespondieren (siehe auch Abschnitt 3.2.), wie z.B.: . CNTBL (bei INTSV$) . $PPTBL (Datenbasis, fuer LOA) . $PPINT (Datenbasis, fuer LOA) . P$$P16 (fuer OMXMC.MAC, INTSV$) 5.2.3.2. Programmieren der Driverquelle --------------------------------------- 001 .TITLE PPDRV 002 .IDENT /01/ 003 ; 004 ;DRIVER FUER EINEN LOCHBANDSTANZER 005 ; 006 ;MACRO-LIBRARY-RUFE 007 ; 008 .MCALL ABODF$, HWDDF$, PKTDF$, TCBDF$ 009 ABODF$ ;DEFINIERE TASK-ABBRUCH-CODE 010 HWDDF$ ;DEFINIERE HARDWAREREGISTER 011 PKTDF$ ;DEFINIERE E/A-PAKET-OFFSETS 012 TCBDF$ ;DEFINIERE TCB-OFFSETS 013 ; 014 ;SYMBOLDEFINITIONEN 015 ; 016 ;BITDEFINITIONEN FUER KENNDATENWORT 2 DES UCB 017 ; 018 WAIT = 100000 ;WARTEN AUF ON-LINE STATUS 019 ;DES GERAETES 020 ABORT = 40000 ;ABBRECHEN DER LAUFENDEN E/A- 021 ;ANFORDERUNG 022 TRAIL = 200 ;STANZEN EINES 170 NUL-INFORMA- 023 ;TIONEN ENTHALTENDEN VORBLOCKES 024 ; 025 ;LOKALE DEFINITIONEN 026 ; 027 CNTBL: .BLKW P$$P16 ;RETTUNGSZELLEN FUER UCB-ADRESSE 028 ;P$$P16=ANZAHL DER BEDIENBAREN AS 029 .IF GT P$$P16 030 TEMP: .BLKW 1 ;TEMPORAERER SPEICHER FUER AS-INDEX 031 .ENDC 032 ; 033 ;TABELLE DER EINTRITTSPUNKTE DES DRIVERS 034 ; 035 $PPTBL::.WORD PPINI ;EINTRITTSPUNKT INITIATORTEIL 036 .WORD PPCAN ;EINTRITTSPUNKT E/A-ABBRUCH 037 .WORD PPOUT ;EINTRITTSPUNKT GERAETEAUSFALL 038 .WORD PPPWF ;EINTRITTSPUNKT NETZAUSFALLBEHANDLUNG 039 ; 040 ;INITIATORTEIL DES DRIVERS  56 041 ; 042 ;DIESER DRIVERTEIL WIRD VON DER WARTESCHLANGENORGANISATION 043 ;GESTARTET, WENN EINE E/A-ANFORDERUNG IN DIE WARTE- 044 ;SCHLANGE EINGEREIHT UND DIE VORHERIGE E/A-OPERATION BEEN- 045 ;DET IST. IST DIE ANSCHLUSSSTEUEREINHEIT NICHT BELEGT, WIRD 046 ;VERSUCHT DIE NAECHSTE E/A-ANFORDERUNG ZU BEARBEITEN. SONST 047 ;WIRD DER DRIVER MIT RETURN VERLASSEN. 048 ; 049 ;EINGABEPARAMETER: 050 ;R5 = ANFANGSADRESSE DES UCB 051 ;AUSGABEPARAMETER: 052 ;WENN DIE ANSCHLUSSSTEUEREINHEIT NICHT BELEGT WAR UND EINE 053 ;E/A- ANFORDERUNG IN DER WARTESCHLANGE STAND, IST DAS 054 ;ENTSPRECHENDE E/A-PAKET AUS DER WARTESCHLANGE AUSGEREIHT 055 ;UND DIE E/A-OPERATION INITIALISIERT. 056 ; 057 .ENABLE LSB 058 PPINI: CALL $GTPKT ;AUFRUFEN DES E/A-PAKETES 059 BCS RETURN ;RUECKKEHR, WENN DIE ANSCHLUSS- 060 ;STEUEREINHEIT BELEGT IST, ODER 061 ;KEINE E/A-ANFORDERUNG IN DER 062 ;WARTESCHLANGE STEHT. 063 ;IN DIESEM FALL IST C = 1. 064 ;BEI ERFOLGREICHEM VERLASSEN VON $GTPKT (C = 0) WERDEN FOL- 065 ;GENDE PARAMETER AUF DEN ANGEGEBENEN REGISTERN UEBERGEBEN. 066 ;R1 = ADRESSE DES E/A-PAKETES 067 ;R2 = PHYSISCHE GERAETENUMMER 068 ;R3 = INDEX DER ANSCHLUSSSTEUEREINHEIT 069 ;R4 = ANFANGSADRESSE DES SCB 070 ;R5 = ANFANGSADRESSE DES UCB. 071 ; 072 MOV R5,CNTBL(R3) ;RETTEN DER UCB-ADRESSE FUER 073 ;DIE INTERRUPTBEHANDLUNG 074 CLR U.CW2(R5) ;LOESCHEN CW2 075 CMPB I.FCN+1(R1),#IO.WLB/256 ;GEFORDERTE FUNK- 076 ;TION WLB? 077 BEQ 10$ ;WENN EQ, DANN JA 078 BIS #TRAIL,U.CW2(R5);FUNKTION IST ATT ODER 079 ;DET, BITSETZEN FUER DAS 080 ;STANZEN DES VORSPANNS 081 MOV #170.,U.CNT(R5) ;BYTEZAEHLER ZUM STANZEN 082 ;VON 170. NUL-INFORMATIONEN 083 ;EINSTELLEN 084 10$: BIS #WAIT,U.CW2(R5) ;WARTEBIT IN CW2 SETZEN 085 TST @S.CSR(R4) ;TEST GERAETESTATUSREGISTER: 086 ;GERAET OFF-LINE? 087 BMI 80$ ;JA 088 20$: BIC #WAIT,U.CW2(R5) ;WARTEBIT IN CW2 LOESCHEN, 089 ;DA GERAET ON-LINE 090 MOVB S.ITM(R4),S.CTM(R4);TIME-OUT-ZAEHLER IN SCB 091 ;SETZEN 092 MOV #100,@S.CSR(R4);INTERRUPTS ERLAUBEN, STARTEN 093 ;DES STANZERS 094 RETURN: RETURN ;RUECKSPRUNG INS RUFENDE 095 ;PROGRAMM 096 ; 097 ;INTERRUPTBEHANDLUNGSTEIL DES DRIVERS 098 ; 099 $PPINT:: 100 INTSV$ PP,PR4,P$$P16 ;;;INTERRUPT RETTEN UND  57 101 ;;;VERRINGERN DER PRIORITAET 102 ;;;AUF PR4 DURCH 103 ;;;MAKRO INTSV$ 104 ;WAEHREND DER ABARBEITUNG DES SYSTEMMAKROS INTSV$ WIRD MIT DEM 105 ;BEFEHL MOV CNTBL,R5 DIE UCB-ADRESSE WIEDER AUF R5 EINGETRAGEN 106 MOV U.SCB(R5),R4 ;;;R4:= SCB-ADRESSE 107 MOVB S.ITM(R4),S.CTM(R4);;;TIME-OUT-ZAEHLER RUECK- 108 ;;;SETZEN 109 MOV S.CSR(R4),R4 ;;;R4:= CSR-ADRESSE 110 MOV (R4)+,U.CW3(R5) ;;;GERAETESTATUS AUF CW3 DES 111 ;;;UCB EINTRAGEN, R4 ENTHAELT 112 ;;;NACH BEFEHLSAUSFUEHRUNG 113 ;;;DIE ADRESSE DES GERAETE- 114 ;;;PUFFERREGISTERS 115 BMI 60$ ;;;FEHLERAUSGANG 116 SUB #1,U.CNT(R5) ;;;BYTEZAEHLER UM 1 117 ;;;VERRINGERN 118 BCS 50$ ;;;ALLE ZEICHEN AUSGEGEBEN 119 TSTB U.CW2(R5) ;;;TRAIL-BIT IM CW2 GESETZT? 120 BPL 30$ ;;;NEIN, ES WIRD KEIN VOR- 121 ;;;SPANN GESTANZT 122 CLRB (R4) ;;;NUL-INFORMATION INS PUF- 123 ;;;FERREGISTER 124 BR 40$ ;;; 125 30$: CALL $GTBYT ;;;NAECHSTES BYTE VOM NUTZER 126 ;;;HOLEN 127 MOVB (SP)+,(R4) ;;;LADEN DES BYTES INS 128 ;;;PUFFERREGISTER 129 40$: JMP $INTXT ;;;VERLASSEN DES INTERRUPT- 130 ;;;TEILS DES DRIVERS 131 50$: INC U.CNT(R5) ;;;RUECKSETZEN BYTEZAEHLER 132 60$: CLR -(R4) ;;;LOESCHEN GERAETESTATUSREGI- 133 ;;;STER, R4 = ADR. STATUSREG. 134 CALL $FORK ;;;AUSLOESEN DES FORK-PROZESSES 135 MOV U.SCB(R5),R4 ;R4 = SCB-ADRESSE 136 MOV S.PKT(R4),R1 ;R1 = ADRESSE DES AKTUELLEN 137 ;E/A-PAKETS 137 MOV I.PPM+4(R1),R1 ;R1 = ZEICHENZAEHLER 139 SUB U.CNT(R5),R1 ;VERRINGERN DES ZEICHENZAEH- 140 ;LERS UM DEN BYTEZAEHLER 141 MOV #IE.SUC+377,R0 ;CODE FUER ERFOLGREICHEN 142 ;TRANSFER 143 TST U.CW3(R5) ;GERAETEFEHLER? 144 BPL 70$ ;NEIN 145 65$: MOV #IE.VER+377,R0 ;CODE FUER HARDWAREFEHLER 146 70$: CALL $IODON ;ABSCHLUSS E/A-ANFORDERUNG 147 BR PPINI ;SPRUNG ZUR NAECHSTEN E/A- 148 ;ENTSCHLUESSELUNG 149 ; 150 ;GERAETEFEHLERABBRUCHTEIL DES DRIVERS 151 ; 152 PPOUT: CLRB S.CSR(R4) ;;;LOESCHEN INTERRUPTERLAUB- 153 ;;;NISBIT 154 CLRB PS ;;;LOESCHEN PS, ERLAUBEN 155 ;;;ALLER INTERRUPTS 156 80$: MOV #IE.DNR+377,R0 ;CODE BEREITSCHAFTSFEHLER 157 MOV U.CW2(R5),R1 ;WAIT-BIT IN CW2 GESETZT? 158 BPL 70$ ;NEIN, E/A-ENDE 159 MOV #IE.ABO+377,R0 ;CODE E/A-ABBRUCH 160 ASL R1 ;ABORT-BIT IN CW2 GESETZT?  58 161 BMI 70$ ;JA, E/A-ENDE 162 TST S.CSR(R4) ;STANZER BEREIT? 163 BPL 20$ ;JA 164 MOV #T.NDNR,R0 ;CODE FUER NICHTBEREIT 165 MOVB #1,S.CTM(R4) ;TIME-OUT-ZAEHLER=1 SEKUNDE 166 DECB G.STS(R4) ;AUSGABEMITTEILUNGSZEIT=NULL? 167 BNE RETURN ;NEIN 168 MOVB #15.,S.STS(R4) ;SETZEN AUSGABEMITTEILUNGS- 169 ;ZEIT 15 SEKUNDEN 170 CALLR $DVMSG ;AUSGABEMITTEILUNG 171 .DSABL LSB 172 ; 173 ;E/A-ABBRUCHTEIL DES DRIVERS 174 ; 175 PPCAN: CMP R1,I.TCB(R0) ;;;E/A-ANFORDERUNG VON 176 ;;;AKTUELLER TASK? 177 BNE 10$ ;;;NEIN 178 BIS #ABORT,U.CW2(R5);;;ABORTBIT IN CW2 SETZEN 179 10$: RETURN ;;;RUECKKEHR 180 ; 181 ;NETZAUSFALLBEHANDLUNGSTEIL DES DRIVERS 182 ; 183 PPPWF: RETURN 184 .END 5.2.4. Vorschriften fuer ladbare Datenbasen ------------------------------------------- Ladbare Datenbasen koennen nur von ladbaren Drivern verwendet werden (vgl.Einleitung Kapitel 5). Durch Nutzung der Assembleran- weisungen zur bedingten Uebersetzung laesst sich die Quelldatei der Datenbasis universell gestalten. Die in Abschnitt 3.2. gege- bene Uebersicht fasst die zu verwendenden Symbole und Namen bei der Programmierung einer ladbaren Datenbasis zusammen. 5.2.5. Behandlung spezieller Nutzerpuffer ----------------------------------------- Einige Driver brauchen fuer die Ausfuehrung der geforderten E/A- Operationen spezielle Informationen, die der Anwender in beson- deren Puffern zur Verfuegung stellen muss. Die Behandlung dieser Puffer erfordert, dass Adresspruefungsoperationen und Adressum- wandlungsoperationen (mit $RELOC s. Abschnitt 4.19.) zum Einstel- len der APR ausgefuehrt sein muessen, bevor das Systemunterpro- gramm $GTPKT gerufen wird, da im Normalfall der dann eingestell- te Status nicht mehr dem der die E/A-Anforderung aussendenden Task entspricht. Folgendes ist dabei zu beachten: 1. Das Bit mit dem symbolischen Namen UC.QUE in U.CTL des betreffenden UCB muss gesetzt sein. 2. Der Driver enthaelt in der DDT anstelle des Eintrittspunkts xxINI die Adresse der speziellen Behandlungsroutine xxCHK. Diese Routine hat die folgenden Aktionen auszufuehren: - Ermitteln der virtuellen Nutzerpufferadresse und Ausfuehren der Adresspruefung durch das Systemunterprogramm $ACHCK.  59 - Umwandeln der virtuellen Pufferadresse in eine Basisadresse relativ zu APR6 mit dem Systemunterprogramm $RELOC und Zurueckspeichern des Resultats in das E/A-Paket. - Eintragen des E/A-Pakets in die Warteschlange und Verzwei- gen zum Eintrittspunkt xxINI, bei dem $GTPKT gerufen wird. 3. Nach Abschluss der Driveroperationen, nach der Abarbeitung von $IODON, wird zu xxINI verzweigt. Beispiel: Aufgrund des gesetzten UC.QUE-Bits im UCB wird der Driver von der Exekutive gestartet, bevor das E/A-Paket in die Warteschlange eingereiht ist. Eingabeparameter: R1=Adresse des E/A-Pakets R4=SCB-Adresse R5=UCB-Adresse ; ;TABELLE DER EINTRITTSPUNKTE DES DRIVERS ; $xxTBL: .WORD xxCHK ;INITIATOR EINTRITTSPUNKT .WORD xxCAN ;EINTRITTSPUNKT E/A-ABBRUCH .WORD xxOUT ;EINTRITTSPUNKT GERAETEAUSFALL .WORD xxPWF ;EINTRITTSPUNKT NETZAUSFALL ; ; xxCHK: MOV R1,R3 ;ADRESSE DES E/A-PAKETS MOV i.PRM+6(R3),R0;VIRTUELLE PUFFERADRESSE .IFDF A$$CHK MOV I.PRM+4(R3),R1;PUFFERLAENGE CALL $ACHCK ;ADRESSPRUEFUNG BCC 10$ ;FALLS CC ADRESSE I.O. MOV #IE.SPC377,R0;RUECKKEHRCODE PUFFERFEHLER CALLR $IOFIN ;BEENDIGUNG DER E/A .ENDC 10$: CALL $RELOC ;UMWANDELN DER VIRTUELLEN ADRESSE MOV R1,I.PRM+6(R3);EINTRAGEN RELATIVADRESSE IN DAS ;E/A-PAKET MOV R2,I.PRM+10(R3);EINTRAGEN PUFFERADRESSE IN DAS ;E/A-PAKET MOV R3,R1 ;ADRESSE E/A-PAKET MOV R4,R0 ;ADRESSE DES WARTESCHLANGENKOPFES CALL $QINSF ;EINREIHEN E/A-PAKET IN DIE ;WARTESCHLANGE xxINI: CALL $GTPKT ;E/A-PAKET AUSREIHEN BCS RETURN ;AS BESETZT . . . CALL $IODON ;BEENDEN E/A-OPERATION BR xxINI  60 5. 3. Einbinden eines Drivers ---------------------------- 5.3.1. Generieren eines residenten Drivers ------------------------------------------ Der allgemeine Ablauf beim Erstellen und Einbinden eines residen- ten Drivers ist folgender: - Erstellen des Assemblerquelltextes des Drivers - Erstellen des Assemblerquelltextes der Datenbasis des Drivers - Starten des Systemgenerierungsvorgangs. Beim Systemgenerierungsvorgang wird der Driver mit seiner Daten- basis in das Steuerprogramm OMEX 1630 eingebunden. Das geschieht im Dialogverkehr unter Steuerung der Generierungs- Kommandodateien. Das Einbinden nutzereigener Driver in den Exekutive-Kern ist nur moeglich, wenn die entsprechende Unterstuetzung in den Exekutive- Kern einbezogen wurde . (vgl. Anleitung fuer den Systemprogrammierer, Teil 2) 5.3.2. Einbinden eines ladbaren Drivers --------------------------------------- 5.3.2.1. Einbinden bei der Systemgenerierung -------------------------------------------- Das Einbinden eines ladbaren Drivers in das BS OMOS bei der Systemgenerierung erfolgt wie bei residenten Drivern im Dialog- verkehr unter Steuerung der Generierungs-Kommandodateien. Die Quelldateien des Drivers und einer ladbaren oder residenten Datenbasis sind in die Quelldatei der Exekutive einzufuegen. Dabei gilt das unter Abschnitt 5.3.1. zur Generierung Erwaehnte. 5.3.2.2. Einbinden in ein fertiges System ----------------------------------------- Nur ein ladbarer Driver mit ladbarer Datenbasis kann nachtraeglich, ohne erneute Generierung, in das BS OMOS 1630 eingebunden werden. Falls fuer das betreffende Geraet bereits eine residente Datenbasis generiert wurde, ist keine ladbare mehr zu programmieren, da diese vom Kommando LOA[D] ignoriert wuerde. In diesem Falle sind beim Assemblieren der Driverquelle die Parameter der Datei OMXMC.MAC zu verwenden. Die Makros werden mit Hilfe der Bibliotheken SYSMAC.SML (Standard) und EXEMC.MLB aufgeloest. Die Assemblierung erfolgt mit folgendem Kommando: MAC>xxDRV=LB:[1,1]EXEMC/ML,DKn:[11,10]OMXMC,DKm:xxDRV wobei xx - Geraetemnemonik, DKn: Systemplatte, DKm: Arbeitsplatte mit Driverquelle bedeuten.  61 Auf analoge Weise wird eine ladbare Datenbasis xxTAB uebersetzt. Anschliessend kann das Taskbilden erfolgen. Dabei entstehen im UFD [1,54] der Systemplatte die Taskabbilddatei xxDRV.TSK und die zugehoerige Symboldefinitionstabelle xxDRV.STB. TKB> [1,54]xxDRV/-HD/-MM,,[1,54]xxDRV= ------------------------------------------- Task-Abbilddatei Symboldefinitionsdatei Bedeutung der Schalter: /-HD: Es wird kein Taskkopf benoetigt, weil ein Driver keine echte Task, sondern ein Bestandteil der Exekutive ist. /-MM: Bei Drivern ist trotz vorhandener Speichervermittlungsein- heit stets /-MM anzugeben. Der Schalter /-MMwird bei Syste- men mit Speichervermittlungseinheit benutzt. - Es muss eine Verbindung der Symbole des Drivers mit der System- Symboldatei hergestellt werden. TKB> DKm:[g,m]xxDRV,xxTAB -------------------- TKB> [1,54]OMEX.STB/SS ----------------- Der Schalter /SS (selektives Suchen der globalen Symbole) ist in der zweiten Kommandozeile unbedingt anzugeben. - Die Systembibliotheksdatei, in der die Masken und verschiedene Offsets definiert sind, muss im Eingabestrom vorhanden sein. TKB> LB:[1,1]EXELIB/LB ----------------- TKB> / -- Mit dem Schraegstrich beginnt die Auswahlphase des Taskbilders. - Der Speicherplatzbedarf fuer den Stack und die Partition, in die der Driver geladen wird, sind zu bestimmen. TKB> STACK=0 ------- TKB> PAR=DRVPAR:120000:4000 ---------------------- TKB> // --- Bei allen Anweisungszeilen gilt: xx Geraetemnemonik DKn: Arbeitsplatte mit Objektdateien von Driver und Datenbasis [g,m] UFD, der die Objektmoduln enthaelt DRVPAR Partition, in die der Driver geladen werden soll Die Startadresse in der Partition muss 120000 (oktal) sein. Die Adresszuweisung der Partition hat ueber das APR5 zu erfolgen. Der zweite Wert gibt die Groesse des benoetigten Speichers (im Beispiel 4000) an. Mit den beiden Schraegstrichen wird die Eingabe der TKB-Kommandos beendet.  62 Zur Realisierung der oben aufgefuehrten Operationen kann auch die Kommandodatei [200,200]BLDDRV.CMD benutzt werden. Man braucht dann die angefuehrten Schritte nicht einzeln abzuarbeiten, son- dern nur den Geraetenamen und die Partitionparameter anzugeben. Naehere Angaben zum Einbinden nutzereigener ladbarer Driver sind in der Anleitung fuer Systemprogrammierer, Teil 2: "Inbetriebnahme und Wartung des BS OMOS 1630" enthalten. 5.4. Laden eines ladbaren Drivers --------------------------------- Der Driver wird mit dem MCR-Kommando LOA[D] in den Hauptspeicher zur Abarbeitung geladen. LOA[D] xx: [/PAR = par] wobei: xx = Geraetebezeichnung par = Partition in die der Driver geladen werden soll. Ist der Parameter par nicht angegeben, wird der Driver in die Partition geladen, die beim Taskbilden bestimmt wurde. Das LOA[D]-Kommando sucht zuerst nach einer residenten Datenba- sis. Wird eine gefunden, so wird eine eventuell vorhandene ladbare ignoriert. Eine ladbare Datenbasis ist nur einmal ladbar, danach ist sie resident bis zu einem Systemneustart. Durch das MCR-Kommando UNL[OAD] erfolgt kein Ausladen der durch LOA[D] geladenen Daten- basis.  63 6. Test des Drivers ------------------- 6.1. Einleitung --------------- Da ein Driver einen Bestandteil des Betriebssystems darstellt, sind vielfaeltige Schutzpruefungen wie fuer Nutzerprogramme hier nicht verfuegbar, so dass Programmierfehler direkt zum Systemabbruch fuehren koennen. Fuer den Test eines Drivers sollen in diesem Kapitel folgende Punkte diskutiert werden: . Testhilfsmittel . Fehlersuche . Korrektur zum Wiedereinbinden eines Drivers 6.2. Testhilfen --------------- OMOS 1630 liefert verschiedene Routinen, welche beim Test eines Drivers benutzt werden koennen: . Exekutiven-Stack- und -Registerauszug, . Testhilfe fuer die Exekutive XDT, . Routine fuer Speicherauszuege bei Systemabbruch (Panic- dump-Routine) . Unterstuetzungsroutine fuer das Abbruchanalyseprogramm CDA 1630 (OMEX) Panic-dump und CDA-Unterstuetzung schliessen einander aus. 6.2.1. Exekutiven-Stack- und -Registerauszug -------------------------------------------- Kommt es beim Test eines Drivers oder anderen Teilen der Exekuti- ve zu einem Abbruch der Systemarbeit, so kann man mit Hilfe der Exekutiven-Stack- und -Registerauszugsroutine Informationen ueber die vermutliche Fehlerquelle erhalten. Diese Routine (vgl. naechster Abschnitt) wird nach einem System- fehler oder mittels des XDT-Kommandos X ueber die Speicherzelle 40 (oktal) erreicht, die einen JMP-Befehl in die Routine CRASH ($CRASH) enthaelt. CRASH ruft anschliessend die Routine, die den Exekutiven-Stack- und -Registerauszug ausgibt. Beispiel: -------- SYSTEM CRASH AT LOCATION 047622 REGISTERS R0 = 000340 R1 = 177753 R2 = 000353 R3 = 000000 R4 = 000004 R5 = 046712 SP = 000472 PS = 000340 SYSTEM STACK DUMP LOCATION CONTENTS 000472 000004 000474 000000 000476 001514  64 000500 000340 000502 177753 000504 000353 000506 000000 000510 000000 000512 057750 . . . . . . 000542 170000 Im Anschluss wird die CDA- oder die Panic-Dump-Routine gerufen, abhaengig davon, ob und welche im System enthalten ist. Ansonsten wird ein System-Halt erreicht. 6.2.2. Exekutive-Testhilfe XDT ------------------------------ Das Testprogramm XDT ist geeignet, Exekutiveteile, und somit auch Driver, zu testen, und kann beim Auftreten folgender Ursachen erreicht werden: . Starten eines neugenerierten Systems, . mit dem MCR-Kommando BRK von einem privilegierten Terminal, . Erreichen einer BPT- oder IOT-Anweisung, . Systemfehler, z.B. ungerade Adresse. Alle Kommandoeingaben und Ausschriften erfolgen im Direktverkehr ueber das Konsol-Terminal. Fuer Listenausgabe (Kommando L) kann neben dem Bediengeraet auch der Paralleldrucker benutzt werden. Fuer die Bedienung gelten die gleichen Vorschriften und Kommandos, die auch fuer das ODT-Testprogramm gelten, ausser: $M, $X, $V, $D, $E, $W, E, F, N, V, W. Das Kommando X loest einen Sprung zur Routine des Exekutiven- Stack- und Registerauszugs aus. XDT meldet sich . bei Systemstart nach Neugenerierung mit XDT: Systemversionsbezeichnung und der Eingabeanforderung XDT> . sonst mit zz:xxxxxx XDT> Dabei bedeuten: zz - Ursache der Unterbrechung (siehe Tabelle 4) xxxxxx - Unterbrechungsadresse. Fuer zz koennen folgende zweibuchstabige Mnemoniks stehen:  65 Tabelle 4: Fehlerursachen bei XDT ----------------------------------------------------------------- Mnemonik | Bedeutung ----------------------------------------------------------------- | BE | Breakpoint-Trap IL | Reservierter oder verbotener Befehl IO | I/O-Trap OD | Ungerade Adresse bei Wortbefehl, unerlaubte Adresse SO | Stack-Ueberlauf TE | T-bit-Fehler ----------------------------------------------------------------- Nach einer Eingabeanforderung von XDT koennen mit den ueblichen ODT-Kommandos Unterbrechungspunkte gesetzt oder andere XDT- Anweisungen gegeben werden. Der Start des Testlaufes wird mit der Eingabe des ueblichen G - Kommandos vollzogen. Wird einer der Unterbrechungspunkte erreicht, erscheint auf dem Terminal die Mitteilung: BE: xxxxxx ------ und die Aufforderung zur Kommandoeingabe XDT> Nach Eingabe der gewuenschten Kommandos kann mit der Eingabe P die Fortsetzung des Testlaufes angewiesen werden. Bei der Anweisung von Unterbrechungspunkten bei ladbaren Drivern ist unbedingt die Adresszuweisung ueber das APR5 zu realisieren. Sonst kann ein sogenannter T-bit-Fehler auftreten: TE: xxxxxx XDT> Dieser T-bit-Fehler kann vermieden werden, indem man beim Assemb- lieren des Drivers einen Break-Point-Trap (BPT) an der gewuensch- ten Unterbrechungsstelle einfuegt, oder durch Benutzung der ZAP- Routine oder durch das MCR-Kommando OPE[N] die an der Unter- brechungsstelle stehende Anweisung durch Eintragen eines BPT (3) ersetzt. Bei Erreichen des eingetragenen BPT erfolgt die uebliche XDT-Meldung: BE: xxxxxx ------ XDT> Beim Fortsetzen des Testlaufs sind das durch die BPT-Anweisung ersetzte Wort wieder einzutragen, der PC (R7) um 2 zu verringern und das Kommando P oder S (Schrittbetrieb) zu geben. Diese Prozedur kann vermieden werden, wenn an signifikanten Stellen des Quelltextes (z.B. bei Eintrittspunkten in den Driver) NOP-Befehle programmiert werden. Beachte: Es sollten nicht gleichzeitig in mehreren Moduln, die die APR5 oder APR6 nutzen (z.B. zwei ladbare Driver), Unterbrechungspunkte gesetzt werden.  66 XDT laeuft staendig unter Prioritaet 7. XDT wird bei der Systemgenerierung (Stufe 1) in das BS OMOS 1630 eingeschlossen. 6.2.3. Routine fuer Speicherauszuege bei Systemabbruch (Panic-dump-Routine) -------------------------------------------------------- Im Anschluss an den Exekutiven-Stack- und -Registerauszug kann bei Systemabbruch die Panic-dump-Routine angesprungen werden, sofern diese im System enthalten ist. Die Panic-dump-Routine sichert die Inhalte der Register R0 bis R6, das Prozessorstatuswort (PS) und den Befehlszaehler (PC). Anschliessend geht der Rechner in den Haltzustand und erwartet Eingaben ueber die Tastatur der BDE. Ausschrift auf der Bedieneinheit: @nnnnnn wobei nnnnnn die Adresse+2 des Haltbefehles angibt. Fuer die Speicherauszuege werden dann die folgenden Eingaben erwartet: @0/ xxxxxx (CR) Eingabe untere Grenze @2/ xxxxxx (CR) Eingabe obere Grenze @P Danach erfolgt die Ausgabe des angegebenen Speicherbereiches. Nach Beendigung der Ausgabe geht der Rechner wieder in den Haltzustand und erwartet weitere Eingaben. Die Ausgabe erfolgt in Gruppen von je drei Zeilen und 9 Spalten. Die erste Spalte von links enthaelt zwei Adressen, von denen die erste die absolute und die zweite die Relativadresse zum Anfang des Speicherauszuges darstellt. Die drei Zeilen jeder Gruppe enthalten nacheinander folgende Informationen: . die oktalen Wortinhalte der Speicherplaetze, . die oktalen Byteinhalte der Speicherplaetze, . die den Byte-Werten entsprechenden KOI7-Zeichen, die wegen der besseren Lesbarkeit vertauscht dargestellt sind. Die erste Ausgabegruppe enthaelt von rechts nach links die In- halte der Register PS, R0, R1, R2, R3, R4, R5 und SP. Ein Beispiel fuer einen solchen Speicherauszug zeigt Bild 7.  67 SP R5 R4 R3 000544 000000 046076 000066 000000 000000 000 000 114 076 000 066 000 000 ^@ ^@ > L 6 ^@ ^@ ^@ 000000 022646 000340 045770 000340 000000 045 246 000 340 113 370 000 340 @ K @ 000020 045776 000340 011124 000340 000020 113 376 000 340 022 124 000 340 K @ T ^R @ 000040 000167 000543 000001 000001 000040 000 167 001 143 000 001 000 001 @ ^A ^A @ ^A @ 000060 035444 000340 034034 000340 000060 073 044 000 340 070 034 000 340 $ ; @ ^\ 8 @ R2 R1 R0 PS 000544 000000 000000 000000 045316 000000 000 000 000 000 000 000 112 316 ^@ ^@ ^@ ^@ ^@ ^@ N J 000000 045770 000340 045770 000340 000000 113 370 000 340 113 370 000 340 K @ K @ 000020 045770 000340 050500 000340 000020 113 370 000 340 121 100 000 340 K @ @ Q @ 000040 000000 000000 000000 000353 000040 000 000 000 000 000 000 000 353 ^@ ^@ ^@ ^@ ^@ ^@ @ 000060 032776 000340 032402 000340 000060 065 376 000 340 065 002 000 340 5 @ ^B 5 @ Bild 7 Beispiel eines Speicherauszugs bei Systemabbruch  68 6.2.4. Unterstuetzungsroutine fuer das Abbruchanalyseprogramm CDA 1630 (OMEX) ------------------------------------------------------------- Die CDA-Unterstuetzung des OMEX 1630 ist generierbar. Kommt es zu einem Systemabbruch, werden mit Hilfe der Exekutiven-Stack- und -Registerauszugsroutine Register- und Stackinhalt ausgegeben (siehe Abschnitt 6.2.1.). Danach wird die Unterstuetzungsroutine fuer das Abbruchanalyseprogramm CDA 1630(OMEX) aufgerufen, falls sie generiert ist. Es erfolgt die Mitteilung: CRASH -- CONTINUE WITH SCRATCH MEDIA ON ddn (ddn Geraetebezeichnung), und der Rechner geht in den Haltzustand. Ausschrift auf dem Bediengeraet: @nnnnnn wobei nnnnnn die Adresse des Haltbefehls angibt. Der Nutzer muss das sekundaere Speichergeraet ddn (crash dump device) bereitmachen. Soll der Speicherabzug nicht auf dem Geraet mit der Geraeteeinheitenummer n ausgegeben werden (n wird bei der Generierung festgelegt), kann der Nutzer eine andere Geraeteein- heitenummer m angeben: @mmmmmm/n m wobei mmmmmm=nnnnnn+2, d.h. obige Ausschrift +2 Nach Eingabe des Fortsetzungskommandos P wird der Inhalt des gesamten Hauptspeichers auf das sekundaere Geraet uebertragen und danach der Prozessor gestoppt. Dieser Speicherabzug ist die Grundlage fuer die Analyse mit CDA nach Systemneustart (siehe auch Anleitung fuer den Bediener, Teil 4: "Dienstprogramme"). 6.3. Fehlersuche ---------------- Systemfehler koennen durch verschiedene Ursachen hervorgerufen werden: - Fehler in den Anwendertasks - Fehler in den Drivern - Fehler im OMEX-Steuerprogramm - Fehler in der Hardware Dieser Abschnitt gibt einige Hinweise, die bei der Isolierung der Fehlerquelle helfen koennen. Voraussetzung fuer die folgende Diskussion ist ein System mit mindestens einer Testhilfe (siehe 6.1.). Beachte, dass ein Minimalsystem keinen Platz fuer diese Routinen hat. Im allgemeinen ist ein Fehler aufgetreten, wenn folgende Ereig- nisse eintreten:  69 - Auftreten eines unbeabsichtigten Traps zum XDT In diesem Fall ist die Anzeige einzelner Speicherzellen moeglich, die Aufschluss ueber Ort und Ursache des Fehlers geben koennen, und durch Modifikation von Befehlscodes, PC- Inhalt, Registerinhalten usw.und einzelne Programmteile zu testen. Anschliessend kann die Routine, die den Exekutiven- Stack-und -Registerauszug (siehe Abschnitt 6.2.1.) realisiert, aktiviert werden. - Es erfolgt eine Mitteilung auf dem Bediengeraet. Diese Mitteilung stammt von der Exekutiven-Stack- und - Registerauszugs- oder von der CDA-Unterstuetzungsroutine. Danach ist, wie in 6.2.2. bzw. 6.2.4. beschrieben, weiterzuarbeiten. - Das System befindet sich im Haltzustand, und es erfolgte keine Mitteilung auf dem Bediengeraet. Bevor irgendetwas anderes unternommen wird, sind zunaechst die Inhalte der Register R0 bis R7 und die der spezifischen Gerae- teregister festzustellen. Danach wird ueber Zelle 40 (oktal) eine der generierten Testhilfen gerufen. - Das System bleibt in einer unbeabsichtigten Schleife. Der Rechner ist in diesem Fall in den Haltzustand zu bringen, und die Inhalte der Register R0 bis R7 und der spezifischen Geraeteregister sind festzustellen. Dann sind zur Lokalisierung der Schleife einige Befehle schrittweise abzuarbeiten. Dabei ist es sinnvoll, die Systemuhr durch Loeschen des Bits 6 in der Zelle 772540 anzuhalten. Beachte:Das System kann nicht wieder anlaufen, bis die Uhr wieder angestossen wird. Nach dem Versuch, die Schleife zu lokalisieren, und dem Wiederanstossen der Uhr kann eine der beschriebenen Testhilfen ueber die Zelle 40 (oktal) erreicht werden. Wichtige Daten fuer die Fehlerfeststellung erhaelt man aus dem Speicherauszug des Systemcommonbereiches (SYSCM). SYSCM enthaelt eine Anzahl von wichtigen Adressen und Listenkoepfen. Die zugehoerigen Adressgrenzen fuer den Modul SYSCM erhaelt man aus der Speicherzuordnungsliste der Exekutive. Diese Grenzen werden fuer die Ausfuehrung der Panic-dump-Routine bzw. fuer den Aufruf von CDA benoetigt. Ergaenzend dazu koennen der dynamische Speicherbereich (POOL) im Modul INITL und die Geraetetabellen im Modul SYSTB ausgedruckt werden. Drei Adressen im Systemcommonbereich (Modul SYSCM) sind fuer die Fehlerermittlung wichtig: - $STKDP: Diese Zelle zeigt an, welcher Stack zur Zeit des Abbruchs benutzt wurde. $STKDP = 1: Der Stack wird von einer Task benutzt. $STKDP = 0 oder <0: Der Stack ist der Systemstack. - $TKTCB: Dieser Speicherplatz enthaelt die Adresse des Tasksteuerblocks (TCB) der aktuellen Task. - $HEADR:  70 Dieser Speicherplatz enthaelt die Adresse des Taskkopfes der aktuellen Task. Das folgende Bild zeigt den Aufbau von Taskkoepfen. ------------------- | 0 |<-------| |-----------------| | | R0 | | ------------------- | . | . | . | ------------------- | | R5 | | |-----------------| | | PC | | |-----------------| | | PS | | ------------------- | . | . | . | ------------------- | H.NLUN | N | | ------------------- | H.GARD | |--------| ------------------- . . . ------------------- H.HDLN | Laenge in Bytes | ------------------- ------------------- | SP | ------------------- Bild 8 Aufbau eines Taskkopfes Das oberste Wort im Taskkopf beinhaltet den zuletzt geretteten Nutzer-Stackpointer. Wenn der Nutzer direkt in die Exekutive eintritt und dort ein Fehler auftritt, kann die Kenntnis dieses Werts bei der Fehlerverfolgung helfen. Weiterhin enthaelt der Taskkopf den zuletzt geretteten Registersatz und zuunterst das Schutzwort der Task, dessen Zeiger sich in H.GARD befindet. Fehlerverfolgung mit Hilfe des Exekutiven-Stack- und -Registerauszuges ---------------------------------------------------- Geht man bei der Ermittlung eines Fehlers von den Informationen aus, die der Exekutiven-Stack- und -Registerauszug enthaelt, dann muss mit der Auswertung des System-SP begonnen werden. Ein Fehler in der Exekutive hat im Normalfall einen Synchronen Systemtrap (SST) und den Aufruf der Crash-Mitteilungs-Routine zur Folge. Der Crash-Ruf wird durch Aussenden eines IOT-Befehls  71 bei einer Stacktiefe ($STKDP) kleiner oder gleich Null ausgeloest. Ein Crash-Ruf erfolgt ebenfalls, wenn ein EMT bei einer Stacktiefe von 0 oder kleiner gesendet oder ein Trap-Befehl bei einer Stacktiefe kleiner 0 ausgefuehrt wurde. Der Aufbau des Stack ist in einem solchen Fall folgender: ------------------------------- | PS | |-----------------------------| | PC | |-----------------------------| | R5 | |-----------------------------| | R4 | |-----------------------------| | R3 | |-----------------------------| | R2 | |-----------------------------| | R1 | |-----------------------------| | R0 | |-----------------------------| | Rueckkehradresse zum System | |-----------------------------| | 0 oder andere SST Parameter | |-----------------------------| | SST-Fehler-Code | |-----------------------------| | Byteanzahl |<--------SP ------------------------------- Bild 9: Stackaufbau 1 - interne SST-Fehler Fehlercodes: 0 : Trap ueber die Adresse 4 oder Adressierung einer ungeraden Wortadresse 2 : Speicherschutzverletzung 4 : Unterbrechungspunkt oder T-Trap (Trace) 6 : E/A-Trap-Anweisung (IOT) 10 : Falsche oder verbotene Anweisung 12 : Keine EMT-Anweisung des BS OMOS 1630 14 : Trapanweisung 20 : SST-Abbruch-Stack 22 : AST-Abbruch-Stack 24 : Abbruch verursacht durch die Direktive 26 : Task-Lade-(Lese)-Fehler 30 : Task-Auslagerungs-Fehler 32 : Taskbeendigung bei noch nicht beendeter E/A 34 : Task-Speicherparitaetsfehler  72 Im PC steht die Adresse des Befehls, der dem den SST-Fehler verursachenden Befehl folgt. Der SP zeigt auf ein Wort, das die Anzahl der Bytes enthaelt, die in den Nutzerstack transportiert wurden, bevor der SST eintrat. Ist diese Anzahl gleich 4, so ist ein unnormaler SST-Fehler auf- getreten und nur das PSW und der PC sind im Stack gespeichert, aber keine SST-Parameter. Wurde der Abbruch im Direktiven- Dispatcher ($DRDSP) entdeckt, sieht der Stack wie in Bild 9 aus. Allerdings fehlen die Anzahl der Bytes, die SST-Fehlercodes und die SST-Parameter. Ein SST-Typ-Abbruch - der Stackunterlauf - fuehrt nicht zu der in Bild 9 dargestellten Stackstruktur. Um zu bestimmen, wo der Systemabbruch ausgeloest wurde, ist zuerst die Stackstruktur festzustellen (Wert des SP, Inhalt des ersten Wortes im Stack). Ergibt sich eine Struktur wie in Bild 9, zeigt das, dass der Abbruch in $DRDSP erfolgt ist bzw. ein normaler SST-Abbruch ausgeloest wurde. Findet sich eine Stackstruktur wie in Bild 10, liegt ein unnormaler SST-Abbruch vor. Der Stack sieht in diesem Fall wie folgt aus: <--------------SP ------------------- | PS | |-----------------| | PC | ------------------- Bild 10 Stackaufbau 2 - unnormale SST-Fehler Unnormale SST-Abbrueche treten dann auf, wenn es nicht moeglich ist, eine Information in den Stack zu speichern, ohne einen anderen SST-Typ zu verursachen. In einer solchen Situation und wenn kein IOT-Abbruch vorliegt, erfolgt ein direkter Sprung zur Crash-Mitteilungs-Routine. Die dort angegebene Adresse sowie PS und PC im Stack sind die aktuellen Werte zur Zeit des Abbruchs. Es ist zu beachten, dass die Crash-Mitteilungs-Routine den PC und das PSW des in diesem Falle falschen IOT-Befehls aus dem Stack entfernt. Somit zeigt der SP eine Adresse an, die um 4 groesser ist als die echte. Fehlerverfolgung bei Systemhalt ohne Mitteilung ----------------------------------------------- In diesem Fall sind $STKDP, $TKTCB und $HEADR zu ueberpruefen. Der Systemstack hat hier keine direkte Verbindung mit der Fehlerursache. Durch Pruefung des $STKDP erhaelt man den System- status zur Zeit des Fehlers. Zeigt dieser den Nutzerstatus an, ist somit der Nutzerstack weiter zu untersuchen. Der Stack ist nach Adressen zu durchsuchen, die zu Unterprogram- men fuehren, die den Fehler verursacht haben koennten. Das ist auch im wesentlichen die Methode, nach der der System- stack zu pruefen ist, falls $STKDP Null oder kleiner als Null ist. Haeufig tritt der Fehler auf, dass der SP auf den Stackanfang + 4 zeigt. Dieser Fehler resultiert aus der Bearbeitung eines RTI- Befehls, wobei die ersten beiden Eintragungen im Stack Daten,  73 also keine Rueckkehradresse und PS darstellen. Das Ergebnis ist ein ungewollter Sprung mit (meistens) anschliessendem HALT. Beispiel -------- Die folgende Abbildung 11 zeigt einen Fall, in welchem zwei Dateneintragungen sich im Stack befinden, waehrend das Programm einen RTI-Befehl ausfuehrt. Der Stackanfang (1) zeigt auf ein Wort, das 40100 enthaelt. In dem Falle, dass nun die Zelle 40100 einen HALT-Befehl enthaelt, ist der richtige SP um 4 kleiner als der nach dem RTI-Befehl (2) eingestellte. |-------------------| SP (2) | |<------ |-------------------| | 5 | |-------------------| SP (1) | 40100 |<------ |-------------------| Bild 11 Stackaubau 3 - nach RTI-Befehl Weitere Hinweise fuer die Fehlerverfolgung ------------------------------------------ Eine weitere Hilfe bei der Fehlerverfolgung kann die Untersuchung des laufenden (oder letzten) E/A-Pakets sein, dessen Adresse im SCB unter dem Offset S.PKT zu finden ist. Die Funktion I.FCN zeigt die letzte Aktivitaet, die zum Geraet gesendet wurde. Bei fehlerbedingtem Abbruch einer E/A-Anforderung kann die Ueberpruefung des dynamischen Speichers wichtige Erkenntnisse liefern, da alle E/A-Paket dort aufgebaut werden. Die Beginn- Adresse des Dynamischen Speichers ist aus $CRAVL, einer Zelle des Systemcommonbereichs (SYSCM) zu entnehmen. Ueber ihre Verket- tungszeiger ist jedes E/A-Paket zu erreichen und zu ueberpruefen. In Systemen mit QIO-Optimierung zeigt die Zelle $PKAVL im Modul SYSCM auf eine Liste von E/A-Paket-grossen Bloecken, die nicht in die $CRAVL-Kette eingebunden ist. Ein haeufiger Fehler bei Drivern fuer interrupt-gesteuerte Geraete besteht darin, dass ein E/A-Paket zweimal ausgereiht wird, falls die Geraetebedienung am Ende einer E/A-Operation fehlerhaft ist und ein ungewollter Interrupt auftritt. Das doppelte Trennen eines dynamischen Puffers im System verursacht bei der der zweiten Ausgliederung desselben Blocks folgenden Operation eine Schleife im Modul $DEACB. Zu diesem Zeitpunkt enthalten die Register R2 und R3 die Adresse des E/A-Pakets, das doppelt ausgereiht wurde.  74 7. Korrektur und Wiedereinbinden eines Drivers ---------------------------------------------- 7.1. Allgemeines ---------------- Die Prozedur des Neubildens und Einbindens eines Drivers in das Betriebssystem haengt davon ab, ob der Driver bzw. seine Datenbasis resident oder ladbar sind. Fuer die Korrektur residenter Bestandteile ist stets eine Neugenerierung notwendig, wogegen sich ladbare Bestandteile im bestehenden System austauschen lassen. 7.2. Residente Driver und residente Datenbasen ---------------------------------------------- Nach der Korrektur der fehlerhaften Moduln sind diese neu zu assemblieren und in der Objektmodulbibliothek der Exekutive auszutauschen: LBR>LB:OMEX/RP=[11,24]xxDRV,USRTB (xx - Geraetemnemonik) Anschliessend ist die Phase 2 der Systemgenerierung zu wiederholen, um den Driver mit der Exekutive neu zu binden, und wie bei einer Erstgenerierung fortzufahren. Lediglich fuer den Fall, dass durch die Korrektur keinerlei Spei- cherplatzverschiebungen auftraten, die sich auf globale Symbole auswirken, und die Laengen von Driver und Datenbasis unveraen- dert blieben, kann das folgende abgekuerzte Verfahren benutzt werden. Mit dem Taskbilder wird der neue Exekutive-Kern (einschliesslich des geaenderten Drivers) gebildet. >SET /UIC=[1,24] --------------- TKB> @OMXBLD ------- Mittels PIP wird eine neue Systemabbilddatei erzeugt. >SET /UIC=[1,54] --------------- PIP>OMEX.SYS/NV/CO/BL:zzz.=OMEX.TSK ------------------------------- wobei zzz. - Blockgroesse der neuen Systemabbilddatei ------------------------------------------ 7.3. Ladbare Driver und ladbare Datenbasen ------------------------------------------ Die Datenbasis, wenn sie einmal geladen wurde, wird ein permanenter Bestandteil der Exekutive und laesst sich nicht wieder mit dem MCR-Kommando UNL entfernen. Beim Austausch einer fehlerhaften Datenbasis ist folglich ein Neustart des Systems erforderlich. Fuer den Fall, dass nur der Driver korrigiert  75 werden muss, ist dieser vor dem Taskbilden fuer die neue Version mit UNL aus dem System zu entfernen. Nach dem Assemblieren des korrigierten Quelltextes und dem Taskbilden kann die ueberarbei- tete Driverversion mit dem MCR-Kommando LOA erneut geladen werden.  76 Abkuerzungsverzeichnis ---------------------- ACNT (Account File Maintenance Wartungsprogramm fuer Nutzer- Program) verzeichnisse ACP (Ancillary Control Processor) Zusatzsteuerroutine AS Anschlusssteuereinheit AFP - fuer Festplattenspeicher AFS - fuer Folienspeichereinheit AIP - fuer paralleles Interface AIS - fuer serielles Interface AKP - fuer Kassettenplatten- speicher AMB - fuer Magnetbandspeicher APR (Address Page Register) Seitenadressregister ASCII (American Standard Code entspricht KOI7-Code for Information Interchange) AST (Asynchronous Systemtrap) Asynchroner Systemtrap AT Verarbeitungsprogramm fuer Indirekt-Kommandodateien BAD (Bad Block Locator Utility) Plattenpruefprogramm BDE Bedieneinheit BOT (Begin Of Tape) Bandanfang BRU (Backup and Restore Utility) Datensicherungsprogramm BS Betriebssystem CDA (Crash Dump Analyzer) Abbruchanalyseprogramm CIB (Controller Initialization Initialisierungsblock Block) fuer die Anschlusssteuer- einheit CLI (Command Line Interpreter) Programm zur Bearbeitung von Kommandos CMP (File Compare Utility) Dateivergleichsprogramm CSI (Command String Interpreter) Kommandozeileninterpreter DCB (Device Control Block) Geraetetypsteuerblock DCL Kommandosprache DCL DDT (Driver Dispatch Table) Tabelle der Eintrittspunkte eines Drivers DEP (Debugging Program) Testprogramm DFNB (Default File Name Block) Standarddateinamenblock DIC (Directive Identifikation Code) Anweisungsidentifikationscode DMP (Dump Utility) Dateidruckprogram DPB (Directive Parameter Block) Anweisungsparameterblock DSC (Disk Save and Compress) Dateirettungs- und Ver- dichtungsprogramm DSW (Directive Status Word) Anweisungsstatuswort E/A Ein- und Ausgabe EDI (Line Text Editor) Editor EDT (Standard Editor) " EFN (Event Flag Number) Ereignisflagnummer EOF (End of File) Dateiendekennsatz EOV (End of Volume) Datentraegerendekennsatz ERL (Error Logging) Fehlerregistrierung  77 FCB (File Control Block) Dateisteuerblock FCS (File Control Services) Dateizugriffsroutinen FDB (File Descriptor Block) Dateibeschreibungsblock FD16 Datensicherungsformat FE16 Global genormte Dateiformate (Dateiformat "established") FEX (File Exchange Utility) Dateiaustauschprogramm FIFO (First in - first out) FIFO-Speicherprinzip FL16 Dateiformat LAOS 1630 FLX (File Transfer Utility) Dateiumwandlungsprogramm FMT (Format Utility) Formatierungsprogramm fuer Magnetplatten FM16 Dateiformat MOOS 1600 und OMOS 1630 FNB (File Name Block) Dateinameblock FPEM (Floating-point Emulation Program) Gleitkommaemulator FPS Festplattenspeicher FQ16 Lokal genormte Dateiformate (Datenformat "queered") FSE Folienspeichereinheit FSR (File Storage Region) Dateispeicherbereich GCML (Get Command Line) Kommandozeilenlesen HDR (Header Label) Dateianfangskennsatz ICB (Interrupt Control Block) Interruptsteuerblock ID Identifikation IESR (Interrupt Enable/Disable Service Routine) Interrupt-Erlauberoutine IOX (I/O Exerciser) Allgemeines Geraete testprogramm ISR (Interrupt Service Routine) Interrupt-Bedienroutine ITB (Interrupt Transfer Block) Interrupt-Transfer-Block KBR Kommerzielles Basisrechner- system KMBE Kassettenmagnetbandeinheit KOI-7 entspricht ASCII-Code KPS Kassettenplattenspeicher KROS Kombinat Robotron Standard LBL Lochbandleser LBN (Logical Block Number) Logische Blocknummer LBR (Librarian Utility) Bibliothekar LC (Location Counter) Speicherplatzzaehler des Assemblers LUN (Logical Unit Number) logische Geraetenummer LUT (Logical Unit Table) Tabelle der logischen Geraetenummern LP (Line Printer) Zeilendrucker MAC Makro-Assembler MBG Magnetbandgeraet MCR (Monitor Console Routines) Kommandoprogramm MFD (Master File Directory) Hauptdateiverzeichnis MGS Mikrorechnergeraetesystem MOEX Exekutive des MOOS MOOS 1600 Modulares Operationssystem  78 NP Nutzerprogramm OCB (Offspring Control Block) Block zur Steuerung der Mutter/Tochter-Taskverbindung ODT (On-Line Debugging Tool) Testprogramm OMEX Exekutive des OMOS OMOS 1630 Optimiertes Modulares Betriebssystem PAR (Page Address Register) Seitenadressregister PAT (Object Module Patch Utility) Objektmodul-Korrekturprogramm PC (Program Counter) Befehlszaehler PCB (Partition Control Block) Partitionsteuerblock PDR (Page Description Register) Seitenbeschreibungsregister PIP (Peripheral Interchange Dateitransferprogramm Program) PRESRV (Preservation Utility) Duplizier- und Sicherungs- programm PRT (Print spooler) Print-Spooler PSW (Processor Status Word) Prozessorstatuswort RAM (Random Access Memory) Speicher mit wahlfreiem Zu- griff RDB (Region Definition Block) Region-Definitionsblock SCB (Status Control Block) Statussteuerblock SD Seriendrucker SHF (Shuffler) Speicherverdichtungsprogramm SLP (Source Line Processor) Quelltext-Korrekturprogramm SKR System der Kleinrechner SP (Stack-pointer) Stackpointer, Kellerzeiger SR (Status Register) Statusregister SRD (Sort Directory Program) Sortierprogramm fuer Verzeichnisdateien SST (Synchronous Systemtrap) Synchroner Systemtrap STD (System Task Directory) Systemtaskverzeichnis SVE Speichervermittlungseinheit TCB (Task Control Block) Tasksteuerblock TKB (Task Builder) Taskbilder TKTN (Task Termination Noti- Mitteilungsroutine fuer Task- fication Routine) beendigung UCB (Unit Control Block) Geraetesteuerblock UFD (User File Directory) Nutzerdateiverzeichnis UIC (User Identification Code) Nutzeridentifikationscode UHL (User Header Label) Nutzereigene Dateikennsaetze UTL (User Trailer Label) " UVL (User Volume Label) " VB (Virtual Block) Virtueller Block VBN (Virtual Block Number) Virtuelle Blocknummer VCB (Volume Control Block) Datentraegersteuerblock VFY (File Structure Verification Dateipruefprogramm Utility) VMR (Virtual Monitor Console Virtuelles Kommandoprogramm Routine)  79 VOL (Volume Label) Datentraegerkennsatz WDB (Window Definition Block) Fenster-Definitionsblock XDT (Executive Debugging Tool) Exekutivetesthilfe ZAP (Task Image File Patch) Dateikorrekturprogramm ZVE Zentrale Verarbeitungseinheit  80 Sachwortverzeichnis ------------------- Seite ACP 19 APR 16,44,47 AST 16,47 Abbruchbit 10 Anforderungstyp 36 Anschlusssteuereinheit 7,8,11,12,16,21,22,26, 28,29,30,31,40,42 Anweisungsparameterblock 12,16 Assembler 58 Assemblierung 44 Bediengeraet 27,39,64,67 Bytezaehler 28 CIB 12,28,29,57 DCB 12,16,30,49,50,57 DDT 8,30 Datenbasis 7,12,22,24,27,30,33,34, 49,51,57,58,60,73,74 Datenkanal 48 Datenpufferadresse 28 Driver, ladbare 7,11,12,20,30,41,43,44, 59,60 Driver, residente 7,30,49,57 E/A-Abbruch 8,30,51 E/A-Bereitschaft 8 E/A-Funktion 8,51 E/A-Geraet 8,10 E/A-Initiator 8,9,30,51 E/A-Operation 7,9,10,39 E/A-Paket 8,10,12,21,23,42,45,72 E/A-Statusblock 16 E/A-Statuscode 10 E/A-Statuswort 46 E/A-Warteschlange 8,9 Ereignis, signifikantes 47 Ereignisflag 13 Exekutiven-Testprogramm XDT 63 Fork-Prozess 23,32,40 Fork-Speicher 23,32,40 Fork-Verbindungswort 23 Fork-Warteschlange 23,32,40 Funktionscode 19,28 Funktionsmaske 18,51 Generierungsoption 7 Geraetefehler 7 Geraetefehlerabbruch 8,10,30,51 Geraeteinterrupt 7,22 Geraeteinterruptbehandlung 8,9,51 Geraeteinterruptvektor 9,12,22,29 Geraetestatus 9,10,11  81 Geraetewarteschlangenkopf 21,45 Go-Bit 28 Hardwareprioritaet 9 Informationsblock 36,38 Initialisierung 11,28,48 Interrupt-Erlaubnisbit 28 Interruptbedienroutine 42 Interruptbehandlungsroutine 32,40,43 Interruptsteuerblock 44 Interruptvektor 44,57 Kenndatenwort 10,11,27 Kommandodatei 58,59,61,74 LUT 14 MCR-Kommando 11,12,25,30,58,62,64,74 MGS 7 NOP 18,19 Netzausfall 7,11 Netzausfallbehandlung 8,11,51 Nutzerpuffer 41,45 PC 43,65 PS 43,65 Partitionssteuerblock 20 Prioritaet 9,14,30,32,33 SCB 8,10,12,21,30,48,49,57 SST 70 Speicherauszug 65 Statusregister 23 Steuerbit 25,42,45,47 System mit Adresszuweisung 9,16,23,28,43,44,46,59, 60,64 System ohne Adresszuweisung 16,28,46,59 Systemabbruch 65,66 Systemanlauf 12,28 Systemgenerierung 58,59,61 Systemstack 33,68,72 TCB 68 Taskbilden 58,59,60,62,74 Taskkopf 68 Time-out-Zaehler 10,22 UCB 8,10,11,12,24,25,30,45, 47,49,57 Warteschlangenorganisation 45,47 Zeit-Warteschlange 36 Zeitueberwachung 22  82