Vielfache Virtuelle Lagerung, allgemeiner genannter MVS, war das meistens verwendete Betriebssystem auf dem System/370 und System/390 Großrechner-Computer von IBM. Es wurde von IBM entwickelt, aber ist zum anderen Großrechner von IBM Betriebssysteme, z.B, VSE, VM ohne Beziehung.

Zuerst veröffentlicht 1974 wurde MVS durch Programm-Produkte mit neuen Namen mehrmals, zuerst zu MVS/SE (Systemerweiterung), neben MVS/SP (Systemprodukt) Version 1, neben MVS/XA (erweiterte Architektur), neben MVS/ESA (Unternehmenssystemarchitektur), neben OS/390 und schließlich zu z/OS erweitert (als 64-Bit-Unterstützung mit den zSeries Modellen hinzugefügt wurde). IBM hat Unterstützung von Unix (ursprünglich genannte OFFENE AUSGABE) in MVS/SP V4.3 hinzugefügt und hat POSIX und Zertifikate von Unix an mehreren verschiedenen Niveaus erhalten. Der Kern von MVS bleibt im Wesentlichen dasselbe Betriebssystem. Durch das Design, Programme, die für MVS geschrieben sind, der auf dem modifikationsfreien z/OS geführt ist.

An erstem IBM beschriebener MVS als einfach eine neue Ausgabe von OS/VS2, aber war es tatsächlich ein Major schreibt um. OS/VS2 Ausgabe 1 war eine Steigung von OS/360 MVT, der den grössten Teil des ursprünglichen Codes und wie MVT behalten hat, im Monteur hauptsächlich geschrieben wurde. Der MVS Kern wurde fast im Monteur XF völlig geschrieben, obwohl einige Module in PL/S, aber nicht den mit der Leistung empfindlichen, insbesondere nicht der Oberaufseher des Eingangs/Produktion (ein/Ausgabe-Steuersystem) geschrieben wurden. Der Gebrauch von IBM von "OS/VS2" hat aufwärts Vereinbarkeit betont: Anwendungsprogramme, die unter MVT gelaufen sind, haben das Wiederkompilieren nicht sogar gebraucht, um unter MVS zu laufen. Dieselben Job-Betriebssprache-Dateien konnten unverändert verwendet werden; Dienstprogramme und andere Nichtkernmöglichkeiten wie TSO sind unverändert gelaufen. IBM und Benutzer haben fast einmütig das neue System MVS vom Anfang genannt, und IBM hat fortgesetzt, den Begriff MVS im Namengeben von späteren Hauptversionen wie MVS/XA zu gebrauchen.

Evolution von MVS

OS/360 MFT (mit einer Festgelegten Zahl von Aufgaben Stark mehrbeanspruchend), das zur Verfügung gestellte Mehrbeschäftigen: Mehrere Speicherteilungen, jede einer festen Größe, wurden aufgestellt, als das Betriebssystem installiert wurde, und als der Maschinenbediener sie wiederdefiniert hat. Zum Beispiel konnte es eine kleine Teilung, zwei mittlere Teilungen und eine große Teilung geben. Wenn es zwei große Programme gäbe, die bereit sind zu laufen, würde man bis zu anderes beendetes warten müssen und hat die große Teilung frei gemacht.

OS/360 MVT (mit einer Variablen Zahl von Aufgaben Stark mehrbeanspruchend), war eine Erhöhung, die weiter Speichergebrauch raffiniert hat. Anstatt Speicherteilungen der festen Größe zu verwenden, hat MVT Gedächtnis zu Gebieten für Arbeitsschritte, wie erforderlich, zugeteilt, vorausgesetzt dass genug aneinander grenzendes physisches Gedächtnis verfügbar war. Das war ein bedeutender Fortschritt über das Speichermanagement von MFT, aber hatte einige Schwächen: Wenn ein Job Gedächtnis dynamisch zugeteilt hat (als die meisten Sorte-Programme und Datenbankverwaltungssysteme tun), mussten die Programmierer die maximale Speichervoraussetzung des Jobs schätzen und sie für MVT vorherbestimmen. Ein Arbeitsschritt, der eine Mischung von kleinen und großen Programmen enthalten hat, hat Gedächtnis vergeudet, während die kleinen Programme gelaufen sind. Am ernstlichsten konnte Gedächtnis gebrochen werden, d. h. das durch aktuelle Jobs nicht verwendete Gedächtnis konnte in nutzlos kleine Klötze zwischen den Gebieten geteilt werden, die durch aktuelle Jobs verwendet sind, und das einzige Heilmittel sollte auf einige aktuelle vor dem Starten irgendwelcher neuen beendete Jobs warten.

