----------------------------------------------------------------- | SOFTWARE- | Methodische Hinweise | MOS | | DOKUMENTATION | | | |-----------------| Anleitung fuer den |------------| | 11/87 | Systemprogrammierer | OMOS 2.0 | ----------------------------------------------------------------- Programmtechnische Anleitung fuer den Systemprogrammierer Beschreibung Teil 1: Methodische Hinweise zum Betriebssystem OMOS 1630 MGS K 1600 VEB Robotron-Vertrieb Berlin Dok.-Nr. C 8063-0417-1M2031 Die vorliegende Ausgabe der Systemunterlagen-Dokumentation - Anleitung fuer Systemprogrammierer, Teil 1: "Methodische Hinweise" - 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 Die vorliegende Schrift soll dem Systemprogrammierer einen ersten Ueberblick ueber das BS OMOS 1630, einen Vergleich mit den Leistungen des Vorgaengersystems MOOS 1600 und Hinweise zur Planung des Arbeitssystem bieten. Weiterhin wird die Struktur der Software-Dokumentation erlaeutert. Inhaltsverzeichnis ------------------ Seite 1. Uebersicht ueber das BS OMOS 1630 5 1.1. Einleitung 5 1.2. Exekutive OMEX 1630 5 1.2.1. Hauptkomponenten 5 1.2.2. Erweitertes Leistungangebot 6 1.2.2.1. Beziehungen zwischen Tasks 6 1.2.2.2. Ereignisflags 7 1.2.2.3. Stop-bit-Arbeit 7 1.2.2.4. Weitere Leistungen 7 1.2.3. Bedienerkommunikation 8 1.3. Systemserviceprogramme 8 1.4. Dienstprogramme, Programmentwicklung 9 1.5. Eingabe/Ausgabe 10 1.5.1. Geraetedriver 11 1.5.2. FCS 1630 12 1.6. Bibliotheken 13 2. Herstellung des Nutzersystems 15 2.1. Ueberblick ueber die Generierung 15 2.1.1. Interner Teil 15 2.1.2. Oeffentlicher Teil 16 2.2. Grundbegriffe im BS OMOS 1630 17 2.2.1. Partition 17 2.2.1.1. Nutzergesteuerte Partition 17 2.2.1.2. Systemgesteuerte Partition 17 2.2.1.3. Residente Bibliothek und COMMON-Bereich 18 2.2.2. Task 18 2.2.2.1. Nichtprivilegierte Task 19 2.2.2.2. Abhaengige Task 19 2.2.2.3. Privilegierte Task 19 2.2.3. Methoden des Systems zur Arbeitsorganisation 20 2.2.3.1. Prioritaets- und zeitgesteuerte Aktivierung von Tasks 20 2.2.3.2. Prioritaets- und zeitgesteuerte Auslagerung von Tasks 20 2.2.3.3. Dynamische Zuteilung von Auslagerungsbereichen 21 2.2.3.4. Zeitscheibensteuerung 22 2.2.4. Mehrnutzerunterstuetzung 22 2.2.4.1. Sicherung der Zugriffsrechte 23 2.2.4.2. Datenschutz 23 2.2.4.3. Privilegstatus der Bediengeraete 23 2.3. Planung des Arbeitssystems 23 2.3.1. Nutzerverzeichnis 24 2.3.2. Partitionfestlegung 24 2.3.3. Anforderungen von Systemtasks an die Partitionaufteilung 25 2.4. Anpassungsarbeiten 26 2.4.1. Veraendern von Systemparametern 27 2.4.2. Veraendern von Peripherieparametern 27 2.4.3. Veraendern von Standardparametern bei Dienstprogrammen 27 3. Hinweise zur Software-Dokumentation 28 3.1. Gliederung der Anleitung fuer Systemprogrammierer 28 3.2. Leserkreis 28 3.3. Weitere Dokumentationen 28 3 Abkuerzungsverzeichnis 30 Sachwortverzeichnis 33 Tabellenverzeichnis ------------------- Seite 1: Dienstprogramme des BS OMOS 1630 9 2: Geraetedriver des BS OMOS 1630 11 Bildverzeichnis --------------- Seite 1: Speicheraufteilung (Standardsystem) 25 4 1. Uebersicht ueber das Betriebssystem OMOS 1630 ------------------------------------------------ 1.1. Einleitung --------------- Das Betriebssystem OMOS 1630 besteht im wesentlichen aus folgenden Komponenten: - Steuerprogrammsystem - Exekutive OMEX 1630 - Geraetedrivern zur Realisierung des physischen E/A-Transfers von und zu den peripheren Geraeten - Logischem E/A-System (FCS 1630) zum satz- bzw. blockweisen Datentransfer von und zu dateistrukturierten Datentraegern - Kommandosteuersprachen (MCR, DCL) zur Kommunikation zwischen dem Nutzer des Systems und dem Steuerprogrammsystem - Prozessor zur Verarbeitung von Indirekt-Kommandodateien, d.h. von Dateien, die aus einer Folge von Bedienerkommandos bestehen - Einem breiten Spektrum an Dienstprogrammen zur Nutzerprogramm- entwicklung, zur Datenmanipulation- und sicherung - Programmen zur Ueberwachung und Steuerung der verfuegbaren Systemressourcen, zur Fehlerregistrierung bei der Arbeit mit peripheren Geraeten und zur Wartungsunterstuetzung (on-line) - Zusaetzlichen Programmen, die die Anwendungsbreite des Betriebssystems erhoehen, wie z.B. die programmtechnische Emulation der Gleitkommabefehlssaetze des Arithmetikprozessors (ARP) des K 1630 bzw. des FIS-Befehlssatzes (Floating Point Instruction Set) anderer SKR-Rechner. Innerhalb der genannten Hauptkomponenten stehen dem Nutzer des Betriebssystems alle softwareseitigen Mittel zur Programmentwicklung und zur Programmsteuerung bereit, die auch im Betriebssystem MOOS 1.2 vorhanden sind. Bei der Beschreibung der Einzelkomponenten werden Grundkenntnisse ueber das Betriebssystem MOOS 1.2 vorausgesetzt. 1.2. Exekutive OMEX 1630 ------------------------- 1.2.1. Hauptkomponenten ----------------------- OMEX 1630 ist modular aufgebaut und kann hinsichtlich seiner Leistungsfaehigkeit an einen konkreten Anwendungsfall angepasst werden. Diese Anpassung erfolgt im Rahmen der Systemgenerierung. Nach erfolgter Systemgenerierung lassen sich viele Leistungsparameter der Exekutive noch veraendern, so dass es nicht erforderlich ist, fuer jeden Anwendungsfall speziell zugeschnittene Exekutiven zu erzeugen. Die Exekutive OMEX 1630 ist prinzipiell auf Hauptspeicher orientiert, die - ausschliesslich mit RAM-Speicherbausteinen aufgebaut sind, - deren Groesse ueber 32 K Worten liegt, d.h., es werden plattenresidente Betriebssysteme mit Adress- zuweisung durch den Entwickler bereitgestellt. Die grundlegenden Funktionen der Exekutive OMEX 1630 sind gegenueber MOEX 1600 unveraendert geblieben. Das bezieht sich auf: 5 - Speicherorganisation Abarbeitbare Programmeinheiten, Tasks werden in zusammenhaengenden Speicherbereichen, den Partitions, abgear- beitet. Partitions werden durch Namen, Basisadresse und Groesse beschrieben. Die Adresszuweisung, d.h. die Zuweisung virtueller Programmadressen (0...32 K Worte) zu den physischen Speicher- adressen (0...124 K Worte), erfolgt ueber die Speichervermitt- lungseinheit. OMEX 1630 unterstuetzt nutzer- und systemgesteuerte Partitions. Tasks koennen ihren Speicherplatz dynamisch durch REGIONS erweitern und COMMON-Bereiche bzw. residente Bibliotheken gemeinsam mit anderen Tasks benutzen. - Nutzerprogrammorganisation Ueber ein System der Nutzerprogrammorganisation wird die Koor- dinierung der abzuarbeitenden Tasks realisiert. Der Umstand, dass nur jeweils eine Task die Steuerung der ZVE (Zentrale Verarbeitungseinheit) besitzen kann, wird dadurch ausgeglichen, dass Wartezeiten, die bei der Taskabarbeitung entstehen, durch andere Tasks genutzt werden koennen. Um die Zuteilung von Zeiten, in denen eine bestimmte Task die Steuerung der ZVE hat, moeglichst gleichmaessig bzw. entsprechend der Bedeutung der Tasks im Verarbeitungsprozess zu gestalten, bietet die Exekutive OMEX (wie MOEX) verschiedene Mittel: . Taskstatus . Vergabe von Taskprioritaeten . Zeitscheibensteuerung . Ausnutzen signifikanter Ereignisse . Taskauslagerung auf Plattenspeicher (prioritaets- und zeitgesteuert) - Nutzung von Exekutiveleistungen Tasks koennen Leistungen der Exekutive anfordern. Durch Exekutiveanweisungen haben sie Zugang zu diesen Leistungen. Diese Anweisungen realisieren vielfaeltige Funktionen wie u.a.: . Steuerung der Taskabarbeitung . Austausch von Informationen zwischen verschiedenen Tasks . Erlangen von Systeminformationen . Ausfuehrung von Ein/-Ausgabeoperationen 1.2.2. Erweitertes Leistungangebot ---------------------------------- 2.1.2.1. Beziehungen zwischen Tasks ----------------------------------- Es besteht die Moeglichkeit, zwischen zwei Tasks sogenannte "Mutter/Tochter-Taskbeziehungen" aufzubauen. Diese sind wie folgt zu beschreiben: - Durch die Muttertask kann an die Tochtertask ein Kommando uebergeben werden, das in der Tochtertask mit Hilfe von FCS- Routinen analysiert und ausgefuehrt wird. - Die Muttertask kann auf die Beendigung der Tochtertask warten. - Die Tochtertask kann an die Muttertask Statuswerte uebergeben, 6 deren Bedeutung zwischen den Tasks vereinbart werden kann (z.B. Rueckkehrcodes). - Neben der Kommandouebergabe kann ein Datenaustausch auf der Ebene von Datenpaketen erfolgen. - Die Mutter/Tochterbeziehung kann von der Tochtertask auf eine andere Task uebertragen werden. Die genannten Moeglichkeiten werden durch neue Exekutivedirekti- ven realisiert. 1.2.2.2. Ereignisflags ---------------------- Neben den vom MOOS 1600 her bekannten 64 Ereignisflags (globale und lokale) koennen pro Gruppennummer des User Identification Code (UIC) weitere 32 Ereignisflags (Nr.65 bis 96) verwendet werden. Die Tasksynchronisation zwischen Tasks, deren Task-UIC die gleiche Gruppennummer hat, kann somit erweitert werden. Hierzu stehen zusaetzliche Exekutivedirektiven zur Verfuegung. 1.2.2.3. STOP - Bit - Arbeit ---------------------------- Spezielle Direktiven erlauben es, eine Task in den STOP-Zustand zu versetzen. Eine solche Task hat die Taskprioritaet 0. Ihre Auslagerung (falls diese erlaubt ist) kann dann von anderen Tasks erzwungen werden. Die Task bewirbt sich erst dann wieder um HS- Platz, wenn der STOP-Zustand beendet ist. Die Ereignisflags werden in den STOP-Direktiven in gleicher Weise wie in den Direktiven zum Blockieren einer Task verwendet. 1.2.2.4. Weitere Leistungen --------------------------- - Privilegierte Tasks koennen die Systemzeit neu setzen. - Beim Abbrechen zeitabhaengiger Taskaktivitaeten koennen spezielle Ereignisflags oder Eintrittspunkte asynchroner Systemtraps (AST's) angegeben werden. - Es ist moeglich, den Abbruch einer Task durch das Bedienerkommando ABO oder durch eine ABRT$-Anweisung zu verhindern, indem fuer diesen Fall ein AST-Eintrittspunkt vorgesehen wird. Wird fuer die Task ein Abbruch angewiesen, wird dieser nicht ausgefuehrt, sondern es wird zu der vorgesehenen AST-Routine verzweigt. Bei nichtprivilegierten Tasks kann der Abbruch einmal verhindert werden, eine folgende Abbruchanforderung ist immer erfolgreich. Bei privilegierten Tasks koennen alle Abbruchanforderungen ueber den AST-Eintrittspunkt abgefangen werden. 7 1.2.3. Bedienerkommunikation ---------------------------- Zur Kommunikation des Nutzers mit der Exekutive stehen zwei CLI's (Command Line Interpreter) zur Verfuegung: MCR DCL MCR ist der Standard-CLI des Systems. Es stehen die vom MOOS her bekannten Kommandos mit funktionellen Erweiterungen und neue Kommandos zur Verfuegung. DCL ist ein alternativ nutzbarer CLI. Die DCL-Syntax ist der englischen Sprache entlehnt. Waehrend ein MCR-Kommando einzelne Aktionen der Exekutive (oder einer Systemtask) aktiviert, sind die DCL-Kommandos komplexer. Sie werden durch DCL analysiert und in entsprechende MCR-Kommandos und/oder Kommandozeilen fuer Dienstprogramme zurueckgefuehrt, die dann ausgefuehrt werden. DCL-Kommandos sind fuer ungeuebte Nutzer leichter zu erlernen und reduzieren die fuer die Kommunikation mit dem System notwendige Zeit. Neben den Bedienerkommandos steht dem Nutzer ein Prozessor zur Verarbeitung von Indirekt-Kommandodateien zur Verfuegung (AT-Prozessor). Mittels dieses Prozessors koennen Dateien, die Folgen von Bedienerkommandos enthalten, interpretiert und abge- arbeitet werden. Die Arbeitsweise ist analog der des AT- Prozessors des MOOS. Die Moeglichkeiten der Anwendung sind durch funktionelle Erweiterungen stark vergroessert worden. Vor allem wurden mehr Standardvariablen (Symbole) zur Steuerung des Ablaufes einer Indirekt-Kommandodatei bereitge- stellt. 1.3. Systemserviceprogramme --------------------------- Mit OMOS 1630 werden einige zusaetzliche, im MOOS 1.2 nicht verfuegbare Systemleistungen angeboten, die den Komfort bei der Anwendung des Systems erhoehen. Die wichtigsten dieser Komponenten sind: - PMT 1630 (Pool-Monitor) PMT dient der Ueberwachung des dynamischen Bereiches der Exeku- tive (Pool) mit dem Ziel, eine uebermaessige Belastung des Pools zu vermeiden. Eine derartige Belastung kann zu Situationen fuehren, in denen der Bediener keine Aktionen der Exekutive mehr einleiten kann und ein Wiederanlauf des Systems erforderlich wird. PMT ueberwacht, dass ein definiertes Minimum an freiem Platz im Pool nicht unterschritten wird. Tritt dieser Zustand ein, so wird der Bediener zum Abbruch von Tasks aufge- fordert. - RMD 1630 (Resource Monitoring Display) RMD bietet die Moeglichkeit, dass der Bediener sich die momen- tane Inanspruchnahme von Systemressourcen am Terminal darstel- len lassen kann. Der Nutzer kann unter verschiedenen Informationsseiten (quasigrafische Darstellungen der Rechnerbe- lastung) auswaehlen. 8 - FPEM 1630 (Floating Point Emulator) FPEM bietet die Moeglichkeit der direkten Abarbeitung von Gleitkommabefehlen. Es werden die Gleitkommabefehle des Arithmetikprozessors (ARP) des K 1630 sowie der Befehlssatz FIS anderer SKR-Rechner nachgebildet. Somit ist das Vorhandensein der entsprechenden Hardware nicht mehr Voraussetzung fuer die Abarbeitbarkeit von Programmen mit Gleitkommabefehlen (z.B.FORTRAN 77-Programme auf Rechnern K 1630 ohne ARP). 1.4. Dienstprogramme, Programmentwicklung ----------------------------------------- Dem Anwender des Betriebssystems OMOS 1630 steht ein breites Spektrum an Dienstprogrammen zur Verfuegung. Diese Hilfsprogramme dienen im wesentlichen der - Entwicklung und Austestung von Anwenderprogrammen - Verwaltung und Pflege von Daten- und Programmbestaenden - Datensicherung. Unter dem Aspekt der strikten Aufwaertskompatibilitaet von MOOS 1.2 zu OMOS 2.0 werden alle vom MOOS her bekannten Dienstprogramme zur Verfuegung gestellt. In OMOS sind einige Erweiterungen realisiert, die einen erhoehten Service bei der Nutzung der Dienstprogramme darstellen. Diese sind folgende: 1. Funktionelle Erweiterungen existierender Programme 2. Neue Dienstprogramme In Tabelle 1 sind die im OMOS 1630 zur Verfuegung stehen- den Dienstprogramme enthalten. Tabelle 1: Dienstprogramme des OMOS 1630 (Ausgabe 2.0) ----------------------------------------------------------------- Unveraendert gegen- Funktionell er- neue Dienst- ueber MOOS 1.2 weitert gegen- programme ueber MOOS 1.2 ----------------------------------------------------------------- EDI 1630 PIP 1630 BRU 1630 PTI 1630 TKB 1630 EDT 1630 PAT 1630 LBR 1630 SRD 1630 ZAP 1630 CDA 1630 FMT 1630 DMP 1630 DSC 1630 IOX 1630 CMP 1630 System der Fehler- FEX 1630 registrierung FLX 1630 (ERROR-LOGGING) VFY 1630 MAC 1600 BAD 1630 ODT/DEP 1630 SLP 1630 On-line-Geraetetest- programme Die funktionellen Erweiterungen der o. g. Dienstprogramme beziehen sich z. B. auf: 9 - zusaetzliche Funktionsschalter (PIP) - Erweiterungen bei Standards von Dateivereinbarungen (PIP) - Unterstuetzung zusaetzlicher Bibliothekstypen (LBR, TKB) - zusaetzlichen Informationsgehalt (CDA, Fehlerregistrierung) Die in Tabelle 1 aufgefuehrten neuen Dienstprogramme des OMOS 1630 realisieren folgende Aufgaben: - BRU 1630 (Backup and Restore Utility) BRU dient dem Kopieren und damit dem Retten bzw. Zureckspei- chern von Datenbestaenden von Platten auf Magnetbaendern. Ein Datentransfer Platte-Platte ist ebenfalls moeglich. Neben dem Kopieren von kompletten Datentraegern (Volumes) ist der Zugriff auf einzelne Dateien (Files) sowohl beim Kopieren als auch beim Zurueckspeichern moeglich. Die Ausgabe von Verzeichnissen von Dateien, die zu einem "BACKUP" (Kopierter Dateibestand) gehoeren, ist moeglich. - EDT 1630 (Editor) EDT ist ein bildschirmorientierter Texteditor. EDT bietet einen wesentlich hoehreren Bedienerservice als EDI. Ein weiterer Vor- teil von EDT ist, dass die Befehle zum Texteditieren in einer Protokolldatei (Journal-File) abgespeichert werden. Diese kann im Fall eines Systemausfalls nach Wiederanlauf abgearbeitet werden. - SRD 1630 (Sort Directory) Mit SRD 1630 koennen Datentraegerverzeichnisse in vielfaelti- ger Weise manipuliert werden. So ist z. B. eine wahlweise Sortierung der Dateispezifikationen innerhalb von Nutzerdatei- verzeichnissen (UFD's) nach Dateinamen, -typ und Versionsnum- mern moeglich. - FMT 1630 (Formatierprogramm) Mit FMT koennen Platten formatiert werden. Dies geschieht unter Steuerung der Exekutive. - IOX 1630 (E/A-Pruefprogramm) IOX gestattet das Ueberpruefen der Funktionsfaehigkeit von externen Geraeten (Platten, Magnetbaendern, Magnetbandkasset- ten). Die Testroutinen von IOX behandeln: - Datentraeger im FM-16-Format (dateistrukturiert) - nichtdateistrukturierte Datentraeger Die Tests koennen unter Erhaltung des jeweiligen Datentraeger- inhalts ablaufen. Es ist auch moeglich, diesen zu ueberschreiben. 1.5. Eingabe/Ausgabe -------------------- Im BS OMOS 1630 kann die E/A-Arbeit auf zwei verschiedenen Stufen realisiert werden. Die erste Stufe ist der physische Transfer, der durch eine Task mit Anweisungen an den Geraetedriver ausgefuehrt wird. Die zweite Stufe ist ein logisches E/A-System, das Anweisungen von einer Task zur dateibezogenen E/A-Arbeit erhaelt. 10 1.5.1.Geraetedriver ------------------- Fuer die Realisierung der Ein- und Ausgabe von und zu peripheren Geraeten auf physischer Ebene (d. h. durch Nutzung der QIO$- Exekutivedirektive) steht dem Nutzer ein Spektrum an Geraete- drivern zur Verfuegung. Im Gegensatz zum MOOS ist das Driverkonzept des OMOS 1630 derart gestaltet, dass alle Driver als ladbar mit ladbarer Datenbasis aufgebaut sind. Dies gilt auch fuer den Geraetedriver der Bediengeraete. Dieses Konzept hat den Vorteil, dass Veraenderun- gen hinsichtlich zu unterstuetzender Geraete problemlos reali- siert werden koennen. Bei Anschluss zusaetzlicher Geraete einer bestimmten Geraeteklasse kann der betreffende Driver mit erweiterter Datenbasis neu erzeugt und in das Betriebssystem eingebunden werden, ohne dass das Betriebssystem erneut generiert werden muss. In der Ausgabe 2.0 stehen fuer OMOS 1630 die in Tabelle 2 aufgefuehrten Driver zur Verfuegung: Tabelle 2: Geraetedriver des OMOS 1630 (Ausgabe 2.0) ---------------------------------------------------------------- Geraete- Chiffre Geraetename Bemerkung bezeichnung im System ---------------------------------------------------------------- Bedieneinheit K 8911 TT Vollduplex Rastersicht- K 8917 geraet ---------------------------------------------------------------- Bedieneinheit K 8911 TG Halbduplex Rastersicht- K 8917 Grafikfunktionen geraet realisiert ---------------------------------------------------------------- Kassetten- CM 5400 DK plattenspeicher ---------------------------------------------------------------- Festplatten- K 5501.xx DM speicher ---------------------------------------------------------------- Magnetband- CM 530x MT geraet ---------------------------------------------------------------- Kassettenmag- K 5261 CT netbandgeraet ---------------------------------------------------------------- Lochbandeinheit K 6200 PR/PP ---------------------------------------------------------------- Folienspeicher- K 5661.xx DY einheit K 5665 ---------------------------------------------------------------- Paralleldrucker VT 27065 LP Grafikfunktionen Seriendrucker SD 1152 realisiert SD 1157.xxx K 631x ---------------------------------------------------------------- 11 Tabelle 2: (Fortsetzung) ---------------------------------------------------------------- Geraete- Chiffre Geraetename Bemerkung bezeichnung im System ---------------------------------------------------------------- Bildspeicher K 3567 RM Gemeinsamer K 3667 Speicher ---------------------------------------------------------------- Display- K 2067 DD prozessor ---------------------------------------------------------------- Grafiksteuerung K 7067.xx GD ---------------------------------------------------------------- Rollkugel- K 7767 TB einheit ---------------------------------------------------------------- Die Anwendung der Standard- bzw. der geraetespezifischen Funktionscodes der QIO$-Anweisungen ist in der Anleitung fuer den Programmierer, Teil 3: "E/A- System" beschrieben. Einige Besonderheiten gelten fuer die Bediengeraetedriver (TTDRV und TGDRV): - Der TT-Driver arbeitet im Vollduplexbetrieb. Drucker, die ueber serielle Hardwareschnittstellen angeschlossen sind (AIS), koennen ueber diesen Driver ebenfalls bedient werden. Der Vollduplexbetrieb ist fuer viele im OMOS vorhandene Leistungen notwendig. Dieser Driver realisiert keine Grafikfunktionen. Ueber einen speziellen Funktionscode (IO.WAL) ist jedoch die Ausgabe grafischer Zeichen moeglich. - Der TG-Driver arbeitet im Halbduplexbetrieb. Er ist hinsichtlich seines Leistungsumfanges identisch mit dem TT- Driver des MOOS 1600. - Beide Driver koennen gleichzeitig im System geladen sein. Die Auswahl, welcher Driver fuer ein bestimmtes Bediengeraet (oder RSG) momentan genutzt werden soll, kann durch ein MCR-Kommando am entsprechenden Bediengeraet getroffen werden. 1.5.2.FCS 1630 -------------- Das Dateizugriffssystem FCS 1630 ermoeglicht die Bearbeitung von Daten auf Dateiebene. Dabei koenen folgende Operationen stattfinden: - Erstellen, Erweitern, Loeschen von Dateien - Lesen und Schreiben logischer Saetze im sequentiellen und im Direktzugriff mit Synchronisation durch die Exekutive - Lesen und Schreiben virtueller Bloecke mit Synchronisation durch die Nutzertask - Bearbeitung von Magnetbanddateien mit Datenkonvertierung (EBCDIC- Code, KOI7- Code). Die interne Struktur des FCS 1630 wurde optimiert. Das bewirkt eine Erhoehung der Verarbeitungsgeschwindigkeit. So ist es 12 beispielsweise moeglich, den Verarbeitungsprozessor fuer datei- strukturierte Datentraeger (FCP fuer Magnetplatten) so zu bilden, dass er vollstaendig HS-resident ist. Damit entfallen bei der Dateiarbeit auf Magnetplatte Zugriffe zum Laden notwendiger Routinen dieses Prozessors. Da dies zu Lasten des fuer den Nutzer verfuegbaren HS-Platzes geht (Speicherbedarf des HS-residenten FCP ca. 9,5 K Worte), ist es auch moeglich, auch eine FCP- Variante zu erzeugen, die nicht vollstaendig HS-resident ist, funktionell aber die gleiche Leistungsfaehigkeit hat (Speicherbedarf ca. 5,5 K Worte). Die Dateizugriffsroutinen des MOOS 1600 sind im FCS 1630 vollstaendig enthalten, so dass die Aufwaertskompatibilitaet zwischen MOOS 1600 und OMOS 1630 gewaehrleistet ist. Zusaetzliche Funktionen des FCS 1630 gegenueber denen des FCS 1600 sind: - Unterstuetzung der Verarbeitung von Magnetbaendern, die dem ANSI-Standard entsprechen (Namenskonventionen). - Ueber Konvertierungsroutinen und Codeumsetzungstabellen ist die Verarbeitung von Magnetbanddateien, die im EBCDIC-Code gespeichert sind, moeglich. - Ein spezielles Steuerprogramm (MAG) steht zur Verfuegung, das die Ausgabe von Dateiattributen kennsatzloser Baender realisiert. Baender ohne Kennsaetze und ANSI-Baender koennen positioniert werden. - Bei Abschliessen von Dateien (Funktion: CLOSE$) wird eine Datei auf ihr logisches Ende verkuerzt. - Es ist moeglich, HS-residente FCS-Bibliotheken mit speicher- residenter Ueberlagerung aufzubauen. - Die Moeglichkeiten der Interpretation von Kommandozeilen (CSI) sind erweitert. - Durch die Nutzung von Grosspuffern, die dem Mehrfachen eines Plattenblockes entsprechen, wird eine Reduzierung von Platten- zugriffen erreicht. - Es werden Mehrfachpuffer unterstuetzt. 1.6. Bibliotheken ----------------- Zum BS OMOS 1630 gehoeren folgende Systemobjektmodulbibliothe- ken und Makrobibliotheken: SYSMAC.SML SYSLIB.OLB VMLIB.OLB EXEMC.MLB EXELIB.OLB In diesen Bibliotheken sind physisch Makros bzw. Unterpro- gramme zusammengefasst, die allgemein benoetigt werden. Dabei gelten die SYSMAC.SML als System-Makrobibliothek fuer den Assembler MAC 1600 bzw. die SYSLIB.OLB als System-Objektmo- dulbibliothek fuer den Taskbilder TKB 1630; der Zugriff des Assemblers bzw. Taskbilders erfolgt ohne gesonderte Angabe dieser Bibliotheken im Kommando. Diese beiden Bibliotheken sind fuer die Anwender von besonderem Interesse, da in ihnen die meisten allgemein benoetigten Routinen (Exekutiveanweisungen, FCS-Makros, Routinen zur Unterstuetzung der Magnetbandarbeit u.a.) enthalten sind. Die Makros der 13 SYSMAC.SML sind oft Aufrufmakros fuer Unterprogramme aus der SYSLIB.OLB. Programme in Assemblersprache rufen meist Makros der SYSMAC.SML auf, die ihrerseits die entsprechenden Unterprogramme der SYSLIB.OLB aktivieren. Programme in hoeheren Programmier- sprachen organisieren den Aufruf der Unterprogramme und die Parameteruebergabe direkt. In der SYSLIB.OLB sind weiterhin die sogenannten Systembibliotheksroutinen enthalten, die die Gebiete Registerrettung Arithmetik Ein-/Ausgabe-Konvertierung Ausgabeformatierung bearbeiten. Sie werden im Quellprogramm mit CALL- oder JSR- Anweisungen aufgerufen und beim Taskbilden gebunden. Die Bibliothek VMLIB.OLB ist eine der Hauptbibliotheken der Exekutive. Die in ihr u.a. enthaltenen Routinen zur Verwaltung des virtuellen Speichers koennen auch in Anwenderprogrammen benutzt werden. Die EXELIB.OLB und die EXEMC.MLB sind systeminterne Bibliothe- ken. Sie enthalten systeminterne Vereinbarungen, von denen einige bei der Programmierung ladbarer Driver benutzt werden. Fuer den Anwender besteht im BS OMOS 1630 die Moeglichkeit, eigene Bibliotheken zu bilden und zu verwalten. Die Moeglichkeit dazu bietet das Dienstprogramm LBR 1630 (Bibliothekar). Wie im BS MOOS 1600 koennen nutzereigene Makro- und Objektmodulbibliotheken gebildet und gewartet werden. Um die Aufwaertskompatibilitaet zwischen MOOS 1600 und OMOS 1630 zu foerdern, sollten alle weiterzufuehrenden Objektmodulbibliotheken mit dem Dienstprogramm LBR 1630 neu gebildet werden, da der Taskbilder TKB 1630 eine Strukturerweiterung bei Objektmodulbibliotheken vorschreibt. Der Bibliothekar LBR 1630 bietet dem Nutzer des BS OMOS 1630 erstmals die Moeglichkeit, auch andere Bibliotheken zu bilden. In diesen Universalbibliotheken mit dem Typ .ULB koennen auf Wunsch des Anwenders beliebige Moduln (z.B. Kommandodateien), die jedoch fuer eine Bibliotheksbestand denselben Typ haben muessen, zusammengefasst werden. Ihre Wartung ist mit LBR 1630 bzw. mit Routinen der Systembibliothek moeglich. 14 2. Herstellen des Nutzersystems ------------------------------- 2.1. Ueberblick ueber die Generierung ------------------------------------- 2.1.1. Interner Teil -------------------- Die Generierung des Betriebssystems OMOS 2.0 wird ausschliesslich in den Vertriebsbetrieben durchgefuehrt. Da der Vertrieb des Betriebssystems hauptsaechlich in Form von Standardvarianten erfolgt, wird eine Neugenerierung nur in einzelnen Faellen bzw. im Rahmen der Fehlerbeseitigung noetig. Als Anleitung fuer diese Generierung ist die interne Schrift "Generierung des Betriebssystems OMOS 2.0" zu verwenden. Das Verteilersystem zum OMOS 2.0 setzt sich wie folgt zusammen: 1. Basissystem OMOSSYS - Inhalt: zur Generierung notwendige Dienstprogramme, Objektmoduln fuer DEP und ODT - Kommandodateien zur Generierung 2. Quellenplatte EXCSRC - Inhalt: Makrobibliotheken alle Quellen (Exekutive + Driver) Kommandodateien zur Generierung 3. Objektmodulplatte PRVOBJ - Inhalt: Objektmodulbibliotheken Objektmoduln der privilegierten Tasks Kommandodateien zum Erzeugen der Kommandodateien fuer das Taskbilden und zum Erzeugen der Ueberlagerungsbeschreibungen 4. Ergaenzungsplatte UTILITY - Inhalt: Zusaetzliche Tasks, Objektmoduln und Kommandodateien 5. Platte zum Generieren der bildverarbeitungsspezifischen Komponenten GENBVS - Inhalt: Driverquellen der BVS- Driver Kommandodateien zum Aufbau der BVS- Driver Objekte und Kommandodateien fuer BVS- Testprogramme Die Generierung des OMOS 2.0 gliedert sich in drei Stufen: 15 Stufe 1 - Uebersetzen der Quellen der Exekutive, des TT-Drivers und aller anderen Driver, Aufbau einer Objektmodul- bibliothek und von Parameter- und Kommandodateien zur Weiterverarbeitung in Stufe 2 Stufe 2 - Aufbau der Exekutive-Task, des Terminaldrivers, aller anderen Driver und der privilegierten Tasks Herstellen des neuen ladefaehigen Systems Stufe 3 - Aufbau zusaetzlicher, allgemein benoetigter Dienstpro- gramme, von zusaetzlichen Tasks, Einbinden von BVS- Driver und nutzereigenen Drivern, Aufbau der On-line- Geraetetestprogramme Das fertige Betriebssystem wird ladefaehig auf Magnetband zum Vertrieb bereitgestellt. Die Komponenten des Betriebssystems OMOS 2.0 befinden sich auf zwei Plattenkassetten vom Typ CM 5400 mit den Datentraegerkennsaetzen OMOSSYS und OMOSZUS oder auf einer Festplatte vom Typ K5501 mit dem Datentraegerkennsatz OMOSSYS. Dieses Betriebssystem enthaelt die Exekutive, die privilegierten Tasks, die Driver und alle zu einer sinnvollen Arbeitsweise notwendigen Dienstprogramme. Der Leistungsumfang der Exekutive kann vom Anwender anhand vorgegebener Standardvarianten ausgewaehlt werden. Die Konfigurierung des Systems erfolgt durch den Vertriebsbetrieb aufgrund der geraetetechnischen Festlegungen des Anwenders. Ausserdem erhaelt der Anwender den Inhalt der Dienstprogrammplatte (Datentraegerkennsatz UTILITY). Hier befin- det sich ein Spektrum von Programmen, Moduln und Kommando- dateien, die den Anwender befaehigen, sein Betriebssystem um bestimmte Dienstprogramme zu komplettieren und vorhandene Tasks entsprechend ihren Standardleistungen zu veraendern. 2.1.2. Oeffentlicher Teil ------------------------- Die Stufe 3 der Systemgenerierung kann der Anwender selbst durchfuehren. Dazu steht ihm auf der Systemzusatzplatte UTILITY eine Indirekt-Kommandodatei SYSGEN3.CMD zur Verfuegung, mit deren Hilfe er die Dienstprogramme und auch einige privilegierte Tasks neu bilden kann (z.B. wenn diese ANSI-Magnetbaender bearbeiten oder auf eine residente FCS-Bibliothek zugreifen sollen bzw. wenn Grosspuffer oder Mehrfachpuffer unterstuetzt werden sollen). Das Konzept ladbarer Driver mit ladbarer Datenbasis ermoeglicht die Anpassung des lauffaehigen Anwendersystems an geaenderte Konfigurationen. Ist eine Neuuebersetzung eines zum Lieferumfang des OMOS 2.0 gehoerenden Drivers notwendig, so erhaelt der Anwender vom jeweiligen Vertriebsbetrieb den Objektmodul des von ihm gewuenschten Drivers. Diesen Modul kann der Anwender dann unter Steuerung einer Indirekt-Kommandodatei in sein Betriebssystem einbinden. Ausserdem besteht die Moeglichkeit, nutzereigene Driver gemaess den Konventionen des OMOS 1630 zu verwenden. Die Bereitstellung von ladbaren Drivern mit erweiterter Datenbasis auf Grund einer realisierten geraetetechnischen Erweiterung wird vom Vertriebsbetrieb vorgenommen. Die 16 Unterstuetzung der dafuer notwendigen Anschlusssteuereinheiten ist in den Standardsystemvarianten gesichert, so dass im Allgemeinen keine Neugenerierung erforderlich sein wird. 2.2. Grundbegriffe im BS OMOS 1630 ---------------------------------- 2.2.1. Partition ---------------- Partitions sind Bereiche im physischen Hauptspeicher, in denen Tasks abgearbeitet werden koennen. Sie sind durch Namen, Anfangsadresse (Basisadresse) und Groesse gekennzeichnet. OMEX 1630 unterstuetzt zwei Arten von Partitions: - die nutzergesteuerten oder festen Partitions und - die systemgesteuerten Partitions. 2.2.1.1. Nutzergesteuerte Partition ------------------------------------ Eine nutzergesteuerte Partition (Hauptpartition) kann in maximal sieben feste Subpartitions unterteilt werden. Es kann entweder eine einzige Task in der gesamten Hauptpartition arbeiten, oder es koennen bis zu sieben Tasks gleichzeitig in den Subparti- tions arbeiten. Wenn eine Task in der Hauptpartition arbeitet, kann keine Task in einer Subpartition arbeiten. Die Haupteigenschaft der nutzergesteuerten Hauptpartition besteht darin, dass unabhaengig von ihrem Speicherbedarf jeweils nur eine Task in ihr arbeiten kann. Das kann zwar zu einer gewissen Ver- schwendung von Speicherplatz fuehren, hat anderseits aber den Vorteil, dass der Nutzer die vollstaendige Kontrolle ueber die Systemaktivitaeten besitzt. 2.2.1.2. Systemgesteuerte Partition ----------------------------------- Systemgesteuerte Partitions sind zusammenhaengende Speichergebie- te, die von der Exekutive verwaltet und den Tasks dynamisch zuge- teilt werden. Den einzelnen Tasks werden jeweils zusammenhaengen- de Bereiche zugewiesen. Es koennen soviele Tasks gleichzeitig in einer systemgesteuerten Partition arbeiten, wie diese aufnehmen kann. Wenn eine Task aktiviert wird, wird sie in eine nach Prio- ritaeten geordnete Taskwarteschlange fuer die jeweilige systemge- steuerte Partition eingeordnet. Die wartenden Tasks werden gemaess ihrer Prioritaeten nacheinander in die systemgesteuerte Partition geladen. Weiterer freier Platz wird erst gewonnen, wenn eine Task blockiert ist und eine Task hoeherer Prioritaet auf Speicherplatzzuweisung wartet. Das geschieht durch Auslagerung von Tasks und Umlagern der geladenen Tasks durch den Shuffler (siehe Anleitung fuer Systemprogrammierer, Teil 4). Jedesmal, wenn eine Task die Arbeit beendet und Speicher in der Partition freigibt, versucht die Exekutive, die Task hoechster Prioritaet aus der Partitionwarteschlange in diesen Bereich zu laden. Der Nutzen einer systemgesteuerten Partition besteht in der Ersparnis an Speicherplatz, die durch die Exekutive organisiert wird. Es koennen also zwei Tasks, wie z.B. PIP und TKB, gleich- zeitig abgearbeitet werden, ohne dass jede Task eine eigene 17 Partition besitzt. Das ist praktisch die sinnvollste Arbeits- weise in Mehrnutzersystemen. Ist die letzte Partition im System eine systemgesteuerte Partition (Driver-Partitions nicht beruecksichtigt), wird sie bei Neustart des Systems in ihrer Groesse automatisch bis zum Ende des physischen Speichers ausgedehnt. Um eine nachtraegliche Vergroesserung des Hauptspei- chers zu nutzen, ist also keine Neugenerierung notwendig. 2.2.1.3. Residente Bibliothek und Common-Bereich ------------------------------------------------ OMEX 1630 unterstuetzt residente Bibliotheken und COMMON- Bereiche, die von mehreren Tasks genutzt werden koennen. Diese Moeglichkeit erspart Speicherplatz in den Taskpartitions und in den Taskabbilddateien, da die in einer residenten Bibliothek angesiedelten Moduln nicht ins Taskabbild einer auf sie zugreifenden Task gebunden werden. Residente Bibliotheken und COMMON-Bloecke muessen in COMMON-Partitions installiert werden. Um diese Moeglichkeit zu nutzen, sind einige Konventionen beim Festlegen der Partitions (MCR-Kommando SET), beim Taskbilden fuer die residente Bibliothek bzw. den COMMON-Bereich (z.B. muessen Task und Partition denselben Namen haben) und beim Taskbilden fuer die anderen, darauf zugreifenden Tasks zu beachten. Die unselbstaendigen Tasks einer residenten Bibliothek oder eines COMMON-Blocks werden mit dem INS-Kommando installiert und auch in den Speicher geladen. Das ist ein Sonderfall der Verarbeitung durch INS (alle anderen Tasks werden nur in das System-Taskver- zeichnis eingetragen). Tasks, die auf residente Bibliotheken oder COMMON-Bloecke zugrei- fen wollen, koennen erst installiert werden, nachdem die entspre- chenden residenten Bibliotheken und Common-Bloecke installiert worden sind. Die Arbeit mit residenten Bibliotheken ist im BS OMOS 1630 gegenueber den Vorgaengersystemen stark erweitert, was auf die erhoehte Leistungsfaehigkeit des Taskbilders zurueckzufuehren ist. Das hauptsaechliche Anwendungsgebiet ist die Nutzung einer residenten FCS-Bibliothek durch System- und Nutzertasks. 2.2.2. Tasks ------------ Eine Task ist eine abarbeitbare Programmeinheit. Sie entsteht im Prozess der Programmentwicklung (siehe Anleitung fuer Programmierer, Teil 1): aus einem Quellprogramm wird durch den Assembler oder einen Compiler ein Objektmodul, der durch den Taskbilder in eine Task uebergefuehrt wird. Eine Task residiert in ihrer Taskabbilddatei auf einer Magnetplatte. Zur Abarbeitung wird sie entweder durch das MCR-Kommando RUN oder, wenn sie vorher mit Hilfe des Kommandos INS installiert wurde, mit ihrem Tasknamen aufgerufen (siehe Anleitung fuer Bediener, Teil 2). Weist man einer Task beim Taskbilden oder Installieren einen Namen zu, der mit drei Punkten beginnt und weiterhin drei Buchstaben enthaelt, so ist dieser aus drei Buchstaben bestehende Taskname zum Aufrufen der Task ausreichend. Er wird also wie ein Kommando benutzt. 18 2.2.2.1. Nichtprivilegierte Task -------------------------------- Eine nichtprivilegierte Task ist die Normalform von Tasks, die auf Rechnern abgearbeitet werden. Sie benutzt bei ihrer Ausfuehrung Exekutiveleistungen in Form von Makros und Unterprogrammen. Ihr logische Adressraum (das ist der Bereich, auf den eine Task zu einem Zeitpunkt zugreifen kann) ist auf 32 K Worte begrenzt. sie kann diesen durch plattenresidente oder speicherresidente Ueberlagerungssegmente oder durch die Benutzung einer COMMON-Partition erweitern. Dazu erhaelt sie Unterstuetzung durch die Exekutive. Sie kann nicht auf Bereiche anderer Tasks zugreifen. 2.2.2.2. Abhaengige Task ------------------------ Abhaengige Tasks sind Tasks, die Funktionen fuer andere Tasks ausfuehren. Sie werden mit den Anweisungen RQST$ (Aktivieren einer Task) und SDAT$ (Senden eines Datenblocks) aktiviert. Wenn eine abhaengige Task eine Anweisung RCVD$ oder RCVX$ (Empfangen eines Datenblocks) ausfuehrt, uebernimmt sie auto- matisch das Bediengeraet und den Schutz-UIC von der Sendertask. Dadurch hat eine abhaengige Task immer die gleichen Zugriffsrecht zu Dateien und zugeteilten Datentraegern wie die Sendertask. Wenn eine abhaengige Task die Anweisung ALUN$ (Zuweisen einer logischen Geraetenummer) ausfuehrt, werden alle bisherigen Zuweisungen von logischen Geraeten fuer das aktuelle TI ignoriert. Abhaengige Systemtasks sind im BS OMOS 1630 die Cross-Referenz- Task CRT..., der Print-Spooler PRT... und die Task zur Erzeugung eines Speicherabzugs PMD... 2.2.2.3. Privilegierte Task --------------------------- Privilegierte Tasks sind solche, die im System gewisse Vorrechte besitzen. Dieser Status muss schon beim Taskbilden vereinbart werden. Die Privilegien betreffen u.a. - Zugriffsrechte auf Speicherbereiche des Systems, also auch der Exekutive - Zugriffsrechte auf Speicherbereiche anderer Tasks - Zugriffsrechte auf den Bereich der Geraeteregister (IOPAGE) - Vorausbestimmte Zuordnung der Seitenadressregister - Ausschalten des Dateischutzes - Schreiben auf eingegliederte Geraete anderer Nutzer Aus diesem Privilegstatus leiten sich bestimmte Nutzungsregeln ab, die durch diese Tasks steng beachtet werden muessen. Bei der Programmierung von privilegierten Tasks, namentlich, wenn Bereiche einnerhalb der Exekutive und der Bereich der E/A-Regis- ter veraendert werden, ist besondere Vorsicht geboten (naeheres dazu in der Anleitung fuer Bediener, Teil 4: "Dienstprogramme" bei der Beschreibung des Taskbilders). 19 2.2.3. Methoden des Systems zur Arbeitsorganisation --------------------------------------------------- Wie allgemein bekannt, kann zu einem Zeitpunkt nur eine Task die Steuerung der Zentralen Verarbeitungseinheit besitzen. Waehrend der Bearbeitung einer Task treten aus verschiedenen Gruenden Unterbrechungen ein. In diesen Zwischenzeiten koennen andere Tasks dei Steuerung der ZVE erhalten. Damit ein grosser Systemdurchsatz erzielt wird (d.h. dass angemeldete Tasks inner- halb einer angemessenen Zeit fertig bearbeitet werden und dass die Wartezeiten der ZVE gering bleiben), werden von der Exe- kutive verschiedene Methoden der Arbeitsorganisation angewendet. Ein wichtiges Hilfsmittel dabei ist die Fuehrung von Warte- schlangen zu bestimmten Zwecken: Anforderungen zur Aktivierung von Tasks werden in Warteschlangen fuer Partitions eingereiht, E/A-Anforderungen in Warteschlangen fuer bestimmte Geraete usw. Die wichtigsten Arbeitsmethoden der Exekutive sollen hier erlaeutert werden. 2.2.3.1. Prioritaets- und zeitgesteuerte Aktivierung von Tasks -------------------------------------------------------------- Eine Task wird durch das MCR-Kommandi INS dem System bekanntgemacht, also ins System-Taskverzeichnis eingetragen. Bei einer Startanforderung ermittelt die Exekutive die Partition, in der die Task abgearbeitet werden soll, und reiht die Task in die Warteschlange dieser Partition ein. Im System-Taskverzeichnis stehen die Tasks in der Reihenfolge, in der sie installiert wurden. Im Gegensatz dazu ist die Warteschlange der Partitions nach Taskprioritaeten geordnet. Die Task mit der hoechsten Prioritaet, fuer die der Platz in der Partition ausreicht, wird geladen. Von allen geladenen Tasks kommt wiederum diejenige mit der hoechsten Prioritaet zur Ausfuehrung. Tritt eine Blockierung ein, kann eine andere geladene Task weiterarbeiten (usw.). Bei jeder Unterbrechung prueft die Exekutive das System-Taskverzeichnis und alle Warteschlangen, um Anforderungen zum Laden von Tasks und zur Weiterarbeit zu erfuellen. Tasks, die zeitabhaengig aktiviert weden, nehmen insofern eine Sonderstellung ein, dass sie in die Warteschlange des Konsolterminals eingeordnet werden und zum vorgesehenen Zeitpunkt von dort mit einer hoeheren Prioritaet gestartet werden. 2.2.3.2. Prioritaets- und zeitgesteuerte Auslagerung von Tasks -------------------------------------------------------------- Wird eine wartende Task durch Warten auf ein bestimmtes Ereignis (E/A-Beendigung o.ae.) unterbrochen, kann eine andere Task weiterarbeiten. Befindet sich in der Warteschlange der Partition nun eine Task mit hoeherer Prioritaet, kann die Exekutive die blockierte Task auf Platte auslagern (wenn diese auslagerbar ist). Damit werden Wartezeiten fuer Tasks hoeherer Prioritaet klein gehalten. In einer nutzergesteuerten Partition erfolgt eine Aus- lagerung, wenn a) eine Task eine nutzergesteuerte Hauptpartition benoetigt und eine hoehere Prioritaet als die Task hat, die die Hauptparti- tion belegt. Wenn die Hauptpartition nicht belegt ist, muessen 20 alle in den Subpartitions befindlichen Tasks niedrigere Prio- ritaet als die Task aufweisen, die die Hauptpartition belegen will, damit eine Auslagerung erfolgen kann. Weiterhin muessen alle die Partition belegenden Tasks auslagerbar sein, und die Auslagerung muss erlaubt sein. Sind alle diese Bedingungen erfuellt, werden alle Tasks, die die Partition belegen, ausge- lagert, und die Task der hoeheren Prioritaet wird in die Hauptpartition zur Abarbeitung eingelesen. b) eine Task eine Subpartition benoetigt, und eine Task niedrige- rer Prioritaet die Hauptpartition oder die Subpartition belegt. Die die Haupt- bzw. Subpartition belegende Task muss auslagerbar sein, und die Auslagerung muss erlaubt sein. Sind diese Bedingungen erfuellt, wird die die Haupt- bzw. Subparti- tion belegende Task ausgelagert, und die Task der hoeheren Prioritaet wird in die Subpartition zur Abarbeitung eingele- sen. In einer systemgesteuerten Partition erfolgt eine Auslagerung, wenn nicht mehr genuegend freier zusammenhaengender Speicherbe- reich fuer eine Task hoeherer Prioritaet vorhanden ist. Wie bei den nutzergesteuerten Partitions muss jede Task, die ausgela- gert werden soll, auslagerbar sein, und die Auslagerung muss erlaubt sein. Wird durch Auslagern einer oder mehrerer Tasks niedriger Prioritaet genuegend freier zusammenhaengender Spei- cherbereich gefunden, wird die wartende Task geladen und abgearbeitet. Bleibt dieser Versuch erfolglos, ruft die Exekutive die Task SHF auf, um den zusammenhaengenden freien Speicher- bereich durch Verdichten der systemgesteuerten Partition zu gewinnen (siehe auch Anleitung fuer Systemprogrammierer, Teil 4). Im Betriebssytem OMOS 1630 wird auch die zeitgesteuerte Ausla- gerung unterstuetzt. Diese Art der Auslagerung bewirkt, dass Tasks gleicher Prioritaet in regelmaessigen Zeitintervallen zur Weiterarbeit in eine Partition geladen werden, in der sie nicht gleichzeitig residieren koennen. Damit wird eine annaehernd gleichmaessige Zuteilung an Hauptspeicherplatz erreicht. Die einzige Generierungoption der Exekutive, die dafuer erforderlich ist, ist die Unterstuetzung der Auslagerung. Die zeitge- steuerte Auslagerung belastet die Exekutive sowohl vom Speicherbedarf als auch vom Zeitaufwand wenig. Die Plattenbe- reichsanforderungen eines Systems mit zeitgesteuerter Auslage- rung koennen durch die Einbeziehung der dynamischen Zuteilung von Auslagerungsbereich wesentlich verringert werden. Eine Task hoeherer Prioritaet kann trotzdem jederzeit eine Aus- lagerung bewirken. 2.2.3.3. Dynamische Zuteilung von Auslagerungsbereichen ------------------------------------------------------- Die Speicherauslastung kann verbessert werden, wenn die meisten Tasks auslagerbar gestaltet werden. In diesen Faellen koennen die Platzanforderungen auf den Plattenspeichern stark verringert werden, wenn das System die dynamische Zuteilung eines Auslagerungsbereiches beinhaltet. Mit dieser System- leistung werden alle auszulagernden Tasks in allgemeine System- auslagerungsdateien uebertragen. Tasks koennen somit als aus- lagerbare Tasks installiert werden, ohne dass sie ueber einen 21 Auslagerungsbereich in der Taskabbild-Datei verfuegen. Systemaus- lagerungsdateien koennen auf jeder eingegliederten Platte mittels des MCR-Kommandos ACS erzeugt werden und auch wieder eliminiert werden. Zu beachten ist dabei, dass pro Datentraeger jeweils nur eine solche Datei erzeugt werden kann. Wenn die Exekutive Auslagerungsbereich benoetigt, benutzt sie die Platten in der Reihenfolge, in der die Auslagerungsdateien er- zeugt wurden. Trotzdem ist es sinnvoll, wenn lange arbeitende Tasks Speicherplatz in ihrer Taskabbilddatei freihalten. Da die Exekutive in den Auslagerungsdateien staendig Bereiche belegt und freigibt, kann es vorkommen, dass Fragmente freier Bereiche entstehen, die in diesem oder jenem Falle nicht gross genug sind, um eine auszulagernde Task aufzunehmen, obwohl die Ausla- gerungsdatei bzw. die Auslagerungsdateien in ihrer absoluten Groesse richtig dimensioniert waren. In diesem Falle kann der Auslagerungsbereich in der Taskabbilddatei genutzt werden, und die Weiterarbeit des Systems ist nicht gefaehrdet. Die Exekutive arbeitet i. a. so, dass sie alle auszulagernden Tasks in die Systemauslagerungsdateien auslagert. Erst wenn dort nicht genuegend Platz ist, erfolgt die Auslagerung in die Taskabbild-Datei. 2.2.3.4. Zeitscheibensteuerung ------------------------------ Die Zeitscheibensteuerung teilt geladenen Tasks eines angegebenen Prioritaetsbereichs der Reihe nach gleiche Zeitintervalle zu, in denen diese die Steuerung der ZVE besitzen. Damit werden die betroffenen Tasks gleichmaessig abgearbeitet. Tasks, die ausgelagert sind oder darauf warten, erstmals in die Partition eingelesen zu werden, sind davon nicht betroffen. Die Tasks dieses Prioritaetsbereichs werden in die uebrigen prioritaets- und zeitgesteuerten Aktivitaeten als Gruppe eingeordnet, d.h. sie bilden eine untergeordnete Warteschlange fuer einen bestimmten Prioritaetsbereich. 2.2.4. Mehrnutzerunterstuetzung ------------------------------------ OMEX 1630 kann mehrere Bediengeraete unterstuetzen. Systeme, die diese Moeglichkeit nutzen, werden Mehrnutzersysteme genannt. Die Anzahl der Nutzer, die gleichzeitig mit einem System arbeiten koennen, ist im wesentlichen von der Anzahl der Plattenspeicher und der Hauptspeichergroesse abhaengig. Bei der Systemgenerierung muss mehr als ein Bediengeraet gene- riert werden. Die Unterstuetzung fuer systemgesteuerte Partitions muss waeh- rend der Generierung in den Exekutive-Kern einbezogen werden. In einer systemgesteuerten Partition teilt die Exekutive den Nutzertasks Speicherplatz nach Bedarf zu. Alle Tasks koennen unabhaengig von der Bediengeraetezuordnung in der gleichen Par- tition installiert werden. Diese Arbeitsweise ist flexibel, da staendig nur der von den einzelnen Tasks gerade benoetigte Speicherplatz belegt wird. Die Standardsysteme entsprechen generell diesen Bedingungen. 22 2.2.4.1. Sicherung der Zugriffsrechte ------------------------------------- Jeder Nutzer muss sich im Mehrnutzersystem anmelden. Dazu dient das MCR-Kommando HELLO. Der Nutzer gibt seinen Nutzeridentifikationscode (UIC) und ein Kennwort ein. Die Exekutive ueberprueft anhand einer Verzeichnisdatei der Nutzer, ob der sich Anmeldende Zugriffsrechte hat. Die Anmeldung kann so gestaltet werden, dass der Nutzer z.B. einen Namen eingibt (er kann auch den UIC eingeben). Die Exekutive setzt den Terminal-UIC auf den vom Nutzer angegebenen Wert, weist ihm sein Systemgeraet zu und installiert seinen Kommandointerpreter (in der Regel MCR). Diese Datei der Nutzer wird vom Systemverwalter mit Hilfe des Programms ACNT (siehe Anleitung fuer Systemprogrammierer, Teil 4) aufgebaut und gewartet. Nichtprivilegierte Nutzer haben i.a. keinerlei Zugriff auf die gesamte Verzeichnisdatei. Wenn das Wartungsprogramm ACNT installiert ist, kann ein nichtprivilegierter Nutzer lediglich sein eigenes Kennwort aendern. 2.2.4.2. Datenschutz -------------------- Schutz vor nichtautorisierter Anmeldung gewaehrt das Nutzerverzeichnis. Wird der im BS OMOS 1630 gueltige Dateischutz vom Systemverwalter und von jedem Nutzer des Systems ueberlegt und richtig eingesetzt, koennen Uebergriffe auf Bereiche anderer Nuzer eingeschraenkt werden. Der Schutz der Dateien und Verzeichnisse wird mit Hilfe des Dienstprogramms PIP gesetzt (siehe Anleitung fuer den Bediener, Teile 2 und 4). Ein wirksamer Datenschutz kann nur erreicht werden durch Kombination von Dateischutzparametern fuer Verzeichnisse und Dateien. Da die Anfoerderungen in jedem Arbeitssytem verschieden sind, kann dafuer kein allgemeingueltiges Rezept erteilt werden. Wichtig ist, dass das Verzeichnis autorisierter Nutzer nur dem Systemverwalter zur Verfuegung steht. Das kann erreicht werden, indem der Dateischutz fuer alle Kopien desselben auf [RWED,RWED,,,] gesetzt wird, d.h. dass alle Operationen nur fuer System und Eigentuemer erlaubt sind. 2.2.4.3. Privilegstatus der Bediengeraete ----------------------------------------- Ein weiteres Hilfsmittel zur Datensicherung ist der Privilegstatus der Bediengeraete. Er wird den einzelnen Bediengeraeten mit Hilfe des MCR-Kommandos SET /PRIV bzw./NOPRIV zugeteilt. Infolge dieser Einteilung ist der Nutzer, der ein nichtprivilegiertes Terminal hat, in der Nutzung der MCR- Kommandos eingeschraenkt, d.h. er kann in den meisten Faellen nur seine eigenen Dateien und Verzeichnisse bearbeiten. Ausserdem uebernimmt das Terminal den UIC des Nutzes und gestattet eine Veraenderung nur in den durch den vorgegebenen Privilegstatus festgelegten Grenzen. 2.3. Planung des Arbeitssytems ------------------------------ 23 2.3.1. Nutzerverzeichnis ------------------------ Das Nutzerverzeichnis wird vom Systemverwalter gebildet und gewartet. Ohne bestehendes Nutzerverzeichnis kann sich niemand im Mehrnutzersystem anmelden. Eine Anleitung dazu findet sich in der Anleitung fuer Systemprogrammierer, Teil 4. Es gibt einige im BS OMOS 1630 bevorzugte UICs, die nicht an allgemeine Nutzer vergeben werden sollten (System-UICs). Im uebrigen setzt das System den Nutzern nur die Grenzen, die diese sich selbst mit Hilfe des Dateischutzes geben. Bei der Planung der Nutzergruppen gibt es die Moeglichkeiten, gleiche Gruppennummern des UIC zu vergeben oder fuer denselben UIC verrschiedene Kennworte zuzulassen. Im ersten Falle kann man die Zugriffsrechte der verschiedenen Gruppenmitglieder noch differenzieren. 2.3.2 Partitionfestlegung ------------------------- Der zur Verfuegung stehende, nicht vom Exekutive-Kern belegte Speicherbereich kann in eine beliebige Anzahl von Partitions aufgeteilt werden. Die Moeglichkeiten der Partitionfestlegung sind abhaengig vom vorhandenen Hauptspeicherplatz. Die folgenden Betrachtungen setzen immer voraus, dass mit dem Arbeitssystem auch Programmentwicklungsarbeiten, wie Assemblieren und Taskaufbau, ausgefuehrt werden sollen. Die bei der Generierung fuer den Aufbau der einzelnen Tasks be- nutzten Standardwerte fuer die Partitionfestlegung entsprechen dem im Bild 1 gezeigten Standardsystem. OMOS 1630 ist ein System mit Adresszuweisung, in dem alle Tasks mit der virtuellen Adresse Null aufgebaut werden. Tasks muessen deshalb nicht neu aufgebaut werden, wenn sie an einer anderen physischen Basisadresse (Partition) angeordnet werden sollen. Dienstprogramme muessen nur dann neu gebildet werden, wenn die Unterstuetzung fuer das FM16-M-Dateiformat (ANSI- Unterstuetzung) eingebunden oder Taskattribute, z. B. die Auslagerbarkeit, geaendert werden sollen. Die Partitions koennen vom Nutzer selbst festgelegt werden (siehe Anleitung fuer Systemprogrammierer, Teil 2). Die Standardsysteme enthalten etwa folgende Partitionaufteilung: 24 1000000 --------------------------- 128 K Worte | IOPAGE | | (wahlweise) | 760000 --------------------------- 124 K Worte | | | | | GEN | | | | | |-------------------------| | COMPAR | | (wahlweise) | |-------------------------| | SYSPAR | |-------------------------| | FCPPAR | | (wahlweise) | |-------------------------| | DRVPAR | | (wahlweise) | |-------------------------| | TTPAR | |-------------------------| | LDRPAR | |-------------------------| | | | Exekutive-Kern | | | 0 --------------------------- 0 K Worte Bild 1: Speicheraufteilung (Standardsystem) Auf die Angabe von Adressen wurde verzichtet, da das Bild nur als Uebersicht dient. LDRPAR ist die Partition fuer den Tasklader, der dort fixiert ist. Der Vollduplex-Terminaldriver besitzt eine eigene Partition TTPAR (ca. 8 K Worte). Eine systemgesteuerte Driverpartition DRVPAR kann wahlweise ein- gerichtet werden. Ihre Groesse richtet sich nach der Groesse aller Driver, die in ihr residieren sollen. SYSPAR ist fuer die Tasks MCR... (Kommandodispatcher), TKTN (Fehlerausschriften bei Taskabbruch und Geraetefehlern), VLFN (Fehlerausschrift bei Luefterausfall) und SHF (Verdichtungspro- gramm) vorgesehen und ist eine nutzergesteuerte Partition. Alle uebrigen Systemtasks, Driver (wenn keine Driverpartition existiert) und alle Nutzertasks arbeiten in der Partition GEN. 2.3.3. Anforderungen von Systemkomponenten an die Partitionfest- legung ----------------------------------------------------------------- Bei der Partitionplanung sollten folgenden Gesichtspunkte beach- tet werden: 25 1) Die Dateiverwaltungsroutine FCP ist in 4 Versionen verfuegbar; die Version FCPMDL.TSK mit ca. 5 K worten wird ins Standardsystem eingebunden, da sie einen guten Kompromiss zwischen schneller Dateiverarbeitung und guenstigem Speicher- platzbedarf darstellt. Die Standardvariante unterstuetzt die Verarbeitung von Verzeichnissen und der Bitmap im Hauptspei- cher, erlaubt bis zu 20 gleichzeitig eroeffnete Dateien und Verzeichnisse, minimiert die Belastung des System-Pools. FCP sollte nicht in nutzergesteuerten Partitions gemeinsam mit Tasks arbeiten, die Datei-E/A-Operationen ausfuehren. FCP kann auch in einer eigenen Partition installiert werden, denn der Systemdurchsatz ist sehr stark von guenstigen Arbeitsbedingungen des Dateisystems abhaengig. 2) Das Verarbeitungsprogramm fuer Indirektkommando-Dateien (AT.) sowie die Dienstprogramm-Tasks CRF, EDI, LBR, MAC, PIP, TKB und VFY ermitteln die Groesse der Partition, in der sie arbei- ten, und nutzen den zusaetzlichen Platz zur Speicherung von Symboltabellen bzw. als Puffer. Es ist demzufolge vorteilhaft, diese Tasks in Partitions zu installieren, die groesser als 8 K Worte sind. Da MAC, TKB und EDI aehnlich verfahren, ist es vorteilhaft, diese ebenfalls in Partitions zu installieren, die groesser als 14 K Worte sind. Standardmaessig benutzen sie die Partition GEN. Wenn diese Tasks in einer systemgesteuerten Partition instal- liert werden, kann der Speicherplatz, der ihnen zugeteilt wird, durch die /INC- Kennzeichnung beim INSTALL-Kommando eingestellt werden. 3) Da genuegend Hauptspeicherplatz zur Verfuegung steht, kann ein Mehrnutzersystem generiert werden, um z.B. bei Programmenent- wicklungsarbeiten mehrere gleichartige oder unterschiedliche Arbeitsgaenge gleichzeitig durchfuehren zu koennen. Ein Mehr- nutzersystem hat mehrere Bediengeraete, die simultan zur Programmentwicklung oder zur Abarbeitung von Nutzertasks benutzt werden koennen. Beim Aufbau eines Mehrnutzersystems kann die Mehrnutzerversion des MCR benutzt werden. In diesem Falle ist das MCR funktio- nell in mehrere Teile - MCR selbst und verschiedene privilegierte Tasks - geteilt. Im Mehrnutzersystem wird nur noch jeweils eine Kopie eines Systemprogramms benoetigt, um simultane Anforderungen zu bearbeiten. 4) Es gibt eine weitere Anzahl von Tasks, die die Wirksamkeit des Systems betraechtlich erhoehen. Die Tasks HEL, BYE und ACNT werden in Systemen benoetigt, in denen die Mehrnutzerunter- stuetzung generiert ist. Die Tasks BRO und SHUTUP benoetigen keine weitere Mehrnutzerunterstuetzung. BRO sendet Mitteilun- gen an alle bzw. ausgewaehlte Bediengeraete. SHUTUP beendet planmaessig die Arbeit des gesamten Systems. 2.4. Anpassungsarbeiten ----------------------- Die in den vorigen Abschnitten angedeuteten Ueberlegungen dienten dazu, die weitere Anpassung des Arbeitssystems vorzubereiten. Es gibt, da das gelieferte System sofort nach dem Zurueckspeichern auf Magnetplatte geladen werden kann, verschiedene Moeglichkeiten zur Manipulation (wie im Prinzip shon vom BS MOOS 1600 bekannt): 26 - Das Systemprogramm VMR (Virtual Console Monitor Routine) kann benutzt werden, um permanente Aenderungen im Systemabbild vorzunehmen und um gewisse Charakteristika zu veraendern. - Das Kommandoprogramm des Systems MCR (Monitor Console Routine) kann benutzt werden, um temporaere Aenderungen am geladenen System vorzunehmen. Diese koennen in einem gesonderten Arbeitsschritt permanent gemacht werden. - Bestimmte Arbeitsschritte koennen jeweils beim Laden des Systems von der Platte durch Aufruf der Indirekt-Kommandodatei STARTUP.CMDangewiesen werden. Gegenueber dem BS MOOS 1600 koennen im BS OMOS 1630 mehr System- und Peripherieparameter geaendert werden. 2.4.1. Aendern von Systemparametern ----------------------------------- Die Veraenderung von Systemparametern geschieht vorwiegend mit Hilfe des VMR- bzw. MCR-Kommandos SET. Damit koennen folgende Parameter beeinflusst werden: System-UIC, Partitions, Poolgroesse und -bedingungen, Erweiterungsbereich fuer Tasks, Intervall des Steuerungswechsels und Prioritaetsbereich fuer Zeitscheibensteuerung und fuer zeitbezogene Aktivierung von Tasks. Die genaue Beschreibung der Parameter ist in der Anleitung fuer Bediener, Teil 2: "Steuerprogrammsystem" beim Kommando SET bzw. fuer VMR in der Anlage der Schrift zu finden. 2.4.2. Aendern von Peripherieparametern --------------------------------------- Auch hierzu kann das Kommando SET (VMR oder MCR) benutzt werden. Damit werden vorwiegend Parameter der Bediengeraete gesetzt (abhaengig vom jeweiligen Driver), aber auch solche Statusin- formationen bestimmt wie Privilegstatus bzw. oeffentlicher oder nichtoeffentlicher Status von Geraeten. Weitere Aenderungen (im Sinne einer E/A-Generierung) sind im Abschnitt 2.1.2. schon angedeutet und werden in der Anleitung fuer Systemprogrammierer, Teil 2, ausfuehrlich behandelt. 2.4.3. Veraendern von Standardparametern bei Dienstprogrammen ------------------------------------------------------------- Die Kommandodatei SYSGEN3.CMD ruft weitere Kommandodateien fuer das Taskbilden fuer alle Dienstprogramme auf. Diese koennen vor oder waehrend der Abarbeitung von SYSGEN3 editiert werden, wenn Aenderungen erforderlich sein sollten. Da die Parameter bei jedem Programm anders lauten, kann keine einheitliche Empfehlung gegeben werden. Die Kommandodateien sind jedoch ausreichend mit Kommentaren versehen, so dass sich der Anwender schnell zurechtfindet. Eine weitere Hilfe ist, wie in anderen Faellen auch, die Anleitung fuer Systemprogrammierer, Teil 2. 27 3. Hinweise zur Software-Dokumentation -------------------------------------- 3.1. Gliederung der Anleitung fuer Systemprogrammierer ------------------------------------------------------ Die Anleitung fuer Systemprogrammierer besteht aus vier Teilen, die wichtige Details fuer die Herstellung eines angepassten Arbeitssystems und Informationen ueber Arbeitsmittel und -methoden des Systemprogrammierers enthalten. Teil 1: Methodische Hinweise zum BS OMOS 1630 Teil 2: Inbetriebnahme und Wartung des BS OMOS 1630 Teil 3: Anleitung zur Entwicklung nutzereigener Driver Teil 4: Systemserviceprogramme Da die Generierung beim Entwickler stattfindet, wie schon im Kap. 2 der vorliegenden Dokumentation beschrieben, gibt es keine Generierungsanleitung. Der Teil 2 der Anleitung fuer den Systemprogrammierer beschreibt die zur Inbetriebnahme und Wartung eines gelieferten Betriebssystems notwendigen Arbeiten des Systemprogrammierers im einzelnen. 3.2. Leserkreis --------------- Neben den Systemprogrammierern, fuer die diese Anleitung vornehmlich bestimmt ist, sollten sich auch alle diejenigen, die im Prozess der Einsatzvorbereitung von Rechnern des MGS 1600 eingesetzt sind, mit dieser einfuehrenden Schrift befassen. Die uebrigen Teile der Anleitung fuer Systemprogrammierer beschreiben die Taetigkeit des Systemprogrammierers so speziell, dass sie als Hilfsmittel im jeweiligen Arbeitsstadium unerlaesslich sind. Die Beschreibung der Systemserviceprogramme im Teil 4 dieser Anleitung, die vorwiegend von privilegierten Nutzern des BS OMOS 1630 (Systemverwalter) benoetigt wird, kann auch allen Bedienern des MGS 1600 unter dem BS OMOS 1630 empfohlen werden. 3.3. Weitere Dokumentationen ---------------------------- Zur Dokumentation des Betriebssystems OMOS 1630 gehoeren weiterhin Anleitungen fuer Programmierer und Bediener, die auf die Aufgaben dieser speziellen Nutzergruppen zugeschnitten sind. Der Systemprogrammierer wird bei seiner Arbeit auf alle diese Dokumentationen zurueckgreifen muessen, weshalb die Gliederungen dieser Schriften hier nochmals angegeben werden. Anleitung fuer Programmierer Teil 1: Vorbemerkungen Teil 2: Exekutive OMEX 1630 (Exekutivemakros) Teil 3: E/A-System Teil 4: Dateiformate im BS OMOS 1630 Teil 5: Dateizugriffsroutinen FCS 1630 Teil 6: Systembibliotheksroutinen 28 Anleitung fuer Bediener Teil 1: Allgemeine Hinweise Teil 2: Steuerprogrammsystem (Exekutive) OMEX 1630 (Kommandoprogramm MCR, AT-Prozessor) Teil 3: Wartungsunterstuetzung Teil 4: Dienstprogramme Teil 5: Makroassembler MAC 1600 Teil 6: Kommandosprache DCL Aus den Bezeichnungen geht der Verwendungszweck der Dokumentationen hervor. Zusaetzlich wird der Systemprogrammierer die Sprachbeschreibung der im BS OMOS 1630 hauptsaechlich verwendeten Programmiersprache MACRO 1600 benoetigen. Andere Sprachen werden als Programmiersysteme mit kompletter Dokumentation gesondert angeboten. Sie sind nicht Bestandteil des Betriebssystems OMOS 1630. Es sei besonders auf die Programmiersysteme fuer die Sprachen FORTRAN IV und FORTRAN 77 sowie COBOL 1600 verwiesen, die dieselbe Anwendungsumgebung wie z.B. unter dem BS MOOS 1600 realisieren. 29 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 AST Asynchroner Systemtrap BAD (Bad Block Locator Utility) Plattenpruefprogramm BDE Bedieneinheit BRU (Backup and Restore Utility) Datensicherungsprogramm BS Betriebssystem CDA Abbruchanalyseprogramm CLI (Command Line Interpreter) Programm zur Bearbeitung von Kommandos CMP (File Compare Utility) Dateivergleichsprogramm DEP (Debugging Program) Testprogramm DMP (Dump Utility) Dateidruckprogram DSC (Disk Save and Compress) Dateirettungs- und Ver- dichtungsprogramm DSW (Directive Status Word) Anweisungsstatuswort E/A Ein- und Ausgabe EDI Editoren EDT EOF (End of File) Dateiendekennsatz EOV (End of Volume) Datentraegerendekennsatz ERL (Error Logging) Fehlerregistrierung FCB (File Control Block) Dateisteuerblock FCS (File Control Services) Dateizugriffsroutinen FD16 Datensicherungsformat FE16 Global genormte Dateiformate (Dateiformat "established") FEX (File Exchange Utility) Dateiaustauschprogramm FL16 Dateiformat LAOS 1630 FLX (File Transfer Utility) Dateiumwandlungsprogramm FMT (Format Utility) Formatierungsprogramm fuer Magnetplatten FM16 Dateiformat MOOS 1600 und OMOS 1630 FPEM (Floating-point Emulator) Gleitkommaemulator FPS Festplattenspeicher FQ16 Lokal genormte Dateiformate (Datenformat "queered") FSE Folienspeichereinheit HDR (Header Label) Dateianfangskennsatz ICB (Interrupt Control Block) Interruptsteuerblock IOX (I/O Exerciser) Allgemeines Geraetestprogramm 30 KBR Kommerzielles Basisrechner- system KMBE Kassettenmagnetbandeinheit KROS Kombinat Robotron Standard KPS Kassettenplattenspeicher 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 Geraete- nummern LP (Line Printer) Zeilendrucker MAC Makro-Assembler MBG Magnetbandgeraet MCR Kommandoprogramm MFD (Master File Directory) Hauptdateiverzeichnis MGS Mikrorechnergeraetesystem MOEX Exekutive des MOOS MOOS 1600 Modulares Operationssystem NP Nutzerprogramm ODT (On Line Debugging Tool) Testprogramm OMEX Exekutive des OMOS OMOS 1630 Optimiertes Modulares Betriebssystem PAR (Page Address Register) Seitenadressregister PAT (Objekt 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 PS Prozessorstatuswort RAM (Random Access Memory) Speicher mit wahlfreiem Zu- griff SD Seriendrucker SHF (Shuffler) Speicherverdichtungsprogramm SLP (Source Line Processor) Quelltext-Korrekturprogramm SKR System der Kleinrechner SRD (Sort Directory Program) Sortierprogramm fuer Verzeichnisdateien SST Synchroner Systemtrap STD (System Task Directory) Systemtaskverzeichnis SVE Speichervermittlungseinheit TCB (Task Control Block) Tasksteuerblock TKB Taskbilder 31 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) Benutzereigene Dateikennsaetze UTL (User Trailer Label) UVL (User Volume Label) VBN (Virtual Block Number) Virtuelle Blocknummer VCB (Volume Control Block) Datentraegersteuerblock VFY (File Structure Verification Dateipruefprogramm Utility) VMR (Virtual Monitor Console Virtuelles Kommandoprogramm Routine) VOL (Volume Label) Datentraegerkennsatz XDT (Executive Debugging Tool) Exekutivetesthilfe ZAP Dateikorrekturprogramm ZVE Zentrale Verarbeitungseinheit 32 Sachwortverzeichnis ------------------- Seite Abbruch einer Task 21 Aktivieren einer Task 22 Auslagerung 11,19 Auslagerung, zeitgesteuert 18 Auslagerungsbereich 17,19 Auslagerungsbereich, dynamisch 17 Bibliothek, resident 15 COMMON-Bloecke 15 COMMON-Partition 15 E/A-Beendigung 21 E/A-Exekutive-Anweisung 22 E/A-Pakete, reservierte 20 Fortsetzen einer Task 21 Mehrnutzerschutz 21 Mehrnutzersystem 16 Partition 7,10 Partition, feste 18 Partition, nutzergesteuert 10 Partition, systemgesteuert 10,12,18 Partitionfestlegung 7 Prioritaet 22 Task 10,11,16 Task, abhaengig 22 Task, auslagerbar 17 Task, nicht auslagerbar 18 Tasklaenge 20 Zeitscheibensteuerung 19 33