OS 2200 - OS 2200

OS 2200

Entwickler	Unisys
OS-Familie	OS 2200
Arbeitszustand	Aktuell
Quellmodell	Geschlossene Quelle . Die meisten Quellen stehen Kunden unter Lizenz zur Verfügung.
Erstveröffentlichung	1967 ; Vor 53 Jahren als Exec 8 ( 1967 )
Neueste Erscheinung	18.0 / 18. Juli 2018 ; vor 2 Jahren ( 2018-07-18 )
Marketingziel	Enterprise / Mainframes
Aktualisierungsmethode	Exec und einige andere Komponenten: Änderungen auf der Basis von Zeilennummern. Die meisten Komponenten: Zwischenkorrekturen (ICs)
Paket-Manager	PRIMUS (intern), COMUS und SOLAR (Client und intern)
Plattformen	UNIVAC 1100/2200 Serie und Unisys ClearPath Dorado Systeme
Kernel - Typ	Monolithischer Kernel (einzigartig hardwareunterstützt)
Standard - Benutzeroberfläche	Befehlszeilenschnittstelle
Lizenz	Proprietär . Laufzeitlizenz oder kostenpflichtige (gemessene) Lizenzen
Offizielle Website	OS 2200-Site

OS 2200 ist das Betriebssystem für die Unisys ClearPath Dorado-Familie von Mainframe-Systemen. Der Betriebssystemkern von OS 2200 ist ein direkter Nachkomme von Exec 8 für UNIVAC 1108. Dokumentation und andere Informationen zu aktuellen und früheren Unisys-Systemen finden Sie auf der öffentlichen Support-Website von Unisys.

Siehe Unisys 2200 Series - Systemarchitektur für eine Beschreibung der Maschinenarchitektur und ihre Beziehung zu dem OS - 2200 - Betriebssystem.

Geschichte

Es gab frühere 1100-Systeme, die 1951 auf den 1101 zurückgingen , aber der 1108 war der erste Computer der 1100-Serie, der für die effiziente Unterstützung von Multiprogramming und Multiprocessing entwickelt wurde. Zusammen mit dieser neuen Hardware kam das Betriebssystem Exec 8 (Executive System für den 1108).

Der UNIVAC 1108- Computer wurde 1964 angekündigt und Ende 1965 ausgeliefert. Die ersten 1108-Computer verwendeten Exec I und Exec II , die für den UNIVAC 1107 entwickelt wurden . Allerdings UNIVAC geplant bieten symmetrische Multi Versionen der 1108 mit bis zu 4 Prozessoren und den älteren Betriebssystemen (wirklich grundlegende Überwachungsprogramme) wurden nicht für die, dass, obwohl sie Mehrprogramm unterstützten begrenzt.

Als der UNIVAC 1110 1972 eingeführt wurde, wurde der Name des Betriebssystems in OS 1100 geändert, um die Unterstützung für die breitere Palette von Systemen widerzuspiegeln. Der Name OS 1100 wurde bis 1988 mit der Einführung der Sperry 2200-Serie als Nachfolger der 1100-Serie beibehalten, als der Name in OS 2200 geändert wurde. Seitdem wurde die 2200-Serie zur Unisys ClearPath IX-Serie und dann zur Unisys ClearPath Dorado-Serie, aber das Betriebssystem behielt den Namen OS 2200 bei.

Der Firmenname und seine Produktnamen haben sich im Laufe der Zeit ebenfalls geändert. Engineering Research Associates (ERA) von Saint Paul wurde von der Remington Rand Corporation übernommen . Remington Rand erwarb auch die Eckert-Mauchly Computer Corporation in Philadelphia, die damals den UNIVAC- Computer baute. Die beiden wurden unter der Leitung von William Norris in der UNIVAC-Abteilung von Remington Rand zusammengefasst. William Norris war einer der Gründer von ERA und verließ später Remington Rand, um die Control Data Corporation zu gründen . Die UNIVAC-Abteilung der Remington Rand Corporation wurde zur UNIVAC-Abteilung der Sperry Rand Corporation, nachdem Remington Rand mit der Sperry Corporation fusioniert war . In den 1970er Jahren startete Sperry Rand ein Corporate-Identity-Programm, das seinen Namen in Sperry Corporation und alle Abteilungsnamen änderte, um mit Sperry zu beginnen. Aus der Abteilung für Computersysteme wurde Sperry UNIVAC. Später wurden die Divisionsnamen gelöscht und alles wurde einfach zu Sperry.

Der Betriebssystemkern wird von den meisten Unisys- und Kundenmitarbeitern immer noch als "Exec" bezeichnet. Als Unisys jedoch mit der Veröffentlichung von Produktreihen begann, die zusammen als Systembasisversionen getestet wurden und später als "ClearPath OS 2200 Release n " bezeichnet wurden, wurde der Begriff OS 2200 geändert, um sich auf die gesamte Produktsuite in der Systemversion und andere, wie z. B. BIS , zu beziehen. asynchron für die Dorado-Hardwareplattformen veröffentlicht.

1986 fusionierten die Unternehmen Burroughs und Sperry zu Unisys (was laut langjährigen Kunden der 2200 Series für "UNIVAC ist immer noch Ihr Lieferant" steht). Die wichtigsten Mainframe-Produktlinien beider Unternehmen wurden weiterentwickelt, darunter das MCP-Betriebssystem von Burroughs und das OS 2200 von Sperry.

2016 stellte Unisys eine virtuelle Microsoft Windows- Version von OS2200 kostenlos für Bildungs- und Freizeitzwecke zur Verfügung.

Exec 8

EXEC 8 (manchmal auch als EXEC VIII bezeichnet) war das 1964 für UNIVAC 1108 entwickelte Betriebssystem von UNIVAC. Es kombinierte die besten Funktionen der früheren Betriebssysteme EXEC I und EXEC II , die auf UNIVAC 1107 verwendet wurden . EXEC 8 war eines der ersten kommerziell erfolgreichen Multiprocessing- Betriebssysteme. Es wurden simultane gemischte Workloads unterstützt, die Batch , Time-Sharing und Echtzeit umfassen . Das eine Dateisystem hatte eine flache Namensstruktur über viele Trommeln und Spindeln hinweg. Es wurde auch ein gut aufgenommenes Transaktionsverarbeitungssystem unterstützt .

Frühere Systeme waren alle Real-Mode-Systeme ohne Hardware-Unterstützung zum Schutz und zur Trennung von Programmen und Betriebssystem. Während es für gewesen Unterstützung hatte Mehrprogramm in früheren Systemen wurde es mit mehreren unterstützenden Funktionen bekannt sein , gut erzogene, wie der Kartenleser, Drucker und Kartenstanzer zum Laufen eines Benutzerauftrages gleichzeitig begrenzt Spooler .

Das Exec 8-Betriebssystem wurde von Anfang an als Multiprogramming- und Multiprocessing-Betriebssystem konzipiert, da das 1108 für bis zu vier CPUs ausgelegt war. Speicher und Massenspeicher waren die primären Systembeschränkungen. Während die 1100-Serie auf einen allgemeineren Markt ausgerichtet war, war eine extreme Echtzeitverarbeitung eine Hauptanforderung.

Die Spezifikationen für Exec 8 wurden bis Dezember 1964 als vorläufiges Programmierreferenzhandbuch (Benutzerhandbuch) erstellt, und die Arbeiten begannen im Mai 1965.

Exec 8 begann als Echtzeit- Betriebssystem mit frühem Einsatz, hauptsächlich in allgemeinen wissenschaftlichen und technischen Arbeiten, wurde aber auch in der Nachrichtenumschaltung, Prozesssteuerung, Simulation und Raketenabschusssteuerung verwendet. Es wurde für die Ausführung auf Systemen entwickelt, die häufig nur 128 KB Wörter (576 KB - weniger als die maximale Speichergröße für den IBM PC XT ) enthielten , und konzentrierte sich auf Echtzeit- und Stapelverarbeitung. Während die frühesten Release-Levels in 128 kW funktionierten, machte die Erhöhung der Funktionalität in späteren Releases dies unhaltbar, da nicht genügend Platz für Programme von nützlicher Größe vorhanden war. Die maximale Speicherkapazität eines 1108 betrug 256 kW (1.148 KB), sodass die effiziente Nutzung des Speichers die wichtigste Einschränkung war, da der Kernspeicher der teuerste Teil des Systems war.