Am Anfang der 1970er Jahre hat sich IBM bemüht, diese Schwierigkeiten durch das Einführen virtuellen Gedächtnisses zu lindern (den IBM "virtuelle Lagerung" genannt hat), der Programmen erlaubt hat, um Adressräume zu bitten, die größer sind als physisches Gedächtnis. Die ursprünglichen Durchführungen hatten einen einzelnen virtuellen Adressraum, der durch alle Jobs geteilt ist. OS/VS1 war OS/360 MFT innerhalb eines einzelnen virtuellen Adressraums; OS/VS2 SVS war OS/360 MVT innerhalb eines einzelnen virtuellen Adressraums. So hatten OS/VS1 und SVS im Prinzip dieselben Nachteile wie MFT und MVT, aber die Einflüsse waren weniger streng, weil Jobs um viel größere Adressräume bitten konnten und die Bitten aus einer 16 Lache von MiB gekommen sind, selbst wenn physische Lagerung kleiner war.

|align = "Zentrum" | die Ansicht einer Anwendung

Mitte der 1970er Jahre hat IBM MVS eingeführt, der nicht nur virtuelle Lagerung unterstützt hat, die größer war als die verfügbare echte Lagerung, wie SVS getan hat, sondern auch einer unbestimmten Zahl von Anwendungen erlaubt hat, in verschiedenen Adressräumen zu laufen. Zwei gleichzeitige Programme könnten versuchen, auf dieselbe virtuelle Speicheradresse zuzugreifen, aber das virtuelle Speichersystem hat diese Bitten zu verschiedenen Gebieten des physischen Gedächtnisses umadressiert. Jeder dieser Adressräume hat aus drei Gebieten bestanden: Ein Betriebssystem (ein Beispiel, das durch alle Jobs geteilt ist), ein Anwendungsgebiet, das für jede Anwendung und ein geteiltes virtuelles Gebiet einzigartig ist, das zu verschiedenen Zwecken einschließlich der Zwischenjob-Kommunikation verwendet ist. IBM hat versprochen, dass Anwendungsgebiete immer mindestens 8 Mb sein würden. Das hat MVS die vollkommene Lösung für Geschäftsprobleme gemacht, die sich aus dem Bedürfnis ergeben haben, mehr Anwendungen zu führen.

MVS hat in einer Prozession gehendes Potenzial durch die Versorgung mehrprogrammierend und die Mehrverarbeitung von Fähigkeiten maximiert. Wie sein MVT und OS/VS2 SVS Vorgänger hat MVS Mehrprogrammierung unterstützt; Programm-Instruktionen und vereinigte Daten stehen durch ein Kontrollprogramm und gegebene in einer Prozession gehende Zyklen auf dem Plan. Verschieden von einer einzelnen Programmierung Betriebssystem maximieren diese Systeme den Gebrauch des in einer Prozession gehenden Potenzials durch das Teilen von in einer Prozession gehenden Zyklen unter den Instruktionen, die mit mehreren vereinigt sind, verschieden gleichzeitig laufende Programme. Auf diese Weise muss das Kontrollprogramm nicht auf die Eingabe/Ausgabe-Operation warten, um vor dem Verfahren zu vollenden. Durch die Durchführung der Instruktionen für vielfache Programme ist der Computer im Stande, hin und her zwischen aktiven und untätigen Programmen umzuschalten.

Frühe Ausgaben von MVS (Mitte der 1970er Jahre) waren unter der ersten von der Reihe von IBM OS, um Mehrverarbeiter-Konfigurationen zu unterstützen, obwohl die M65MP Variante von OS/360, der auf 360 Modellen 65 und 67 läuft, beschränkte Mehrverarbeiter-Unterstützung zur Verfügung gestellt hatte. Das 360 Modell 67 hatte auch den Mehrverarbeiter fähiger TSS/360, MTS und BEDIENUNGSFELD 67 Betriebssysteme veranstaltet. Weil Mehrverarbeitung von Systemen Instruktionen gleichzeitig durchführen kann, bieten sie größere in einer Prozession gehende Macht an als einzeln in einer Prozession gehendes System. Infolgedessen ist MVS im Stande gewesen, die durch das Bedürfnis verursachten Geschäftsprobleme zu richten, große Datenmengen zu bearbeiten.

