DOS/360
DOS/360
Disk Operating System / 360 (DOS/360、または単にDOS)はIBMメインフレーム用の歴史上のオペレーティングシステム(OS)。1964年の大晦日にIBMが発表し、1966年6月に最初に提供された。60年代当時DOS/360は世界で最も広く利用されたOSだった。
TOS/360 (Tape Operating System/360、いわゆるDOSではなく、DOSとは呼ばない)はIBMのSystem/360用のOSであり、1965年頃の黎明期にSystem/360 Model 30や同様のプラットフォームをサポートした。
TOSはその名が示す通りテープドライブが必要だった。コードの大半やマニュアルの一部はIBMのDOS/360と共通だった。
TOSは14回に渡って更新された。IBM 7090では高額で贅沢品だったディスクドライブのIBM 2311やIBM 2314が、System/360の時代になると安価になり、TOSは更新されなくなった。
DOS/360は小型モデルから中型モデルまでのS/360で第一選択肢となるOSだった。
DOS/VSは1972年にリリースされた。最初のDOS/ VSには「リリース28」という番号が付けられ、バージョンナンバーはDOS/360からの通算になっていた。新機種のSystem/370シリーズが搭載している仮想メモリ機能をサポートしていた。全てのメモリパーティションを総合すると最大で16MBになる、単一のアドレス空間にマッピングする固定のページテーブルが用いられた。
DOS/VSでは同時にプログラムを実行できるパーティションの本数が3本(バックグラウンド、フォアグラウンド1、フォアグラウンド2)から5本(バックグラウンドとF1からF4)に増強され、システム全体としては15本のサブタスクが同時に動いた。
DOS/VSは後にDOS/VSEからz/VSEへと進化していった。
1979年にリリースしたDOS/VSEは新機種の4300プロセッサをサポートする拡張版のDOS/VS。4300システムにはプロセッサとI/Oチャネルの両方を単一レベルのストレージとして扱えるECPS:VSE機能が搭載されていた。DOS/VSEはECPS:VSEをサポートしていたが、この機能がないSystem/370でもこの機能を使わなければ動作した。DOSが無料で提供されたのはVSEが最後だった。
SSX/VSE (Small System Executive)はOSと人気のアプリをあらかじめ組み合わせたパッケージで、IBMはこれを使ってVSEの販売やインストールを簡略化しようと試みた。SSXは1982年にリリースされ、後に後継のVSE/SPがリリースされた。IBMはSSXに14本のコンポーネント製品(Advanced Functions/VSE、VSE/POWER、ACF/VTAME、VSE/VSAM、CICS/DOS/VS、DOS/VS、Sort/Merge、VSE/ICCF、VSE/OCCF、VSE/IPCS、DOS/COBOL、バックアップ/リストア、スペースマネジメント、VSE/DITTO)をバンドルして販売した。ISVよりバンドル販売が独占禁止法に抵触するとの指摘を受けたIBMは、見積もりを請求すれば個別の販売に応じる妥協案を示して受け入れられたが、再び批判を受けて結局は各製品の単体価格を製品リストに明記することになった。
IBMが1986年にリリースしたVSE/SP (System Product)は9370プロセッサーと共に発表された。VSE/SPはSSX/VSEの後継で、VSE/AF、ACF/VTAM、CICS、POWER/VS等のVSEで最も人気が高い製品がVSEにバンドルされた。顧客はXA(31ビット)バージョンを望んだが、VSE/SPは24ビットアドレスのみをサポートしていた。
1990年にリリースされたVSE/ESAはDOS/VSEの31ビット版で、最大384MBの実ストレージをサポートしていた。最大12本の静的なパーティション分割が可能で、VSE/POWERとACF/VTAMをプライベートアドレス空間で実行できた。新機能の動的パーティションでは最大150個のジョブを並列実行でき、各ジョブには個別のアドレス空間が割り当てられた。バージョン1はESAと370のいずれかのモードで動作し、またESAモードではXAハードウェアを制限付きでサポートした。バージョン2はESAハードウェアでのみESAモードをサポートした。
IBMは2005年にz/VSE 3.1をリリースした。この名前はIBMメインフレームの新商品であるSystem zブランドを表しているが、これまでにリリースされていたVSE/ESA 2.7からアーキテクチャ的な大改革があったことを意味しているわけではなかった。特にz/Architecture機が持つ64ビットの能力に対応しておらず、64ビット機上でも31ビットモードでしか動作しなかった。2007年にリリースされたz/VSE 4.1では64ビットのリアルアドレッシングに対応し、最大で8GBのメモリに対応した。しかしながら、スーパーバイザー部は64ビットで動作したものの、アプリケーションの仮想メモリ空間は31ビットしかなかった。2011年の時点では、z/VSEを使用している組織の数は約4000と推定される。
共通アーキテクチャの新世代機であるSystem/360 (S/360)を開発するにあたり、IBMは当初ローエンドでも動作する共通OSとしてOS/360の1種類だけを提供すると公約していた。しかしハードは完成したにもかかわらず、フレデリック・ブルックスが人月の神話で詳しく書いたとおり、OS/360の開発プロジェクトは計画よりも大幅に遅れた。IBMは4つのOSを早急に追加ででっちあげる必要性に迫られた。
BPS/360 - 8KB以上のコアメモリとパンチカードリーダーを搭載したマシン用。
BOS/360 - 8KB以上のメモリとディスクドライブを搭載したマシン用。
DOS/360 - 16KB以上のメモリとディスクドライブを搭載したマシン用。
TOS/360 - 16KB以上のメモリとテープドライブを搭載したマシン用。
OS/360は1年遅れでようやくリリースされ、最低メモリ容量は64KBだった。DOSは少ないメモリでも動作するように設計されており、16KBでも動作可能で、ローエンドのS/360 Model 30で利用可能な設定があった。OS/360と違いDOS/360は当初マルチタスクをサポートしないシングルジョブシステムだった。後にリリースされた最大3本のメモリパーティションをサポートするマルチタスク版は32KBのメモリが必要だった。System/360はバカ売れし、DOS/360は中堅企業でも購入できる手ごろな価格の構成のSystem/360でも上手く動作し、ユーザーがこれまでに所有してきたどのマシンのOSよりもマシだったことから、前述のような制約があったにもかかわらず、DOS/360は256KB以下のメモリで動作するプロセッサで最も広く使われたOSとなった。
DOS/360はSystem/360が発表されて、当初予定していたOSであるOS/360が利用できるようになるまでの間を持たせるための繋ぎのOSだった。遅延により数多くの顧客がDOSを使うようになり、これらを使用するのに多額の金的・人的投資をした。IBMはDOS/360のユーザーがすぐにOS/360へアップグレードするだろうと考えていたが、顧客は既にDOSへ投資しており、アップグレードの採用に消極的だった。このためIBMはもう1つのOSとしてDOS/360を継続的にサポートし続けなければならなくなった。ジャーゴンファイルにはGECOS (別名GCOS)がDOS/360をコピーしたと書かれており、これはデマだったが、ゼロックスデータシステムのゼロックスOS (XOS)はプログラムの移植を楽にするため意図的にDOSを真似た。
DOS/360に標準命令セット(10進演算命令と浮動小数点命令はオプション)を持つSystem/360 CPUのModel 25以上が必要だった。最小メモリ容量は16KBで、マルチプログラミング(マルチタスク)機能を利用しなければストレージ保護機能は不要だった。1052 Model 7プリンタキーボード、セレクターまたはマルチプレクサーチャネルのいずれか、少なくとも1台のディスクドライブが必要で、当時のディスクドライブ2311は7.25MBの容量があった。カードリーダー、カードパンチャー、ラインプリンタは通常であれば構成に含まれたが、ストレージには磁気テープドライブが選ばれることもあった。
S/360 model 30は32KBのメモリと10進演算命令を搭載し、カードリーダーとカードパンチャーのIBM 2540、プリンターのIBM 1403、IBM 2311ディスクが2~3台、磁気テープドライブのIBM 2415が2台、コンソールの1052-7という構成にするのが一般的だった。
下記の解説は特に明記がない限りDOS/360に固有のものである。以降のバージョンでは機能が強化されている。
DOS/360はSystem/360のローエンドモデルで動作するように設計されたためメモリ消費量が大きな懸念事項だった。OSの常駐部分であるDOSスーパバイザを生成可能で、そのサイズは5902バイト程度だった。詳細チャート図には各sysgenオプションも必要メモリ容量が記載されており、その多くはわずか100バイト程度だった。最小のシステム構成では1本のメモリパーティションに10KB強のストレージが残され、ユーティリティやコンパイラを動かすには普通は十分な容量だったが、COBOL、PL/I、フルセットのFORTRAN IVなどを走らせるには足りなかった。メモリ容量を可能な限り抑えるためDOSはフルアセンブラで記述された。
メモリ消費量をさらに削減するため、スーパーバイザを分割し、一部を必要な時にだけ読み込むトランジェント(仮設置)というオーバーレイ的な仕組みを採用した。トランジェントには物理トランジェントと論理トランジェントの2つがあり、それぞれハードウェア例外やOPEN/CLOSE等のプログラムサービスを提供した。トランジェントモジュールの名前は全て$$Aまたは$$Bで始まり、ディレクトリの先頭に名前の一覧を格納することによりロードの高速化を図った。そのためAトランジェントやBトランジェントなどと呼ばれた。
他の全てのSystem/360用OSと同様に、DOSの初期バージョンでは同時に1つのプログラムしか実行できなかった。その後のバージョンの「リアル」なDOSでは最大3つのプログラムを別々のメモリパーティション上で同時に実行でき、よりスケーラブルなOS/360と同じハードウェアメモリ保護機能がサポートされていた。各パーティションにはBG (バックグラウンド)、F1 (フォアグラウンド1)、F2 (フォアグラウンド2)という名前が付いていた。マルチプログラミング機能はDOS/360ではオプションでありシステム構成時に設定できた。いずれかのフォアグラウンドパーティションでバッチを実行できるSYSGENのオプションもあった。事前に構成していない場合はオペレータが手動でフォアグラウンドプログラムを起動しなければならなかった。
DOS-VSでは最大で7つのプログラムを同時に実行できたが、DOSシステムがインストールされているような規模の小さなシステム上では5~6本までの構成をとるのが普通だった。DOSやDOS-VSではIBMでブートローダを意味する用語であるIPL (Initial Program Load)でパーティションの本数を設定できた。
実行可能プログラムはコアイメージライブラリ(CIL)に格納された。プログラムの実行中はプログラムを削除したり、新しいバージョンに差し替えたりすることができず、スペースをすぐに再利用できなかった。CILがいっぱいになるとユーティリティプログラムで圧縮しなければならず、開発作業が半日止まることがあった。多くのソフトハウスでは日中の更新を我慢して、終業後の夜間にCILを圧縮し、翌朝の始業時に圧縮し終えた新しいCILをIPLで読み込ませた。リンク可能なオブジェクトプログラムのリロケータブルライブラリ、アセンブラマクロのソースステートメントライブラリ、組み込みテキストもサポートされていた。プライベート用のリロケータブルライブラリやソースステートメントライブラリを、インストールする際に別のディスクボリューム上に設定することができた。
DOS/360にはアセンブラ、FORTRANとCOBOLのコンパイラ、様々なファイル構成に対応したインターフェイスなどのユーティリティプログラムが付属しており、後のバージョンではPL/Iも追加された。
シーケンシャルデータセット - 1レコードブロックだけしかなく、最初から最後まで一括で読み書きすることしかできない。
インデックス付きファイル(ISAM) - 各レコードの特定のセクション(カラム)をキーにして検索可能。
ダイレクトアクセスファイル(BDAM) - アプリケーションはアクセスしたいデータのディスク上の物理位置を自分で指定しなければならない。BDAMのプログラミングは難しく、ユーザーの多くはその使用を望まないが、ディスク上のデータへのアクセスが最も早く、多くのソフトウェア企業は主にADABASやIDMS、IBM製のDBOMPやDL/Iなどのデータベースマネージメントシステムを用いた。
シーケンシャルファイルとISAMファイルは、固定長と可変長のレコードを選択でき、全ての形式において複数のディスクボリュームに跨って格納できた。
DOS/360はまたデータ通信機能としてBTAMも提供しており、今日の基準で見れば大変に使い辛いものだった。しかしBTAMはあらゆる種類の端末と通信でき、標準的な通信プロトコルがほぼなかった当時としては非常に画期的だった。APIがシンプルだったことから外部通信プロセッサとの接続が比較的容易で、DOS/360機は大規模組織のネットワークでノードにしやすかった。
DOSジョブ制御ステートメントはカードの先頭2文字が必ず//で始まる。ただし例外として、ジョブの終了は/&␣、データの終了は/*␣、コメントは*␣で始まる(ここでは␣は1文字のスペース記号を表している)。
JOBステートメントは「ジョブの制御情報の始まり」を示す。形式は 。<jobname>はジョブを識別する1~8文字の英数字。<comments>は無視される。
EXECステートメントはジョブステップとして実行するプログラムを示す。このステップの実行に必要なすべての制御ステートメントはEXECステートメントが読まれる前に全て事前に処理されていなければならない。形式は。
PAUSEステートメントは次のジョブステップを実行する前にオペレーターが介入できるようにする。形式は。コメントはオペレータに示すメッセージとなる。
コメントステートメントはオペレータに示すメッセージを表示するために使用する。 形式は* <comment>。
データ終了ステートメントは、入力ストリームのデータ終了を示す。形式は。ステートメント内で空白文字以降のデータは無視される。
ジョブ終了ステートメントはジョブが終了することを示し、もしジョブが異常終了した場合はデータも終了したものとして扱われる。形式は。ステートメント内で空白文字以降のデータは無視される。
OPTIONステートメントはこのジョブに適用するシステムオプションの値を指定する。形式は。
ASSGNステートメントは論理I/Oユニットを物理デバイスに割り当てる。形式は。SYSxxxはSYS001やSYSIPTなどの論理ユニットを示す。<device>には物理デバイス(チャネルやユニット)を示すX'cuu'、無視すること(nullデバイス)を示すIGN、割り当てがないことを示すUAのいずれかを指定する。<tape>には密度やパリティなどのテープモードを指定するか、代替デバイスであることを示すALTを指定する。
RESETステートメントは指定したI/Oユニットの割り当てをデフォルト値にリセットする。形式は。<option>には、システム論理ユニットへの割り当てをリセットするSYS、プログラマによる割り当てをリセットするPROG、あらゆる割り当てをリセットするALL、論理ユニットSYSxxxの割り当てをリセットするSYSxxx(例えばSYS002など)のいずれかを指定する。
LISTIOステートメントは指定したI/Oに現時点で割り当てられている論理ユニットの一覧を全て列挙する。形式は。<option>には、システム割り当てを列挙するSYS、バックグラウンドや指定のフォアグラウンドのパーティションへの割り当てを列挙するPROG、F1、F2、割り当て済みユニットを列挙するALL、SYSxxx、X'cuu'、UNITS、未割当のユニットを列挙するUA、故障中のユニットを列挙するDOWNを指定する。
MTCステートメントは磁気テープ装置にコマンドを発行する。形式は 。<opcode>には1ファイル早送りするFSFや巻き戻すREWなどを指定する。<nn>には同じコマンドを繰り返す数を指定でき、2ファイル早送りする等の操作が可能。
VOLステートメントはラベルチェック用のディスクまたはテープボリュームラベル情報を提供する。形式は 。
初期のDOSではテープのラベル情報にはTPLABステートメントを、ディスクのラベル情報や拡張情報にはDLABステートメントやXTENTステートメントを使う仕様だった。少なくとも1968年にはTPLABはTLBLに変更され、DLABはDLBLに変更された。これらのステートメントでは数多くのポジション情報をパラメータとして指定でき、かなりの情報量があった。
DOS JCLは処理速度と実装のシンプルさを優先して設計された。そのためOS/360のキーワード駆動型ジョブ制御よりも文法的に可読性が悪かった。
初期バージョンのDOSにはパンチカードやラインプリンタのI/O効率を高めるためのスプーラサブシステムがなかった。1960年代後半までにIBMやサードパーティのベンダーがこの欠点を補おうとした。IBMはPOWERというスプーラをオプションで提供し、独立系ソフトウェア会社のSoftware Design社はGRASPというスプーラを販売した。
DOS/360にはリロケータブルバイナリローダがなく、ユーザーは各プログラムのアドレスを絶対アドレスで指定するリンク情報を手動で編集して、目的のパーティションで実行できるように修正しなければならなかった。アセンブラで書いたプログラムは自力でロケーションを再配置することも可能だったが、プログラムが複雑になるうえサイズも肥大化し、わずかしかないメモリで対応するのは大変だった。複数のパーティションで構成される複数台のマシンを所有するDOSの大口ユーザー企業は自社でリロケータブルバイナリローダを開発するところが多かった。
DOS/360とOS/360はAPIに互換性がなかった。高級言語で書かれたDOS用のプログラムはOS/360で実行するためにコンパイルとリンクをやり直す必要があった。大きな差異があったOSとは対照的に、コンパイラの差は小さく、プログラム自体の修正が必要になることはあまりなかった。しかし逆にOS/360用のプログラムをDOSに移植するのは困難だった。OS/360のAPIは非常に多機能であるため、DOSに移植する際にはこれらの機能を使用しないようにプログラムを直す必要があった。COBOLなどの高級言語を使うプログラマにはそれでも大きな問題にはならなかった。一方アセンブラで書かれたプログラムはこれらの機能を頻繁に使う傾向があり、DOSで実行させるためには大掛かりな修正が必要になるのが普通だった。