Der Massenspeicher bestand aus 6 Fuß langen rotierenden Trommeln, die 256 kW (in der FH-432) bis 2 MW (in der FH-1782) hielten. Der Massenspeicher mit der höchsten Kapazität war die FASTRAND- Trommel mit 22 MW (99 MB). Die Dateifragmentierung wurde durch einen Prozess namens "Dateispeicherung" behoben, der im Allgemeinen einmal pro Tag in der Nacht durchgeführt wurde. Dabei wurden alle Dateien auf Band gerollt, das Drum-Dateisystem neu initialisiert und die Dateien wieder eingelesen.

Bei schwerwiegenden Speicherbeschränkungen und Echtzeitnutzung war es erforderlich, nur eine einzige Kopie des in den Kern geladenen Codes zu behalten. Da der 1108 für Multitasking ausgelegt war, war das System vollständig "wiedereintrittsfähig" ( threadsicher ). Jedes wiedereintretende Modul hat über eine einzelne Speicher- "Basisadresse" auf Programmdaten zugegriffen, die für jede Instanz von Laufdaten unterschiedlich war. Das Umschalten von Ausführungskontexten könnte in einem einzelnen Befehl erfolgen, indem lediglich eine andere Basisadresse in einem einzelnen Register festgelegt wird. Das System verwendete feinkörnige Sperren, um gemeinsam genutzte Datenstrukturen zu schützen. Die Exekutive, Compiler, Dienstprogramme und sogar hochentwickelte Benutzeranwendungen, bei denen möglicherweise mehrere Kopien gleichzeitig ausgeführt werden, wurden so geschrieben, dass ihr Code gemeinsam genutzt werden kann. Dies erforderte das Laden nur einer Kopie in den Speicher, wodurch sowohl Speicherplatz als auch Zeit für das Laden des Codes gespart wurden.

Ein weiterer Grund für die Trennung von Code und Daten in verschiedene Ladeeinheiten war, dass der Speicher als zwei unabhängige Bänke (separate physische Schränke) implementiert wurde, die als IBANK und DBANK (Befehl und Daten) bezeichnet werden. Jeder hatte seinen eigenen Zugriffspfad, sodass die CPU beide Bänke gleichzeitig lesen konnte. Durch Laden von ausführbarem Code in eine Speicherbank und von Daten in die andere konnte die Laufzeit vieler Programme fast halbiert werden.

Wiedereintrittscode musste threadsicher sein (nur ausführen); Selbstmodifizierender Code war nicht erlaubt. Bei anderen Programmen war das Ändern von ausführbarem Code zur Laufzeit in der Zeit von Computern der Serie 1100 noch eine akzeptable Programmiertechnik. Die Benutzer wurden jedoch aufgefordert, dies aufgrund der Leistungseinbußen nicht zu tun. Sicherheitsvorteile wurden angepriesen, aber nicht hoch geschätzt, da das Hacken der meisten Anwendungen der Serie 1100 niemandem Vorteile bringen würde und weil damals nur wenige Hacker böswillig waren.

Exec 8 war in erster Linie ein Stapelverarbeitungssystem , mit dem Anwendungen (als "Aufgaben" bezeichnet) die CPU-Planungspriorität für ihre Threads (als "Aktivitäten" bezeichnet) sehr genau steuern konnten. Das Umschalten des Prozessors war präventiv, wobei Threads mit höherer Priorität die Kontrolle über den Prozessor erlangten, auf dem derzeit der Thread mit der niedrigsten Priorität eines Programms ausgeführt wird. Außer in Echtzeitsystemen haben selbst die Aufgaben mit der niedrigsten Priorität einige Prozessorzeit. Es war ein Multiprogramming- und Multiprocessing-Betriebssystem mit vollständig symmetrischer Prozessorverwaltung. Ein in die Hardware integrierter Test-and-Set-Befehl ermöglichte ein sehr effizientes und feinkörniges Sperren sowohl innerhalb des Betriebssystems als auch in Multithread-Anwendungen.

In Exec 8 ist die Arbeit in Jobs organisiert, die als "Läufe" bezeichnet werden und nach ihrer Priorität und dem Bedarf an abschließbaren Ressourcen wie Uniservo-Bandlaufwerken oder Fastrand-Drum-Dateien geplant werden. Die Syntax der Steuerungssprache verwendet das Symbol "@" (das Univac als "Master Space" bezeichnet) als Erkennungssymbol für Steueranweisungen. Es folgten sofort der Befehls- oder Programmname, dann ein Komma und alle Optionsschalter. Nach einem Leerzeichen unterschied sich der Rest der Anweisung für bestimmte Befehle. Ein Befehl zum Kompilieren eines FORTRAN-Programms würde wie folgt aussehen: "@FOR [, Optionen] Quelldatei, Objektdatei". Eingabedaten für eine Anwendung können aus einer Datei gelesen werden (im Allgemeinen Kartenbilder) oder sofort dem Befehl @ im Ausführungsstrom folgen. Alle Zeilen bis zum Sentinel-Befehl "@END" wurden als Eingabedaten angenommen. Wenn Sie also vergessen, sie einzufügen, interpretierte der Compiler nachfolgende Befehle als Programmdaten. Aus diesem Grund war es vorzuziehen, Daten in Dateien zu verarbeiten, anstatt sie in den Ausführungsstrom einzugeben.

Im Jahr 1968 begannen die Arbeiten zum Hinzufügen von Time-Sharing- Funktionen zu Exec 8. Sie wurden 1969 mit Level 23 der Führungskraft ausgeliefert. Time-Sharing (als Anforderungsmodus bezeichnet ) verfügte über dieselben Funktionen wie Batch- und Echtzeitprozesse. Alles, was im Batch erledigt werden konnte, konnte von einem ASCII-Terminal aus erledigt werden. Im Anforderungsmodus wurde die Jobstrom-E / A an einen Terminal-Handler angehängt und nicht an Kartenbild- (Eingabe) und Spooldateien (Ausgabe). Für beide wurde dieselbe Laufsteuerungssprache verwendet. Einige Jahre später wurden spezifischere Time-Sharing-Befehle hinzugefügt, und einige Steueranweisungen konnten zur sofortigen Verarbeitung asynchron ausgegeben werden, selbst wenn weder die Exekutive noch das laufende Programm Daten erwarteten. Diese Befehle, die nur von einem Terminal aus eingegeben werden konnten, begannen mit "@@". Da sie ausgeführt werden konnten, ohne andere laufende Arbeiten vom selben Terminal aus zu stoppen, wurden sie als transparente Befehle bezeichnet. Anfangs waren dies nur Anweisungen, um das aktuelle Programm zu beenden oder die Terminalausgabe in eine Datei umzuleiten, aber schließlich durften fast alle Steueranweisungen "sofort" sein.

Sowohl Stapel- als auch Bedarfsläufe werden mit einer @ FIN-Anweisung beendet. Wenn ein Bedarfsbenutzer seine Sitzung beendet, während sein Lauf aktiv ist, beendet der Exec den Lauf automatisch, ohne dass @FIN erforderlich ist.

Kommunikationssoftware

Eine Transaktionsverarbeitungsfunktion wurde Ende der 1960er Jahre als gemeinsames Projekt mit United Airlines entwickelt und später in einem weiteren gemeinsamen Projekt mit Air Canada verfeinert. Diese Fähigkeit wurde 1972 vollständig in das Betriebssystem integriert und wurde zur Grundlage für einen Großteil des zukünftigen Wachstums der 1100-Serie. Frühe Benutzer kontrollierten Kommunikationsleitungen direkt aus ihren Echtzeitprogrammen heraus. Ein Teil der Entwicklung der Transaktionsverarbeitung umfasste ein Kommunikationsnachrichtensystem, das die Kommunikationsleitungen verwaltete und Exec 8 Nachrichten präsentierte, die als Transaktionen geplant werden sollten. Dadurch wurden das gesamte Management und die Protokolle der physischen Kommunikation auf niedriger Ebene aus den Anwendungen in die CMS 1100-Anwendung verschoben.

