MVs

多重仮想記憶 (MVS)

開発者	IBM
書かれた	アセンブラ（XF）、PL/S
OSファミリー	オペレーティングシステム
初回リリース	1974年; 50年前 （1974年）
マーケティングターゲット	IBM メインフレーム コンピュータ
利用可能	英語
プラットフォーム	システム/370、システム/390
影響を受けた	TSS
ライセンス	独自仕様 最初は無料
先行	OS/VS2 (SVS)
後継者	MVS/SE、MVS/SP、MVS/XA、MVS/ESA、OS/390、z/OS

多重仮想記憶(MVS ) は、 System/370、System/390、IBM Z IBM メインフレーム コンピュータで最も一般的に使用されているオペレーティング システムです。IBM は、 OS/360の後継として、OS/VS1およびSVSとともに MVS を開発しました。これは、 VSE、VM、TPFなどの IBM の他のメインフレーム オペレーティング システム ラインとは無関係です。

1974 年に初めてリリースされた MVS は、新しい名前のプログラム製品によって何度も拡張されましたが、命名法では MVS という用語が保持されています。

• 最初はMVS/SE（MVS/System Extensions）、^{[NB 1]}
• MVS/SP (MVS/システム製品) バージョン1の横に、
• MVS/XA (MVS/eXtended Architecture) の横に、
• MVS/ESA (MVS/エンタープライズ システム アーキテクチャ) の横に、

そして延長

• System/390システムの場合はOS/390へ、
• 最終的にz/OSに移行しました( zSeriesモデルで64 ビットサポートが追加されたとき)。IBM は MVS/SP V4.3 で UNIX サポート (当初はOpenEdition MVSと呼ばれていました) を追加し、 IEEE、X/Open、The Open GroupからさまざまなレベルでPOSIXおよびUNIX™ の認定を取得しました。MVS のコアは基本的に同じオペレーティング システムのままです。設計上、MVS 用に作成されたプログラムは変更せずに z/OS で実行できます。

当初 IBM は MVS を単にOS/VS2の新リリースと説明していたが、実際には大幅な書き直しであった。OS/VS2 リリース 1 はOS/360 MVTのアップグレード版であり、元のコードの大半が保持され、MVT と同様に主にアセンブリ言語で記述されている。MVS コアはほぼ完全にアセンブラ XFで記述されているが、いくつかのモジュールはPL/Sで記述されているが、パフォーマンス重視のモジュール、特に入出力スーパーバイザ(IOS) は PL/S で記述されていない。IBM が「OS/VS2」を使用したのは上位互換性を重視したためである。MVT で実行されていたアプリケーション プログラムは、MVS で実行するために再コンパイルする必要さえなかった。同じジョブ制御言語ファイルを変更せずに使用でき、ユーティリティやTSOなどのコア以外の機能は変更せずに実行できた。IBM とユーザーは、当初からほぼ一致してこの新しいシステムを MVS と呼び、IBM はその後のメジャーバージョン (MVS/XA など) の命名でもMVSという用語を使用し続けた。

OS/360 MFT (固定数のタスクによるマルチプログラミング) ^[1]は、マルチプログラミングを提供します。オペレーティングシステムのインストール時およびオペレータが再定義したときに、それぞれが固定サイズの複数のメモリパーティションが設定されます。たとえば、小さなパーティション、2 つの中規模のパーティション、および大きなパーティションが 1 つあるとします。実行可能な 2 つの大きなプログラムがある場合、一方のプログラムは、もう一方のプログラムが終了して大きなパーティションが空くまで待機する必要があります。OS/360 R19 では、MFT サブタスク (マルチタスク) が追加されました。これは、ジョブが ATTACH マクロを使用して新しいタスクを動的に作成する機能です。

OS/360 MVT (Multiprogramming with a Variable number of Tasks) ^{[1] は}、メモリの使用をさらに改良した拡張機能でした。MVT は、固定サイズのメモリ パーティションを使用する代わりに、連続した物理メモリが十分にある限り、必要に応じてジョブ ステップの領域にメモリを割り当てます。これは MFT のメモリ管理に比べて大幅に進歩していますが、いくつか弱点があります。ジョブがメモリを動的に割り当てる場合(ほとんどのソートプログラムやデータベース管理システムがそうであるように)、プログラマーはジョブの最大メモリ要件を見積もり、MVT 用に事前に定義する必要があります。小さなプログラムと大きなプログラムが混在するジョブ ステップでは、小さなプログラムの実行中にメモリが浪費されます。最も深刻なのは、メモリが断片化される可能性があることです。つまり、現在のジョブで使用されていないメモリが、現在のジョブが使用する領域間で無駄に小さなチャンクに分割される可能性があり、唯一の解決策は、現在のジョブのいくつかが終了するまで待ってから新しいジョブを開始することだけでした。

