Loading article…
Multiple Virtual Storage ( MVS ) は、 System/370、System/390、およびIBM Z IBM メインフレームコンピュータで最も一般的に使用されているオペレーティングシステムです。IBM は、 OS/360の後継として、OS/VS1およびSVSとともに MVS を開発しました。これは、IBM の他のメインフレームオペレーティングシステムライン ( VSE、VM、TPF など) とは無関係です。
1974年に初めてリリースされたMVSは、その後、名称にMVSという用語を残しつつ、複数のプログラム製品によって拡張され、それぞれ新しい名前が付けられた。
そしてさらに拡張
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 ]はマルチプログラミングを提供します。オペレーティングシステムのインストール時とオペレータが再定義する際に、それぞれ固定サイズの複数のメモリパーティションが設定されます。たとえば、小さなパーティションが 1 つ、中サイズのパーティションが 2 つ、大きなパーティションが 1 つ存在する場合があります。実行準備が整った大きなプログラムが 2 つある場合、一方のプログラムが終了して大きなパーティションが空くまで、もう一方のプログラムを待つ必要があります。OS/360 R19 では、MFT サブタスク (マルチタスク) が追加され、ジョブが ATTACH マクロを使用して新しいタスクを動的に作成できるようになりました。
OS/360 MVT (可変タスク数によるマルチプログラミング) [ 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つの同時実行プログラムが同じ仮想メモリ アドレスにアクセスしようとすると、仮想メモリ システムはこれらの要求を物理メモリの異なる領域にリダイレクトしました。これらのアドレス空間はそれぞれ、オペレーティングシステム（すべてのジョブで共有されるインスタンス）、各アプリケーション固有のアプリケーション領域、およびジョブ間の通信を含むさまざまな目的で使用される共有仮想領域の3つの領域で構成されていました。IBMは、アプリケーション領域が常に少なくとも8MBであることを約束しました。これにより、MVSは、より多くのアプリケーションを実行する必要性から生じるビジネス上の問題に対する完璧なソリューションとなりました。
MVS は、マルチプログラミングとマルチプロセッシング機能を提供することで、処理能力を最大限に引き出しました。[ 2 ] MVS は、 MVTやOS/VS2 SVSといった前身システムと同様に、マルチプログラミングをサポートしていました。プログラム命令と関連データは、制御プログラムによってスケジュールされ、処理サイクルが割り当てられます。単一プログラミングのオペレーティングシステムとは異なり、これらのシステムは、同時に実行される複数の異なるプログラムに関連付けられた命令間で処理サイクルを分割することで、処理能力の使用を最大化します。このようにして、制御プログラムは、処理を進める前に I/O 操作が完了するのを待つ必要がありません。複数のプログラムの命令を実行することで、コンピュータはアクティブなプログラムと非アクティブなプログラムを切り替えることができます。
MVSの初期バージョン（1970年代半ば）は、IBM OSシリーズの中で初めてマルチプロセッサ構成をサポートしたOSの一つですが、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つ以上のデータ処理システムをネットワーク接続することが可能になりました。この機能は、後にJES2ユーザーにもマルチアクセススプール（MAS）として提供されるようになりました。
MVSは当初、24ビットアドレス指定（最大16MB）をサポートしていました。基盤となるハードウェアの進歩に伴い、31ビット（XAおよびESA、最大2048MB）および現在（z/OSとして）64ビットアドレス指定をサポートするようになりました。31ビットアドレス指定への急速なアップグレードの最も重要な動機は、主にCICSによって制御される大規模なトランザクション処理ネットワークの成長でした。これらのネットワークは単一のアドレス空間で動作し、DB2リレーショナルデータベース管理システムは効率的に動作するために8MBを超えるアプリケーションアドレス空間を必要としていました。（初期バージョンでは、共有仮想領域を介して通信する2つのアドレス空間に構成されていましたが、すべての通信がオペレーティングシステムを介して送信されるため、大きなオーバーヘッドが発生していました。）
MVS の主なユーザー インターフェイスは、元々はバッチ処理用に設計されたものの、1970 年代以降はCICSなどの長時間実行される対話型ジョブの開始とリソースの割り当てにも使用されたジョブ制御言語( JCL )と、主に開発ツールや少数のエンド ユーザー情報システムを実行するために使用された対話型タイムシェアリングインターフェイスであるTSO (Time Sharing Option)です。ISPF は、3270 ファミリー端末 (後に VM でも) のユーザー向けの TSO アプリケーションで、TSO のコマンドラインと同じタスクをメニューとフォーム指向で実行でき、フルスクリーン エディタとファイル ブラウザーを備えています。TSO の基本インターフェイスはコマンドラインですが、 ISPFなどのフォーム駆動型インターフェイスの機能は後から追加されました。[ 3 ]
MVSは、IBMがソフトウェアリカバリと呼んでいた以前のSTAE機能をベースに、フォールトトレランスにおいて大きな進歩を遂げました。IBMは、ビジネスの世界におけるMVTの長年の実務経験を経て、この決断を下しました。システム障害が顧客のビジネスに大きな影響を与えるようになったため、IBMは、最高のソフトウェア開発およびテスト手法を用いても「問題は必ず発生する」という前提に立ち、設計上の大きな転換を図りました。この前提は、システムにフォールトトレランスコードを大幅に追加する上で極めて重要であり、ソフトウェアおよびハードウェア障害に対するシステムの耐性向上に大きく貢献したと考えられます。
この設計では、システム（カーネル／特権）モードの「機能回復ルーチン」と、ユーザー（タスクまたは問題プログラム）モードの「ESTAE」（拡張指定タスク異常終了ルーチン）と呼ばれる、エラー処理プログラムの階層構造が規定されていました。これらのプログラムは、システムがエラー（ハードウェアプロセッサまたはストレージのエラー、あるいはソフトウェアエラー）を検出した場合に呼び出されます。各回復ルーチンは、「メインライン」関数を再呼び出し可能にし、原因となっている問題をデバッグするのに十分なエラー診断データを取得し、「再試行」（メインラインを再呼び出し）するか、「パーコレーション」（エラー処理を階層内の次の回復ルーチンにエスカレーション）するかのいずれかを実行します。
このように、システムはエラーが発生するたびに診断データを取得し、修復を試み、システムの稼働を維持しようとしました。最悪の事態は、修復されないエラーが発生した場合にユーザーアドレス空間（「ジョブ」）を停止させることでした。これは当初の設計上のポイントでしたが、最新のMVSバージョン（z/OS）になって初めて、リカバリープログラムが独自のリカバリールーチンを持つことが保証され、さらに各リカバリールーチンがそれぞれ独自のリカバリールーチンを持つようになりました。このリカバリー構造はMVSの基本制御プログラムに組み込まれており、アプリケーションプログラム開発者やサードパーティ開発者が利用できるプログラミング機能が用意されています。
実際には、MVSのソフトウェアリカバリ機能は、問題のデバッグを容易にする一方で、難しくもしました。ソフトウェアリカバリでは、プログラムが現在位置と実行中の処理の「痕跡」を残す必要があるため、デバッグが容易になります。しかし、エラーが発生しても処理が進行すると、これらの痕跡が上書きされてしまう可能性があります。エラー発生時に早期にデータを取得することでデバッグが最大限に活用でき、リカバリルーチン（タスクモードとシステムモードの両方）には、このための機能が備わっています。
IBMは、IBMサービスを必要とする重大なソフトウェア問題に関する追加基準を設けていました。メインラインコンポーネントがソフトウェアリカバリを開始できなかった場合、それは報告すべき有効な障害とみなされました。また、リカバリルーチンが重要な診断データを収集できず、そのデータによって元の問題が解決できる場合、IBMの基準では、この障害は報告対象であり、修復が必要であると規定されていました。このように、IBMの基準を厳密に適用することで、継続的な改善が促進されました。
IBMは、OS/VS1およびOS/VS2リリース1で導入した主要な保守ツールであるDynamic Support System [ 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が実際のオペレーティング・システムであり、「ゲスト」オペレーティング・システムは、非常に高い権限を持つアプリケーションとして扱われました。その後のハードウェアの改良により、オペレーティング・システム（MVS、ゲスト・システムを含むVM、またはその他のシステム）のインスタンスが、物理システム全体ではなく、論理パーティション（LPAR）を占有することも可能になりました。
複数の MVS インスタンスは、1990 年 9 月に導入されたシステム複合体またはシスプレックスと呼ばれる構造で編成され、まとめて管理できます。インスタンスは、クロスシステム結合機能(XCF) と呼ばれるソフトウェア コンポーネントと、ハードウェア結合機能(CF または、同じメインフレーム ハードウェアに共存する場合は統合結合機能 (ICF)) と呼ばれるハードウェア コンポーネントを介して相互運用されます。複数のシスプレックスは、IBM 独自のシステム ネットワーク アーキテクチャ(SNA) などの標準ネットワーク プロトコル、または最近ではTCP/IPを介して接続できます。z/OS オペレーティング システム (MVS の最新の後継) は、POSIXおよびシングル UNIX 仕様アプリケーションを実行するためのネイティブ サポートも備えています。このサポートは MVS/SP V4R3 から開始され、IBM は z/OS V1R2 以降で UNIX 95 認証を取得しています。[ 5 ]
このシステムは一般的にビジネスや銀行業務で使用され、アプリケーションは多くの場合COBOLで記述されます。COBOL プログラムは従来、 IMSやCICSなどのトランザクション処理システムで使用されていました。CICS で実行されるプログラムの場合、特別な EXEC CICS ステートメントが COBOL ソースコードに挿入されます。プリプロセッサ (トランスレータ) は、プログラムがコンパイルされる前に、これらの EXEC CICS ステートメントを CICS を呼び出すための適切な COBOL コードに置き換えます。これは、DB2を呼び出すために使用されるSQL と全く同じではありません。アプリケーションは、 C、C++、Java、アセンブリ言語、FORTRAN、BASIC、RPG、REXXなどの他の言語でも記述できます。言語サポートは、「言語環境」または「LE」と呼ばれる共通コンポーネントとしてパッケージ化されており、統一されたデバッグ、トレース、プロファイリング、およびその他の言語に依存しない機能を可能にします。
MVSシステムへのアクセスは従来、3270端末または3270エミュレータを実行するPCで行われてきました。しかし、最近のメインフレームアプリケーションの多くは、独自のWebインターフェースまたはGUIインターフェースを備えています。z/OSオペレーティングシステムはTCP/IPを標準でサポートしています。かつて3270端末で行われていたシステム管理は、現在ではハードウェア管理コンソール（HMC）およびWebインターフェースを介して行われるようになっています。オペレータコンソールは2074エミュレータを介して提供されるため、S/390またはzSeriesプロセッサに実際の3270が接続されているのを目にすることはまずないでしょう。
MVSとその周辺機器のネイティブ文字エンコーディング方式はEBCDICですが、TR命令によって他の7ビットおよび8ビットコードへの変換が容易になりました。IBMはその後、より大きなコードへの変換やコード間の変換を実行するためのハードウェアアクセラレーションサービス、Unicode変換のためのハードウェア固有のサービス、そしてASCII、ISO/IEC 8859、UTF-8、UTF-16、UTF-32などのソフトウェアサポートを追加しました。ソフトウェア変換サービスは、入力としてソースコードページとデスティネーションコードページを受け取ります。
MVSでは、Unixファイル以外のファイルは、正式にはデータセットと呼ばれます。これらのファイル名は、 VSAMファイルであるカタログに整理されています。
データセット名 (DSN、メインフレームにおけるファイル名の用語) は、ドットで区切られた階層構造で構成されます。例: "DEPT01.SYSTEM01.FILE01"。階層構造の各レベルは最大 8 文字です。ファイル名の全長は、ドットを含めて最大 44 文字です。慣例として、ドットで区切られたコンポーネントは、他のオペレーティングシステムのディレクトリと同様にファイルを整理するために使用されます。たとえば、Windows エクスプローラーと同様の機能 (ただしGUIはなく、通常はバッチ処理モード) を実行するユーティリティ プログラムがあり、新しい要素の追加、名前の変更、削除、および指定された要素のすべての内容の報告などが可能です。ただし、他の多くのシステムとは異なり、これらのレベルは通常、実際のディレクトリではなく、単なる命名規則です(フォルダ階層がFinder によって維持される幻想であったオリジナルのMacintosh ファイルシステムと同様)。 TSOはファイルに対するデフォルトのプレフィックス（「現在のディレクトリ」の概念に類似）をサポートしており、RACFはファイル名のパターンに基づいてアクセス制御を設定することをサポートしています。これは、他のプラットフォームにおけるディレクトリのアクセス制御に類似しています。
他のOSファミリーのメンバーと同様に、MVSのデータセットはレコード指向である。MVSは前身から主に3つのタイプを継承している。
シーケンシャルデータセットとISAMデータセットは、固定長レコードまたは可変長レコードのいずれでも格納でき、いずれのタイプも複数のディスクボリュームを占有する可能性がある。
これらはすべてVTOCディスク構造に基づいています。
初期のIBMデータベース管理システムでは、ISAMデータセットとBDAMデータセットを様々な組み合わせで使用していました。通常は、実際のデータ保存にはBDAM、インデックスにはISAMが用いられていました。
1970年代初頭、IBMの仮想メモリオペレーティングシステムは、同様の機能を提供する新しいファイル管理コンポーネントであるVSAMを導入した。
これらのVSAMフォーマットは、 IBMのデータベース管理システムであるIMS/VSおよびDB2の基盤となり、通常は実際のデータ格納にESDS、インデックスにKSDSが用いられた。
VSAMには、ユーザーカタログとMVSのマスターカタログに使用されるカタログコンポーネントも含まれていました。
パーティションデータセット（PDS）は、それぞれが独立したシーケンシャルファイルとして処理できる「メンバー」に分割されたシーケンシャルデータセットです（ファイルシステムのフォルダのようなものです）。PDSの最も重要な用途はプログラムライブラリでした。システム管理者はメインのPDSを使用してプロジェクトにディスク領域を割り当て、プロジェクトチームはその後メンバーを作成および編集しました。PDSのその他の用途としては、頻繁に使用されるジョブ制御プロシージャ（PROC）のライブラリや、複数のプログラムで使用されるレコード定義などのプログラミング言語ステートメントの「コピーブック」などがあります。
世代データグループ (GDG) は、同じ名前のデータセットのグループで、絶対世代番号または最新の世代からのオフセットで参照できます。これらは元々、祖父-父-息子バックアップ手順をサポートするように設計されていました。ファイルが変更されると、変更されたバージョンが新しい「息子」になり、以前の「息子」が「父」になり、以前の「父」が「祖父」になり、以前の「祖父」が削除されます。しかし、3 世代を超える GDG を設定することができ、一部のアプリケーションでは、複数のソースからデータを収集して 1 つのプログラムに情報を供給するために GDG を使用しました。各収集プログラムはファイルの新しい世代を作成し、最終プログラムはグループ全体を単一の連続ファイルとして読み取ります ( 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）と呼ばれる機能があり、一時的なデータセットをページングデータセット上のシミュレートされたトラックに格納できるため、既存のアクセス方法の使用が容易になり、割り当てのオーバーヘッドがなくなりますが、実際のDASDやメモリマップドファイルシステムに必要な処理オーバーヘッドよりも多くなります。
IBMはOS/VS2のリリースおよびサブリリースで追加した新機能に加え、多数の無償増分変更リリース（ICR）および選択可能ユニット（SU）、ならびに最終的にz/OSの一部としてバンドルされた有料プログラム製品およびフィールド開発プログラムを提供しました。これらには以下が含まれます。
1970年代後半から1980年代初頭にかけて、IBMは次のように発表した。
DF/DSでは新しいデバイスサポートが追加されましたが、IBMは無料版へのデバイスサポートの追加を今後行わないと発表しました。DF/EFでは、VSAMカタログとコントロールボリューム（CVOL）の代替として改良カタログ構造（ICF）が追加されましたが、信頼性の問題が多発しました。
IBMは[ 6 ] MVS/SPバージョン2（MVS/XA）を発表した際、上記の他の5つの製品の代替およびアップグレードとして[ 7 ]データファシリティプロダクト™（DFP™）も発表し、1984年12月1日をもって販売を終了すると述べた。1983年6月7日に発表されたDFP/370リリース1（プログラム番号5665-295）はMVS/SPバージョン1、MVS/SE、OS/VS2 R3.8向けでオプションであったが、MVS/Extended Architectureデータファシリティプロダクト（5665-284）はMVS/SPバージョン2（MVS/XA）の必須要件であった。DFPはデータ管理機能を強化するだけでなく、リンケージエディタとユーティリティの無料版を置き換えた。
DFPは単体製品としては提供されなくなりましたが、データファシリティストレージ管理サブシステムの一部となり、 DFSMSdfpという名称で提供されています。
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（Multiple Virtual Storage/Extended Architecture）は、新しいI/Oアーキテクチャを備え、アドレスを24ビットから31ビットに拡張して2ギガバイトのアドレス指定可能なメモリ領域を提供する370-XAアーキテクチャをサポートするMVSのバージョンでした。[ 9 ] MVS/XAは、古い24ビットアプリケーション（つまり、 32ビットワードの下位24ビットに24ビットアドレスを格納し、そのワードの上位8ビットを他の目的に使用するアプリケーション）向けに24ビットのレガシーアドレッシングモードをサポートしました。
MVSエンタープライズシステムアーキテクチャ（MVS/ESA ）とは、 OS/390より前のMVSのバージョンで、 S/370エンタープライズシステムアーキテクチャ（S/370-ESA）をサポートするものを指します。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: バージョン 4 へのアップグレード MVS/ESA SP リリース 3 は、POSIXおよびその他の標準をサポートする形で 1993 年 2 月に発表されました[ 15 ] 。 [ 16 ] [ 17 ] [ 18 ]初期リリースでは、米国国立標準技術研究所(NIST) による連邦情報処理標準(FIPS) 151 準拠の認証のみでしたが、後続のリリースでは、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世紀で最も有名な産業スパイ事件の1つで、IBMのMVSソースコードと内部文書を繰り返し違法に入手した。[ 21 ]富士通は、自社のMSPメインフレームオペレーティングシステムでIBMのコードに大きく依存しており、同様に日立もVOS3オペレーティングシステムで同じことをした。MSPとVOS3は、日本でメインフレームの設置ベースで依然として大きなシェアを占めているが、オーストラリアをはじめとする他の国でもある程度販売された。IBMのバグや文書のスペルミスさえも忠実にコピーされた。IBMは、米国連邦捜査局（FBI）の潜入捜査に協力し、1980年代初頭に最高潮に達した数年にわたる捜査の過程で、富士通と日立に独自のMVSとメインフレームハードウェア技術を渋々提供した。この捜査では、会社の幹部や一部の日本政府関係者も関与していた。しかし、アムダールは富士通によるIBMの知的財産の窃盗には一切関与していなかった。アムダールから富士通への通信はすべて「アムダール専用仕様書」を通じて行われ、そこにはIBMの知的財産やIBMの知的財産への言及は一切含まれていなかった。
調査後、IBMは富士通と日立の両社と数百万ドルの和解に達し、両社の利益のかなりの割合を長年にわたって徴収した。信頼できる報告によると、和解金は5億ドルを超えた。[ 22 ] [ 21 ] [ NB 7 ]
3社は以前から友好的に多くの共同事業に合意してきた。例えば、2000年にはIBMと日立が協力してIBM z900メインフレームモデルを開発した。
このような歴史的コピーにより、MSPとVOS3はMVSの「フォーク」として適切に分類され、MVS互換製品を持つ多くのサードパーティソフトウェアベンダーは、ほとんどまたは全く変更を加えることなくMSPおよびVOS3互換バージョンを作成することができました。[ 23 ] [ 24 ] [ 25 ]
IBMが2000年に64ビットのz/Architectureメインフレームを発表した際、OS/390とMVSの後継となる64ビットのz/OSオペレーティングシステムも同時に発表しました。富士通と日立は、自社の準MVSオペレーティングシステムおよびハードウェアシステムにIBMのz/Architectureのライセンスを取得しなかったため、MSPとVOS3は、ベンダーによる名目上のサポートは継続しているものの、現在に至るまでMVSの1980年代のアーキテクチャ上の制約のほとんどを抱えています。z/OSはMVS時代のアプリケーションとテクノロジーを依然としてサポートしており、数十年にわたる進化を経て大幅に強化・改良されているとはいえ、MVSのコードの大部分を今もなお含んでいるため、MSPとVOS3上で動作するアプリケーション（および運用手順）は、他のオペレーティングシステムよりもz/OSへはるかに容易に移行できます。
システム サービス
名称がOpenEditionからOS/390 UNIXシステムサービスに変更されました。