CMS 1100 selbst wurde als Echtzeit-Multithread-Programm mit dem Privileg ausgeführt, die Kontrolle über Kommunikationsleitungen zu erlangen und Transaktionsnachrichten zur Planung zu senden. Dies führte in Exec 8 zu dem Gedanken, dass Anwendungen jeglicher Art sorgfältig kontrolliert werden müssen, um sicherzustellen, dass sie keine Integritätsprobleme verursachen können. Sicherheit war sicherlich ein Problem, aber in den frühen Tagen waren Systemzuverlässigkeit und -integrität viel größere Probleme. Das System bestand immer noch hauptsächlich aus Stapel- und Transaktionsverarbeitung, und es bestand kaum eine Chance, dass jemand nicht autorisierten Code auf dem System installieren konnte. CMS 1100 fügte später die Fähigkeit hinzu, die Schnittstelle für Bedarfsterminals sowie Transaktions-Terminals zu sein, so dass Terminals für beide verwendet werden konnten und die frühen Terminaltreiber aus dem Exec entfernt werden konnten. CMS 1100 wurde später durch eine Kombination aus CPComm (ClearPath Enterprise Servers Communications Platform) und SILAS (Systemschnittstelle für ältere Anwendungssysteme) ersetzt. Bei den Intel-basierten Dorado-Servermodellen wurde die Kommunikation auf der unteren Ebene auf Firmware verschoben, wobei die oberen Ebenen von SILAS und CPCommOS (ClearPath Enterprise Server-Kommunikationsplattform für offene Systeme) verwaltet wurden.

Die Exec

Der Exec enthält den gesamten Code im System, der mit den höchsten Berechtigungsstufen ausgeführt werden darf. Es gibt keine Mechanismen, mit denen anderer Code auf diese Berechtigungsstufen heraufgestuft werden kann.

Der Exec ist verantwortlich für die Verwaltung der Systemhardware, die Planung und Verwaltung der Arbeit sowie für die Kommunikation mit Bedienern und Administratoren.

In Release 16.0 ist der Exec Level 49R2 (49.70.5). Die internen Systemebenen verwenden eine dreiteilige Nummer wie 21.92.42 (dies war das erste weit verbreitete Produktionssystem, obwohl frühere Versionen in der Produktion an mehreren Standorten verwendet wurden). Der erste Nummernteil ist die Hauptebene und zeigt eine neue Version von Exec an, wobei alle vorherigen Updates in eine neue Basisversion integriert sind. Dies ist ein seltener Prozess und tritt in Abständen von Jahren auf. Der zweite Nummernteil zeigt Versionen von Updates auf der Hauptebene an und tritt häufig mehrmals pro Woche auf. Wenn entschieden wird, den Funktionsinhalt einzufrieren und die Veröffentlichung vorzubereiten, kommt der dritte Teil ins Spiel und zeigt Versionen der Vorabversion an, wenn Korrekturen und kleinere Funktionsaktualisierungen angewendet werden. Gleichzeitig mit der Vorbereitung eines Levels für die Veröffentlichung werden die Aktualisierungen der "Hauptlinie" fortgesetzt, während die Ingenieure Änderungen in die Vorbereitung für eine zukünftige Version integrieren. Für viele Jahre war das offizielle Release-Level die volle dreiteilige Nummer. Spätere Versionen wurden einfach 44R1, 44R2, 49R2 usw. genannt, obwohl die dreiteilige Nummer immer noch intern verwendet wird.

Arbeiten durchführen

Der Exec ist im Kern ein Echtzeit-Stapelverarbeitungssystem mit mehreren Threads. Alles wurde um dieses Modell herum gebaut. Der Exec selbst ist weitgehend als Echtzeitprogramm strukturiert. Funktionen, die unter Windows als Dienste oder unter Linux und UNIX als Daemons ausgeführt werden, werden entweder als Aktivitäten in Exec oder als Stapelverarbeitungsprogramme implementiert, die immer im Hintergrund ausgeführt werden.

Time-Sharing (als Anforderungsmodus bezeichnet ) und Transaktionsverarbeitung werden als Sonderfälle des Stapels implementiert. Ein Ergebnis ist, dass es nur wenige Einschränkungen gibt, was ein Time-Sharing-Benutzer oder ein Transaktionsprogramm tun kann. Es gibt viele Warnungen für Verfasser von Transaktionsprogrammen, dass sie mit der Leistung nicht zufrieden sind, wenn sie beispielsweise eine Bandmontage fordern, dies ist jedoch zulässig.

Die größte Arbeitseinheit ist der "Lauf". Dies ist der werkseitigen Terminologie "Produktionslauf" entnommen und entspricht im Allgemeinen einem Auftrag oder einer Sitzung auf anderen Systemen. Ein Lauf wird durch seinen "Laufstrom" definiert. Ein Run-Stream ist eine Folge von Steueranweisungen, die die auszuführenden Schritte darstellen. Sie können die Dateiverwaltung, die Programmausführung und Kontrollzweige umfassen. Ein Batch-Lauf wird normalerweise als Datei gespeichert und durch einen "Start" -Befehl in einem anderen Lauf oder vom Bediener geplant. Ein Time-Sharing-Lauf wird gestartet, indem Sie sich von einem Time-Sharing-Terminal aus anmelden und den Befehl @RUN eingeben. Oft werden die @ RUN-Anweisung und die zweite Steueranweisung (häufig @ADD oder eine Programmausführung) automatisch basierend auf dem Benutzerprofil generiert. Sicherheitsberechtigungen werden basierend auf der authentifizierten Benutzer-ID und anderen Informationen validiert, die in der Run-Steueranweisung angegeben sind.

Transaktionen sind ein Sonderfall. Es gibt eigentlich keine Steueranweisungen, aber die internen Datenstrukturen eines Laufs werden erstellt. Auf diese Weise kann der Exec Transaktionsprogrammen dieselben Sicherheits-, Buchhaltungs-, Debugging- usw. Mechanismen zuordnen. Im Allgemeinen wird ein Sicherheitsprofil zum Zeitpunkt der Authentifizierung des Transaktionsbenutzers im Speicher zwischengespeichert und beim Planen der Transaktion aus den Sitzungsdaten des Benutzers in den Transaktionslaufstatus kopiert. Da es sich bei jeder Transaktionsinstanz im Wesentlichen um eine Ausführung handelt, werden Abrechnung, Protokollierung und Fehlerbehandlung vom Ausführungsmechanismus gekapselt.

Stapel

Stapeljobs (Runs) sind dadurch gekennzeichnet, dass ein Runstream (Anweisungen zur Jobsteuerungssprache) in einer Datei gespeichert ist. Ein Stapeljob enthält immer eine @ RUN-Anweisung als ersten Datensatz in der Datei. Diese Anweisung gibt dem Lauf einen Namen (runid), definiert Prioritäten und definiert die maximale Anzahl von SUPS (Standard Units of Processing), die der Job voraussichtlich verwenden wird. Der Job wird von einem anderen Job mit einer @ START-Steueranweisung oder vom Bediener über eine ST-Eingabe gestartet. Das System kann so konfiguriert werden, dass beim Booten automatisch @ START-Anweisungen für eine beliebige Anzahl von Jobs ausgegeben werden. Diese Jobs dienen zum Ausführen von Initialisierungs-, Wiederherstellungs- und Hintergrundfunktionen.

Alle Felder in der @ RUN-Anweisung können durch entsprechende Felder in der @ START-Anweisung überschrieben werden. Außer wenn der @START von einem privilegierten Benutzer ausgeführt wird, werden die Benutzer-ID und der andere Sicherheitsstatus immer aus dem Lauf genommen, der den @START ausführt.

Die @ RUN-Anweisung enthält zwei Prioritätsfelder. Eine wird verwendet, um die Backlog-Priorität anzugeben. Es gibt 26 Backlog-Prioritätsstufen (A - Z). Der Exec hat eine konfigurierte maximale Anzahl offener Stapelläufe. Wenn diese Ebene erreicht ist, werden Jobs in der Prioritätsreihenfolge aus den Backlog-Warteschlangen ausgewählt. Innerhalb einer Prioritätsauswahl befindet sich normalerweise FIFO. Der Exec scannt jedoch die Jobsteuerungsanweisungen bis zur ersten Programmausführung vorab nach Dateinamen und Rollennummern. Wenn der Job sofort zum Stillstand kommt, weil einige der benötigten Ressourcen nicht verfügbar sind, kann er umgangen werden, um andere Jobs mit derselben Prioritätsstufe zu starten.