1970 年代初頭、IBM は仮想メモリ(IBM は「仮想ストレージ」と呼んでいた) を導入することでこれらの問題を軽減しようとしました。これにより、プログラムは物理メモリよりも大きなアドレス空間を要求できるようになりました。元の実装では、すべてのジョブで共有される単一の仮想アドレス空間がありました。OS/VS1 は単一の仮想アドレス空間内の OS/360 MFT であり、OS/VS2 SVS は単一の仮想アドレス空間内の OS/360 MVT でした。したがって、OS/VS1 と SVS は原理的には MFT や MVT と同じ欠点がありましたが、ジョブとオペレーターが 2 KiB の粒度 (OS/VS1 の場合) のはるかに大きなパーティションまたは 4 KiB の粒度 (SVS の場合) の領域を要求でき、物理ストレージが小さくても 16MiB のアドレス空間から要求が行われるため、影響はそれほど深刻ではありません。 OS/360 MVT と同様に、SVS の TSO ユーザーはログイン処理中に TSO 領域に割り当てられ、同じ領域に割り当てられた他のユーザーと競合します。そのスワップインおよびスワップアウトのロジックは、基本的に MVT の TSO と同じです。

1970 年代半ばに IBM は MVS を発表しました。MVS は、SVS と同様に、利用可能な実ストレージよりも大きい仮想ストレージをサポートしただけでなく、^{[NB 2]}異なるアドレス空間で不特定多数のアプリケーションを実行できるようにしました。2 つの同時プログラムが同じ仮想メモリ アドレスにアクセスしようとしても、仮想メモリ システムによってこれらの要求が物理メモリの異なる領域にリダイレクトされました。これらの各アドレス空間は、オペレーティング システム (すべてのジョブで 1 つのインスタンスを共有)、アプリケーションごとに固有のアプリケーション領域、ジョブ間通信などのさまざまな目的で使用される共有仮想領域の 3 つの領域で構成されていました。IBM は、アプリケーション領域は常に少なくとも 8 MB であると約束しました。これにより、MVS は、より多くのアプリケーションを実行する必要があることから生じるビジネス上の問題に対する完璧なソリューションとなりました。

MVS は、マルチプログラミングとマルチプロセッシング機能を提供することで、処理能力を最大限に引き出しました。^[2] MVTやOS/VS2 SVSの前身と同様に、MVS はマルチプログラミングをサポートしていました。プログラム命令と関連データは、制御プログラムによってスケジュールされ、処理サイクルが与えられます。単一プログラミングのオペレーティングシステムとは異なり、これらのシステムは、複数の異なる同時実行プログラムに関連付けられた命令間で処理サイクルを分割することで、処理能力を最大限に活用します。このようにして、制御プログラムは、処理を進める前に I/O 操作が完了するのを待つ必要がありません。複数のプログラムの命令を実行することで、コンピューターはアクティブなプログラムと非アクティブなプログラムを切り替えることができます。

MVS の初期版 (1970 年代中頃) は、マルチプロセッサ構成をサポートする最初の IBM OS シリーズの 1 つですが、360 モデル 65 および67で実行される OS/360 の M65MP バリアントは、限定的なマルチプロセッサ サポートを提供していました。360 モデル 67 は、マルチプロセッサ対応のTSS/360、MTS、およびCP-67オペレーティング システムもホストしていました。マルチプロセッシング システムは命令を同時に実行できるため、シングルプロセッシング システムよりも処理能力が高くなります^{(説明が必要)}。その結果、MVS は、大量のデータを処理する必要性によって生じるビジネス上の問題に対処することができました。

マルチプロセッシング システムは、各コンピュータが共通の作業負荷にアクセスできる疎結合か、またはコンピュータが同じ実ストレージを共有し、オペレーティング システムの単一のコピーによって制御される密結合のいずれかです。^{[説明が必要] MVS は、}接続サポート プロセッサ(ASP) ^{[NB 3]}の 疎結合マルチプロセッシングとOS/360 モデル 65 マルチプロセッシングの密結合マルチプロセッシングの両方を保持していました。密結合システムでは、2 つの CPU が同じメモリ (およびオペレーティング システムのコピー) と周辺機器への同時アクセスを共有し、1 つの CPU に障害が発生した場合に処理能力が向上し、ある程度の段階的な低下が起こりました。疎結合構成では、プロセッサ グループ (単一または密結合) のそれぞれが独自のメモリとオペレーティング システムを持ちましたが、周辺機器は共有され、オペレーティング システム コンポーネントJES3によって 1 つのコンソールからグループ全体を管理できました。これにより回復力が高まり、オペレーターは中央のジョブ キューからどのジョブをどのプロセッサで実行するかを決定できました。 MVS JES3 は、共有ディスクとチャネル間アダプタ (CTCA) を介して 2 つ以上のデータ処理システムをネットワークで接続する機会をユーザーに提供しました。この機能は最終的に、マルチアクセス SPOOL (MAS) として JES2 ユーザーに提供されるようになりました。 ^{[引用が必要]}

