1960年代初頭まで、IBMの「強力な」ソリューションと「予算」ソリューションには互換性がありませんでした。 プログラムの移植は難しく、時には完全に不可能でした。 これは、オペレーティングシステムの違いから周辺機器の違いまで、さまざまな理由によるものです。 自明のように思われるもの-さまざまなソフトウェアおよびハードウェアコンポーネントの互換性は、その後完全にオプションでした。 System / 360の開発中に、同社のエンジニアは、このようなアプローチにより開発とさらなるメンテナンスのコストが大幅に増加すると判断し、新しいシステムを標準化してプログラムの移植とコンピューターメンテナンスを簡素化することを決定しました。
最初は、System / 360コンピューターにジョブのバッチ処理を行う新しいオペレーティングシステムを提供することが計画されていました。 簡単に言えば、実行する必要のある各プログラムは「パッケージ」、つまりプログラム自体と入力データのセットとして記述されます。 これらのパケットは、リソースの優先度と可用性に応じて順番に処理されます。 このアプローチにより、メインフレームの計画への人間の参加を減らし、メインフレームの負荷を最適化して、オーバーヘッドを削減できました。 オペレーティングシステムはOS / 360と呼ばれることになっていました。
このOSの開発者は、これまで解決されなかった信じられないほど野心的なタスクを設定しました。 このオペレーティングシステムは、「マルチプログラミング」のサポートを提供するはずでした。 低速の周辺機器では、一度に1つのプログラムのみを実行すると、システムが外部デバイスからのデータを待機しているときに頻繁にダウンタイムが発生しました。 したがって、最新の非同期プログラミングに似たアプローチが使用されました。 いくつかのプログラムがメモリにロードされ、最初のプログラムが実行のために起動されました。 長い待機が必要な場合、現在のプログラムのコンテキストが保存され、制御は次のプログラムに移されました。これは、最初のプログラムがデータを待っている間に機能します。 この場合、オペレーティングシステムはすべてを常に制御し、ダウンロードしたプログラムを他のプログラムの障害から保護し、リソースへのアクセスを制御する必要がありました。 これはすべて、仮想メモリの概念の欠如により複雑でした。 オペレーティングシステムは、ラインのすべてのモデルで動作するはずだったため、構成は16 KBのRAMから1 MBで、動作速度は1秒あたり数千回から50万回でした。 また、オペレーティングシステムは、外部ドライブをほとんど使用しない複雑な数学的計算から始まり、完全にI / O操作に基づく単純なDBMSアナログで終わる、すべてのプログラムのニーズを満たす必要がありました。
ご覧のとおり、計画は野心的でしたが、時間が不足していました。 ハードウェアの販売準備が整い、競合他社はIBMが最も脆弱な市場セグメントを攻撃し、OS / 360の安定した信頼できるバージョンは生まれませんでした。 さらに、結果のソリューションは、若いモデルの記憶に収まりたくありませんでした。 さらなるアップグレードを約束して、オペレーティングシステムをよりシンプルな形でリリースすることがソロモンの決定でした。
いくつかの中間オプションが開発されました。
BOS / 360（基本OS）-最も単純なローエンドモデル用のシステム。
TOS / 360（テープOS）-磁気テープからの読み込みによる変更のためのシステム。
DOS / 360（名前にもかかわらず、おなじみのx86時代のDOSとは何の関係もありませんでした）-ほとんどの中規模で強力な構成の「メイン」バージョン。
PCP（Primary Control Program）は、マルチプログラミングをサポートしなかったフルOS / 360の「ベータ版」と呼ばれるものです。
Series / 360-67のリリースまでに（記事の最初の部分を読んだ場合、仮想メモリの概念がこのシステムに登場したことを覚えておく必要があります）、TSS / 360（Time Sharing System）のリリースが計画されました。 名前が示すように、このバージョンはタイムシェアリングモードをサポートすることになっています。 このオペレーティングシステムの試用版は、大企業のクライアント向けのテスト用に提供されましたが、レビューは否定的であり、市場状況を考慮してOSはすでに「遅れ」ていたため、TSS / 360はキャンセルされました。 この時点で、IBMのケンブリッジリサーチセンターで開発されていたCP-67 OSは、すでに十分にデバッグされていました。 CP-67は非常に安定していたため、IBMはタイムシェアリングをサポートするOSとしての「保証の放棄」の条件の下で、顧客への提供を開始しました。 このオペレーティングシステムのさらなる開発により、VM / 370、次にz / VMの基盤が形成されました。
」
IBMがOS / 360を開発する際に直面した問題は非常に大きいため、「ソフトウェアエンジニアリング」の開発に弾みをつけました。 その後、これらのプロセスのソフトウェア開発と管理はリソース集約型の分野であり、制御された結果を得るには科学的アプローチを適用する必要があることが明らかになりました。
すべてを個人的に担当した上級OS / 360開発プロジェクトマネージャーは、ソフトウェア開発マネージャーのほぼ聖書になった本を書きました（著者が「誰でも読んでいるが、誰もそれを読んでいない」）。 はい、フレデリックブルックスと彼の著書「Mythical Man-Month」について話しています。
Brooksが策定したすべての原則の中で、次の2つはOS / 360プロジェクトの本質を最も明確に特徴付けています。
プロジェクトにリソース（人的リソースを含む）を追加しても、その時間が短縮されるとは限りません。多くの場合、その効果は逆になります。 本で述べたように、関与するプログラマの数に関係なく、Algolコンパイラの開発には常に6か月かかります。
開発者はユーザーのすべての希望を実現しようとするため、成功したシステムの新しいバージョンは失敗する運命にあります。 ブルックスはそれを「第二のシステム効果」と呼んだ。
ご覧のとおり、一方で、OS / 360のメインバージョンの開発は、完全な障害にならなかったとしても、それに非常に近いものです。 一方、IBMはこれにもかかわらず、System / 360を成功させることに成功し、これから学んだ教訓がソフトウェア開発への最新のアプローチの基盤となりました。
続く