Die zweite Prioritätsstufe definiert eine Ausführungsprozessor-Ressourcengruppe. Im Allgemeinen erhalten höhere Ausführungsgruppenprioritäten normalerweise mehr Prozessorzeit.

Die Jobsteuerungssprache OS 2200 unterstützt zwar nicht die vollständige Programmierbarkeit, ermöglicht jedoch das dynamische Hinzufügen von Sequenzen der Steuerungssprache über eine @ ADD-Steueranweisung. Die hinzuzufügende Datei wurde möglicherweise von demselben Job unmittelbar vor dem Hinzufügen erstellt. Die @ ADD- und die meisten anderen Steueranweisungen können auch aus einem laufenden Programm über eine API gesendet werden. Zusätzliche Programmierbarkeit ist indirekt durch die Verwendung des Symbolic Stream Generator (SSG) verfügbar. SSG ist eine Programmiersprache zum Bearbeiten und Erstellen von Textdateien aus Eingabeparametern und Systeminformationen. Es wird häufig für die Verarbeitung des Konfigurationsmanagements ( make ) und andere Funktionen verwendet, bei denen Textbilder programmgesteuert erstellt werden müssen. Die resultierende Ausgabe kann im selben Lauf "@ADD" sein, wodurch der indirekt programmierbare Laufstrom bereitgestellt wird.

Operatorbefehle stehen zur Verfügung, um sowohl den Rückstand als auch die Ausführungsprioritäten von Läufen zu ändern. Da alle Bedienerbefehle über API für entsprechend privilegierte Benutzer verfügbar sind, kann dies von einem Remote-Administrator automatisiert oder gesteuert werden.

Die Frist ist ein Sonderfall der Charge. Ein Deadline-Lauf sieht genauso aus wie jeder andere Batch-Lauf, außer dass in der Steueranweisung @RUN oder @START eine Deadline-Zeit angegeben ist. Die Frist wird in Verbindung mit dem maximalen SUPS (Zeitschätzung) auf der Kontrollanweisung verwendet. Ein Terminjob wird mit normalen Stapelprioritäten ausgeführt, es sei denn oder bis sich herausstellt, dass er seine Terminzeit verpassen könnte. Je größer die Nichtübereinstimmung zwischen der Zeit bis zum Stichtag und den verbleibenden SUPS ist, desto höher ist die Priorität. Während die Frist Transaktionen nicht vollständig abschließen kann und keine Auswirkungen auf die Echtzeit hat, kann sie die meisten anderen Verarbeitungen im System bei Bedarf effektiv abschalten, um das Ziel zu erreichen.

Nachfrage

Time-Sharing-Sitzungen für OS 2200 werden als Bedarfsläufe (von "on demand") bezeichnet. Sie verwenden dieselbe Steuerungssprache wie Batch-Läufe mit einigen Ergänzungen, die als "sofortige" Steueranweisungen bezeichnet werden. Sofortige Steueranweisungen verwenden den Sentinel "@@", der angibt, dass sie auch dann sofort ausgeführt werden sollen, wenn ein Programm ausgeführt wird. Während sie zum Erstellen oder Zuweisen von Dateien verwendet werden können, ermöglichen die wichtigsten einem angeforderten Benutzer, ein laufendes Programm fehlerhaft zu beenden oder sogar ein Signal zu senden.

Transaktionen

Transaktionen werden als Läufe ausgeführt, jedoch ohne gespeicherte oder übermittelte Steueranweisungen. Wenn eine Nachricht von einer als Transaktionssitzung definierten Sitzung empfangen wird, wird sie gescannt, um die Transaktionswarteschlange zu bestimmen, in die sie gestellt werden soll. Dies wird normalerweise durch die ersten Zeichen der Nachricht bestimmt, es können jedoch auch vom Benutzer geschriebene Scanner hinzugefügt werden.

Der Kommunikationsmanager, der bis zu 250.000 aktive Sitzungen verarbeiten kann, nimmt eingehende Transaktionsnachrichten entgegen und leitet sie an die Nachrichtenwarteschlangensoftware weiter. Mithilfe der Nachrichtenwarteschlangenarchitektur kann eine unbegrenzte Anzahl von Nachrichten in der Warteschlange verarbeitet werden. Die TIP-APIs ( Transaction Interface Package ) im Betriebssystem werden aufgerufen, um die Transaktion am entsprechenden Warteschlangenpunkt in die Warteschlange zu stellen. Jeder Warteschlangenpunkt identifiziert die Prioritäts- und Parallelitätsstufe der Arbeit und das zugehörige auszuführende Transaktionsprogramm.

Ein Transaktionsprogramm-Planungsbaum ermöglicht es dem Client, die relative Verwendung für Gruppen von Transaktionsprogrammen festzulegen. Parallelitätsbeschränkungen vermeiden, dass eine Art von Arbeit das System dominiert, unter Ausschluss anderer Arbeiten, und vermeiden, dass zu viel Ressourcen gebunden werden. Im Baum können bis zu 4094 Knoten erstellt werden.

• Maximale Parallelität für jeden Knoten in der Baumstruktur angegeben
• Die Parallelität höherer Knoten begrenzt die Gesamtparallelität abhängiger Knoten
• Die Parallelität des höchsten Knotens begrenzt die Parallelität des Systems

Für jedes Transaktionsprogramm können Priorität (0 bis 63) und Parallelitätsstufe (1 bis 2047) angegeben werden.

Die Transaktion mit der höchsten Priorität wird für die Planung ausgewählt, sofern dies nicht durch die für den Knoten und höhere Knoten geltenden Parallelitätsrichtlinien begrenzt ist.

Echtzeit

Echtzeit ist keine andere Art von Lauf. Es handelt sich vielmehr um eine Reihe von Prioritätsstufen, die von jeder Aktivität angefordert werden können. Echtzeit wird am häufigsten von Batch-Programmen mit langer Laufzeit verwendet, wie z. B. dem OS 2200 Communications Manager CPComm, ist jedoch nicht auf solche beschränkt.

Die API stellt 36 Echtzeitprioritätsstufen zur Verfügung, die von Anwendungen verwendet werden können. Der Benutzer und das Konto müssen die Berechtigung haben, Echtzeitprioritäten zu verwenden. Es ist Sache der Site, zu steuern, wie ihre Anwendungen die Prioritätsstufen verwenden. Echtzeitprioritäten dominieren alle niedrigeren Prioritäten vollständig, so dass es durchaus möglich ist, dass ein schlecht benommenes Echtzeitprogramm einen oder mehrere Prozessoren bindet.

Die Echtzeitpriorität gilt für eine einzelne Aktivität (Thread), sodass in einem Programm möglicherweise sowohl Echtzeit- als auch Nicht-Echtzeit-Threads gleichzeitig ausgeführt werden.

CPU-Versand

Sobald ein Lauf gestartet wurde, steuert der Zugriff auf den Prozessor dessen Fortschrittsrate. Das Herzstück des Exec ist der Dispatcher, der alle Prozessoren verwaltet.

Der Exec unterstützt bis zu 4095 Versandprioritäten, obwohl die meisten Sites nur eine kleine Teilmenge davon definieren. Die beiden höchsten "Prioritäten" sind nicht umschaltbar. Sie erkennen bestimmte Arten der Verarbeitung an, die auf dem Prozessor, auf dem sie gestartet wurden, fortgesetzt werden dürfen, bis sie freiwillig die Kontrolle aufgeben. Eine Interrupt-Sperre tritt auf, wenn ein Interrupt eintrifft oder in einigen besonderen Fällen, wenn ein anderer Exec-Code alle Interrupts verhindert (um einige Daten zu ändern, auf die ein Interrupt-Handler möglicherweise auch zugreift).

Interlock wird von Interrupt-Nachbearbeitungsroutinen verwendet, die entweder auf demselben physischen Prozessor ausgeführt werden müssen oder einfach nicht unterbrochen werden sollten. Der Dispatcher, die E / A-Vervollständigungen und die E / A-Initiierung sind einige Beispiele. Alle Sperren, die von diesen beiden Prioritäten verwendet werden, sind Spin-Sperren, da sie nur von einer anderen Person auf einem anderen Prozessor festgelegt werden können und das Design erfordert, dass sie nur für sehr kurze Befehlssequenzen festgelegt werden.