MVS は当初、24 ビットアドレッシング (つまり、最大 16 MB) をサポートしていました。基盤となるハードウェアが進化するにつれて、31 ビット(XA および ESA、最大 2048 MB) がサポートされ、現在は (z/OS として) 64 ビット アドレッシングをサポートしています。31 ビット アドレッシングへの急速なアップグレードの最も重要な動機は、主にCICSによって制御され、単一のアドレス空間で実行される大規模なトランザクション処理ネットワークの増加でした。また、DB2 リレーショナル データベース管理システムを効率的に実行するには、8 MB を超えるアプリケーション アドレス空間が必要でした。(初期のバージョンは、共有仮想領域を介して通信する 2 つのアドレス空間に構成されていましたが、このような通信はすべてオペレーティング システムを介して送信されていたため、大きなオーバーヘッドが発生しました。)

MVS の主なユーザー インターフェースは、ジョブ制御言語(JCL) です。これは、もともとバッチ処理用に設計されましたが、1970 年代以降は、CICSなどの長時間実行される対話型ジョブを開始してリソースを割り当てるためにも使用されました。TSO (Time Sharing Option)は、対話型タイム シェアリングインターフェースで、主に開発ツールやいくつかのエンド ユーザー情報システムを実行するために使用されました。ISPFは、 3270 ファミリー端末 (後に VM も)のユーザー向けの TSO アプリケーションです。ISPF を使用すると、ユーザーは TSO のコマンド ラインと同じタスクをメニューとフォーム指向の方法で実行でき、フル スクリーン エディターとファイル ブラウザーを使用できます。TSO の基本インターフェースはコマンド ラインですが、 ISPFなどの機能が後にフォーム駆動型インターフェース用に追加されたことがあります。^[3]

MVS は、IBM がソフトウェア リカバリーと呼んでいた以前の STAE 機能に基づいて、フォールト トレランスにおいて大きな前進を遂げました。IBM は、ビジネスの世界で MVT を実際に何年も使用した後、これを実行することを決定しました。システム障害が顧客のビジネスに大きな影響を与えるようになったため、IBM は設計を大幅に変更し、最高のソフトウェア開発およびテスト技術にもかかわらず「問題は必ず発生する」と想定することにしました。この深い想定は、フォールト トレランス コードをシステムに追加する上で極めて重要であり、ソフトウェアおよびハードウェア障害に対するシステムの耐性向上に貢献したと考えられます。これらの設計機能の価値を証明する統計情報を入手するのは困難ですが (「防止された」または「回復された」問題をどうやって測定できるでしょうか)、IBM は、さまざまな側面で、これらのフォールト トレラント ソフトウェア リカバリー機能と迅速な問題解決機能を長年にわたって強化してきました。

この設計では、システム (カーネル/「特権」) モードでは機能回復ルーチンと呼ばれるエラー処理プログラムの階層、ユーザー (「タスク」または「問題プログラム」) モードでは「ESTAE」(拡張指定タスク異常終了ルーチン) と呼ばれるエラー処理プログラムの階層が指定されており、これらはシステムがエラー (ハードウェア プロセッサまたはストレージ エラー、またはソフトウェア エラー) を検出した場合に呼び出されます。各回復ルーチンは、「メインライン」機能を再呼び出し可能にし、原因となっている問題をデバッグするのに十分なエラー診断データをキャプチャし、「再試行」(メインラインを再呼び出し) または「パーコレート」(階層内の次の回復ルーチンにエラー処理をエスカレート) します。

したがって、システムはエラーが発生するたびに診断データを取得し、修復を実行してシステムを稼働させようとします。修復されないエラーの場合、最悪の事態はユーザー アドレス スペース (「ジョブ」) がダウンすることです。これは初期の設計ポイントでしたが、最新の MVS バージョン (z/OS) になって初めて、リカバリ プログラムに独自のリカバリ ルーチンが保証されるだけでなく、各リカバリ ルーチンに独自のリカバリ ルーチンが備わりました。このリカバリ構造は基本的な MVS 制御プログラムに組み込まれ、プログラミング機能が利用可能になり、アプリケーション プログラム開発者やサード パーティ開発者が使用できるようになりました。

実際には、MVS ソフトウェア リカバリによって、問題のデバッグが容易になると同時に困難になりました。ソフトウェア リカバリでは、プログラムが現在位置と実行内容の「トラック」を残す必要があるため、デバッグが容易になりますが、エラーが発生しても処理が進行すると、トラックが上書きされる可能性があります。エラー発生時に早期にデータを取得すると、デバッグが最大限に行われ、リカバリ ルーチン (タスク モードとシステム モードの両方) でこれを行うための機能が用意されています。

IBM は、IBM サービスを必要とする重大なソフトウェア問題に関する追加基準を設けました。メインライン コンポーネントがソフトウェア回復を開始できなかった場合、それは有効な報告対象障害とみなされました。また、回復ルーチンが重要な診断データを収集できず、その回復ルーチンによって収集されたデータによって元の問題が解決できる場合、IBM 標準では、この障害は報告対象であり、修復が必要であると規定されました。このように、IBM 標準を厳密に適用すると、継続的な改善が促進されました。

