| 多重仮想記憶 (MVS) | |
|---|---|
| 開発者 | IBM |
| 書かれた | アセンブラ(XF)、PL/S |
| OSファミリー | OS/360 |
| 初回リリース | 1974年 (1974年) |
| マーケティングターゲット | IBMメインフレームコンピュータ |
| 入手可能な | 英語 |
| サポートされているプラットフォーム | システム/370、システム/390 |
| 影響を受けた | TSS |
| ライセンス | 独自仕様 当初は無料 |
| 先行 | OS/VS2 (SVS) |
| 後継者 | MVS/SE、MVS/SP、MVS/XA、MVS/ESA、OS/390、z/OS |
| IBM メインフレーム オペレーティング システムの歴史 |
|---|
多重仮想記憶(Multiple Virtual Storage、通称MVS )は、System/370、System/390、IBM Z IBM メインフレームコンピュータで最も広く使用されているオペレーティングシステムです。IBMは、 OS/VS1およびSVSとともに、 OS/360の後継としてMVSを開発しました。MVSは、 VSE、VM、TPFなどのIBMの他のメインフレームオペレーティングシステムとは無関係です。
概要
MVS は 1974 年に初めてリリースされ、その後何度も新しい名前のプログラム製品によって拡張されましたが、命名法では 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) はそうではありません。IBM が「OS/VS2」を使用したのは上位互換性を重視していたためです。MVT で実行されるアプリケーション プログラムは、MVS で実行するために再コンパイルする必要さえありませんでした。同じジョブ制御言語ファイルは変更せずに使用でき、ユーティリティやTSOなどのコア以外の機能も変更なく実行されました。IBM とユーザーは、当初からほぼ一致してこの新しいシステムを MVS と呼び、IBM はその後のメジャーバージョンの命名にもMVSという用語を使用し続けました。
MVSの進化
OS/360 MFT(Multiprogramming with a Fixed number of Tasks)[1]は、マルチプログラミング機能を提供します。オペレーティングシステムのインストール時およびオペレータによる再定義時に、固定サイズの複数のメモリパーティションが設定されます。例えば、小さなパーティションが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 は、アプリケーション領域は常に少なくとも 8MB であると約束しました。これにより、MVS は、より多くのアプリケーションを実行する必要があることから生じるビジネス上の問題に対する完璧なソリューションとなりました。
MVSは、マルチプログラミングとマルチプロセッシング機能を提供することで、処理能力を最大限に引き出しました。[2] MVTやOS/VS2といった先行OSと同様に、MVSはマルチプログラミングをサポートしていました。プログラム命令と関連データは制御プログラムによってスケジュールされ、処理サイクルが割り当てられます。シングルプログラミングのオペレーティングシステムとは異なり、これらのシステムは、複数の異なる同時実行プログラムに関連付けられた命令間で処理サイクルを分割することで、処理能力を最大限に引き出します。これにより、制御プログラムは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つ以上のデータ処理システムをネットワークで接続する機能をユーザーに提供しました。この機能は最終的に、マルチアクセス・スプール(MAS)としてJES2ユーザーにも利用可能になりました。 [要出典]
MVSは当初、24ビット・アドレッシング(つまり最大16MB)をサポートしていました。基盤となるハードウェアの進化に伴い、31ビット(XAおよびESA、最大2048MB)をサポートし、現在では(z/OSと同様に)64ビット・アドレッシングをサポートしています。31ビット・アドレッシングへの急速なアップグレードの最大の理由は、主に単一のアドレス空間で実行されるCICSによって制御される大規模トランザクション処理ネットワークの拡大と、 DB2 リレーショナル・データベース管理システムが効率的に動作するために8MBを超えるアプリケーション・アドレス空間を必要としたことです。(初期バージョンでは、共有仮想領域を介して通信する2つのアドレス空間で構成されていましたが、このような通信はすべてオペレーティング・システムを介して送信されていたため、大きなオーバーヘッドが発生していました。)
MVS への主なユーザーインターフェースは、ジョブ制御言語(JCL) です。これはもともとバッチ処理用に設計されたものですが、1970 年代以降はCICSなどの長時間対話型ジョブの開始とリソースの割り当てにも使用されました。また、TSO (タイムシェアリングオプション) は対話型タイムシェアリングインターフェースで、主に開発ツールと少数のエンドユーザー情報システムの実行に使用されました。ISPFは3270 ファミリー端末 (後に VM でも) のユーザー向けの TSO アプリケーションで、ユーザーは TSO のコマンド ラインと同じタスクをメニューとフォーム指向で実行でき、フルスクリーンエディターとファイルブラウザーを備えています。TSO の基本インターフェースはコマンド ラインですが、 ISPFなどの機能が後にフォーム駆動型インターフェース用に追加された
MVS は、IBM がソフトウェア リカバリーと呼んでいた以前の STAE 機能を基にして、フォールト トレランスにおいて大きな前進を遂げました。IBM がこれを採用したのは、ビジネスの世界で MVT を何年も実践してきた経験の後のことです。システム障害が顧客のビジネスに重大な影響を及ぼすようになったため、IBM は設計を大幅に変更し、最高のソフトウェア開発およびテスト技術をもってしても「問題は必ず起こる」と想定することにしました。この深い想定が、フォールト トレランス コードをシステムに追加する際に極めて重要となり、システムがソフトウェアおよびハードウェアの障害に耐えることに成功したことに貢献したと考えられます。これらの設計機能の価値を証明するための統計情報を得るのは困難です (「防止された」または「回復された」問題をどのように測定できるでしょうか)。しかし IBM は、長年にわたり、さまざまな側面でこれらのフォールト トレラントなソフトウェア リカバリー機能と迅速な問題解決機能を強化してきました。
この設計では、システム(カーネル/「特権」)モードでは機能回復ルーチンと呼ばれるエラー処理プログラム、ユーザー(「タスク」または「問題プログラム」)モードでは「ESTAE」(拡張指定タスク異常終了ルーチン)と呼ばれるエラー処理プログラムの階層構造が規定されていました。ESTAEは、システムがエラー(ハードウェアプロセッサまたはストレージエラー、あるいはソフトウェアエラー)を検出した場合に呼び出されます。各回復ルーチンは、「メインライン」機能を再呼び出し可能にし、原因となっている問題をデバッグするのに十分なエラー診断データを取得し、「再試行」(メインラインを再呼び出し)または「パーコレーション」(エラー処理を階層内の次の回復ルーチンにエスカレート)します。
このように、システムはエラーが発生するたびに診断データを取得し、修復を実行してシステムの稼働を維持しようとしました。最悪の事態は、修復されないエラーが発生した場合にユーザーアドレス空間(「ジョブ」)が停止することです。これは当初の設計ポイントでしたが、最新のMVSバージョン(z/OS)になって初めて、リカバリプログラムに独自のリカバリルーチンが保証されるだけでなく、各リカバリルーチンにも独自のリカバリルーチンが備わりました。このリカバリ構造はMVSの基本制御プログラムに組み込まれており、アプリケーションプログラム開発者やサードパーティ開発者が利用できるプログラミング機能を備えています。
実際には、MVSのソフトウェアリカバリは問題のデバッグを容易にすると同時に、困難にもしました。ソフトウェアリカバリでは、プログラムが現在位置と動作の「軌跡」を残す必要があり、これによりデバッグが容易になります。しかし、エラーが発生しても処理が進行すると、軌跡が上書きされる可能性があります。エラー発生時に早期にデータを取得することでデバッグの効果を最大限に高めることができ、リカバリルーチン(タスクモードとシステムモードの両方)にはこれを実行するための機能が用意されています。
IBMは、IBMサービスを必要とする重大なソフトウェア問題に関する追加基準を設けました。主要コンポーネントがソフトウェアリカバリを開始できない場合、それは報告対象となる有効な障害とみなされました。また、リカバリルーチンが重要な診断データを収集できず、そのリカバリルーチンによって収集されたデータによって元の問題が解決可能な場合も、IBMの基準ではこの障害は報告対象であり、修復が必要であると定められました。このように、IBMの基準を厳密に適用することで、継続的な改善が促進されました。
IBMは、OS/VS1およびOS/VS2リリース1で導入した主要な保守ツールであるダイナミック・サポート・システム[4](DSS)のサポートを継続しました。この対話型機能は、診断プロシージャを作成するためのセッションを開始したり、既に保存されているプロシージャを呼び出したりするために呼び出されました。これらのプロシージャは、プログラムのロード、デバイスI/O、システム・プロシージャ・コールなどの特別なイベントを捕捉し、事前に定義されたプロシージャの起動をトリガーしました。これらのプロシージャは再帰的に呼び出され、データの読み書きや命令フローの変更を可能にしました。プログラム・イベント・レコーディング(PVR)ハードウェアが使用されました。
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、またはその他のシステム)の1つのインスタンスが、物理システム全体ではなく、 論理パーティション(LPAR)を占有することも可能になりました。
1990年9月に導入されたシステム・コンプレックスまたはシスプレックスと呼ばれる構造では、複数のMVSインスタンスを編成し、まとめて管理することができます。インスタンスは、システム間カップリング・ファシリティー( XCF)と呼ばれるソフトウェア・コンポーネントと、ハードウェア・カップリング・ファシリティー(同じメインフレーム・ハードウェア上に共存する場合はCF、または統合カップリング・ファシリティー、ICF)と呼ばれるハードウェア・コンポーネントを介して相互運用します。複数のシスプレックスは、IBM独自のシステム・ネットワーク・アーキテクチャー(SNA)などの標準ネットワーク・プロトコル、または最近ではTCP/IPを介して結合することができます。z/OSオペレーティング・システム(MVSの最新の後継システム)は、POSIXおよびSingle UNIX Specificationアプリケーションを実行するためのネイティブ・サポートも備えています。このサポートは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エミュレータを介して提供されるため、S/390やzSeriesプロセッサーに実際の3270が接続されていることはまずありません。
MVSとその周辺機器のネイティブ文字エンコード方式はEBCDICですが、TR命令により他の7ビットおよび8ビットコードへの変換が容易になりました。IBMは、より大きなコード間の変換を実行するハードウェアアクセラレーションサービス、Unicode変換のためのハードウェア固有のサービス、そしてASCII、ISO/IEC 8859、UTF-8、UTF-16、UTF-32などのソフトウェアサポートを徐々に追加してきました。ソフトウェア変換サービスは、ソースコードページと宛先コードページを入力として受け取ります。
MVSファイルシステム
Unixファイル以外のファイルは、MVSではデータセットと呼ばれます。これらのファイルの名前は、 VSAMファイル自体であるカタログに整理されます。
Data set names (DSNs, mainframe term for filenames) are organized in a hierarchy whose levels are separated with dots, e.g. "DEPT01.SYSTEM01.FILE01". Each level in the hierarchy can be up to eight characters long. The total filename length is a maximum of 44 characters including dots. By convention, the components separated by the dots are used to organize files similarly to directories in other operating systems. For example, there are utility programs that performed similar functions to those of Windows Explorer (but without the GUI and usually in batch processing mode) - adding, renaming or deleting new elements and reporting all the contents of a specified element. However, unlike in many other systems, these levels are not usually[NB 4] actual directories but just a naming convention (like the original Macintosh File System, where folder hierarchy was an illusion maintained by the Finder). TSO supports a default prefix for files (similar to a "current directory" concept), and RACF supports setting up access controls based on filename patterns, analogous to access controls on directories on other platforms.
As with other members of the OS family, MVS' data sets are record-oriented. MVS inherited three main types from its predecessors:
- Sequential data sets were normally read one record at a time from beginning to end.
- In BDAM (direct access) data sets, the application program had to specify the physical location of the data it wanted to access (usually by specifying the offset from the start of the data set).
- In ISAM data sets a specified section of each record was defined as a key that could be used as a key to look up specific records. The key quite often consisted of multiple fields but these had to be contiguous and in the right order; and key values had to be unique. Hence an IBM ISAM file could have only one key, equivalent to the primary key of a relational database table; ISAM could not support foreign keys.
Sequential and ISAM datasets could store either fixed-length or variable length records, and all types could occupy more than one disk volume.
All of these are based on the VTOC disk structure.
Early IBM database management systems used various combinations of ISAM and BDAM datasets - usually BDAM for the actual data storage and ISAM for indexes.
In the early 1970s IBM's virtual memory operating systems introduced a new file management component, VSAM, which provided similar facilities:
- エントリ シーケンス データセット (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つのプログラムに提供していました。各収集プログラムはファイルの新しい世代を作成し、最終的なプログラムはグループ全体を単一のシーケンシャルファイルとして読み取りました(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サーバーの基本アーキテクチャでもあります。
仮想I/O(VIO)
MVS には仮想 I/O (VIO) と呼ばれる機能が含まれており、これを使用すると、一時データセットをページング データセット上のシミュレートされたトラックに格納できるため、既存のアクセス方法の使用が容易になり、割り当てのオーバーヘッドが排除されますが、実際の DASD またはメモリ マップ ファイル システムに必要な処理オーバーヘッドよりも多くの処理オーバーヘッドが追加されます。
MVSへのアップグレード
IBMは、OS/VS2のリリースおよびサブリリースで追加された新機能に加え、多数の無償の増分変更リリース(ICR)と選択可能ユニット(SU)、そして最終的にz/OSの一部としてバンドルされた有償のプログラム製品と現場開発プログラムを提供しました。これらには以下が含まれます。
| SU | SUID | SU名 |
|---|---|---|
| 1 | 5752-801 | VTAM2 |
| 2 | 5752-802 | TCAM 10 |
| 3 | 5752-803 | JES2 リリース 4 |
| 4 | 5752-804 | スケジューラの改善 |
| 5 | 5752-805 | スーパーバイザーパフォーマンス1 |
| 6 | 5752-806 | 168AP |
| 7 | 5752-807 | スーパーバイザーパフォーマンス2 |
| 8 | 5752-808 | データ管理の強化 |
| 9 | 5752-809 | |
| 10 | 5752-810 | 3800 サポート |
| 12 | 5752-812 | JES3 リリース 2 |
| 13 | 5752-813 | TSO/VTAM |
| 15 | 5752-815 | SMP |
| 16 | 5752-816 | スケジューラ/IOS サポート |
| 17 | 5752-817 | サービスデータの改善 |
| 18 | 5752-818 | JES3 リリース 3.1 MSS |
| 21 | 5752-821 | SSSリリース4 |
| 24 | 5752-824 | 3850 MSSプログラミングの機能強化 |
| 25 | 5752-825 | JES2 リリース 4.1 RJE 3790 のサポート |
| 26 | 5752-826 | JES3 RJP |
| 27 | 5752-827 | EREPの変更 |
| 29 | 5752-829 | 3838 VPSS |
| 30 | 5752-830 | 3895 デポジットシステム |
| 32 | 5752-832 | システムセキュリティサポート |
| 33 | 5752-833 | MVS ダンプの改善 |
| 36 | 5752-836 | TCAM ダイレクト (TCAM 10) |
| 37 | 5752-837 | SSS リリース 5 TCAM ダイレクト |
| 47 | 5752-847 | 158/168 AP |
| 48 | 5752-848 | 3800 12行/インチ |
| 51 | 5752-851 | プロセッササポート |
| 55 | 5752-855 | ハードウェアリカバリの機能強化 |
| 57 | 5752-857 | IPCS |
| 58 | 5752-858 | TSO/VTAM レベル 2 |
| 60 | 5752-860 | データ管理サポート |
| 63 | 5752-863 | SMPリリース3 |
| 64 | 5752-864 | プロセッササポート2 |
| 68 | 5752-868 | DEMF(ディスプレイ例外監視プログラム) |
- 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
データ ファシリティ プロダクト (DFP)
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]データ機能製品™(DFP™)も発表した。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という名前で、Data Facility Storage Management Subsystemの一部になりました。
現代のMVS

MVS は現在、z/OS に進化しており、古い MVS リリースは IBM によってサポートされなくなり、2007 年以降は 64 ビットの z/OS リリースのみがサポートされています。z/OS は、新しい 64 ビット アプリケーションと並行して、古い 24 ビットおよび 31 ビットの MVS アプリケーションの実行をサポートしています。
MVSリリース3.8j(24ビット、1981年リリース)までは無料で利用でき、現在ではHercules EmulatorなどのメインフレームエミュレータでMVS 3.8jリリースを無料で実行できる 。[8]
MVS/370
MVS/370は、MVS/XA以前のすべてのバージョンのMVSオペレーティングシステムを指す総称です。[注 6] MVSがリリースされた当時のSystem/370アーキテクチャは24ビットの仮想アドレスのみをサポートしていたため、MVS/370オペレーティングシステムアーキテクチャは24ビットアドレスに基づいています。この24ビットのアドレス長のため、MVS/370で実行されるプログラムにはそれぞれ16MBの連続した仮想記憶域が与えられます。
MVS/XA
MVS/XA(多重仮想記憶/拡張アーキテクチャ)は、新しいI/Oアーキテクチャを持ち、アドレスを24ビットから31ビットに拡張し、2 ギガバイトのアドレス指定可能なメモリ領域を提供する370-XAアーキテクチャをサポートするMVSのバージョンでした。 [9] MVS/XAは、古い24ビットアプリケーション(つまり、32ビットワードの下位24ビットに24ビットアドレスを格納し、そのワードの上位8ビットを他の目的に使用するアプリケーション)用に24ビットのレガシーアドレッシングモードをサポートしていました。
MVS/ESA
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: MVS/ESA SP のバージョン 4 リリース 3 へのアップグレードが 1993 年 2 月に発表され[15]、POSIXおよびその他の標準をサポートしています。[16] [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でもその名称が維持されています。
OS/390
1995 年後半、IBM は MVS をいくつかのプログラム製品にバンドルし、名前を MVS/ESA から OS/390 に変更しました。
z/OS
現在のレベルの MVS は z/OS として販売されています。
密接に関連するオペレーティングシステム
日本のメインフレーム製造業者である富士通と日立は、20世紀で最も有名な産業スパイ事件の一つで、 IBMのMVSのソースコードと内部文書を繰り返し違法に入手した。[21]富士通はMSPメインフレームオペレーティングシステムでIBMのコードに大きく依存しており、同様に日立もVOS3オペレーティングシステムで同じことを行っていた。MSPとVOS3は日本で積極的に宣伝され、現在でもメインフレームのインストールベースの大きなシェアを占めているが、他の国々、特にオーストラリアでもある程度宣伝されていた。IBMのバグや文書のスペルミスさえも忠実にコピーされた。IBMは米国連邦捜査局のおとり捜査に協力し、1980年代初頭に最高潮に達した数年にわたる捜査の間、富士通と日立に独自のMVSとメインフレームのハードウェア技術を渋々提供した。この捜査には、同社の上級管理職や日本政府関係者も関与していた。しかし、アムダールは富士通によるIBMの知的財産の窃盗には関与していなかった。アムダールから富士通へのあらゆる通信は、「アムダール専用仕様」を通じて行われ、IBMの知的財産やそれに関連する記述は徹底的に排除されていた。
調査後、IBMは富士通と日立の両社と数百万ドル規模の和解に達し、長年にわたり両社の利益の相当部分を回収した。信頼できる報道によると、和解金は5億ドルを超えたという。[22] [21] [注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 時代のアプリケーションとテクノロジーをサポートしており (z/OS には、数十年にわたる進化を通じて大幅に機能強化および改善されたとはいえ、MVS のコードの大部分がまだ含まれています)、MSP および VOS3 で実行されるアプリケーション (および運用手順) は、他のオペレーティング システムよりもはるかに簡単に z/OS に移行できます。
参照
- OS/360 と後継機種#タイムライン
- Hercules は、MVS を実行できる S/370、S/390、および zSeries エミュレータです。
- MVS(および後継)オペレーティング システムに付属するユーティリティ プログラム
- BatchPipes は、 MVS/ESAオペレーティング システムおよびそれ以降のすべてのバージョン ( OS/390およびz/OS)向けに設計されたバッチ ジョブ処理ユーティリティです。
注記
- ^ 一部の印刷媒体では単数形が使用されていた。MVS/System Extension: Computerworld、1980年12月15日 - 5ページ; 1978年6月26日 - 8ページ
- ^ 一部のプロセッサは、単一のアドレス空間のサイズよりも多くの物理ストレージを使用できますが、それでも、一般的なワークロードの仮想ストレージの合計サイズよりはるかに小さくなります。
- ^ ジョブ入力サブシステム3(JES3)経由
- ^ 例外となるのは、主にデータセット名の先頭にある CVOL とユーザー カタログのエイリアス名です。
- ^ たとえば、IBM は PDS と Unix ディレクトリの連結の使用をサポートしていません。
- ^ OS/VS2 リリース 2 から 3.8、MVS/SE および MVS/SP バージョン 1
- ^ 議会証言の終わり近くには、「日立はIBMの秘密が新製品の開発に使用されたことをまだ認めておらず、訴訟の解決にかかった莫大な費用をIBMにまだ補償していない」とだけ書かれている。
参考文献
- ^ ab IBM System/360 オペレーティング・システム: 概念と機能(PDF) (第7版). IBM . 1970年6月. p. 16. GC28-6535-7.
- ^ OS/VS2 MVSの概要(PDF) . 初版. IBM. 1978年6月. GC28-0984-0.
- ^ DuCharme, Bob. 「MVS」. オペレーティングシステムハンドブック、またはミニコンピュータとメインフレームを偽装する方法.
- ^ OS/VS ダイナミック・サポート・システム(PDF) (第2版). IBM. 1973年11月. GC28-0640-1.
- ^ 「IBM Corporation - UNIX 95」。The Open Group 。 2015年10月7日閲覧。
- ^ 「IBM Large Systems 発表概要」(発表レター)IBM、1981年10月21日。LTR ENUS283-042 。 2025年1月19日閲覧。
- ^ 「データ機能製品リリース1」(発表レター)。IBM。1981年10月21日。LTR ZP81-0798。
- ^ “The MVS 3.8j Tur(n)key 4- System”. 2023年3月30日時点のオリジナルよりアーカイブ。2023年3月30日閲覧。
- ^ ホスキンス、ジム、フランク、ボブ (2003). 『IBM eServer zSeriesとS/390サーバーの探究:IBMの再設計されたメインフレーム・コンピュータ・ファミリーがかつてないほど人気を集めた理由』マキシマム・プレス (FL). pp. 210– 290. ISBN 1-885068-91-3。
- ^ 「Enterprise Systems Architecture/370 (TM) および MVS/System 製品バージョン 3」(発表レター)IBM、1988年2月15日、288-059。
- ^ 「IBM MVS/ESA システム製品バージョン4の概要」(発表レター)。IBM。1990年9月5日。290-487ページ。
- ^ 「IBM MVS/ESA SP バージョン5リリース1およびOpenEditionの機能強化」(発表レター)。IBM。1994年4月6日。294-152ページ。
- ^ 「プレビュー: S/390 サーバー オペレーティング システム」(発表レター). IBM. 1995年10月10日. 295-423.
- ^ 「OS/390 リリース 1 の提供開始とリリース 2 の追加機能」(発表レター)。IBM。1996 年 3 月 29 日。296-018。
- ^ 「MVS/ESA SP バージョン4リリース3におけるOpenEditionサービスの発表と、追加機能強化を備えたMVS/ESA SP バージョン4リリース3の提供開始」(発表レター)。IBM。1993年2月9日。293-060。
- ^ OpenEdition MVSの紹介。第1版。IBM。1993年12月。GC23-3010-00。
- ^ OpenEdition MVS POSIX.1適合文書. 初版. IBM. 1993年2月. GC23-3011-00.
- ^ OpenEdition MVS POSIX.2適合文書. 初版. IBM. 1993年12月. GC23-3012-00.
- ^ 「IBM OS/390 バージョン2 リリース5の可用性とリリース6」IBM、1998年2月24日、298-049。UNIX
システムサービス
- ^ "1.3.9 OS/390 V2R6 - 1998". UNIX System Services z/OS バージョン1リリース7実装(PDF) . Redbooks (第2版). IBM. 2006年3月. p. 26. SG24-7035-01.
OpenEditionからOS/390 UNIX System Servicesに名称変更
- ^ ab https://fas.org/irp/congress/1989_cr/h890712-japan.htm IBMに対する日本の産業スパイ活動に関する議会公聴会の1時間分の「議事録」
- ^ ラザレスキ、カーラ(1988年11月30日)「富士通のIBMへの支払いは10億ドルを超える可能性がある」ロサンゼルス・タイムズ。 2025年2月4日閲覧。
- ^ アレクサンダー、チャールズ、ブデリ、ボブ(1982年7月5日)「FBIから:ジャパン詐欺」タイム誌。2010年10月15日時点のオリジナルよりアーカイブ。
- ^ マローン、マイケル・S. (1983年5月16日). 「日立とFBIのテープが公開される」.ニューヨーク・タイムズ.
- ^ アンチョードガイ、マリー(2005年)『日本の再プログラミング:コミュニタリアン資本主義下のハイテク危機』コーネル大学出版局、159頁。
外部リンク
- IBM: z/OS V1R11.0 MVS マニュアル( Wayback Machineより) (2009 年 9 月 5 日アーカイブ)
- IBM: z/OS V1R8.0 MVS マニュアル( Wayback Machineより、2006 年 11 月 4 日アーカイブ)
- 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.