Die hohe Exec-Priorität wird vom Bedienerbefehlshandler und einigen anderen Funktionen verwendet, die möglicherweise ausgeführt werden müssen, selbst wenn ein Echtzeitprogramm die Kontrolle hat. Es wird erwartet, dass sie nur sehr kurze Zeit benötigen. Wenn sie mehr Zeit benötigen, sollten sie die Arbeit in eine Warteschlange stellen, die von einer Low Exec-Aktivität verarbeitet werden soll.

Echtzeitaktivitäten haben ein unbegrenztes Prozessorquantum und werden ohne Umschaltung ausgeführt, sofern sie nicht durch eine Echtzeitaktivität mit höherer Priorität oder eine High Exec-Aktivität unterbrochen werden. Echtzeitaktivitäten erhalten die Kontrolle über jeden verfügbaren Prozessor, auf dem etwas mit niedrigerer Priorität ausgeführt wird. Bei Bedarf werden Interrupts zwischen Prozessoren gesendet, um die sofortige Verfügbarkeit sicherzustellen. Kunden verwenden Echtzeit, um Raketen zu fliegen, Simulatoren zu betreiben und andere Funktionen, die eine sofortige Reaktion erfordern.

Transaktionsprioritäten können auf zwei von der Site definierte Arten behandelt werden. Sie können eine Art Echtzeit mit niedrigerer Priorität sein, da nur die Priorität zählt und die Quantengröße im Wesentlichen unendlich ist. Dies ist für sehr kurzlebige Transaktionen wie Flugreservierungen geeignet. Wenn eine Schleife aufgrund eines Programmierfehlers ausgeführt wird, beendet der Exec diese, wenn die sehr kleine konfigurierte maximale Zeit erreicht ist. Mit der anderen Form kann der Exec die Priorität innerhalb eines Bereichs variieren, um die Nutzung der Systemressourcen zu optimieren. Der Ansatz gibt Programmen mit höherer Priorität und kürzeren Zeitscheiben für Programme mit eingeschränkter E / A und zunehmend niedrigeren Prioritäten, aber längeren Zeitscheiben für Programme mit Rechenleistung. Der Exec passt diese Prioritäten dynamisch basierend auf dem Verhalten an, da sich Programme häufig zu unterschiedlichen Zeiten in beide Richtungen verhalten. Dieser Ansatz eignet sich für länger laufende Transaktionen wie Datenbankabfragen oder Flugpreisangebote.

Charge und Nachfrage verwenden immer dynamisch angepasste Prioritäten. Programme, die auf E / A beschränkt sind oder sich in einem Gespräch mit einem Benutzer mit gemeinsamer Zeitnutzung befinden, erhalten höhere Prioritäten, aber kurze Zeitscheiben. Mehr rechenorientierte Programme erhalten niedrigere Prioritäten und längere Zeitscheiben.

Der Exec verfügt über zwei zusätzliche Mechanismen zur Optimierung des Versands. Eine davon ist das affinitätsbasierte Versenden. Wenn möglich, führt der Exec eine Aktivität auf demselben Prozessor aus wie beim letzten Mal, um den größten Vorteil des verbleibenden Cache-Inhalts zu erzielen. Wenn dies nicht möglich ist, wird versucht, die Aktivität unter dem Gesichtspunkt der Cache- und Speicherzugriffszeiten auf dem "nächsten" Prozessor zu halten. Der zweite ist ein "Fairness" -Politikmechanismus. Die Site kann den relativen Prozentsatz der Ressourcen definieren, die den einzelnen Transaktionen, Anforderungen und Chargen zugewiesen werden sollen. Innerhalb von Transaktionen und Stapeln gibt es Prioritätsgruppierungen, die weiter angeben können, wie viel Prozent der Zeit ihrer Gruppe der Priorität zugewiesen werden soll. Dies stellt sicher, dass Transaktionen das System nicht so dominieren können, dass keine Stapelarbeit ausgeführt wird. Innerhalb der verschiedenen Prioritätsgruppierungen wird sichergestellt, dass für jede Gruppe ein gewisser Fortschritt sichergestellt werden kann (es sei denn, der Gruppenprozentsatz ist Null). Diese "Fairness" -Algorithmen kommen nur dann ins Spiel, wenn die Prozessoren sehr ausgelastet sind. OS 2200-Systeme werden jedoch häufig mit nahezu 100% ausgelasteten Prozessoren ausgeführt.

Messung

OS 2200 unterstützt mehrere Modelle für das Systemleistungsmanagement. Kunden können ein bestimmtes festes Leistungsniveau erwerben, und der Exec überwacht die Prozessornutzung, um sicherzustellen, dass die Leistung dieses Niveau nicht überschreitet. Kunden können zusätzliche Leistung entweder vorübergehend oder dauerhaft bis zur vollen Kapazität des Systems erwerben, wenn sich ihre Arbeitsbelastung erhöht oder ein Notfall dies erfordert.

In jüngerer Zeit hat das System eine Messnutzungsfunktion hinzugefügt. In diesem Modus steht dem Kunden immer die volle Leistung des Systems zur Verfügung (obwohl dies möglicherweise administrativ eingeschränkt ist). Die Nutzung wird über einen Monat akkumuliert und anschließend wird die gemeldete Nutzung der Unisys-Abrechnung übermittelt. Abhängig von den spezifischen Vertragsbedingungen erhält der Kunde möglicherweise eine Rechnung für eine übermäßige Nutzung, die über einer vertraglich vereinbarten Basis für den Monat liegt, oder nur eine Erklärung, aus der hervorgeht, dass die gesamte vertraglich vereinbarte Nutzung verringert wurde. Das erste Formular ist wie eine Handyrechnung mit dem Potenzial, übermäßige Minuten aufzuladen. Letzteres ist wie der Kauf einer Prepaid-Telefonkarte.

Dateisystem

OS 2200 verfügt nicht wie die meisten anderen Betriebssysteme über ein hierarchisches Dateisystem . Vielmehr hat es eine strukturierte Namenskonvention und den Begriff von Containerdateien, die als Programmdateien bezeichnet werden.

Dateien in OS 2200 sind einfach Container, die entweder durch Wortversatz in der Datei oder durch Sektorversatz (28-Wort-Einheit) in der Datei adressiert werden können. Die 28 Wörter sind eine historische Einheit aus einem frühen Massenspeichergerät (der FASTRAND-Trommel), die 64 solcher Einheiten pro physischer Spur aufnehmen kann. Trotzdem ist es ein glücklicher historischer Unfall. Vier solcher 28-Wort-Einheiten oder 112 Wörter belegen 504 Bytes. Bei den heutigen Massenspeichergeräten, die alle physische 512-Byte-Datensätze verwenden, haben OS 2200-Clients fast alle ein Vielfaches von 112 Wörtern als physische Datensatzgröße und Datenbankseitengröße übernommen. E / A-Prozessoren passen sich automatisch an die 504 <12> 512-Byte-Zuordnung an, indem sie beim Schreiben 8 Byte Nullen hinzufügen und beim Lesen jedes physischen Datensatzes entfernen. OS 2200 verarbeitet Anwendungen, die andere Größen als ein Vielfaches von 112 Wörtern verwenden, indem es die enthaltenen physischen Datensätze untrennbar liest und die unveränderten und geänderten Teile mit Datenverkettung zurückschreibt. Spezielle Sperrfunktionen garantieren die Unteilbarkeit auch bei Gerätefehlern und auf mehreren Systemen in einem Cluster.

Dateiformate und andere interne Datenstrukturen werden im Referenzhandbuch zur Programmierung von Datenstrukturen beschrieben .

Dateinamen

Seit Exec-8 haben Dateinamen die Form: Qualifier * Dateiname (f-Zyklus) (z. B. "PERSONAL * MITARBEITER (+1)"). Qualifier und Dateiname sind einfach zwölfstellige Zeichenfolgen, mit denen die vom Client gewünschte Namensstruktur erstellt wird. F-Zyklus ist eine Zahl von 0 bis 999, die mehrere Generationen einer Datei ermöglicht. Diese können durch relative Zahlen referenziert werden: (+1) nächster oder neuer Zyklus, (-1) vorheriger Zyklus, (+0) aktueller Zyklus. Wenn Sie den Zyklus ausgeschaltet lassen, wird standardmäßig der aktuelle Zyklus verwendet. Stapelproduktionsläufe, die neue Generationen von Dateien erstellen, verwenden diesen Ansatz. Die Zahlen werden nach 999 umbrochen. Es können nur 32 aufeinanderfolgende relative Zyklusnummern gleichzeitig existieren. Durch das Erstellen eines (+1) wird (-31) gelöscht.