In einer Prozession mehrgehende Systeme werden entweder lose verbunden, was bedeutet, dass jeder Computer Zugang zu einem allgemeinen Arbeitspensum, oder dicht verbunden hat, was bedeutet, dass die Computer dieselbe echte Lagerung teilen und von einer einzelnen Kopie des Betriebssystems kontrolliert werden. MVS behalten sowohl die lose verbundene Mehrverarbeitung von Attached Support Processor (ASP) als auch die dicht verbundene Mehrverarbeitung der OS/360 Mehrverarbeitung des Modells 65. In dicht verbundenen Systemen haben zwei Zentraleinheiten gleichzeitigen Zugang zu demselben Gedächtnis (und Kopie des Betriebssystems) und Peripherie geteilt, größere in einer Prozession gehende Macht und einen Grad der anmutigen Degradierung zur Verfügung stellend, wenn eine Zentraleinheit gescheitert hat. In lose verbundenen Konfigurationen hatte jede einer Gruppe von Verarbeitern (einzeln und / oder dicht verbunden) sein eigenes Gedächtnis und Betriebssystem, aber hat Peripherie und den Betriebssystembestandteil geteilt JES3 hat erlaubt, die ganze Gruppe von einer Konsole zu führen. Das, vorausgesetzt dass größere Elastizität und Maschinenbediener hat entscheiden lassen, welcher Verarbeiter der Jobs von einer Hauptjob-Warteschlange laufen sollte. MVS JES3 hat Benutzern die Gelegenheit gegeben, zusammen zwei oder mehr in einer Prozession gehende Datensysteme über geteilte Platten und Channel-to-Channedl Adapter (CTCA'S) zu vernetzen. Diese Fähigkeit ist schließlich verfügbar für JES2 Benutzer als Multi-Access SPOOL (MAS) geworden.

MVS hat ursprünglich das 24-Bit-Wenden (d. h., bis zu 16 Mb) unterstützt. Als die zu Grunde liegende Hardware fortgeschritten ist, hat sie 31 Bit unterstützt (XA und ESA; bis zu 2048 Mb) und jetzt (als z/OS) das 64-Bit-Wenden. Die bedeutendsten Motive für die schnelle Steigung zum 31-Bit-Wenden waren das Wachstum von großen Transaktion bearbeitenden Netzen, die größtenteils von CICS kontrolliert sind, der in einem einzelnen Adressraum gelaufen ist — und das DB2 Verwandtschaftsdatenbankverwaltungssystem mehr als 8 Mb des Anwendungsadressraums gebraucht hat, um effizient zu laufen. (Frühe Versionen wurden in zwei Adressräume konfiguriert, die über das geteilte virtuelle Gebiet kommuniziert haben, aber das hat einen bedeutenden oben auferlegt, seitdem alle diese Kommunikationen hatten, übersenden über das Betriebssystem.)

Die Hauptbenutzerschnittstellen zu MVS sind: Job Control Language (JCL), die für die Gruppe-Verarbeitung, aber von den 1970er Jahren vorwärts ursprünglich entworfen wurde, wurde auch verwendet, um Mittel interaktiven Langzeitjobs solcher CICS anzufangen und zuzuteilen; und TSO (Time-Sharing-Auswahl), die interaktive Time-Sharing-Schnittstelle, die hauptsächlich verwendet wurde, um Entwicklungswerkzeuge und einige Endbenutzer-Informationssysteme zu führen. ISPF ist eine TSO Anwendung für Benutzer auf 3270-Familien-Terminals (und später, auf VM ebenso), der dem Benutzer erlaubt, dieselben Aufgaben wie die Befehl-Linie von TSO zu vollbringen, aber in einem Menü und Form hat Weise, und mit einem vollen Schirm-Redakteur und Dateibrowser orientiert. Die grundlegende Schnittstelle von TSO ist Befehl-Linie, obwohl Möglichkeiten später für Form-gesteuerte Schnittstellen hinzugefügt wurden).

MVS hat einen Hauptschritt vorwärts in der Schuld-Toleranz gemacht, hat früher STAE Möglichkeit aufgebaut, dass IBM Softwarewiederherstellung genannt hat. IBM hat sich dafür entschieden, das nach Jahren der praktischen wirklichen Erfahrung mit MVT in der Geschäftswelt zu tun. Systemausfälle hatten jetzt Haupteinflüsse auf Kundengeschäfte, und IBM hat sich dafür entschieden, einen Hauptdesignsprung zu nehmen, anzunehmen, dass trotz der sehr besten Softwareentwicklungs- und Probetechniken, dass 'Probleme vorkommen WERDEN.' Diese tiefe Annahme war im Hinzufügen großer Prozentsätze des Codes der Schuld-Toleranz zum System zentral, aber hat wahrscheinlich zum Erfolg des Systems im Dulden der Software und Hardware-Misserfolge beigetragen. Statistische Information ist hart zu kommen durch, den Wert dieser Designeigenschaften zu beweisen (wie können Sie 'verhinderte' oder 'wieder erlangte' Probleme messen?), aber IBM, in vielen Dimensionen, hat diese mit der Schuld tolerante Softwarewiederherstellung und schnelle Problem-Entschlossenheitseigenschaften mit der Zeit erhöht.

