IBMメインフレーム用オペレーティングシステムの歴史は、世界最大のメインフレーム機メーカーとして長期に渡り君臨したIBMの歴史であり、オペレーティングシステムの歴史の中でも特に注目に値する。
IBMが初期にメインフレーム用としてユーザーに提供していたオペレーティングシステム (OS) は、CP-67以降から実装された仮想マシン以外はそれほど革新的といえるものではなかった。しかし実績のある確かなテクノロジーを優先する同社の姿勢は評判を呼び、コンピュータの購入希望者はIBMのシステムであれば間違いないと納得しやすかった。IBMのメインフレーム用OSであるz/OS、z/VM、 z/VSE、z/TPFは、1960年代に開発されたOSの後継バージョンで、大幅に改良されている。
当記事ではIBM提供のOS以外にも、IBM以外が提供したIBMメインフレームで著名なOSについても記載する。
System/360以前 当初IBMはOSを開発していなかった。ゼネラルモーターズは自社が所有するIBM機のために、1955年にGeneral Motors OSを開発し、1956年にGM-NAA I/Oを開発、また1962年には同業他社のバロウズコーポレーションがMCPを、ゼネラルエレクトリックがGECOSをユーザー向けに開発した。
IBM機用の最初のOSは、1950年代半ばの相場で200万ドルもする非常に高価なマシンを前にして、計算もさせずにジョブを手入力する時間がもったいないと思い、ジョブのキューを管理する仕組みが欲しいと考えたユーザーが開発したものだった。
下記のOSは一部のモデルでのみ動作し、科学技術計算や工学計算にのみ適していた。IBMの別のモデルを持つユーザーや、別のアプリケーションでは、OSなしでなんとかしなければならなかった。しかしIBMの小型機の1つであるIBM 650には、後にOS/360の一部となるある機能があった。もし処理がハード障害を意味する「ランダム処理エラー」で中断された場合、オペレーターが自動でジョブを最初からやり直すのではなく、直近のチェックポイントから自動的に復旧することができた。
ゼネラルモーターズのGM-NAA I/OがIBSYSになるまで ゼネラルモーターズの研究開発部門は、1955年に開発したGM Operating Systemをプロトタイプに、1956年に社内で使っていたIBM 701用にGM-NAA I/Oを開発し、その後701の後継機に対応するようアップデートした。1960年にIBMユーザー互助会SHAREがこれを引き継ぎ、アップデート版のSHARE OSを開発した。
最終的にIBMがこのプロジェクトを引き継ぎ、拡張したバージョンをIBSYSと名付け、IBM 7090用やIBM 7094用として提供した。IBSYSは8台のテープドライブが必要だった(システムが1台以上のディスクドライブを持つ場合はこの数を減らすことができた)。カード方式のジョブ制御言語、FORTRANとCOBOLのコンパイラ、 アセンブラ、ソートプログラムなどの様々なユーティリティなどが付属した。
1958年にミシガン大学はコンピュータシステムにGM-NAA I/Oを採用し、学生が書いた小さなジョブを大量に処理するのに適したUMESを開発した。UMESは1967年にMTSタイムシェアリングシステムへ置き換わるまで使われた。
BESYS ベル研究所はBESYS (別名BELLMON)を開発して1960年代中頃まで使用した。 ベル研究所はこれを無料・無保証で他社にも公開した。
FORTRANモニターシステム IBSYSが登場する前にIBMはIBM 709、7090、7094の各機種用に、FORTRANのプログラムをコンパイルするための単機能OSとしてテープベースのOSであるFMSを開発した。FMSとFORTRANコンパイラは同じテープの中に格納されていた。
初期のタイムシェアリングシステムと仮想マシンシステム MITのフェルナンドコルバトは、メインフレームのIBM 704とIBM 7090を使い、CTSSなどの初期の実験的なタイムシェアリングシステムを1957年から1960年代初頭に開発した。これらのシステムはジョン・マッカーシーから提案されたアイデアに基づいていた describes the origins of timesharing。IBMは自社の複数の研究所で1960年代にタイムシェアリングシステムの実験をしており、市販のメインフレームをベースにハードウェアとマイクロコードを修正して仮想メモリをサポートし、1960年代初頭にIBM M44/44X、1964年から1967年にCP-40、1967年から1972年にCP-67を開発した。CP-67に至っては1968年から1972年までの間に無保証で複数の大手顧客にリリースしていた。CP-40とCP-67にはSystem/360 CPUシリーズに改造が必要だったが、M44/44Xは内部構造が大きく異なる最初期のCPUであるIBM 7044で動作したMelinda Varian, VM and the VM community, past present, and future, SHARE 89 Sessions 9059-9061, 1977; available online at www.princeton.edu/~melinda outstanding source for CP/CMS and VM history。
これらのプロトタイプはIBMが1964年に発売したSystem/360シリーズには間に合わなかったものの、IBMはこれを足掛かりにして1972年に発売したSystem/370で仮想メモリと仮想マシンに対応した。
M44/44Xの仮想マシンは限定的な物であり、スラッシングにより仮想メモリシステムの速度が大幅に低下する可能性があった。スラッシングとは、物理メモリとディスクの間で仮想メモリページをシャッフルするのに多くの時間が割かれてしまい、システムが非常に遅くなる状態のことである。 IBMはCP-40とCP-67の開発を通じてどのようにスラッシング問題に対処すればよいのかを学習した。新たな仮想メモリと仮想マシンのテクノロジーは非常に高速かつ信頼性があり、メインとなる市場での負荷の高い商用システムでの使用に耐えるものだった。自動化された仮想メモリは優秀なプログラマが開発したオーバーレイ方式のプログラムと同様のパフォーマンスをコンスタントに叩きだせるとしてデビッド・セイヤーは会社に採用を迫った。
コンピュータソフトウェアシステムという名前のコンサルティング会社は1968年にリリース版のCP-67を用いて商用タイムシェアリングサービスを提供した。同社の技術チームはMITの卒業生であるディック・オレンシュタインとハロルド・ファインリーブの2人を新卒で採用していた(前述のCTSSを参照)。会社の規模拡大に伴い社名をナショナルCSSに改め、サポートを求める有料ユーザーが増えるようにシステムに大幅な改良を加えてOSの名前をVP/CSSに変えた。1980年代初頭にIBMがVM/370(詳細は後述)を投入して市場を奪われるまで、VS/CSSはナショナルCSSの主力商品だった。
これらの他にも1960年代後半には複数の大学が3つのS/360用タイムシェアリングOSを開発していた。
ミシガンターミナルシステム (MTS)はミシガン大学主導のコンソーシアムが1967年に開発したOS。S/360-67以降の仮想メモリ機能を持つ全てのIBMメインフレーム機に対応していた。MTSは1999年まで運用されたMTS History by Dan Boulet for Everything2.com。 モントリオールのマギル大学は1969年にMUSIC (McGill University System for Interactive Computing)の開発を開始した。MUSICはアップグレードを繰り返し、最終版までにテキスト検索、ウェブサーバ、メールサーバ、ソフトウェア開発ツールなどに対応した。IBMはMUSICを同社のメインフレーム機で動作する主に教育機関向けの安価な選択肢として位置付け、1985年にIBMの公式な製品ラインナップ(MUSIC/SP、Multi-User System for Interactive Computing / System Product)として加えた。公式な最終バージョンは1999年にリリースされた。 ORVYLとWYLBURはスタンフォード大学が1967-68年にIBM S/360-67向けに開発したOSORVYL/370 Timesharing System Functional Description, Stanford University, 1978WYLBUR Reference Manual, Stanford University, 1984。これらによりIBM S/360で初めてタイムシェアリング機能が使えるようになった。
System/360 オペレーティングシステム 1960年代初頭までIBMのローエンドシステムとハイエンドシステムには互換性がなく、プログラムを別のシステムに移植するのは難しく、各システムはディスクドライブなどの周辺機器も異なっていることが多かった。このためIBMではハードとソフトの設計、開発、製造のコストが高騰し、顧客からのアップグレードの要望に応えきれなくなり、そのために売り上げが頭打ちになった。同社が1964年に発売したSystem/360は全てのマシンで共通の周辺機器を使用でき、プログラムもほぼ共有できることが売りとなったChuck Boyer, The 360 Revolution。
元々IBMはバッチ処理に特化したOSであるOS/360だけをSystem/360に提供するつもりだった。後によりシンプルなバッチ処理専用OSであるDOS/360を開発しており、これを開発した理由には主に以下の2つがあった。
System/360のモデルのうち、メモリが少ない小型モデルにはOS/360は大きすぎた。 OS/360の開発が予想以上に遅れており、System/360のハードウェアの売り上げが落ちて市場が崩壊することを防ぐため、隙間を埋めるラインナップの1つとしてDOS/360を提供した。別のラインナップとしてはBOS/360(小型機用のBasic Operating System)とTOS/360(テープドライブだけしか装備していない機種用のTape Operating System)があったChuck Boyer, The 360 Revolution。
System/360のOSはこれまでにIBMが開発したOSの中でも特に複雑で、それには以下のような理由があった。
マルチタスクのサポート。ディスクの読み込みなどのI/O処理が完了するのを現在のアプリケーションがブロック処理で待っている間に別の動作中のアプリケーションへ切り替える。マルチタスクに対応しなければこのクラスのCPUが持つ高い処理能力のほとんどを遅いI/O操作に対する待ち時間で浪費してしまう。従ってシステムを司る心臓部としてOSを位置づけ、アプリケーションに対する正当な要求に全て応じつつ、もしアプリケーションがクラッシュしたり永久ループなどの誤動作が生じた場合は、同時に動作している別のアプリケーションに影響を与えないよう対処することが求められた。 様々なクラスのマシンをサポート。メモリ搭載量が16KBの下位モデルから1MBの上位モデルに対応し、秒間1000命令から50万命令までの命令処理速度に対応した。 様々なアプリケーションの要求に応える。例えばあるアプリケーションではファイルを先頭から最後まで読むだけでよいが、別のアプリケーションでは巨大なファイルの特定のレコードに高速にランダムアクセスする必要があり、また別のアプリケーションでは処理時間のほとんどを計算に費やしておりディスクをほとんど読み書きしなかった。
こうした厳しい要求によりOS/360や他のSystem/360用ソフトウェアの開発は当時としては前人未到の大規模プロジェクトとなり、間もなくIBMは問題に直面し、膨大な時間と費用をかけて大量のバグに対処しなければならなくなった。PCがなくクロスコンパイラやエミュレーターもない当時の開発環境では、System/360のOSを実機上で開発してテストしなければならず、問題は大きくなる一方で、IBMはBasic Programming Support / 360 (BPS/360)を先に開発しなければならなくなった。BPSはDOS/360やOS/360を開発するのに必要なツールを開発するのに使われ、FORTRANとCOBOLのコンパイラやソートなどのユーティリティ及びこれら全てをビルドするのに必要だったアセンブラなどのツールがあり、これらのツールはDOS/360やOS/360にも含まれた。
IBMの競合他社はOS/360とSystem/360の開発が遅れたことを利用し、IBM市場の最大の弱点をシステムと捉え、各社ともOSを発表した。IBMはSystem/360のセールスが失敗するのを防ぐため4つの間に合わせのOSを繋ぎでリリースしたChuck Boyer, The 360 Revolution。
Basic Operating System / 360 (BOS/360) - ディスクドライブまたはテープドライブから起動し、テープドライブと数種類のディスクドライブをサポートする。このシステムはベータテストのユーザーに提供されたもので、DOS/360の初期バージョンと考えることもできる。 TOS/360 - テープドライブを装備し、ディスクドライブを装備していないIBM 1401シリーズのコンピュータを持つユーザーへのアップグレードパスとして提供するべく開発された。 DOS/360 - BOS/360やTOS/360に向けたアプリケーションを開発していたIBMのスモールビジネスコンピュータ部門の開発者がビルドしたもので、その後広く普及して主力のOSとなったz/VSEの祖先。 Operating System/360 (OS/360)で、マルチタスクをサポートしないPrimary Control Program (PCP)の構成で固定されたもの。
IBMはS/360-67の発表と同時に、360/67の新しい仮想メモリ機能を活用したタイムシェアリングOSのTSS/360も発表した。TSS/360のリリースは遅れ、初期バージョンは遅くて不安定だった。当時既にIBMのケンブリッジ科学センターがCP-67を別途開発しており、タイムシェアリング機能としてIBMが一部の大口顧客向けに無保証ながら提供しているほどに上手く動作していた。CP-67はVM/370にアップグレードし、最終的にはz/VMとなった。IBMはTSS/360を導入したユーザーにアップグレードパスのTSS/370 PRPQを3度リリースした後にこれを放棄した。
System/360 OSを開発する際に得られた教訓からソフトウェア工学を学問的に整備しようとする機運が高まり、ソフトウェア開発やプロジェクトマネジメントを科学的に取り扱うようになった。System/360のプロジェクト全体を監督し、後にOS/360の特定パートの責任者となったシニアプロジェクトマネージャーのフレデリック・ブルックスは、プロジェクト中に遭遇した問題や学んだ教訓をもとにベストセラーとなった人月の神話を執筆した。その教訓とは主に次の2つである。
問題が発生しているプロジェクトに追加のリソース(主にスタッフ)を追加投入すると、コミュニケーションが困難になり、急に生産性が落ちて逆効果になることがある。これは書籍のタイトルでもある「人月の神話」症候群である。 成功したシステムの後継版は、元のシステムを使った人からの要望を全て取り込もうとして肥大化し、問題が生じやすい。ブルックスはこれを「セカンドシステム効果」と呼び、OS/360を悪い例として全体的に引用している。
DOS/360
System/360シリーズの中でもハイエンド向けのOSとしてOS/360が推奨された一方で、DOS/360はローエンド向けの非力なマシンに適した平凡なOSだった。これには一連のユーティリティプログラム、マクロアセンブラ、FORTRANやCOBOLのコンパイラなどが含まれていた。RPGがサポートされたのは後年で、最終的にはPL/Iのサブセットが追加された。また様々なファイルの構造をサポートし、そのアクセスを制御するインターフェイスが提供された。
レコード全体を一度に読み込むのに最適なシーケンシャルデータセット。 各レコードの特定のセクションをキーに検索できるインデックス付きファイルのISAM。 アクセスしたいデータのディスク上の物理位置をアプリケーションが自分で指定しなければならないダイレクトアクセスファイルのBDAM。 BDAMのプログラミングは難しく、ユーザーの多くはその使用を望まないが、ディスク上のデータへのアクセスが最も早く、多くのソフトウェア企業は主にADABAS、IDMS、IBM製のDL/Iなどのデータベースマネージメントシステムを用いた。
シーケンシャルファイルとISAMファイルは固定長又は可変長のレコードを格納でき、いずれの組み合わせにおいても複数のディスクボリュームにまたがってデータを格納できる。
DOS/360はまたデータ通信機能としてBTAMも提供しており、今日の基準で見れば大変に使い辛いものだった。しかしBTAMはあらゆる種類の端末と通信でき、通信プロトコルが全く標準化されていなかった当時としては非常に画期的だった。
しかしDOS/360は、System/360機のより大型なモデルで使われたOS/360と比べて制約が大きかった。
最初のバージョンは同時に1つのプログラムしか実行できなかった。後のバージョンでは最大で3つのプログラムを同時に実行できたが、各プログラムのメモリ空間のサイズはDOS/360をインストールする際に各ユーザーがあらかじめ区切った3本のパーティションのサイズに固定された。 ジョブの制御に使用するスクリプト言語のJCLはローエンド機での処理が軽くなるように設計されており、プログラマが読み書きするのは難しかった。 パンチカードやプリンタの処理を効率化するためのスプーラサブシステムがなかった。1960年代後半に独立系ソフトウェア会社がGRASPと呼ばれるスプーラを販売した。 DOS/360にはリロケータブルバイナリローダがなく、ユーザーは使用するパーティションごとに各プログラムのアドレスを絶対アドレスで指定するリンク情報を手動で編集しなけばならなかった。 実行プログラムを格納するコアイメージライブラリは、プログラムを削除したり更新したりした場合に、古いプログラムが格納されていたスペースが解放されなかった。コアイメージライブラリがいっぱいになるとユーティリティプログラムで圧縮しなければならず、これにより開発作業が半日潰れることがあった。 アプリケーションプログラミングのインターフェースがOS/360と異なっていた。COBOLなどの高水準言語で記述されたDOS/360用のプログラムは、OS/360で使用するには若干の修正が必要で、アセンブラで記述かれたプログラムは大幅な変更を強いられた。
DOS/360のユーザーはすぐにOS/360へアップグレードするだろうとIBMは考えていたが、制約があったにもかかわらず、DOS/360は世界で最も広く使われるOSになった。それには次のような理由があった。
System/360機は非常によく売れた。 販売された360システムの90％以上がローエンドのModel 20、30、40だった。 これらの安価なモデルが装備していたコアメモリはほとんどの場合においてOS/360の実行に必要な容量には到底足りなかった。
DOS/360は中規模の企業が購入できるSystem/360機で不都合なく動作しており、またこのクラスのユーザーたちが過去に持っていたマシンが備えていたどのOSよりもまだマシだった。この結果、その子孫であるz/VSEは2005年になっても依然として広く使われている。
OS/360
OS/360は様々なレベルの機能をサポートしており、共通のAPIで、より多くのコードが共通化された。PCPは同時に1つのプログラムだけしか実行できない廉価版で、MFT (一定個数のタスクを実行できるマルチプログラミング版)とMVT(タスクを無制限に実行できるマルチプログラミング版)は、後継機が発売されてから5年が経過した1970年代後半頃まで使用された。PCP、MFT、MVTの3つに分割した理由は明らかではなく、MVTが中間クラスのモデルで使用するにはメモリを喰い過ぎたのか、あるいはIBMがマルチプログラミング版をMFTとして至急リリースしなければならなかったかなどの理由が考えられる。
PCP、MFT、MVTの3つはメモリの管理方法が異なっているが、機能的には非常に似ている(下記参照)。
共通化されたアプリケーションプログラミングインターフェイス(API)。アプリケーションプログラムのバイナリは再コンパイルすることなくPCP、MFT、MVTで実行できる。 DOS/360よりも柔軟で使いやすい同じJCL。 DOS/360と同じファイルの読み書き方式(シーケンシャル、インデックス、ダイレクト)に対応。データ通信のBTAMにも対応している。 新しいパーティション分けされたファイル構造とアクセスインターフェイスであるBPAMに対応。主にプログラムライブラリの管理に用いられた。パーティションはスペースを解放するために圧縮する必要が相変わらずあったが、PCP、MFT、MVTではパーティションの数に制限がなく、プロジェクトごとに1本以上のパーティションを割り当てることができるため、DOS/360のコアイメージライブラリとは異なり作業が止まって開発作業に支障が出ることがほとんどなかった。 ファイルを階層として管理できるようにするファイル名のシステム。PROJECT.USER.FILENAMEなどの命名が可能だった。 スプーラ機能 (DOS/360にはない)。 アプリケーションがジョブの中でサブタスクを生成できるマルチタスクに対応。
OSが256KB未満のシステムにインストールすることは当時の経験から推奨されず、これは1960年代にはどこでもよくある制約だった。
MFT ユーザーはMFTをインストールする際に、メモリを最大で4本のパーティションに固定長で区切ることができ、複数のアプリケーションを同時に実行できるように設定できた。MFTバージョンII (MFT-II)は最大で52本まで上限を緩和した。
MVT MVTはMFTよりもはるかに巨大かつ複雑であり、そのためSystem/360のハイエンド機で用いられた。OSは全ての未使用メモリを単一のプールとして扱い、そこから連続した領域を並列動作するアプリケーションの数に応じて必要なだけ無制限に割り当てることができた。この方式はMFTよりもはるかに柔軟で、仕組み的にメモリを効率よく利用できたが、断片化しやすい問題があった。この問題が顕在化すると、全体としてはプログラムを実行するのに十分な空き容量があるにもかかわらず、各領域が分断されてしまい必要なサイズの連続した空き領域がないという状態に陥った。
1971年にMVTで使えるタイムシェアリングオプション(TSO)機能が追加された。バッチジョブ実行機能、ジョブの完了通知機能、レポートが印刷されるのを待たなくても結果を閲覧できる機能などを持つエディタが含まれていたほか、System/360で使われる一部のプログラミング言語で使用できるデバッガが含まれていたことから、 TSOはプログラムの開発に広く使われるようになった。TSOはTCAM (Telecommunications Access Method)で端末と通信でき、これまで使われていたQTAM (Queued Telecommunications Access Method)と置き換わった。IBMはデータ通信のスタンダードになることを見越してTCAMと名付けたが、結局TCAMはほぼTSO上でしか使われず、1970年代後半にVTAMにほぼ置き換えられた。
TPモニタ System/360のハードウェアとOSは実行に何時間もかかる可能性がある極端なバッチジョブを処理できるように設計されている。そのため各件の処理時間が30秒から数分程度の処理を1日に数千件こなすトランザクション処理には適していなかった。IBMは1968年にトランザクションを処理するためにIMSをリリースし、1969年にはIBMグループの従業員がとある顧客のために開発した、よりシンプルなトランザクション処理システムであるCICSをリリースした。IMSはOS/360とその後継OSでしか利用できなかったが、CICSはDOS/360とその後継OSでも利用できた。この種の製品は長年に渡り「TP（テレプロセッシング）モニタ」と呼ばれていた。厳密に言えば、TPモニタはOSの構成要素ではなく、アプリケーションを管理するためのアプリケーションに過ぎなかった。1970年代と1980年代には複数のサードパーティ (Taskmaster、Shadow、Intercommなど）がTPモニタをリリースしてCICSと競合したが、IBMは継続的にCICSを改善してゆき、ほとんどの顧客がIBMの純正品を使うようになった lists the major 1970s-1980s TP monitors。
航空会社専用システム 航空業界は1950年代に急成長していたが、数千件の予約をカードファイルを使って手作業で裁く手間による物理的な制約があったため伸び悩んでいた。IBMは1957年にコンピュータ予約システムを開発する契約をアメリカン航空と結び、後にこのシステムをSABREと名付けた。1960年にテスト版の稼働を開始し、1964年に全ての予約業務を引き受けるようになり、このプロジェクトでは最初から一貫してIBM 7090メインフレームが用いられた。IBMは1960年代初期には他の航空会社とも同様のプロジェクトを開始し、すぐにSystem/360用の共通予約システムであるPARSを開発することを決めた。
SABREや初期バージョンのPARSにはアプリケーションとOSの区別がなかったが、IBMは1968年にアプリケーション部分のPARSとOS部分のACPに分割した。その後ACPはACP/TPFに改名され、また航空業界以外の業界向けに大量のオンライントランザクションを裁けるOSとしてTPF (Transaction Processing Facility)の名前で提供した。最新バージョンはz/TPFという名前になっている。
IBMの汎用OS(DOS/360やOS/360)は1960年代中盤までバッチ処理に特化しており、大量の短いトランザクションを高速に捌くことができず、汎用OSで動作するトランザクションモニタのIMSやCICSであっても、数百便のフライトの予約を数千の旅行代理店から受け付けるのに十分な処理速度がなかったことから、IBMはACPやその後継版を開発した。
最後のパブリックドメイン版であり無料版のACPはACP 9.2で、1本のミニリールテープで配布され、48インチ幅の棚一列がいっぱいに埋まるほどの数十冊のマニュアルが付属し、IBM 3340のディスクドライブに展開でき、ACPシステムの全機能が完璧に動作する形で提供された。
ACPはマスターカード®などの銀行発行カードや、金融機関向けのアプリケーションを主なユーザーとして想定していたが、航空業界用の予約システムにも利用でき、当時としてはACPは多目的な汎用OSだった。