Jede Datei kann als Programmdatei verwendet werden. Eine Programmdatei enthält Elemente, die im Allgemeinen als Dateien fungieren. Die Benennung der Elemente lautet Qualifier * Dateiname (f-Zyklus). Element / Version (e-Zyklus) (z. B. "PERSONAL * PROGRAMS.TAXCALC / 2008"). Element und Version sind zwölfstellige Namen, die auf beliebige Weise vom Benutzer verwendet werden. Der E-Zyklus ist dem F-Zyklus insofern ähnlich, als er eine Generationsnummer darstellt, jedoch ohne die Beschränkung auf 32 gleichzeitige Zyklen und die Grenze liegt bei 256 K Zyklen. E-Cycle gilt jedoch nur für Textelemente, und jede Zeile in einem Textelement ist mit den Zyklusnummern gekennzeichnet, bei denen es eingefügt und gelöscht wurde. Elemente haben auch einen Typ und einen Untertyp. Die am häufigsten verwendeten Typen sind "Text" und "Objekt". Wenn der Standardtyp nicht geeignet ist, wählen die Optionen den entsprechenden Typ aus. Textelemente haben auch Untertypen, die typischerweise die Programmiersprache darstellen (z. B. "ASM", "C", "COB", "FOR"). Der Standardelementname einer Objektdatei entspricht der Textdatei, aus der sie erstellt wurde.

Ein Objektelement kann ausgeführt werden, wenn es ein Hauptprogramm ist oder mit anderen Objektelementen einschließlich eines Hauptprogramms verknüpft ist. Die Verknüpfung kann statisch oder dynamisch sein. Ein Hauptprogramm kann ohne Vorverknüpfung ausgeführt werden, vorausgesetzt, alle erforderlichen Unterprogramme befinden sich in derselben Programmdatei, sind Systembibliotheken oder auf andere Weise bekannt. In eine Programmdatei können Regeln aufgenommen werden, um die Suche des dynamischen Linkers nach unerfüllten Referenzen zu steuern. Der Linker kann auch verwendet werden, um mehrere Objektmodule statisch miteinander zu verknüpfen, um ein neues Objektmodul zu bilden, das alle Anweisungen, Daten und andere Informationen in den ursprünglichen Objektmodulen enthält.

Omnibus-Elemente können von Anwendungen als Daten verwendet werden oder dazu dienen, strukturierte Informationen für Anwendungen und Systemdienstprogramme zu speichern. Es gibt keine angenommene Struktur für ein Omnibus-Element.

Aus Gründen der Kompatibilität mit früheren Programmiermodellen (Basismodus) gibt es verschiebbare und absolute Elementtypen. Verschiebbare Elemente sind die Ausgabe von Basismodus-Compilern. Sie können durch den statischen Linker im Basismodus (@MAP - der Kollektor) kombiniert werden, um ein "absolutes" Element zu bilden, das ausführbar ist.

Dokumentenverwaltung

OS 2200 implementiert ein vollständig virtuelles Dateisystem. Dateien können überall auf allen Massenspeichergeräten zugewiesen werden. Massenspeicher wird als großer Speicherpool behandelt, ähnlich wie der virtuelle Speicher verwaltet wird. Während nach Möglichkeit zusammenhängender Speicherplatz zugewiesen wird, wird der Massenspeicher als eine Reihe von Seiten mit einer Größe von 8 KB behandelt, und eine Datei kann in beliebig vielen Bereichen desselben oder verschiedener Geräte abgelegt werden. Die dynamische Erweiterung von Dateien versucht, Speicherplatz neben der vorherigen Zuordnung zuzuweisen, findet jedoch Speicherplatz, wo immer er verfügbar ist. Tatsächlich müssen Dateien nicht einmal im Massenspeicher vorhanden sein, um verwendet zu werden. Das Exec- und das Dateisicherungssystem sind vollständig integriert. Wenn Dateisicherungen durchgeführt werden, werden die Bandspulennummern im Dateiverzeichnis aufgezeichnet. Wenn der Massenspeicher knapp wird, werden einige Dateien einfach als "entladen" markiert, wenn sie über eine aktuelle Sicherungskopie verfügen und ihr Speicherplatz zur Verwendung verfügbar ist. Wenn auf diese Weise nicht genügend Speicherplatz gefunden werden kann, wird eine Sicherung gestartet.

Alle Verweise auf eine entladene Datei werden in die Warteschlange gestellt, während die Datei zurück in den Massenspeicher kopiert wird. Das gesamte System ist automatisch und für Benutzer im Allgemeinen transparent.

Zugriffsmethoden

Im Allgemeinen bietet der Exec keine Zugriffsmethoden . Dateien sind einfach Container. Zugriffsmethoden werden von den Sprachlaufzeitsystemen und dem Datenbankmanager bereitgestellt. Die einzige Ausnahme ist eine Festblockzugriffsmethode, die für die Transaktionsverarbeitung mit hohem Volumen bereitgestellt wird. Es hat viel weniger Overhead als der Datenbankmanager, ist jedoch an allen Sperr-, Clustering- und Wiederherstellungsmechanismen beteiligt.

Abnehmbare Packungen

Wenn Clients eine explizitere Kontrolle über den Speicherort von Dateien wünschen, können sie das Konzept des "Wechselpakets" verwenden. Zu einer Zeit stellten diese wirklich physisch entfernbare Festplattenpakete dar, und das Betriebssystem erzeugte bei Bedarf automatisch Anforderungen zum Einhängen von Paketen an die Bediener.

Noch heute werden sie verwendet, um Dateien, normalerweise Datenbankdateien oder Transaktionsdateien, auf einem oder mehreren Datenträgern abzulegen. Dateien können immer noch mehrere Datenträger umfassen. Jetzt wird die Liste der Datenträgernamen beim Erstellen der Datei angegeben. Dateien, die sich auf solchen Datenträgergruppen befinden, werden weiterhin gesichert, unterliegen jedoch keiner automatischen Verwaltung des virtuellen Speicherplatzes.

CIFS

OS 2200 bietet auch eine vollständige Implementierung des Common Internet File System ( CIFS ). CIFS implementiert das von Microsoft-Servern verwendete SMB-Protokoll und die UNIX / Linux Samba- Software. CIFS für ClearPath OS 2200 ist sowohl ein Dateiserver als auch ein Dateiclient für andere CIFS-kompatible Systeme. Dies schließt Desktop-PCs mit Windows ein. CIFS unterstützt das Signieren von SMB-Nachrichten.

Um die Sicherheit von OS 2200 zu gewährleisten, bietet CIFS für ClearPath OS 2200 zwei Schutzstufen. Erstens sind OS 2200-Dateien für das Netzwerk erst sichtbar, wenn sie mit einem CIFS-Befehl als "Freigaben" deklariert wurden. Es besteht ein bestimmtes Privileg, um zu steuern, wer eine Freigabe deklarieren darf. Die zweite Kontrollebene besteht darin, dass der gesamte Zugriff weiterhin durch die Sicherheit von OS 2200 geschützt ist. Clients, die über CIFS auf OS 2200 zugreifen, müssen entweder automatisch über NTLM oder Kerberos identifiziert werden, oder sie erhalten eine Abfrage nach ihrer OS 2200-Benutzer-ID und ihrem Kennwort.

Mit CIFS können OS 2200-Dateien in einer hierarchischen Ansicht dargestellt werden. In der Regel wird das Qualifikationsmerkmal als höchste Ebene im Baum angezeigt, gefolgt von Dateiname, Elementname und Version. Darüber hinaus können Dateien auf OS 2200-Servern im vollständigen Windows-Dateinamenformat gespeichert werden. Windows-Anwendungen sehen OS 2200 als einen anderen Dateiserver. OS 2200-Anwendungen verfügen über APIs zum Lesen und Schreiben von Dateien, die auf anderen CIFS-kompatiblen Servern, z. B. Windows-Dateiservern, im Netzwerk vorhanden sind. Textdateien werden automatisch in und aus internen OS 2200-Formaten konvertiert. Binärdateien müssen vom Anwendungsprogramm verstanden werden.