Dieses Design hat eine Hierarchie von fehlerbehandelnden Programmen, im System (Kern/'privileged') Weise, genannt Funktionelle Wiederherstellungsroutinen, und im Benutzer ('Aufgabe' oder 'Problem-Programm') Weise, genannt "ESTAE" angegeben (Erweiterte Angegebene Aufgabe Anomale Ausgangsroutinen), die angerufen wurden, im Falle dass das System einen Fehler (wirklich, Hardware-Verarbeiter oder Lagerungsfehler oder Softwarefehler) entdeckt hat. Jede Wiederherstellungsroutine hat die 'Hauptstrecke' reinvokable fungieren lassen, gewonnener Fehler diagnostische Daten, die genügend sind, um beim Verursachen-Problem und irgendeinem die Fehler zu beseitigen, 'neu verhandelt' (rufen Sie die Hauptstrecke wiederan), oder ist (eskalierter Fehler 'durchgesickert', zur folgenden Wiederherstellungsroutine in der Hierarchie in einer Prozession gehend).

So mit jedem Fehler hat das System diagnostische Daten gewonnen und hat versucht, eine Reparatur durchzuführen und das System aufrechtzuerhalten. Das schlechteste mögliche Ding war, einen Benutzeradressraum (ein 'Job') im Fall von unreparierten Fehlern abzunehmen. Obwohl es ein anfänglicher Designpunkt war, erst als die neuste MVS Version (z/OS), dieses Wiederherstellungsprogramm nicht nur versichert wurde, hat seine eigene Wiederherstellungsroutine, aber jede Wiederherstellungsroutine jetzt seine eigene Wiederherstellungsroutine. Diese Wiederherstellungsstruktur wurde im grundlegenden MVS-Kontrollprogramm eingebettet, und Programmiermöglichkeiten sind verfügbar und durch Anwendungsprogramm-Entwickler und 3. Parteientwickler verwendet.

Praktisch hat die MVS Softwarewiederherstellung Problem gemacht, sowohl leichter als auch schwieriger die Fehler beseitigend. Softwarewiederherstellung verlangt, dass Programme 'Spuren' dessen verlassen, wo sie sind, und was sie tun, so erleichternd die Fehler beseitigend — aber die Tatsache, dass die Verarbeitung von Fortschritten trotz eines Fehlers die Spuren überschreiben kann. Die frühe Datum-Festnahme zur Zeit des Fehlers maximiert das Beseitigen, und Möglichkeiten bestehen für die Wiederherstellungsroutinen (Aufgabe und Systemweise, beide), um das zu tun.

IBM hat zusätzliche Kriterien für ein Hauptsoftwareproblem eingeschlossen, das Dienst von IBM verlangt hat. Wenn ein Hauptstrecke-Bestandteil gescheitert hat, Softwarewiederherstellung zu beginnen, die als ein gültiger wiedertragbarer Misserfolg betrachtet wurde. Außerdem, wenn eine Wiederherstellungsroutine gescheitert hat, bedeutende diagnostische solche Daten zu sammeln, dass das ursprüngliche Problem durch durch diese Wiederherstellungsroutine gesammelte Daten lösbar war, haben Standards von IBM diktiert, dass diese Schuld wiedertragbare und erforderliche Reparatur war. So haben Standards von IBM, wenn streng angewandt, dauernde Verbesserung gefördert.