IBM は、OS/VS1 および OS/VS2 リリース 1 で導入した主要な保守ツールであるダイナミック サポート システム^[4] (DSS) のサポートを継続しました。この対話型機能を呼び出すと、診断プロシージャを作成するセッションを開始したり、すでに格納されているプロシージャを呼び出したりできます。プロシージャは、プログラムのロード、デバイス I/O、システム プロシージャ コールなどの特別なイベントをトラップし、以前に定義されたプロシージャのアクティブ化をトリガーします。これらのプロシージャは再帰的に呼び出すことができ、データの読み取りと書き込み、および命令フローの変更が可能です。プログラム イベント記録ハードウェアが使用されました。

IBM は、プログラム製品 OS/VS2 MVS/System Extensions (MVS/SE)、プログラム番号 5740-XEl に必要な OS/VS2 リリース 3.7 のアップデートである Selectable Unit 7 (SU7) による DSS のサポートを中止しました。ユーザー グループSHARE は、 IBM が DSS を復活させるという要件を可決し、IBM はMVS/SE のインストール後に DSS を使用できるように PTFを提供しました。

IBM は、MVS/SE リリース 2 に必要な OS/VS2 リリース 3.8 のアップデートである SU64 で、再び DSS のサポートを中止しました。

プログラム イベント記録 (PER) の利用は、SU 64/65 (1978) での PER サポート (SLIP/Per) の導入による診断 SLIP コマンドの拡張によって実行されました。

VM/370によって制御されているマシンであれば、MVS (または他の IBM オペレーティング システム) の複数のコピーが同じマシンを共有できます。この場合、VM/370 が実際のオペレーティング システムであり、「ゲスト」オペレーティング システムを非常に高い権限を持つアプリケーションと見なします。その後のハードウェアの機能強化により、オペレーティング システムの 1 つのインスタンス (MVS、ゲスト付き VM、またはその他のもの) が、物理システム全体ではなく、 論理パーティション(LPAR) を占有することも可能になりました。

複数の MVS インスタンスは、1990 年 9 月に導入されたシステム コンプレックスまたはシスプレックスと呼ばれる構造で編成され、まとめて管理できます。インスタンスは、クロス システム カップリング ファシリティー(XCF) と呼ばれるソフトウェア コンポーネントとハードウェアカップリング ファシリティー(CF、または同じメインフレーム ハードウェア上に共存する場合は統合カップリング ファシリティー、ICF) と呼ばれるハードウェア コンポーネントを介して相互運用されます。複数のシスプレックスは、IBM 独自のシステム ネットワーク アーキテクチャー(SNA) などの標準ネットワーク プロトコル、または最近ではTCP/IPを介して結合できます。z/OS オペレーティング システム (MVS の最新の子孫)には、 POSIXおよびSingle UNIX 仕様アプリケーションを実行するためのネイティブ サポートもあります。このサポートは MVS/SP V4R3 から開始され、IBM は z/OS V1R2 以降で UNIX 95 認定を取得しました。^[5]

このシステムは通常、ビジネスや銀行業務で使用され、アプリケーションはCOBOLで記述されることが多いです。 COBOL プログラムは、従来、 IMSやCICSなどのトランザクション処理システムで使用されていました。 CICS で実行されるプログラムの場合、特別な EXEC CICS ステートメントが COBOL ソース コードに挿入されます。プリプロセッサ (トランスレータ) は、プログラムをコンパイルする前に、それらの EXEC CICS ステートメントを適切な COBOL コードに置き換えて CICS を呼び出します。これは、DB2 を呼び出すために使用されるSQLとまったく同じです。アプリケーションは、 C、C++、Java、アセンブリ言語、FORTRAN、BASIC、RPG、REXXなどの他の言語で記述することもできます。言語サポートは、「言語環境」または「LE」と呼ばれる共通コンポーネントとしてパッケージ化されており、統一されたデバッグ、トレース、プロファイリング、およびその他の言語に依存しない機能を可能にします。

MVS システムには、従来、3270 端末または 3270 エミュレーターを実行する PC からアクセスしていました。しかし、最近の多くのメインフレーム アプリケーションには、カスタムWebまたはGUIインターフェースがあります。z/OS オペレーティング システムには、TCP/IPのサポートが組み込まれています。以前は 3270 端末で行われていたシステム管理は、現在ではハードウェア管理コンソール (HMC) を介して行われ、Web インターフェースもますます増えています。オペレーター コンソールは 2074 エミュレーターを介して提供されるため、実際の 3270 が接続された S/390 または zSeries プロセッサーを目にすることはほとんどありません。