Das unter OS 2200 ausgeführte CIFSUT-Dienstprogramm kann verschlüsselte komprimierte Dateien mit anderer Software wie WinZip austauschen.

Subsysteme

Das Konzept von Subsystemen und geschützten Subsystemen ist für das Design von OS 2200 von zentraler Bedeutung. Ein Subsystem ist einer DLL in Windows am ähnlichsten. Es sind Code und Daten, die von allen im System ausgeführten Programmen gemeinsam genutzt werden können. In OS 2200 verfügt jedes Subsystem über einen eigenen Satz von Bänken, die sich in einem separaten Teil des Adressraums befinden, auf den kein Benutzerprogramm direkt zugreifen kann. Stattdessen stellen die Hardware und das Betriebssystem ein "Gate" bereit, das das Ziel eines Aufrufbefehls sein kann. Siehe Unisys 2200 Series Systemarchitektur für weitere Informationen.

Die Datenbankmanager, Laufzeitbibliotheken, das Nachrichtensystem und viele andere Systemfunktionen sind als Subsysteme implementiert. Einige Subsysteme, die normalerweise aus reinem Code bestehen, wie z. B. die Laufzeitbibliotheken, können das direkte Ziel eines Aufrufbefehls sein, ohne dass ein Gate erforderlich ist. Diese Subsysteme werden in der Schutzumgebung des Benutzerprogramms ausgeführt. Andere Subsysteme wie die Datenbankmanager bestehen aus Code und Daten oder privilegiertem Code und können nur über ein Gate aufgerufen werden. Diesen Subsystemen können auch Zugriffssteuerungslisten zugeordnet sein, um zu steuern, wer sie anrufen darf. Noch wichtiger ist, dass das Gate die spezifischen sichtbaren Einstiegspunkte, die Schutzumgebung, in der das Subsystem ausgeführt wird, und häufig einen benutzerspezifischen Parameter steuert, der zusätzliche sichere Informationen über den Anrufer bereitstellt.

Sicherheit

B1 Sicherheit

Das OS 2200-Sicherheitssystem schützt Daten vor unbefugtem Zugriff, Änderung oder Gefährdung. Es enthält eine Implementierung der DoD Orange Book B1- Levelspezifikation. OS 2200 erhielt erstmals im September 1989 eine erfolgreiche B1-Evaluierung. Diese Evaluierung wurde bis 1994 beibehalten. Danach folgten die Entwickler von OS 2200 weiterhin den für die B1-Evaluierung erforderlichen Entwicklungs- und Dokumentationspraktiken.

Zentral für ein B1-System sind die Konzepte von Benutzern und Objekten. Benutzer haben Identitäten, Freigabestufen, Fächer und Berechtigungen. Objekte erfordern bestimmte Kombinationen von Objekten für verschiedene Zugriffsarten. Objekte in OS 2200 bestehen aus Dateien, geschützten Subsystemen, Geräten und Bandspulen.

Das Sicherheitsprofil einer Benutzersitzung enthält die Benutzeridentität, die Freigabestufe (0-63), den Fachsatz und den Satz zulässiger Berechtigungen. OS 2200 implementiert sowohl die obligatorische Zugriffskontrolle (MAC) als auch die diskretionäre Zugriffskontrolle (DAC) basierend auf dem Bell-La Padula-Modell für Vertraulichkeit (kein Auflesen, kein Aufschreiben) und dem Biba-Integritätsmodell (kein Ablesen, kein Aufschreiben). . Damit ein Lauf eine Datei lesen oder ausführen kann, muss die Ausführungsfreigabestufe des Laufs größer oder gleich der Freigabestufe der Datei sein und die Freigabestufe der Datei muss 0 oder innerhalb des Freigabestufenbereichs des Laufs liegen. Darüber hinaus muss der ausführende Abteilsatz des Laufs den Abteilsatz der Datei enthalten. Da OS 2200 die Modellanforderungen von Bell-La Padula und Biba kombiniert, müssen die Ausführungsfreigabestufe und der Fachsatz eines Laufs genau mit denen einer Datei übereinstimmen, damit in die Datei geschrieben oder gelöscht werden kann.

Der DAC ordnet einem Objekt eine Zugriffssteuerungsliste zu. Die Liste identifiziert Benutzer und Benutzergruppen, die Zugriff haben, und definiert die Art des Zugriffs, der Benutzer oder Gruppe gewährt wird (Lesen, Schreiben, Ausführen oder Löschen).

Da der vollständige Satz von B1-Steuerelementen für die meisten Umgebungen zu restriktiv ist, können Systemadministratoren Server konfigurieren, indem sie auswählen, welche Steuerelemente angewendet werden sollen. Eine Reihe von Sicherheitsstufen von der grundlegenden Sicherheit bis zur Sicherheitsstufe 3 dient als Ausgangspunkt.

Sicherheitsbeauftragter

Jedes OS 2200-System verfügt über einen Benutzer, der als Sicherheitsbeauftragter festgelegt ist. Auf Systemen mit grundlegender Sicherheit darf nur der Sicherheitsbeauftragte bestimmte Aufgaben ausführen. Auf Systemen mit höheren Sicherheitsstufen können andere vertrauenswürdige Benutzer möglicherweise einige dieser Aufgaben ausführen.

OS 2200 bietet einen detaillierten Sicherheitsmechanismus, der auf dem Prinzip der geringsten Berechtigungen basiert . Dieses Prinzip verlangt, dass nur das Mindestprivileg gewährt wird, das zur Ausführung der erforderlichen Aufgabe erforderlich ist. Somit hat OS 2200 kein Konzept einer "Super User" -Rolle, die von jedem Benutzer übernommen werden kann. Vielmehr werden zahlreiche spezifische Berechtigungen verwendet, die jedem Benutzer separat gewährt werden können. Jedes Privileg ist einer bestimmten Berechtigung zugeordnet.

Dateisicherheit

Auf Systemen, die mit Sicherheitsstufe 1 oder höher konfiguriert sind, ist der Benutzer, der ein Objekt erstellt, der Eigentümer des Objekts. Standardmäßig ist das Objekt für den erstellenden Benutzer privat, es kann jedoch auch öffentlich sein oder von einer Zugriffssteuerungsliste gesteuert werden. Der Eigentümer oder der Sicherheitsbeauftragte kann eine Zugriffssteuerungsliste für dieses Objekt erstellen.

Auf einem System mit grundlegender Sicherheit haben Dateien keine Eigentümer. Stattdessen werden sie privat für ein Konto oder Projekt erstellt oder sind öffentlich. Der Zugriff auf sie kann über Lese- und Schreibtasten gesteuert werden.

Authentifizierung

Wenn sich Benutzer am System anmelden, identifizieren sie sich und wählen optional die Freigabestufe und das Fachset aus, die sie für diese Sitzung verwenden möchten.

OS 2200 bietet ein flexibles Authentifizierungssystem. Es werden mehrere Authentifizierungsmechanismen gleichzeitig unterstützt. Von Kunden oder Dritten geschriebene Authentifizierungssoftware kann ebenfalls verwendet werden. Zu den Standardauthentifizierungsfunktionen gehören:

• Benutzer-ID und Kennwort werden von OS 2200 in einer verschlüsselten Datei verwaltet
• Die Authentifizierung wird von einem externen System wie Microsoft Windows unter Verwendung der Benutzer-ID und des Kennwortmechanismus durchgeführt
• NTLM
• Kerberos
• LDAP

Die letzten beiden erlauben die Verwendung von Biometrie, Smartcards und anderen Authentifizierungsmechanismen, die von diesen Technologien unterstützt werden.

Verschlüsselung

OS 2200 bietet Verschlüsselung für ruhende Daten über die Cipher API, ein Software-Subsystem, das Anruferdaten verschlüsselt und entschlüsselt. Die Cipher API unterstützt auch die Verwendung einer Hardwarebeschleunigerkarte für die Verschlüsselung von Massendaten.

Für CMOS-basierte Dorado-Server bietet CPComm eine SSL / TLS- Verschlüsselung für Daten während der Übertragung . Für Intel-basierte Dorado-Server werden SSL und TLS von openSSL bereitgestellt , das in der Dorado-Firmware enthalten ist. Alle Dorado-Server unterstützen die TLS-Stufen 1.0 bis 1.2 sowie SSLv3. SSL ist jedoch aufgrund von Sicherheitslücken im Protokoll standardmäßig deaktiviert.