IBM hat auf Verlangen Hyperschirm, ein Hauptbrauchbarkeitswerkzeug genannt Dynamic Support System (DSS) in der ersten Ausgabe von MVS eingeführt. Diese Möglichkeit konnte angerufen werden, um eine Sitzung zu beginnen, um diagnostische Verfahren zu schaffen, oder bereits versorgte Verfahren anzurufen. Die Verfahren haben spezielle Ereignisse, wie das Laden eines Programms, Gerät-Eingabe/Ausgabe, Systemverfahren-Anrufe 'gefangen', und haben dann die Aktivierung der vorher definierten Verfahren ausgelöst. Diese Verfahren, die rekursiv angerufen werden konnten, haben das Lesen und das Schreiben von Daten und die Modifizierung des Instruktionsflusses berücksichtigt. Programm-Ereignis-Aufnahme-Hardware wurde verwendet. Wegen der Gemeinkosten dieses Werkzeugs wurde es von kundenverfügbaren MVS Systemen entfernt. Ausnutzung von Program-Event Recording (PER) wurde durch die Erhöhung des diagnostischen "GLEIT"-Befehls mit der Einführung PRO Unterstützung (GLEITEN/PRO) in SU 64/65 (1978) durchgeführt.

Vielfache Kopien von MVS (oder anderer IBM Betriebssysteme) konnten den teilen

dieselbe Maschine, wenn diese Maschine von VM/370 kontrolliert wurde. In diesem Fall war VM/370 das echte Betriebssystem, und hat den "Gast" Betriebssysteme als Anwendungen mit ungewöhnlich hohen Vorzügen betrachtet. Infolge späterer Hardware-Erhöhungen konnte ein Beispiel eines Betriebssystems (entweder MVS oder VM mit Gästen oder anderem) auch eine Logische Teilung (LPAR) statt eines kompletten physischen Systems besetzen.

Vielfache MVS Beispiele können organisiert und insgesamt in einer Struktur genannt einen Systemkomplex oder sysplex, eingeführt im September 1990 verwaltet werden. Beispiele zwischenfunktionieren durch einen Softwarebestandteil genannt eine Quer-Systemkopplungsmöglichkeit (XCF), und ein Hardware-Bestandteil hat eine Hardware-Kopplungsmöglichkeit (VGL oder Einheitliche Kopplungsmöglichkeit, ICF, wenn co-located auf derselben Großrechner-Hardware) genannt. Vielfacher sysplexes kann über Standardnetzprotokolle wie Eigentumssystems Network Architecture (SNA) von IBM oder mehr kürzlich über TCP/IP angeschlossen werden. Der z/OS Betriebssystem (der neuste Nachkomme von MV) hat auch heimische Unterstützung, um POSIX Anwendungen durchzuführen.

Dateien werden Dateien in MVS richtig genannt. Namen jener Dateien werden in Katalogen organisiert, die VSAM Dateien selbst sind.

Das heimische Verschlüsselungsschema von MVS und seiner Peripherie ist Großer Endian EBCDIC, aber mit der Zeit hat IBM Hardware-beschleunigte Dienstleistungen hinzugefügt, Übersetzung und Unterstützung von ASCII, Wenig Endian und Unicode durchzuführen.

MVS filesystem

Datei-Namen (DSNs, Großrechner-Begriff für Dateinamen) werden in einer Hierarchie organisiert, deren Niveaus mit Punkten z.B getrennt werden" DEPT01. SYSTEM01. FILE01". Jedes Niveau in der Hierarchie kann bis zu acht Charaktere lange sein. Die Gesamtdateinamenlänge ist ein Maximum von 44 Charakteren einschließlich Punkte. Durch die Tagung werden die durch die Punkte getrennten Bestandteile verwendet, um Dateien ähnlich zu Verzeichnissen in anderen Betriebssystemen zu organisieren. Zum Beispiel gab es Dienstprogramme, die ähnliche Funktionen für diejenigen des Windows-Forschers (aber ohne den GUI und gewöhnlich in der Gruppe-Verarbeitungsweise) - das Hinzufügen, die Umbenennung oder das Löschen neuer Elemente und das Melden des ganzen Inhalts eines angegebenen Elements durchgeführt haben. Jedoch, unterschiedlich in vielen anderen Systemen, sind diese Niveaus nicht wirkliche Verzeichnisse, aber gerade eine Namengeben-Tagung (wie das ursprüngliche Dateisystem von Macintosh, wo Mappe-Hierarchie ein Trugbild war, das vom Finder aufrechterhalten ist). TSO unterstützt ein Verzug-Präfix für Dateien (ähnlich einem "aktuellen" Verzeichniskonzept), und RACF-Unterstützungen, die Zugriffssteuerungen aufstellen, die auf Dateinamenmustern gestützt sind, die Zugriffssteuerungen auf Verzeichnissen auf anderen Plattformen analog sind.

Als mit anderen Mitgliedern der OS Familie wurden die Dateien von MV rekordorientiert. MVS hat drei Haupttypen von seinen Vorgängern geerbt:

• Folgende Dateien wurden normalerweise eine Aufzeichnung auf einmal von Anfang bis zum Ende gelesen.
• In BDAM (direkter Zugang) Dateien musste das Anwendungsprogramm die physische Position der Daten angeben, auf die es (gewöhnlich durch das Spezifizieren des Ausgleichs vom Anfang der Datei) hat zugreifen wollen.
• In ISAM Dateien wurde eine angegebene Abteilung jeder Aufzeichnung als ein Schlüssel definiert, der als ein Schlüssel verwendet werden konnte, spezifische Aufzeichnungen nachzuschlagen. Der Schlüssel hat ganz häufig aus vielfachen Feldern bestanden, aber diese mussten aneinander grenzend sein und in der richtigen Ordnung; und Schlüsselwerte mussten einzigartig sein. Folglich konnte eine Datei von IBM ISAM nur einen Schlüssel haben, der zum primären Schlüssel eines Verwandtschaftsdatenbanktisches gleichwertig ist; ISAM konnte Auslandsschlüssel nicht unterstützen.

Folgend und ISAM konnte datasets entweder Aufzeichnungen der festen Länge oder variablen Länge versorgen, und alle Typen konnten mehr als ein Plattenvolumen besetzen.

Alle von diesen basieren auf der VTOC Plattenstruktur.

Frühe Datenbankverwaltungssysteme von IBM haben verschiedene Kombinationen von ISAM und BDAM datasets - gewöhnlich BDAM für die wirkliche Datenlagerung und ISAM für Indizes verwendet.

Am Anfang der 1970er Jahre das virtuelle Gedächtnis von IBM haben Betriebssysteme einen neuen Dateiverwaltungsbestandteil, VSAM eingeführt, der ähnliche Möglichkeiten zur Verfügung gestellt hat:

• Zugang-Sequenced Datasets (ESDS) hat Möglichkeiten zur Verfügung gestellt, die denjenigen sowohl dessen ähnlich sind, folgenden als auch BDAM datasets, seitdem sie entweder von Anfang bis Ende oder direkt durch das Spezifizieren eines Ausgleichs vom Anfang gelesen werden konnten.
• Schlüssel-Sequenced Datasets (KSDS) war eine Hauptsteigung von ISAM: Sie haben sekundäre Schlüssel mit nichteinzigartigen Werten und gebildete Schlüssel erlaubt, indem sie aneinander nichtgrenzende Felder in jeder Ordnung verkettet haben; sie haben außerordentlich die Leistungsprobleme reduziert, die durch Überschwemmungsaufzeichnungen in ISAM verursacht sind; und sie haben außerordentlich die Gefahr reduziert, dass eine Software oder Hardware-Misserfolg in der Mitte einer Index-Aktualisierung den Index verderben könnten.

Diese VSAM-Formate sind die Basis der Datenbankverwaltungssysteme von IBM, IMS/VS und DB2 - gewöhnlich ESDS für die wirkliche Datenlagerung und KSDS für Indizes geworden.

VSAM hat auch einen für den Master-Katalog von MV verwendeten Katalogbestandteil eingeschlossen.

Verteilte datasets (PDS) waren folgender datasets, der in "Mitglieder" unterteilt ist, die als folgende Dateien in ihrem eigenen Recht bearbeitet werden konnten. Der wichtigste Gebrauch von PDS war für Programm-Bibliotheken - Systemverwalter haben den wichtigen PDS als eine Weise verwendet, Speicherplatz einem Projekt und der Projektmannschaft dann geschaffen zuzuteilen, und haben die Mitglieder editiert.

Generation Data Groups (GDGs) wurde ursprünglich entworfen, um Aushilfsverfahren des Großvaters-Vaters-Sohnes zu unterstützen - wenn eine Datei modifiziert wurde, ist die geänderte Version der neue "Sohn" geworden, der vorherige "Sohn" ist der "Vater" geworden, der vorherige "Vater" ist der "Großvater" geworden, und der vorherige "Großvater" wurde gelöscht. Aber man konnte GDGs mit sehr mehr als 3 Generationen aufstellen, und einige Anwendungen haben GDGs verwendet, um Daten von mehreren Quellen zu sammeln und die Information zu einem Programm zu füttern - jedes sich versammelnde Programm hat eine neue Generation der Datei geschaffen, und das Endprogramm hat die ganze Gruppe als eine einzelne folgende Datei gelesen (indem es eine Generation im JCL nicht angegeben worden ist).