MVS とその周辺機器のネイティブ文字エンコード方式はEBCDICですが、 TR 命令により、他の 7 ビットおよび 8 ビット コードへの変換が容易になりました。IBM は、時間の経過とともに、より大きなコードへの変換やより大きなコード間の変換を実行するハードウェア アクセラレーション サービス、Unicode 変換用のハードウェア固有のサービス、およびASCII、ISO/IEC 8859、UTF-8、UTF-16、UTF-32などのソフトウェア サポートを追加しました。ソフトウェア変換サービスは、ソース コード ページと宛先コード ページを入力として受け取ります。

Unix ファイル以外のファイルは、 MVS ではデータ セットと呼ばれます。これらのファイルの名前は、 VSAMファイル自体であるカタログに整理されます。

データ セット名 (DSN、ファイル名のメインフレーム用語) は、レベルがドットで区切られた階層構造で編成されます (例: "DEPT01.SYSTEM01.FILE01")。階層の各レベルは、最大 8 文字までです。ファイル名の合計の長さは、ドットを含めて最大 44 文字です。慣例により、ドットで区切られたコンポーネントは、他のオペレーティング システムのディレクトリと同様に、ファイルを編成するために使用されます。たとえば、Windows エクスプローラと同様の機能(ただしGUIはなく、通常はバッチ処理モード) を実行するユーティリティ プログラムがあります。つまり、新しい要素の追加、名前の変更、または削除、および指定された要素のすべての内容の報告です。ただし、他の多くのシステムとは異なり、これらのレベルは通常^{[NB 4]}実際のディレクトリではなく、命名規則にすぎません (元のMacintosh ファイル システムのように、フォルダー階層は Finder によって維持される幻想でした)。TSO は、ファイルのデフォルト プレフィックス (「現在のディレクトリ」の概念に類似) をサポートし、RACF は、他のプラットフォームのディレクトリのアクセス制御と同様に、ファイル名パターンに基づくアクセス制御の設定をサポートします。

OS ファミリーの他のメンバーと同様に、MVS のデータ セットはレコード指向です。MVS は、その前身から 3 つの主要なタイプを継承しています。

• 通常、連続データ セットは最初から最後まで 1 レコードずつ読み取られます。
• BDAM (直接アクセス) データ セットでは、アプリケーション プログラムはアクセスするデータの物理的な場所を指定する必要がありました (通常は、データ セットの先頭からのオフセットを指定します)。
• ISAMデータ セットでは、各レコードの指定されたセクションがキーとして定義され、特定のレコードを検索するためのキーとして使用できます。キーは多くの場合、複数のフィールドで構成されますが、これらのフィールドは連続していて正しい順序である必要があり、キーの値は一意である必要があります。したがって、IBM ISAM ファイルには、リレーショナル データベーステーブルの主キーに相当するキーが 1 つしか存在できず、ISAM は外部キーをサポートできませんでした。

シーケンシャルおよび ISAM データセットには、固定長レコードまたは可変長レコードのいずれかを保存でき、すべてのタイプが複数のディスク ボリュームを占有できます。

これらはすべてVTOCディスク構造に基づいています。

初期の IBMデータベース管理システムでは、ISAM データセットと BDAM データセットのさまざまな組み合わせが使用されていました。通常、実際のデータ ストレージには BDAM が使用され、インデックスには ISAM が使用されていました。

1970 年代初頭、 IBM の仮想メモリオペレーティング システムでは、同様の機能を提供する新しいファイル管理コンポーネントVSAMが導入されました。

• エントリ シーケンス データセット (ESDS) は、最初から最後まで読み取ることも、先頭からのオフセットを指定して直接読み取ることもできるため、シーケンシャル データセットと BDAM データセットの両方と同様の機能を提供しました。
• キー シーケンス データセット (KSDS) は ISAM からのメジャー アップグレードです。KSDS では、一意でない値を持つセカンダリ キーと、連続していないフィールドを任意の順序で連結して形成されたキーが許可され、ISAM のオーバーフロー レコードによって発生するパフォーマンスの問題が大幅に軽減され、インデックス更新の途中でソフトウェアまたはハードウェアに障害が発生してインデックスが破損するリスクが大幅に軽減されました。

これらの VSAM 形式は、IBM のデータベース管理システム、IMS/VSおよびDB2の基礎となり、通常、実際のデータ ストレージには ESDS、インデックスには KSDS が使用されています。

VSAM には、ユーザー カタログと MVS のマスター カタログに使用されるカタログ コンポーネントも含まれていました。

パーティション データ セット (PDS) は、連続データ セットを「メンバー」に分割したもので、各メンバーは、それ自体で連続ファイルとして処理できます (ファイル システム内のフォルダーのように)。PDS の最も重要な用途は、プログラム ライブラリです。システム管理者は、メインの PDS を使用してプロジェクトにディスク領域を割り当て、プロジェクト チームがメンバーを作成および編集します。PDS のその他の用途としては、頻繁に使用されるジョブ制御プロシージャ (PROC) のライブラリや、複数のプログラムで使用されるレコード定義などのプログラミング言語ステートメントの「コピー ブック」があります。