Sowohl CPComm als auch Cipher API verwenden die Verschlüsselungsdienste von CryptoLib, einem FIPS- zertifizierten Software-Verschlüsselungsmodul. Die Algorithmen AES und Triple DES gehören zu den in CryptoLib implementierten Algorithmen.

OS 2200 unterstützt auch die Verschlüsselung von Bandlaufwerken, die die Verschlüsselung von Archivdaten ermöglichen.

Clustering

OS 2200-Systeme können geclustert werden , um eine höhere Leistung und Verfügbarkeit als ein einzelnes System zu erzielen. Bis zu 4 Systeme können über gemeinsam genutzte Festplatten zu einem Cluster zusammengefasst werden, der Datenbanken und Dateien gemeinsam nutzt. Ein Hardwaregerät, der XPC-L, sorgt für die Koordination zwischen den Systemen, indem er einen Hochgeschwindigkeits-Sperrmanager für den Datenbank- und Dateizugriff bereitstellt.

In einer Clusterumgebung kann jedes System über eigene lokale Dateien, Datenbanken und Anwendungsgruppen sowie gemeinsam genutzte Dateien und eine oder mehrere gemeinsam genutzte Anwendungsgruppen verfügen. Auf lokale Dateien und Datenbanken wird nur von einem einzigen System zugegriffen. Freigegebene Dateien und Datenbanken müssen sich auf Datenträgern befinden, auf die von allen Systemen im Cluster gleichzeitig zugegriffen werden kann.

Der XPC-L bietet einen Kommunikationspfad zwischen den Systemen zur Koordinierung von Aktionen. Es bietet auch einen sehr schnellen Motor. Die Verbindung zum XPC-L erfolgt über einen speziellen E / A-Prozessor, der mit extrem geringen Latenzen arbeitet. Der Sperrmanager im XPC-L bietet alle Funktionen, die für Datei- und Datenbanksperren erforderlich sind. Dies umfasst die Erkennung von Deadlocks und die Möglichkeit, Sperren für fehlgeschlagene Anwendungen freizugeben.

Der XPC-L wird mit zwei physischen Servern implementiert, um eine vollständig redundante Konfiguration zu erstellen. Die Wartung, einschließlich des Ladens neuer Versionen der XPC-L- Firmware , kann auf einem der Server durchgeführt werden, während der andere weiterhin ausgeführt wird. Fehler, einschließlich physischer Schäden an einem Server, stoppen den Cluster nicht, da alle Informationen auf beiden Servern gespeichert sind.

Betrieb und Verwaltung

Operationen

Der Betrieb von OS 2200 basiert auf aktiven Bedienern und einer oder mehreren Konsolen. Jede Konsole ist ein Terminalfenster, von dem ein Teil für eine feste Anzeige reserviert ist, die häufig mit zusammenfassenden Informationen zu Aktivitäten im System aktualisiert wird.

Der Rest der Konsole wird als Bildlaufanzeige für Ereignisse verwendet. Wenn eine Nachricht ausgegeben wird, die eine Bedienerantwort erfordert, erhält sie eine Nummer von 0 bis 9 und bleibt auf dem Display, bis sie beantwortet wird. Bandmontagemeldungen scrollen mit anderen Nachrichten, werden jedoch alle zwei Minuten wiederholt, bis das Band bereitgestellt wird.

Operations Sentinel wird für alle OS 2200-Operationen verwendet. OS 2200-Konsolen sind einfach Fenster in einer Operations Sentinel-Anzeige. Es können beliebig viele Display-PCs vorhanden sein. Fernbedienung ist typisch. Operations Sentinel unterstützt eine beliebige Anzahl von ClearPath-, Windows-, Linux- und UNIX-Systemen.

Mit dem Produkt wird eine automatische Aktionsnachrichtendatenbank freigegeben. Mit dieser Datenbank kann Operations Sentinel Nachrichten erkennen. Skripte können geschrieben werden, um automatisch auf Nachrichten zu antworten, die eine Antwort erfordern, unerwünschte Nachrichten auszublenden, sie in andere Sprachen zu übersetzen, Ereignisse zu erstellen usw. Einige Clients verwenden den vollständigen Dunkelraumbetrieb. Sie werden höchstens Operations Sentinel-Anzeigen an entfernten Standorten haben, die das System überwachen und Warnungen erstellen, wenn bestimmte Ereignisse auftreten.

Verwaltung

Die Verwaltung von OS 2200-Systemen erfolgt mit einer Vielzahl von Tools, die jeweils auf einen bestimmten Bereich des Systems spezialisiert sind. Beispielsweise gibt es ein Tool zum Verwalten der Transaktionsumgebung, mit dem neue Transaktionsprogramme installiert, alle erforderlichen Informationen dazu angegeben, die Warteschlangenstruktur, Prioritäten und Parallelitätsstufen geändert usw. werden können.

Andere Werkzeuge sind speziell für die Sicherheitsbeauftragten und ermöglichen die Erzeugung von Benutzern, erlaubten Privilegien ändern, ändert Systemsicherheitseinstellungen usw. ^{, ,}

Die meisten Tools verfügen über eine grafische Oberfläche, einige jedoch nicht. Alle bieten eine Batch-Schnittstelle für gespeicherte Dateien, in der alle Aktionen im Steuerungsstrom angegeben sind. Auf diese Weise können alle Verwaltungsschnittstellen von lokalen Standorten aus, möglicherweise basierend auf der Tageszeit oder anderen Ereignissen, oder von Remotestandorten aus per Skript erstellt werden. Für jeden Verwaltungsbereich sind eindeutige Berechtigungen erforderlich.

Anwendungsgruppen

Anwendungsgruppen sind ein logisches Konstrukt, das aus einer Instanz des Universal Data System (UDS), einer Instanz des Subsystems für Nachrichtenwarteschlangen und einigen Transaktionen besteht. Jede Anwendungsgruppe verfügt über einen eigenen Prüfpfad. OS 2200 unterstützt maximal 16 Anwendungsgruppen in einem System.

Der Begriff der Anwendungsgruppe entspricht dem, was oft als "Anwendung" bezeichnet wird. Das heißt, eine Reihe von Programmen und Daten, die eine größere Einheit der verbundenen Verarbeitung darstellen. Beispielsweise könnte eine Anwendungsgruppe ein Airline-System darstellen. Eine andere Anwendungsgruppe könnte das Unternehmensfinanzierungssystem repräsentieren. Oder Anwendungsgruppen können Instanzen derselben Anwendungs- und Datenmodelle darstellen wie in Bankfilialen. Wichtig ist, dass jede Anwendungsgruppe ihre eigene Umgebung, Sitzungen, Wiederherstellung usw. hat.

Anwendungsgruppen können unabhängig voneinander gestartet, gestoppt und wiederhergestellt werden.

Anwendungsgruppen haben keine eigenen Abrechnungs- und Planungsregeln. Transaktionen in mehreren Anwendungsgruppen haben möglicherweise dieselben Prioritäten und verschachtelte Prioritäten. Auf diese Weise kann der Standort die relativen Prioritäten von Transaktionen im gesamten System steuern.

Siehe auch

• Systemarchitektur der Unisys 2200-Serie für Informationen zur Hardwarearchitektur.
• Unisys OS 2200-Programmiersprachen für Informationen zu den OS 2200-Compilern und -Linkern.
• Unisys OS 2200-Datenbanken für Informationen zu den OS 2200-Datenbanken und zum Datenbankmanager.
• Unisys OS 2200-Kommunikation für Informationen zur OS 2200-Kommunikation.
• Unisys OS 2200 verteilte Verarbeitung für Informationen zur verteilten Verarbeitung von OS 2200.

Andere Orte des Quellmaterials

Der Unisys History Newsletter enthält Artikel über die Geschichte und Computer von Unisys. Zusätzlich zu allen Unisys History Newslettern gibt es Links zu anderen Websites.

Die meisten historischen Archive von Unisys befinden sich am Charles Babbage Institute der University of Minnesota sowie im Hagley Museum and Library in Delaware. Das Charles Babbage Institute besitzt die Archive von ERA, einige frühe Remington Rand-Archive von Saint Paul, MN, und die Burroughs-Archive. Das Hagley Museum and Library beherbergt den Großteil der Sperry-Archive.

Verweise

Fußnoten