Moderne Versionen von MVS (z.B, z/OS) unterstützen auch POSIX-vereinbaren "Hieb" filesystems zusammen mit Möglichkeiten, für die zwei filesystems zu integrieren. D. h. der OS kann einen MVS dataset machen erscheinen als eine Datei zu einem POSIX Programm oder Subsystem. Diese neueren filesystems schließen Hierarchical File System (HFS) ein (um mit dem Hierarchischen Dateisystem des Apfels nicht verwirrt zu sein), und zFS (um mit dem ZFS der Sonne nicht verwirrt zu sein).

Geschichte und Modernität

MVS ist jetzt ein Teil von z/OS, ältere MVS-Ausgaben werden von IBM nicht mehr unterstützt, und seit 2007 werden nur 64 Bit z/OS Ausgaben unterstützt. Z/OS-Unterstützungen, die MVS ältere 24-bit- und 31-Bit-Anwendungen neben 64-Bit-Anwendungen führen.

MVS Ausgaben bis zu 3.8j (24 Bit, veröffentlicht 1981) waren frei verfügbar, und es ist jetzt möglich, den MVS 3.8j Ausgabe in Großrechner-Emulatoren umsonst zu führen.

MVS/370

MVS/370 ist ein Oberbegriff für alle Versionen von MVS Betriebssystem vor MVS/XA. Die Architektur des Systems/370 zurzeit wurde MVS veröffentlicht, hat nur 24 Bit virtuelle Adressen unterstützt, so basiert der MVS/370 Betriebssystemarchitektur auf einer 24-Bit-Adresse. Wegen dieser 24-Bit-Adresslänge werden Programme, die unter MVS/370 laufen, jeder 16 Megabytes der aneinander grenzenden virtuellen Lagerung gegeben.

MVS/XA

MVS/XA, oder Vielfache Virtuelle Lagerung / Verlängerte Architektur, war eine Version von MVS, der die 370-XA Architektur unterstützt hat, die Adressen von 24 Bit bis 31 Bit ausgebreitet hat, 2 Gigabytes addressable Speicherbereich zur Verfügung stellend. Es hat auch eine 24-Bit-Vermächtnis-Wenden-Weise für ältere 24-Bit-Anwendungen unterstützt (d. h. diejenigen, die eine 24-Bit-Adresse in den niedrigeren 24 Bit eines 32-Bit-Wortes versorgt haben und die oberen 8 Bit dieses Wortes zu anderen Zwecken verwertet haben).

MVS/ESA

MVS/ESA: MVS Unternehmenssystemarchitektur. Version von MVS, zuerst eingeführt als MVS/SP Version 3 im Februar 1988. Ersetzt durch/umbenannt als OS/390 im späten 1995 und nachher als z/OS.

MVS/ESA OpenEdition: Befördern Sie zur Ausgabe 3 der Version 4 von MVS/ESA hat Februar 1993 mit der Unterstützung für POSIX und andere Standards bekannt gegeben. Während die anfängliche Ausgabe nur Nationales Institut für Standards und Technologie (NIST) Zertifikat für Federal Information Processing Standard (FIPS) 151 Gehorsam hatte, wurden nachfolgende Ausgaben an höheren Niveaus und von anderen Organisationen z.B bescheinigt. X/Open und sein Nachfolger, Open Group. Es hat ungefähr 1 Million neue Linien des Codes eingeschlossen, die eine API-Schale, Dienstprogramme und eine verlängerte Benutzerschnittstelle zur Verfügung stellen. Arbeiten mit einem hierarchischen Dateisystem, das durch DFSMS (Datenmöglichkeitssystem Geführte Lagerung) zur Verfügung gestellt ist. Die Schale und Dienstprogramme basieren auf Zapfenloch-Kerns Produkte von InterOpen. Unabhängige Fachmänner rechnen damit, dass es mehr als 80 % offen systementgegenkommend — mehr waren als die meisten Systeme von Unix. DCE2 unterstützen bekannt gegebenen Februar 1994 und viele Anwendungsentwicklungswerkzeuge im März 1995. Mitte 1995 IBM hat angefangen aufzuhören, OpenEdition als eine getrennte Entität als alle offenen Eigenschaften zu kennzeichnen, ist ein Standardteil der Vanille MVS/ESA SP Ausgabe 1 der Version 5 geworden. Unter OS/390 ist es UNIX System Services geworden, und hat diesen Namen unter z/OS behalten.

Nah verwandte Betriebssysteme