世代データ グループ (GDG) は、同じ名前のデータセットのグループで、絶対世代番号または最新の世代からのオフセットで参照できます。これらは、もともと、祖父、父、息子のバックアップ手順をサポートするために設計されました。つまり、ファイルが変更されると、変更されたバージョンが新しい「息子」になり、以前の「息子」が「父」になり、以前の「父」が「祖父」になり、以前の「祖父」が削除されます。ただし、3 世代を超える GDG を設定することもでき、一部のアプリケーションでは、GDG を使用して複数のソースからデータを収集し、その情報を 1 つのプログラムに送ります。収集プログラムごとにファイルの新しい世代が作成され、最後のプログラムがグループ全体を 1 つのシーケンシャル ファイルとして読み取ります ( JCLで世代を指定しない)。

最新バージョンの MVS (z/OS など) は、データセットを Unix ファイルシステムのコンテナとして使用し、それらを部分的に統合する機能も備えています。つまり、 fopen() を使用する Unix プログラムは MVS データセットにアクセスでき、ユーザーは Unix ファイルをデータセットであるかのように割り当てることができますが、いくつかの^{[NB 5]}制限があります。階層ファイル システム(HFS) (Apple の階層ファイル システムと混同しないでください) は独自のタイプのデータセットを使用しますが、新しい z/OS ファイル システム (zFS) (Sun のZFSと混同しないでください) は VSAM 線形データ セット (LDS) を使用します。

ネットワークに接続されたコンピュータ ( IBM AS/400など) で実行されるプログラムは、分散データ管理アーキテクチャ(DDM)に従って実装されたクライアント サーバー製品を使用して、ローカル データ管理インターフェイスを使用して、VSAM レコード指向ファイルを透過的に作成、管理、およびアクセスできます。DDM は、分散リレーショナル データベース アーキテクチャ(DRDA) を実装する MVS DB2サーバーの基本アーキテクチャでもあります。

MVS には仮想 I/O (VIO) と呼ばれる機能が含まれており、これを使用すると、一時的なデータセットをページング データセット上のシミュレートされたトラックに格納できるため、割り当てのオーバーヘッドはなくなりますが、処理のオーバーヘッドがいくらか追加されます。

IBM は、OS/VS2 のリリースおよびサブリリースで追加された新機能に加えて、多数の無料の増分変更リリース (ICR) と選択可能ユニット (SU)、および有料のプログラム製品と現場開発プログラムを提供し、最終的に z/OS の一部として IBM にバンドルされました。これには次のものが含まれます。

• ACF/TCAM (5735-RCl)
• ACF/VTAM (5746-RC3、5735-RC2)
• データ機能/デバイス サポート (DF/DS)、5740-AM7
• データ機能拡張機能 (DF/EF)、5740-XYQ
• データ機能/データ セット サービス (DF/DSS)、5740-UT3。
• データ ファシリティ ソート、5740-SM1
• OS/VS2 MVS 拡張順次アクセス方式 (SAM-E)、5740-AM3
• MVS/370データ機能製品（DFP）、5665-295、代替
  • 5740-AM7 データ機能デバイスサポート (DFDS)
  • 5740-XYQ データ機能拡張機能 (DFEF)
  • 5740-AM3 シーケンシャル アクセス メソッド拡張 (SAM-E)
  • 5740-AM8 アクセス方式サービス暗号化オプション
  • 5748-UT2 オフライン 3800 ユーティリティ
• MVS/XA データ機能製品バージョン 1 リリース 1、5665-284
• MVS/XA データ機能製品バージョン 2 リリース 1、5665-XA2
• MVS/ESA データ機能製品バージョン 3、5665-XA3
• データ機能ストレージ管理サブシステム(DFSMS)、5695-DF1 は、
  DFP、DF/DSS、DF/HSM に代わるものです。
• OS/VS2 MVS TSO コマンド パッケージ (5740-XT6)
• TSO コマンド プロセッサ - FDP 5798-AYF (PRINT コマンド)
• TSO/VS2 プログラミング制御機能 - FDP 5798-BBJ
• TSOプログラミング制御機能 - II (PCF II)、FDP 5798-CLW、
• TSO 拡張機能は
  、TSO コマンド パッケージ、TSO コマンド プロセッサ、および PCF を置き換えます。
  • MVS/370 用 5665-285
  • MVS/XA 用 5665-293
  • 5685-025 MVS/XA
    用 REXX付き初版
• OS/VS2 MVS/システム拡張機能、5740-XEl
• MVS/システム製品
  • JES3 バージョン 1 5740-XYN
  • JES2 バージョン 1 5740-XYS
  • MVS/システム製品 - JES2 バージョン 2、5740-XC6
  • MVS/システム製品 - JES3 バージョン 2、5665-291
  • MVS/システム製品 - JES2 バージョン 3、5685-001
  • MVS/システム製品 - JES3 バージョン 3、5685-002
  • MVS/ESA システム製品: JES2 バージョン 4、5695-047
  • MVS/ESA システム製品: JES3 バージョン 4、5695-048
  • MVS/ESA システム製品: JES2 バージョン 5、5655-068
  • MVS/ESA システム製品: JES3 バージョン 5、5655-069

