Multiple Virtual Storage allgemeiner als MVS bezeichnet, war das am häufigsten verwendete Betriebssystem auf den IBM / Mainframe-Computern System / 370 und System / 390. Es wurde von IBM entwickelt, hat jedoch keinen Bezug zu den anderen Mainframe-Betriebssystemen von IBM, z. B. VSE, VM, TPF.
MVS wurde 1974 erstmals veröffentlicht und wurde mehrfach um Programmprodukte mit neuen Namen erweitert:
- zuerst zu MVS / SE (MVS / Systemerweiterungen), [NB 1]
- neben MVS / SP (MVS / Systemprodukt) Version 1,
- neben MVS / XA (MVS / eXtended Architecture),
- Neben MVS / ESA (MVS / Enterprise Systems Architecture),
- dann OS / 390 und
- schließlich z / OS (als 64-Bit-Unterstützung wurde bei den zSeries-Modellen hinzugefügt). IBM fügte UNIX-Unterstützung (ursprünglich als OpenEdition MVS bezeichnet) in MVS / SP V4.3 hinzu und erhielt POSIX- und UNIX ™ -Zertifizierungen auf verschiedenen Ebenen von IEEE, X / Open und The Open Group. Der MVS-Kern bleibt grundsätzlich dasselbe Betriebssystem. Programme, die für MVS geschrieben wurden, laufen ohne Änderungen unter z / OS.
Zunächst beschrieb IBM MVS einfach als eine neue Version von OS / VS2, die jedoch in der Tat eine grundlegende Umschreibung war. OS / VS2-Version 1 war ein Upgrade von OS / 360 MVT, das den Großteil des ursprünglichen Codes beibehielt und wie MVT hauptsächlich in Assembler geschrieben wurde. Der MVS-Kern wurde fast vollständig in Assembler XF geschrieben, obwohl einige Module in PL / S geschrieben wurden, nicht jedoch die leistungsabhängigen, insbesondere nicht der Input / Output Supervisor (IOS). Die Verwendung von "OS / VS2" von IBM betonte die Aufwärtskompatibilität: Anwendungsprogramme, die unter MVT ausgeführt wurden, mussten nicht einmal neu kompiliert werden, um unter MVS ausgeführt zu werden. Die gleichen Job Control Language-Dateien können unverändert verwendet werden. Dienstprogramme und andere nicht zum Kerngeschäft gehörende Einrichtungen wie TSO liefen unverändert. IBM und Benutzer nannten das neue System fast einstimmig von Anfang an MVS, und IBM verwendete den Begriff MVS in der Benennung späterer major-Versionen wie MVS / XA.
Evolution von MVS [ edit ]
OS / 360 MFT (Multitasking mit fester Anzahl von Tasks): Multitasking: Mehrere Speicherpartitionen mit fester Größe wurden eingerichtet wann das Betriebssystem installiert wurde und wann der Bediener sie neu definierte. Beispielsweise könnte es eine kleine Partition, zwei mittlere Partitionen und eine große Partition geben. Wenn zwei große Programme zum Ausführen bereit wären, müsste eines warten, bis das andere beendet ist, und die große Partition freigegeben.
OS / 360 MVT (Multitasking mit einer variablen Anzahl von Tasks) war eine Erweiterung, die den Speicherverbrauch weiter verfeinerte. Anstatt Speicherpartitionen mit fester Größe zu verwenden, ordnete MVT bei Bedarf Arbeitsschritte zu -Regionen zu, vorausgesetzt, es war ausreichend physischer Speicher verfügbar. Dies war ein erheblicher Fortschritt gegenüber der MFT-Speicherverwaltung, hatte jedoch einige Schwächen: Wenn ein Job dynamisch Speicher zugewiesen hat (wie bei den meisten Sortierprogrammen und Datenbankverwaltungssystemen), mussten die Programmierer den maximalen Speicherbedarf des Jobs schätzen und ihn für MVT vordefinieren . Ein Jobschritt, der eine Mischung aus kleinen und großen Programmen enthielt, verschwendete Speicher, während die kleinen Programme ausgeführt wurden. Im Ernstfall könnte der Speicher fragmentiert werden, d. H. Der Speicher, der nicht von aktuellen Jobs verwendet wird, kann in unnötig kleine Abschnitte zwischen den Bereichen, die von aktuellen Jobs verwendet werden, aufgeteilt werden, und die einzige Abhilfe bestand darin, einige laufende Jobs zu warten, bevor neue Jobs gestartet werden.
In den frühen 70er Jahren versuchte IBM, diese Schwierigkeiten durch die Einführung eines virtuellen Speichers (von IBM als "virtueller Speicher" bezeichnet) zu mildern, mit dem Programme Adressräume anfordern konnten, die größer als der physische Speicher waren. Die ursprünglichen Implementierungen hatten einen einzigen virtuellen Adressraum, den alle Jobs gemeinsam nutzen. OS / VS1 war OS / 360 MFT innerhalb eines einzigen virtuellen Adressraums. OS / VS2 SVS war OS / 360 MVT innerhalb eines einzigen virtuellen Adressraums. So hatten OS / VS1 und SVS im Prinzip die gleichen Nachteile wie MFT und MVT. Die Auswirkungen waren jedoch weniger schwerwiegend, da Jobs viel größere Adressräume anfordern konnten und die Anforderungen aus einem 16-MB-Pool stammen, selbst wenn der physische Speicher kleiner war.
MVS-Adressräume - globale Ansicht
| |||||||||
Die Ansicht einer Anwendung
| |||||||||
Mitte der 70er Jahre führte IBM MVS ein, das nicht nur virtuellen Speicher unterstützte, der größer war als der verfügbare reale Speicher, [NB 2] wie auch SVS, sondern auch eine unbegrenzte Anzahl von Anwendungen in unterschiedlichen Adressräumen ausführen konnte. Zwei gleichzeitige Programme versuchen möglicherweise, auf dieselbe virtuelle Speicheradresse zuzugreifen, aber das virtuelle Speichersystem hat diese Anforderungen in verschiedene Bereiche des physischen Speichers umgeleitet. Jeder dieser Adressräume bestand aus drei Bereichen: einem Betriebssystem (eine von allen Jobs gemeinsam genutzte Instanz), einem für jede Anwendung eindeutigen Anwendungsbereich und einem gemeinsam genutzten virtuellen Bereich, der für verschiedene Zwecke einschließlich der Kommunikation zwischen Jobs verwendet wird. IBM versprach, dass die Anwendungsbereiche immer mindestens 8 MB betragen würden. Dies machte MVS zur perfekten Lösung für geschäftliche Probleme, die sich aus der Notwendigkeit ergaben, mehr Anwendungen auszuführen.
MVS maximierte das Verarbeitungspotenzial durch die Bereitstellung von Multiprogrammierungs- und Multiprozessierungsfunktionen. Wie seine Vorgänger MVT und OS / VS2 SVS unterstützte MVS Multiprogramming. Programmanweisungen und zugehörige Daten werden von einem Steuerprogramm und vorgegebenen Verarbeitungszyklen geplant. Im Gegensatz zu einem Betriebssystem mit einer einzigen Programmierung maximieren diese Systeme die Nutzung des Verarbeitungspotenzials, indem sie die Verarbeitungszyklen unter den Befehlen aufteilen, die mehreren verschiedenen gleichzeitig laufenden Programmen zugeordnet sind. Auf diese Weise muss das Steuerungsprogramm nicht warten, bis die E / A-Operation abgeschlossen ist, bevor Sie fortfahren. Durch Ausführen der Anweisungen für mehrere Programme kann der Computer zwischen aktiven und inaktiven Programmen hin und her wechseln.
Frühere Versionen von MVS (Mitte der 1970er Jahre) gehörten zu den ersten der IBM OS-Serie, die Multiprozessorkonfigurationen unterstützten, obwohl die M65MP-Variante von OS / 360, die auf den 360-Modellen 65 und 67 ausgeführt wird, nur eingeschränkte Multiprozessorunterstützung bietet. Das 360 Model 67 hatte auch die Multiprozessor-fähigen Betriebssysteme TSS / 360, MTS und CP-67 gehostet. Da Multiprocessing-Systeme Befehle gleichzeitig ausführen können, bieten sie eine größere ] Verdeutlichung benötigte Verarbeitungsleistung als Einzelverarbeitungssystem. Dadurch konnte MVS die geschäftlichen Probleme lösen, die sich aus der Notwendigkeit ergeben, große Datenmengen zu verarbeiten.
Multiprocessing-Systeme sind entweder lose gekoppelt, was bedeutet, dass jeder Computer Zugriff auf eine gemeinsame Arbeitslast hat, oder eng gekoppelt, was bedeutet, dass die Computer den gleichen realen Speicher verwenden und von einer einzigen Kopie des Betriebssystems gesteuert werden. [ Erläuterung erforderlich MVS behielt sowohl das lose gekoppelte Multiprocessing des ASP (Attached Support Processor) [NB 3] als auch das eng gekoppelte Multiprocessing von OS / 360, Modell 65, bei. In eng gekoppelten Systemen haben zwei CPUs den gleichzeitigen Zugriff auf denselben Speicher (und dieselbe Kopie des Betriebssystems) und auf die Peripheriegeräte gemeinsam genutzt, wodurch eine höhere Verarbeitungsleistung und ein gewisser Grad an Ausfallsicherheit für eine CPU bereitgestellt werden. In locker gekoppelten Konfigurationen verfügte jeder aus einer Gruppe von Prozessoren (einzeln und / oder fest gekoppelt) über einen eigenen Speicher und ein eigenes Betriebssystem. Gemeinsame Peripheriegeräte und die Betriebssystemkomponente JES3 ermöglichten die Verwaltung der gesamten Gruppe von einer Konsole aus. Dies führte zu einer höheren Ausfallsicherheit und ließ die Bediener entscheiden, welcher Prozessor welche Jobs von einer zentralen Jobwarteschlange aus ausführen sollte. MVS JES3 bot den Benutzern die Möglichkeit, zwei oder mehr Datenverarbeitungssysteme über gemeinsam genutzte Festplatten und Channel-to-Channel-Adapter (CTCAs) miteinander zu vernetzen. Diese Funktion wurde JES2-Anwendern schließlich als Multi-Access SPOOL (MAS) zur Verfügung gestellt. Zitat benötigt ]
MVS unterstützte ursprünglich die 24-Bit-Adressierung (dh bis zu 16 MB) ). Mit dem Fortschreiten der zugrunde liegenden Hardware wurden 31-Bit-Adressen (XA und ESA; bis zu 2048 MB) und jetzt (als z / OS) 64-Bit-Adressierung unterstützt. Die wichtigsten Motive für das schnelle Upgrade auf die 31-Bit-Adressierung waren das Wachstum großer Transaktionsverarbeitungsnetzwerke, die größtenteils von CICS gesteuert werden und in einem einzigen Adressraum ausgeführt wurden. Das relationale Datenbankverwaltungssystem von DB2 benötigte mehr als 8 MB an Anwendungen Adressraum für einen effizienten Betrieb. (Frühere Versionen wurden in zwei Adressräume konfiguriert, die über den gemeinsam genutzten virtuellen Bereich kommunizierten, dies bedeutete jedoch einen erheblichen Aufwand, da alle derartigen Kommunikationen über das Betriebssystem übertragen wurden.)
Die Hauptbenutzeroberflächen für MVS sind: Job Control Language (JCL), die ursprünglich für die Stapelverarbeitung konzipiert wurde, aber ab den 70er Jahren auch zum Starten und Zuweisen von Ressourcen für lang laufende interaktive Jobs wie CICS verwendet wurde. und TSO (Time Sharing Option), die interaktive Schnittstelle für die gemeinsame Nutzung von Zeitnutzern, die hauptsächlich zum Ausführen von Entwicklungswerkzeugen und einigen Endbenutzerinformationssystemen verwendet wurde. ISPF ist eine TSO-Anwendung für Benutzer von Terminals der 3270-Familie (und später auch von VM), mit der der Benutzer dieselben Aufgaben wie die Befehlszeile von TSO ausführen kann, jedoch menü- und formabhängig und mit einem Vollbild-Editor und Dateibrowser. Die Basisschnittstelle des TSO ist die Befehlszeile, obwohl später Funktionen für formularbasierte Schnittstellen hinzugefügt wurden.
MVS machte bei der Fehlertoleranz, die auf der früheren STAE-Einrichtung aufbaute, die IBM Software Recovery nannte, einen großen Schritt nach vorne. IBM entschied sich dazu nach jahrelangen praktischen Erfahrungen mit MVT in der Geschäftswelt. Systemausfälle hatten nun erhebliche Auswirkungen auf die Kundengeschäfte, und IBM entschied sich für einen großen Konstruktionssprung, um davon auszugehen, dass trotz der besten Softwareentwicklungs- und Testtechniken "Probleme auftreten". Diese tiefgreifende Annahme war ausschlaggebend für das Hinzufügen großer Prozentsätze des Fehlertoleranzcodes zum System und trug wahrscheinlich zum Erfolg des Systems bei der Tolerierung von Software- und Hardwareausfällen bei. Statistische Informationen sind schwer zu finden, um den Wert dieser Konstruktionsmerkmale zu belegen (wie können Sie „vorbeugende“ oder „wiederhergestellte“ Probleme messen?), Aber IBM hat diese fehlertolerante Softwarewiederherstellung in vielen Dimensionen verbessert und eine schnelle Problemlösung ermöglicht Funktionen im Laufe der Zeit.
Dieser Entwurf spezifizierte eine Hierarchie von Fehlerbehandlungsprogrammen im Systemmodus (Kernel / Privilegiert), die als Functional Recovery Routines bezeichnet werden, und im Benutzermodus ("Task" oder "Problemprogramm") als "ESTAE" ( Erweiterte festgelegte Task (Abnormal Exit-Routinen), die aufgerufen wurden, falls das System einen Fehler feststellte (tatsächlich ein Hardwareprozessor- oder Speicherfehler oder ein Softwarefehler). Jede Wiederherstellungsroutine machte die 'Mainline'-Funktion wiederaufrufbar, erfasste Fehlerdiagnosedaten, um das verursachende Problem zu debuggen, und entweder' erneut versucht '(erneute Wiederholung der Hauptlinie) oder' perkoliert '(eskalierte Fehlerverarbeitung zur nächsten Wiederherstellungsroutine in der Hierarchie).
Daher hat das System mit jedem Fehler Diagnosedaten erfasst und versucht, eine Reparatur durchzuführen und das System in Betrieb zu halten. Am schlimmsten war es, bei unreparierten Fehlern einen Benutzeradressraum (einen 'Job') abzunehmen. Obwohl dies ein erster Entwurfspunkt war, wurde dem Wiederherstellungsprogramm nicht nur bis zur neuesten MVS-Version (z / OS) eine eigene Wiederherstellungsroutine garantiert, sondern jede Wiederherstellungsroutine verfügt nun über eine eigene Wiederherstellungsroutine. Diese Wiederherstellungsstruktur wurde in das grundlegende MVS-Steuerungsprogramm eingebettet. Programmierfunktionen stehen zur Verfügung und werden von Anwendungsprogrammentwicklern und Drittanbieterentwicklern verwendet.
In der Praxis machte die MVS-Software-Wiederherstellung das Debuggen von Problemen sowohl einfacher als auch schwieriger. Die Software-Wiederherstellung erfordert, dass Programme Spuren hinterlassen, wo sie sich befinden und was sie tun, wodurch das Debuggen erleichtert wird. Die Tatsache, dass die Verarbeitung trotz eines Fehlers fortschreitet, kann die Spuren jedoch überschreiben. Durch die Erfassung des frühen Datums zum Zeitpunkt des Fehlers wird das Debugging maximiert, und für die Wiederherstellungsroutinen (Task- und Systemmodus, beide) stehen dazu Einrichtungen zur Verfügung.
IBM fügte zusätzliche Kriterien für ein schwerwiegendes Softwareproblem hinzu, für das IBM Service erforderlich war. Wenn eine Mainline-Komponente keine Softwarewiederherstellung initiierte, wurde dies als gültiger meldepflichtiger Fehler betrachtet. Wenn eine Wiederherstellungsroutine keine signifikanten Diagnosedaten erfasst hat, sodass das ursprüngliche Problem durch die von dieser Wiederherstellungsroutine gesammelten Daten gelöst werden konnte, gaben die IBM-Standards vor, dass dieser Fehler meldepflichtig war und repariert werden musste. Daher haben die IBM-Standards bei konsequenter Anwendung zu einer kontinuierlichen Verbesserung geführt.
IBM hat in der ersten Version von MVS einen On-Demand-Hypervisor eingeführt, ein wichtiges Tool für die Wartbarkeit, das Dynamic Support System (DSS). Diese Funktion könnte aufgerufen werden, um eine Sitzung zum Erstellen von Diagnoseprozeduren oder zum Aufrufen bereits gespeicherter Prozeduren zu initiieren. Die Prozeduren "fangen" spezielle Ereignisse, wie das Laden eines Programms, Geräte-E / A, Systemprozeduraufrufe, und lösen dann die Aktivierung der zuvor definierten Prozeduren aus. Diese Prozeduren, die rekursiv aufgerufen werden können, ermöglichten das Lesen und Schreiben von Daten sowie die Änderung des Befehlsflusses. Es wurde Hardware zur Programmierung von Programmereignissen verwendet. Aufgrund des Overheads dieses Tools wurde es aus den vom Kunden verfügbaren MVS-Systemen entfernt. Die Programmereignisaufzeichnung (PER) wurde durch die Erweiterung des Diagnosebefehls "SLIP" um die Einführung der PER-Unterstützung (SLIP / Per) in SU 64/65 (1978) durchgeführt.
Mehrere Kopien von MVS (oder anderen IBM-Betriebssystemen) können das gemeinsam nutzen gleiche Maschine, wenn diese Maschine von VM / 370 gesteuert wurde. In diesem Fall war VM / 370 das eigentliche Betriebssystem und betrachtete die "Gast" -Betriebssysteme als Anwendungen mit ungewöhnlich hohen Berechtigungen. Infolge späterer Hardwareverbesserungen könnte eine Instanz eines Betriebssystems (entweder MVS oder VM mit Gastsystemen oder eine andere) auch eine logische Partition (LPAR) anstelle eines gesamten physischen Systems belegen.
Mehrere MVS-Instanzen können in einer Struktur organisiert und gemeinsam verwaltet werden, die als Systemkomplex oder oder bezeichnet wird und im September 1990 eingeführt wurde. Instanzen interoperieren durch eine Softwarekomponente, die als Cross- System Coupling Facility (XCF) und eine Hardwarekomponente, die als Hardware Coupling Facility bezeichnet wird (CF oder Integrated Coupling Facility, ICF, wenn sie auf derselben Mainframe-Hardware angeordnet sind). Mehrere Sysplexe können über Standard-Netzwerkprotokolle wie IBM Systems Systems Architecture (SNA) oder in jüngster Zeit über TCP / IP verbunden werden. Das Betriebssystem z / OS (jüngster Nachkomme von MVS) bietet auch native Unterstützung für die Ausführung von POSIX- und Single UNIX-Spezifikationsanwendungen. Der Support begann mit MVS / SP V4R3, und IBM hat die UNIX 95-Zertifizierung für z / OS V1R2 und höher erhalten. [1]
Das System wird normalerweise in Unternehmen und im Bankwesen verwendet, und Anwendungen werden häufig verwendet in COBOL geschrieben. COBOL-Programme wurden traditionell mit Transaktionsverarbeitungssystemen wie IMS und CICS verwendet. Für ein Programm, das in CICS ausgeführt wird, werden spezielle EXEC CICS-Anweisungen in den COBOL-Quellcode eingefügt. Ein Präprozessor (Übersetzer) ersetzt die EXEC CICS-Anweisungen durch den entsprechenden COBOL-Code, um CICS aufzurufen, bevor das Programm kompiliert wird - nicht ganz anders als SQL, das zum Aufruf von DB2 verwendet wird. Anwendungen können auch in anderen Sprachen wie C, C ++, Java, Assembler, FORTRAN, BASIC, RPG und REXX geschrieben werden. Die Sprachunterstützung wird als übliche Komponente namens "Sprachumgebung" oder "LE" bereitgestellt, um einheitliches Debugging, Tracing, Profiling und andere sprachunabhängige Funktionen zu ermöglichen.
Auf MVS-Systeme wird traditionell über 3270-Terminals oder auf PCs mit 3270-Emulatoren zugegriffen. Viele Mainframe-Anwendungen verfügen jedoch heutzutage über benutzerdefinierte Web- oder GUI-Schnittstellen. Das Betriebssystem z / OS bietet eine integrierte Unterstützung für TCP / IP. Die Systemverwaltung, die in der Vergangenheit mit einem 3270-Terminal durchgeführt wurde, erfolgt jetzt über die Hardware Management Console (HMC) und zunehmend auch über Webschnittstellen. Operator-Konsolen werden über 2074-Emulatoren bereitgestellt. Es ist daher unwahrscheinlich, dass ein S / 390- oder zSeries-Prozessor mit einer echten 3270 angeschlossen ist.
Das systemeigene Zeichencodierungsschema von MVS und seiner Peripheriegeräte ist EBCDIC, aber der TR-Befehl machte es leicht, in andere 7- und 8-Bit-Codes zu übersetzen. Im Laufe der Zeit fügte IBM hardwarebeschleunigte Services hinzu, um Übersetzungen in und zwischen größeren Codes durchzuführen, hardwarespezifische Services für Unicode-Transformationen und Softwareunterstützung, z. B. ASCII, ISO / IEC 8859, UTF-8, UTF-16 und UTF-32 . Die Software-Übersetzungsdienste verwenden Quell- und Zielcodeseiten als Eingaben.
MVS-Dateisystem [ edit ]
Dateien werden in MVS ordnungsgemäß als Datensätze bezeichnet. Die Namen dieser Dateien sind in Katalogen organisiert, die selbst VSAM-Dateien sind.
Datensatznamen (DSNs, Mainframe-Begriff für Dateinamen) sind in einer Hierarchie organisiert, deren Ebenen durch Punkte getrennt sind, z. "DEPT01.SYSTEM01.FILE01". Jede Ebene in der Hierarchie kann bis zu acht Zeichen lang sein. Die Gesamtlänge des Dateinamens beträgt maximal 44 Zeichen einschließlich Punkten. Normalerweise werden die durch Punkte getrennten Komponenten dazu verwendet, Dateien ähnlich wie Verzeichnisse in anderen Betriebssystemen zu organisieren. Beispielsweise gab es Hilfsprogramme, die ähnliche Funktionen wie Windows Explorer ausführten (jedoch ohne GUI und normalerweise im Stapelverarbeitungsmodus) - neue Elemente hinzugefügt, umbenannt oder gelöscht und alle Inhalte eines angegebenen Elements gemeldet. Im Gegensatz zu vielen anderen Systemen sind diese Ebenen jedoch normalerweise keine [NB 4] tatsächlichen Verzeichnisse, sondern lediglich eine Namenskonvention (wie das ursprüngliche Macintosh-Dateisystem, bei dem die Ordnerhierarchie eine vom Finder verwaltete Illusion war). TSO unterstützt ein Standardpräfix für Dateien (ähnlich einem "aktuellen Verzeichnis" -Konzept), und RACF unterstützt die Einrichtung von Zugriffssteuerungen basierend auf Dateinamensmustern, analog zu Zugriffssteuerungen für Verzeichnisse auf anderen Plattformen.
Wie bei anderen Mitgliedern der Betriebssystemfamilie waren die Datensätze von MVS rekordorientiert. MVS hat drei Haupttypen von seinen Vorgängern geerbt:
- Sequentielle Datensätze wurden normalerweise von Anfang bis Ende Datensatz für Datensatz gelesen.
- Bei BDAM-Datensätzen (Direktzugriff) musste das Anwendungsprogramm den physischen Ort der Daten angeben, auf die er zugreifen wollte Versatz vom Anfang des Datensatzes aus.)
- In ISAM-Datensätzen wurde ein bestimmter Abschnitt jedes Datensatzes als Schlüssel definiert, der als Schlüssel zum Nachschlagen bestimmter Datensätze verwendet werden kann. Der Schlüssel bestand oft aus mehreren Feldern, die jedoch zusammenhängend und in der richtigen Reihenfolge sein mussten. und Schlüsselwerte mussten eindeutig sein. Daher könnte eine IBM ISAM-Datei nur einen Schlüssel haben, der dem Primärschlüssel einer relationalen Datenbanktabelle entspricht. ISAM konnte Fremdschlüssel nicht unterstützen.
Sequentielle und ISAM-Datensätze können entweder Datensätze mit fester oder variabler Länge speichern, und alle Typen können mehr als ein Festplatten-Volume belegen.
Alle basieren auf der VTOC-Plattenstruktur.
Frühe IBM Datenbankverwaltungssysteme verwendeten verschiedene Kombinationen von ISAM- und BDAM-Datasets - normalerweise BDAM für die eigentliche Datenspeicherung und ISAM für Indizes.
In den frühen 70er Jahren des letzten Jahrhunderts führten die Betriebssysteme für virtuelle Arbeitsspeicher von IBM die neue Dateiverwaltungskomponente VSAM ein, die ähnliche Möglichkeiten bot:
- Entry-Sequenced Datasets (ESDS) stellten ähnliche Funktionen bereit wie sequenzielle und BDAM-Datensätze, da sie entweder von Anfang bis Ende oder direkt durch Angabe eines Versatzes vom Start aus gelesen werden konnten.
- Schlüsselsequenzierte Datensätze ( KSDS) waren ein bedeutendes Upgrade von ISAM: Sie erlaubten sekundäre Schlüssel mit nicht eindeutigen Werten und Schlüssel, die durch Verketten nicht zusammenhängender Felder in beliebiger Reihenfolge gebildet wurden. Die durch Überlaufdatensätze in ISAM verursachten Leistungsprobleme wurden erheblich reduziert. und sie reduzierten das Risiko, dass ein Software- oder Hardwarefehler während einer Indexaktualisierung den Index beschädigen könnte, erheblich.
Diese VSAM-Formate bildeten die Grundlage für die Datenbankverwaltungssysteme von IBM, IMS / VS und DB2 - in der Regel ESDS Datenspeicher und KSDS für Indizes.
VSAM enthielt auch eine Katalogkomponente, die für den Hauptkatalog von MVS verwendet wird.
Partitionierte Datensätze (PDS) waren sequentielle Datensätze, die in "Mitglieder" unterteilt waren, die als sequenzielle Dateien selbst verarbeitet werden konnten. Die wichtigste Verwendung von PDS war für Programmbibliotheken. Systemadministratoren nutzten die Haupt-PDS, um einem Projekt Speicherplatz zuzuweisen, und das Projektteam erstellte und bearbeitete die Mitglieder.
Generationsdatengruppen (GDGs) waren ursprünglich für die Unterstützung von Sicherungsprozeduren für Großvater, Vater und Sohn vorgesehen. Wenn eine Datei geändert wurde, wurde die geänderte Version zum neuen "Sohn", der vorherige "Sohn" wurde zum "Vater", der Der bisherige "Vater" wurde zum "Großvater" und der vorherige "Großvater" wurde gestrichen. Man könnte jedoch GDGs mit mehr als drei Generationen einrichten, und einige Anwendungen verwendeten GDGs, um Daten aus verschiedenen Quellen zu sammeln und die Informationen einem Programm zuzuführen. Jedes Sammlungsprogramm erzeugte eine neue Generation der Datei und das abschließende Programm las die gesamte Gruppe als einzelne sequentielle Datei (indem keine Generierung in der JCL angegeben wird).
Moderne Versionen von MVS (z. B. z / OS) unterstützen auch POSIX-kompatible "Slash" -Dateisysteme sowie Möglichkeiten zur Integration der beiden Dateisysteme. Das Betriebssystem kann also ein MVS-Dataset als Datei für ein POSIX-Programm oder ein Subsystem erscheinen lassen. Zu diesen neueren Dateisystemen gehören das hierarchische Dateisystem (HFS) (nicht zu verwechseln mit Apples Hierarchischem Dateisystem) und zFS (nicht zu verwechseln mit Suns ZFS).
Programme, die auf Computern im Netzwerk (z. B. AS / 400) ausgeführt werden, können lokale Datenverwaltungsschnittstellen verwenden, um auf VSAM-datensatzorientierte Dateien mithilfe von Client-Server-Produkten, die gemäß der Distributed Data Management Architecture implementiert sind, transparent zu erstellen, zu verwalten und auf sie zuzugreifen (DDM). DDM ist auch die Basisarchitektur für den MVS DB2-Server, der die Distributed Relational Database Architecture (DRDA) implementiert.
Geschichte und Moderne [ edit ]
MVS ist jetzt Teil von z / OS, ältere MVS-Versionen werden von IBM nicht mehr unterstützt und seit 2007 nur noch 64-Bit-z / OS Releases werden unterstützt. Neben 64-Bit-Anwendungen unterstützt z / OS ältere 24-Bit- und 31-Bit-MVS-Anwendungen.
MVS-Releases von bis zu 3,8j (24-Bit, 1981 veröffentlicht) waren frei verfügbar, und es ist jetzt möglich, die MVS-Version 3.8j in Mainframe-Emulatoren kostenlos auszuführen.
MVS / 370 [ edit ]
MVS / 370 ist ein Oberbegriff für alle Versionen des MVS-Betriebssystems vor MVS / XA [NB 5] ] Die System / 370-Architektur unterstützte zum Zeitpunkt der Veröffentlichung von MVS nur virtuelle 24-Bit-Adressen, sodass die Architektur des MVS / 370-Betriebssystems auf einer 24-Bit-Adresse basiert. Aufgrund dieser 24-Bit-Adresslänge erhalten Programme, die unter MVS / 370 ausgeführt werden, jeweils 16 MB zusammenhängenden virtuellen Speicher.
MVS / XA oder Multiple Virtual Storage / Erweiterte Architektur war eine Version von MVS, die die 370-XA-Architektur unterstützte, die Adressen von 24 Bit auf 31 Bit erweiterte und eine 2 bereitstellte Gigabyte-Adressierbarer Speicherbereich. [2] Außerdem wurde ein älterer 24-Bit-Adressierungsmodus (dh, der eine 24-Bit-Adresse in den unteren 24 Bit eines 32-Bit-Wortes gespeichert hat, ein älterer 24-Bit-Adressierungsmodus unterstützt und die oberen 8 verwendet Bits dieses Wortes für andere Zwecke).
MVS / ESA [ edit ]
MVS / ESA: MVS Enterprise System Architecture. Version von MVS, erstmals im Februar 1988 als MVS / SP Version 3 eingeführt. Ende 1995 durch / umbenannt in OS / 390 und anschließend als z / OS.
MVS / ESA OpenEdition: Upgrade auf Version 4 Release 3 von MVS / ESA wurde im Februar 1993 mit Unterstützung für POSIX und andere Standards angekündigt. [3][4][5] Während der Erstveröffentlichung nur das National Institute of Standards and Technology zur Verfügung stand (NIST) -Zertifizierung für die Einhaltung des Federal Information Processing Standard (FIPS) 151, wurden nachfolgende Releases auf höheren Ebenen und von anderen Organisationen zertifiziert, z X / Open und sein Nachfolger, The Open Group. Es enthielt etwa 1 Million neue Codezeilen, die eine API-Shell, Dienstprogramme und eine erweiterte Benutzeroberfläche bereitstellen. Arbeitet mit einem hierarchischen Dateisystem, das von DFSMS (Data Facility System Managed Storage) bereitgestellt wird. Die Shell und die Hilfsprogramme basieren auf den InterOpen-Produkten von Mortice Kerns. Unabhängige Spezialisten schätzen, dass es zu über 80% mit offenen Systemen kompatibel war - mehr als bei den meisten Unix-Systemen. Die Unterstützung für DCE2 wurde im Februar 1994 angekündigt, und im März 1995 wurden zahlreiche Anwendungsentwicklungstools veröffentlicht. Seit Mitte 1995, als alle offenen Funktionen zu einem Standardbestandteil von Vanilla MVS / ESA SP Version 5 Release 1 wurden, hat IBM die Trennung von OpenEdition und dem Betriebssystem eingestellt. Unter OS / 390 wurde es zu UNIX System Services und hat diesen Namen unter z / OS beibehalten.
Ende 1995 bündelte IBM MVS mit mehreren Programmprodukten und änderte den Namen von MVS / ESA in OS / 390.
Die aktuelle Version von MVS wird als z / OS vermarktet.
[ edit ]
Die japanischen Mainframe-Hersteller Fujitsu und Hitachi haben sowohl MVS-Quellcode als auch interne Dokumentation des 20. Jahrhunderts wiederholt und unrechtmäßig in einem der berühmtesten Fälle des 20. Jahrhunderts erhalten Industriespionage. [6] Fujitsu verließ sich bei seinem MSP-Mainframe-Betriebssystem stark auf den Code von IBM, und Hitachi tat dies auch beim Betriebssystem VOS3. MSP und VOS3 wurden stark in Japan vermarktet, wo sie immer noch einen erheblichen Anteil an der Mainframe-Installationsbasis halten, in gewissem Umfang aber auch in anderen Ländern, insbesondere in Australien. Sogar IBMs Fehler und Dokumentationsfehler wurden originalgetreu kopiert. IBM kooperierte mit dem US-amerikanischen Bureau of Investigation in einer Sting-Operation und versorgte Fujitsu und Hitachi widerwillig mit proprietären MVS- und Mainframe-Hardwaretechnologien im Verlauf mehrjähriger Ermittlungen, die in den frühen achtziger Jahren ihren Höhepunkt erreichten - Untersuchungen, die leitende Unternehmensmanager und sogar einige Japaner betrafen Regierungsbeamte. Amdahl war jedoch nicht an Fujitsus Diebstahl von IBMs geistigem Eigentum beteiligt. Jegliche Kommunikation von Amdahl an Fujitsu erfolgte über "Amdahl Only-Spezifikationen", die sorgfältig von jeglicher IBM-IP-Adresse oder jeglichen Verweisen auf IBM-IPs gereinigt wurden.
Im Anschluss an die Ermittlungen erreichte IBM mit Fujitsu und Hitachi mehrere Millionen US-Dollar-Siedlungen, die über viele Jahre beträchtliche Bruchteile der Gewinne beider Unternehmen sammelten. Aus zuverlässigen Berichten geht hervor, dass die Siedlungen 500.000.000 US-Dollar überstiegen. Zitat erforderlich ] [6]: Die Aussage des Kongresses am Ende sagt nur: "Hitachi muss noch zugeben, dass einer von IBMs Bericht Geheimnisse wurden bei der Entwicklung neuer Produkte verwendet, und sie haben IBM noch nicht für die enormen Kosten entschädigt, die mit der Beilegung des Falls verbunden sind. "
Die drei Unternehmen haben sich schon längst vielen Joint Ventures einig . Im Jahr 2000 haben IBM und Hitachi beispielsweise gemeinsam an der Entwicklung des IBM z900-Mainframemodells gearbeitet.
Aufgrund dieses historischen Kopierens werden MSP und VOS3 ordnungsgemäß als "Gabeln" von MVS klassifiziert, und viele Drittanbieter von Softwareanbietern mit MVS-kompatiblen Produkten waren in der Lage, MSP- und VOS3-kompatible Versionen mit geringen oder keinen Modifikationen zu produzieren. [7] [8] [9]
Als IBM im Jahr 2000 seine 64-Bit-z / Architecture-Mainframes vorstellte, führte IBM auch den 64-Bit z / OS-Betriebssystem, der direkte Nachfolger von OS / 390 und MVS. Fujitsu und Hitachi entschieden sich nicht für die Lizenzierung von z / Architecture von IBM für ihre Quasi-MVS-Betriebssysteme und -Hardersysteme. Daher halten MSP und VOS3, obwohl sie nominell von ihren Herstellern unterstützt werden, die meisten architektonischen Einschränkungen von MVS aus den 80er Jahren bis heute aufrecht. Da z / OS noch immer Anwendungen und Technologien der MVS-Ära unterstützt, enthält z / OS zwar immer noch den Großteil des Codes von MVS, auch wenn er im Laufe der Jahrzehnte der Evolution stark verbessert und verbessert wurde. Anwendungen (und Betriebsverfahren), die auf MSP und VOS3 ausgeführt werden, können zu z wechseln / OS viel einfacher als zu anderen Betriebssystemen.
Siehe auch [ edit ]
- ^ Einige Druckmedien verwendeten die singuläre MVS / System-Erweiterung: Computerworld, 15. Dezember 1980 - Seite 5; 26. Juni 1978 - Seite 8
- ^ Einige Prozessoren benötigen möglicherweise mehr physischen Speicher als die Größe eines einzelnen Adressraums, aber immer noch viel weniger als die Gesamtgröße des virtuellen Speichers eines typischen Workloads.
- ^ [19659102] Via Job Entry Subsystem 3 (JES3)
- ^ Die Ausnahmen sind meistens CVOL- und Benutzerkatalogaliasnamen am Anfang eines Datensatznamens.
- ^ OS / VS2 Release 2 bis 3.8, MVS / SE und MVS / SP Version 1
Referenzen [ edit ]
- Bob DuCharme: "Das Handbuch zu Betriebssystemen", Teil 06: MVS (hier online verfügbar)
- OS / VS2-MVS-Übersicht (PDF) . Erste Ausgabe. IBM. Juni 1978. GC28-0984-0. Nach dem Original (PDF) am 16. März 2011 archiviert.
No comments:
Post a Comment