Japanische Großrechner-Hersteller Fujitsu und Hitachi sowohl wiederholt als auch der MVS Quellcode von ungesetzlich erhaltenem IBM und innere Dokumentation in einem der berühmtesten Fälle des 20. Jahrhunderts der Industriespionage. Fujitsu hat sich schwer auf den Code von IBM in seinem MSP Großrechner Betriebssystem verlassen, und ebenfalls hat Hitachi für seinen VOS3 Betriebssystem dasselbe gemacht. MSP und VOS3 wurden in Japan schwer auf den Markt gebracht, wo sie noch einen wesentlichen Anteil des Großrechners installierte Basis, sondern auch zu einem gewissen Grad in anderen Ländern, namentlich Australien halten. Sogar die Programmfehler von IBM und falsches Dokumentationsbuchstabieren wurden treu kopiert. IBM hat mit der amerikanischen Amerikanischen Bundespolizei in einer Stachel-Operation zusammengearbeitet, ungern Fujitsu und Hitachi mit Eigentums-MVS und Großrechner-Hardware-Technologien während des Kurses von Mehrjahr-Untersuchungen versorgend, die am Anfang der 1980er Jahre - Untersuchungen kulminieren, die ältere Firmenbetriebsleiter und sogar einige japanische Staatsangestellte hineingezogen haben. Amdahl wurde jedoch am Diebstahl von Fujitsu des geistigen Eigentums von IBM nicht beteiligt. Irgendwelche Kommunikationen von Amdahl bis Fujitsu waren durch "Amdahl Nur Spezifizierungen", die jedes IBM IP oder irgendwelcher Verweisungen auf den IP von IBM skrupulös gereinigt wurden.

Nachfolgend auf die Untersuchungen hat IBM die Ansiedlungen von Mehrmillion Dollar sowohl mit Fujitsu als auch mit Hitachi erreicht, wesentliche Bruchteile der Gewinne der beider Gesellschaften viele Jahre lang sammelnd. Zuverlässige Berichte zeigen an, dass die Ansiedlungen um 500,000,000 US$ zu weit gegangen sind. Die drei Gesellschaften haben schon lange vielem gemeinsamem geschäftlichem Unterfangen freundlich zugestimmt. Zum Beispiel 2002 haben IBM und Hitachi am Entwickeln des Großrechner-Modells von IBM z800 zusammengearbeitet.

Wegen dieses historischen Kopierens werden MSP und VOS3 als "Gabeln" von MVS richtig klassifiziert, und viele Drittsoftwareverkäufer mit MVS-vereinbaren Produkten sind im Stande gewesen, MSP- und VOS3-vereinbare Versionen mit wenig oder keiner Modifizierung zu erzeugen.

Als IBM seine 64 Bit z/Architecture Großrechner das Jahr 2000 eingeführt hat, hat IBM auch die 64 Bit z/OS Betriebssystem, der direkte Nachfolger von OS/390 und MVS eingeführt. Fujitsu und Hitachi haben sich dafür entschieden, den z/Architecture von IBM für ihren quasi-MVS Betriebssysteme und Hardware-Systeme nicht zu lizenzieren, und so erhalten MSP und VOS3, während noch nominell unterstützt, durch ihre Verkäufer, die meisten 1980er Jahre des MVS architektonische Beschränkungen bis zu den heutigen Tag aufrecht. Seitdem z/OS unterstützt noch MVS-Zeitalter-Anwendungen und Technologien - tatsächlich, z/OS enthält noch den grössten Teil des Codes von MVS, obgleich außerordentlich erhöht und verbessert im Laufe Jahrzehnte der Evolution - Anwendungen (und betriebliche Verfahren), auf MSP und VOS3 laufend, können sich zu z/OS viel leichter bewegen als zu anderen Betriebssystemen.

Siehe auch

• Herkules ein S/370, S/390 und zSeries Emulator, der dazu fähig ist, MVS zu führen
• Dienstprogramme, die mit MVS (und Nachfolger) Betriebssysteme geliefert sind
• BatchPipes ist ein Gruppe-Job-Verarbeitungsdienstprogramm, das für den MVS/ESA Betriebssystem, und alle später incarnations-OS/390 und z/OS entworfen ist.

Referenzen

• Bob DuCharme: "Das Betriebssystemhandbuch, Teil 06: MVS" (verfügbar online hier)

Außenverbindungen

• IBM: Z/OS V1R11.0 MVS Handbücher
• IBM: Z/OS V1R8.0 MVS Handbücher
• MVS: Das Betriebssystem, das die Welt behält, die geht
• MVS... eine lange Geschichte
• Funktionelle Struktur von IBM virtuelle Lagerung zweiter Betriebssystemteil: OS/VS2-2 Konzepte und Philosophien durch A. L. Scherr