1970 年代後半から 1980 年代前半にかけて、IBM は次のような発表をしました。

• 5740-AM7 データ ファシリティ デバイス サポート (DF/DS)
• 5740-XYQ データ機能拡張機能 (DF/EF)
• 5740-AM3 シーケンシャル アクセス メソッド拡張 (SAM-E)
• 5740-AM8 アクセス方式サービス暗号化オプション
• 5748-UT2 オフライン 3800 ユーティリティ

DF/DS は新しいデバイス サポートを追加しましたが、IBM は、無料ベースにデバイス サポートを追加しないことを発表しました。DF/EF は、VSAM カタログと制御ボリューム (CVOL) の代替として改良カタログ構造 (ICF) を追加しましたが、信頼性の問題が山積していました。

IBMは^[6] MVS/SPバージョン2 (MVS/XA)を発表した際、1984年12月1日付けで販売を終了すると発表し、上記5つの製品の代替およびアップグレードとして^[7] Data Facility Product™ (DFP™)も発表しました。1983年6月7日に発表されたDFP/370リリース1 (プログラム番号5665-295)はMVS/SPバージョン1、MVS/SE、OS/VS2 R3.8用でオプションでしたが、MVS/Extended Architecture Data Facility Product (5665-284)はMVS/SPバージョン2 (MVS/XA)の必須ソフトウェアでした。データ管理機能の強化に加えて、DFPはリンケージエディターとユーティリティーの無料バージョンを置き換えました。

DFP は個別の製品としては利用できなくなり、DFSMSdfpという名前でData Facility Storage Management Subsystemの一部になりました。

MVS は現在、z/OS に進化しています。古い MVS リリースは IBM によってサポートされなくなり、2007 年以降は 64 ビットの z/OS リリースのみがサポートされています。z/OS は、古い 24 ビットおよび 31 ビットの MVS アプリケーションを新しい 64 ビット アプリケーションと並行して実行することをサポートしています。

MVSリリース3.8j（24ビット、1981年リリース）までは無料で入手でき、現在ではHercules EmulatorなどのメインフレームエミュレータでMVS 3.8jリリースを無料で実行できる 。^[8]

MVS/370 は、 MVS/XA より前のすべてのバージョンの MVS オペレーティング システムを表す一般的な用語です。^{[NB 6]} MVS がリリースされた時点での System/370 アーキテクチャは 24 ビットの仮想アドレスのみをサポートしていたため、MVS/370 オペレーティング システムのアーキテクチャは24ビットのアドレスに基づいています。この 24 ビットのアドレス長のため、MVS/370 で実行されるプログラムにはそれぞれ 16 MB の連続した仮想ストレージが与えられます。

MVS/XA、または多重仮想記憶/拡張アーキテクチャは、 370-XAアーキテクチャをサポートするMVSのバージョンでした。370 -XAアーキテクチャは新しいI/Oアーキテクチャを持ち、アドレスも24ビットから31ビットに拡張され、2 ギガバイトのアドレス指定可能なメモリ領域を提供しました。^[9] MVS/XAは、古い24ビットアプリケーション（つまり、32ビットワードの下位24ビットに24ビットアドレスを格納し、そのワードの上位8ビットを他の目的に使用するアプリケーション）用に24ビットのレガシーアドレッシングモードをサポートしていました。

MVS エンタープライズ システム アーキテクチャ( MVS/ESA ) は、S/370 エンタープライズ システム アーキテクチャ(S/370-ESA)をサポートするOS/390より前の MVS のバージョンです。MVS/ESA は、アドレス空間間の参照用にアクセス レジスタ (AR) モードを追加することで、MVS/XA の 24 ビットおよび 31 ビットのアドレス指定モードを拡張します。

IBMは1988年2月にMVS/ESAをMVS/SPバージョン3として^[10]導入し、その後MVS/ESA SPバージョン4 ^[11]とMVS/ESA SPバージョン5 ^[12]を導入した。IBMは1995年後半にこれをOS/390 ^{[13] [14]に置き換え、その後}z/OSに置き換えた。

MVS/ESA OpenEdition: 1993年2月^に 発表されたMVS/ESA SPのバージョン4リリース3へのアップグレード。POSIXおよびその他の標準をサポート。^{[15] [17] [18]最初のリリースでは、}連邦情報処理標準(FIPS)151準拠について米国国立標準技術研究所(NIST)の認定を受けただけだったが、その後のリリースでは、X/Openやその後継組織であるThe Open Groupなど、より高いレベルで他の組織によって認定された。約100万行の新しいコードが含まれており、APIシェル、ユーティリティ、および拡張ユーザーインターフェイスを提供している。DFSMS (Data Facility System Managed Storage)が提供する階層型ファイルシステムで動作する。シェルとユーティリティは、Mortice KernsのInterOpen製品に基づいている。独立した専門家は、これが80%以上オープンシステムに準拠していると推定している。これはほとんどのUnixシステムよりも高い。 DCE2のサポートは1994年2月に発表され、多くのアプリケーション開発ツールは1995年3月に発表されました。1995年半ばから、すべてのオープン機能が標準のMVS/ESA SPバージョン5リリース1の一部となったため、 IBMはOpenEditionをオペレーティングシステムと区別しなくなりました。OS /390 V2R6では、これはUNIX System Servicesとなり、^{[19] [20] 、} z/OSでもその名前が維持されました。

1995 年後半、IBM は MVS をいくつかのプログラム製品にバンドルし、名前を MVS/ESA から OS/390 に変更しました。

現在のレベルの MVS は z/OS として販売されています。

日本のメインフレームメーカーである富士通と日立は、20世紀で最も有名な産業スパイ事件の一つで、 IBMのMVSのソースコードと内部文書を繰り返し違法に入手した。^{[21]富士通は}MSPメインフレームオペレーティングシステムでIBMのコードに大きく依存しており、同様に日立もVOS3オペレーティングシステムで同じことをしていた。MSPとVOS3は日本で大々的に宣伝され、現在でもメインフレームのインストールベースのかなりの部分を占めているが、他の国々、特にオーストラリアでもある程度宣伝されている。IBMのバグや文書のスペルミスさえも忠実にコピーされた。IBMは米国連邦捜査局のおとり捜査に協力し、1980年代初頭に最高潮に達した数年にわたる捜査の過程で、富士通と日立に独自のMVSとメインフレームのハードウェア技術を渋々提供した。この捜査には、会社の上級管理職や日本政府関係者も関与していた。しかし、アムダールは富士通による IBM の知的財産の窃盗には関与していませんでした。アムダールから富士通への通信はすべて「アムダール専用仕様」を通じて行われ、IBM の知的財産や IBM の知的財産への言及は徹底的に排除されていました。

調査の結果、IBMは富士通と日立の両社と数百万ドルの和解に達し、両社の利益の相当部分を長年にわたって回収した。信頼できる報告によると、和解金は5億ドルを超えたという。^{[要出典] [21] [NB 7]}

3 社は以前から多くの共同事業に友好的に合意してきました。たとえば、2000 年には IBM と日立が IBM z900 メインフレーム モデルの開発で協力しました。

この歴史的なコピーにより、MSPとVOS3はMVSの「フォーク」として適切に分類され、MVS互換製品を持つ多くのサードパーティソフトウェアベンダーは、ほとんどまたはまったく変更せずにMSPおよびVOS3互換バージョンを作成することができました。^{[22] [23] [24]}

IBM は 2000 年に 64 ビットのz/Architectureメインフレームを発表した際、OS/390 および MVS の直接の後継となる 64 ビットの z/OS オペレーティング システムも発表しました。富士通と日立は、準 MVS オペレーティング システムおよびハードウェア システム用に IBM の z/Architecture のライセンスを取得しないことを選択したため、MSP および VOS3 はベンダーによって名目上はサポートされているものの、現在に至るまで MVS の 1980 年代のアーキテクチャ上の制限のほとんどが残っています。z/OS は MVS 時代のアプリケーションとテクノロジを引き続きサポートしているため (z/OS には、数十年にわたる進化を通じて大幅に強化および改善されたとはいえ、MVS のコードの大部分が依然として含まれています)、MSP および VOS3 で実行されるアプリケーション (および運用手順) は、他のオペレーティング システムよりもずっと簡単に z/OS に移行できます。

• Hercules は、 MVS を実行できる S/370、S/390、および zSeries エミュレータです。
• MVS（および後継）オペレーティング システムに付属するユーティリティ プログラム
• BatchPipes は、 MVS/ESAオペレーティング システムおよびそれ以降のすべてのバージョン ( OS/390およびz/OS)用に設計されたバッチ ジョブ処理ユーティリティです。

• IBM: Wayback Machineの z/OS V1R11.0 MVS マニュアル(2009-09-05 アーカイブ)
• IBM: Wayback Machineの z/OS V1R8.0 MVS マニュアル(2006-11-04 アーカイブ)
• MVS: 世界を動かし続けるオペレーティングシステム ( Wayback Machineより) (2001-06-30 アーカイブ)
• MVS... Wayback Machineの長い歴史(2001-07-16 アーカイブ)
• AL Scherr (1973 年 12 月)。「IBM 仮想ストレージ オペレーティング システムの機能構造パート II: OS/VS2-2 の概念と原理」。IBM Systems Journal。12 ( 4 )。IBM: 382–400。doi :10.1147/sj.124.0382。