IBM 未来システムプロジェクト

フューチャー システム プロジェクト( FS )は、1970 年代初頭にIBMで実施された研究開発プロジェクトであり、最新の強力なハードウェアを活用してソフトウェア開発を簡素化する新しいソフトウェア モデルを含む、革新的なコンピュータ製品ラインを開発することを目的としていました。新しいシステムは、1970 年代後半に市場で System/370に取って代わることを目的としていました。

FS には 2 つの重要な要素がありました。1 つ目は、シングル レベル ストアの使用です。これにより、ディスク ドライブなどの二次記憶装置に格納されたデータを、プログラム内でメイン メモリに格納されているデータであるかのように参照できます。コード内の変数は記憶装置内のオブジェクトを指すことができ、それらはメモリに目に見えない形でロードされるため、ファイル処理用のコードを書く必要がありません。2 つ目は、高水準プログラミング言語のステートメントに対応する命令を組み込むことです。これにより、コンパイラが言語からマシン コードに変換する必要なく、システムがプログラムを直接実行できます。たとえば、テキスト エディターでプログラムを作成すれば、マシンでそれを直接実行できます。

2 つのコンセプトを 1 つのシステムに 1 つのステップで統合することは不可能であることが判明しました。この懸念はエンジニアによって最初から指摘されていましたが、さまざまな理由から経営陣とプロジェクト リーダーによって無視されました。1971 年秋に正式に開始されたプロジェクトは 1974 年までに終焉を迎え、1975 年 2 月に正式にキャンセルされました。シングル レベル ストアは System /38に実装され、その後ラインナップ内の他のシステムにも導入されましたが、高水準言語を直接実行するマシンというコンセプトは IBM 製品に登場したことはありませんでした。

System /360 は1964 年 4 月に発表されました。わずか 6 か月後に、IBM は市場でどのようなトレンドが起こっているか、そしてそれを将来 360 に代わるマシン シリーズにどのように活用すべきかについての研究プロジェクトを開始しました。重要な変更点の 1 つは、便利な集積回路(IC) の導入です。これにより、360 の多数の個別コンポーネントを、より少ない数の IC に置き換えることができます。これにより、既存のモデルと同じ価格で、より強力なマシンを製造できるようになります。^[1]

1960年代半ばまでに、360は大ベストセラーとなった。このことが新しいマシンの設計に影響を与え、マシンには360シリーズとの完全な下位互換性が求められるようになった。1970年に発表されたマシン（現在はSystem /370として知られる）は、基本的には360で、ロジックに小規模なICを使用し、内部メモリを大幅に増やし、その他の変更は比較的軽微だった。^[2]いくつかの新しい命令が追加され、他の命令が整理されたが、プログラマーの観点からはシステムはほぼ同一であった。^[3]

1969年から1970年にかけての不況により、1970年から1971年にかけての売上は鈍化し、5年前の360の急速な普及に比べると370の受注は大幅に減少した。^[4]数十年ぶりにIBMの成長は停滞した。社内の一部は370をより魅力的にするためにできるだけ早く有用な改良を導入する努力を始めたが、他の者はシステムを完全に作り直す以外に長期的には効果がないと考えていた。^[3]

370 の発表の 2 か月前に、同社は再び市場の変化とそれが将来の設計にどのような影響を与えるかを検討し始めました。^[3] 1965 年、ゴードン・ムーアは、集積回路がサポートする回路の数が指数関数的に増加すると予測しました。これは今日ではムーアの法則として知られています。IBM のジェリア・A・ハッダッドはこのトピックに関するメモを書き、ロジックとメモリのコストが測定できるよりも速いペースでゼロに近づいていることを示唆しました。^[3]

社内のコーポレート テクノロジー コミッティ (CTC) の調査では、メモリの価格が今後 5 年間で 30 分の 1 に低下し、その後の 5 年間でさらに 30 分の 1 に低下すると結論付けられました。IBM が売上高を維持するためには、5 年間で 30 倍のメモリを販売し、さらに 5 年後には 900 倍のメモリを販売する必要があります。同様に、ハード ディスクのコストは今後 10 年間で 10 分の 1 に低下すると予想されています。従来の年間 15% の成長率を維持するには、1980 年までにディスク容量を 40 倍、メモリを 3600 倍販売する必要があります。^[4]

コンピュータ自体について言えば、360 から 370、そして仮想の System/380 へと進化していくと、新しいマシンは大規模統合に基づいており、複雑さとコストが大幅に削減されるだろう。現在の価格でそのようなマシンを販売することは不可能であり、もし販売しようとすれば、別の会社がはるかに安価なシステムを導入するだろう。^[3]代わりに、同じ価格帯ではるかに強力なマシンを製造することは可能だが、顧客はすでに既存のシステムを十分に活用していなかった。新しいハイエンド マシンを購入する合理的な理由を提供するために、IBM は顧客がこの追加のパワーを必要とする理由を考え出す必要があった。^{[5] [6]}

もう一つの戦略的な課題は、コンピューティングのコストが着実に下がっている一方で、人件費で構成されるプログラミングと運用のコストが着実に上昇していることでした。そのため、ハードウェア ベンダーに提供される顧客の IT 予算の一部は今後数年間で大幅に削減され、IBM の収益基盤もそれとともに減少することになります。IBM は、将来の製品でアプリケーション開発と運用のコストに対処することにより、同時に顧客の IT 総コストを削減し、そのコストのより大きな部分を獲得することが不可欠でした。^[6]

1969 年、IBM 最大のメインフレームを開発したシステム開発部門の社長、ボブ・O・エバンスは、IBM ポキプシー研究所のエリック・ブロックに、これらのはるかに安価なコンポーネントを使用して、会社の利益を維持できるマシンを構築する方法を検討するよう依頼しました。ブロックは、カール・コンティにそのようなシステムの概要を依頼しました。「未来のシステム」という用語が使用されているのを見て、エバンスはグループを Advanced Future Systems と呼びました。グループはほぼ 2 週間ごとに会合を開きました。

AFS の下で最初に研究された多くの開発の中で、1 つの概念が際立っていました。当時、仮想メモリ(VM) を備えた最初のシステムが登場し、独創的なMulticsプロジェクトがこの概念をシングルレベル ストアの基礎として拡張しました。この概念では、システム内のすべてのデータはメイン メモリにあるかのように扱われ、データが物理的にセカンダリ ストレージに配置されている場合は、プログラムが要求すると VM システムが自動的にそれをメモリにロードします。ファイル内のデータを読み書きするコードを書く代わりに、プログラマーは特定のデータを使用することをオペレーティング システムに伝えるだけで、そのデータはプログラムのメモリ内のオブジェクトとして表示され、他の変数と同様に操作できます。VM システムにより、必要に応じてデータがストレージと同期されます。^[7]

バブルメモリの出現により、将来のシステムには別々のコアメモリとディスクドライブがなく、代わりにすべてが大量のバブルメモリに保存されることが示唆されていたため、これは当時特に有用な概念と見なされていました。^[7]物理的には、システムは単一レベルのストアであるため、別のストレージを表す「ファイル」用の別のレイヤーを持つという考えは意味がなく、単一の大きなメモリへのポインタを持つことは、ローカルであるかのように任意のデータを参照できるだけでなく、同じデータがロードされているかどうかに応じて、同じデータに対して別々のアプリケーションプログラミングインターフェイス(API) が必要なくなることを意味します。^[7]

エヴァンスはまた、IBM のアーモンク本社のジョン・マクファーソンに、IBM がこれらの新しい設計を多くの部門にどう提供していくかを検討する別のグループの議長を務めるよう依頼した。3 つの部門にまたがる 12 人の参加者のグループは、「高レベル システム レポート」、つまり HLS を作成し、1970 年 2 月 25 日に提出した。HLS の重要な要素は、プログラミングはハードウェアよりも高価であるという考えであった。システムによって開発コストを大幅に削減できれば、そのシステムはより高値で販売できる。なぜなら、全体的な運用コストは競合製品よりも低いままだからである。^[8]

System/360 シリーズの基本概念は、アセンブリ言語プログラマが望む可能性のあるすべての命令を提供する単一の命令セットアーキテクチャ(ISA) を定義することでした。以前のシステムは科学プログラミングや通貨計算専用で、その種のデータ用の命令を持っていましたが、360 ではこれらと、実質的に他のすべてのタスク用の命令を提供しました。次に、特定のワークロードを対象にした個別のマシンが設計され、それらの命令をハードウェアで直接実行し、他の命令をマイクロコードで実装しました。つまり、360 ファミリのどのマシンでも、タスクに応じて高速または低速になるだけで、他のどのプログラムも実行できました。これは非常に成功しました。顧客はローエンドのマシンを購入し、将来いつでもより高速なマシンにアップグレードでき、すべてのアプリケーションが引き続き実行されることがわかっていたからです。

360 の命令セットは大規模でしたが、それらの命令は依然として低レベルで、中央処理装置(CPU) が実行する「2 つの数値を加算する」や「この数値を 0 と比較する」などの単一の操作を表していました。プログラミング言語とオペレーティング システムへのリンクにより、ユーザーは「ファイルを開く」や「これらの配列を加算する」などの高レベルの概念を使用してプログラムを入力できました。コンパイラは、これらの高レベルの抽象化を一連のマシン コード命令に変換します。

HLS の場合、命令は代わりにそれらの高レベルのタスクを直接表します。つまり、マシン コードに「ファイルを開く」命令があることになります。プログラムがこの命令を呼び出した場合、これを低レベルのコードに変換する必要はなく、マシンはマイクロコードまたは直接ハードウェア実装で内部的にこれを実行します。^[8]これはシングル レベル ストアと連携して機能しました。HLS を実装するために、システム内のすべてのデータは、データのタイプ、メモリ内の位置、精度、サイズを含むレコードである記述子とペアになっています。記述子は配列やレコード構造も指すことができるため、マシン言語はこれらをアトミック オブジェクトとして処理できます。^[8]

これらのはるかに高レベルのオブジェクトをシステム内で直接表現することで、ユーザー プログラムははるかに小さく、シンプルになります。たとえば、従来の言語でファイルに保存されている 2 つの数値配列を加算する場合、通常は 2 つのファイルを開き、それぞれから 1 つの項目を読み取り、それらを加算して、その値を 3 番目のファイルに格納します。HLS アプローチでは、ファイルを開いて add を呼び出すだけです。基盤となるオペレーティング システムはこれらをメモリにマップし、両方が配列であることを示す記述子を作成します。次に、add 命令はこれらが配列であることを確認し、すべての値を一緒に加算します。その値を新しく作成された配列に割り当てると、その値がストレージに書き戻されます。1 ページ程度のコードが必要になるプログラムが、数行にまで削減されました。さらに、これはマシンの自然言語であるため、コマンド シェル自体も同様にプログラム可能であり、このような単純なタスクのために「プログラムを書く」必要はなく、コマンドとして入力できます。^[8]

報告書は次のように結論づけている。

簡潔なプログラムのコーディングとデバッグが容易になることで、ユーザーとIBMはともに大きな利益を得ることになります。プログラムの品質とプログラマの生産性が向上するため、プログラミングのコストと複雑なプログラムのサイズが大幅に削減されると期待しています。^[8]

1960年代末まで、IBMは利益のほとんどをハードウェアで稼いでおり、システムの魅力を高めるためにサポートソフトウェアとサービスをシステムにバンドルしていました。価格が付けられていたのはハードウェアのみでしたが、その価格にはソフトウェアとサービスへの割り当ても含まれていました。^[7]

他のメーカーは、主にテープやディスクドライブなどの周辺機器をIBMより大幅に安い価格で互換性のあるハードウェアに売り始めていたため、ソフトウェアとサービスのコストを回収できる基盤が縮小しました。IBMは、これらのサードパーティのアドオンを搭載したマシンのサービスを拒否することで対応しましたが、これはほぼ即座に広範な反トラスト調査とその後の多くの法的救済につながりました。1969年、同社はバンドル契約を終了せざるを得なくなり、ソフトウェア製品を個別に販売すると発表した。^[9]

ジーン・アムダールは、ソフトウェアなしで互換機を販売するチャンスを見出しました。顧客はアムダールからマシンを購入し、オペレーティング システムとその他のソフトウェアを IBM から購入できるのです。IBM が販売を拒否した場合、法的義務に違反することになります。1970 年初頭、アムダールは IBM を辞め、IBM のハイエンド製品よりも高速で、購入と運用のコストが低い System/370 互換機を導入する意向を発表しました。^[10]

当初、IBM は気にしていなかった。IBM はソフトウェアとサポートで収益の大部分を稼いでおり、その収益は依然として IBM に流れていた。しかし、1971 年初頭に IBM 社内のタスク フォースである Project Counterpoint が結成され、このコンセプトを研究した。彼らは、互換メインフレーム ビジネスは確かに実行可能であり、ハードウェア価格の一部としてソフトウェアとサービスに課金する根拠はすぐに消滅するだろうという結論に達した。これらの出来事により、IBM 内では、顧客にすべてを IBM から購入するよう強制するが、独占禁止法に違反しない方法で何らかの解決策を見つけたいという願望が生まれた。^[7]

IBMがHLSレポートの提案に従った場合、他のベンダーは膨大な数の命令を実装するマイクロコードをコピーしなければならないことになります。これはソフトウェアであるため、他のベンダーがコピーした場合、それらの企業は著作権侵害の対象となります。^[7]この時点で、AFS/HLSの概念は社内で新たな注目を集めました。

1971 年 5 月から 6 月にかけて、当時 IBM 副社長だったジョン・オペルの指揮のもと、国際タスク フォースがアーモンクで招集されました。その任務は、IBM の技術的優位性を生かして、これまでのすべてのコンピューター (互換性のある製品だけでなく IBM 自身の製品も) を時代遅れにする新しいコンピューター ラインの実現可能性を調査することでした。タスク フォースは、このプロジェクトは追求する価値があるが、市場で受け入れられるかどうかの鍵は、アプリケーション ソフトウェアの開発、運用、保守にかかるコストを大幅に削減することであると結論付けました。

その結果、FS プロジェクトの主な目的は次のように述べられました。

• 最新の技術をフル活用して、IBMを含む既存のすべてのコンピューター機器を時代遅れにする。
• アプリケーションの開発と運用にかかるコストと労力を大幅に削減します。
• IBMの製品（ハードウェア、ソフトウェア、サービス）を可能な限り再バンドルするための技術的に健全な基盤を提供する

コストが低下しているハードウェア リソースをより有効活用する新しいアーキテクチャにより、ソフトウェア開発が大幅に簡素化され、IBM と顧客の両方のコストが削減されると期待されていました。

FS の設計原則の 1 つは、仮想メモリ(VM)の考え方を拡張して永続的なデータをカバーする「シングル レベル ストア」でした。従来の設計では、プログラムはデータを表す値を保持するためにメモリを割り当てます。このデータは通常、マシンの電源を切るかユーザーがログアウトすると消えてしまいます。このデータを将来も利用できるようにするためには、ハード ドライブなどの永続的なストレージに書き込み、後で読み戻すための追加コードが必要です。これらの一般的な操作を容易にするために、プログラムがデータをエンジンに渡し、エンジンがデータを保存して必要に応じて再度取得できるようにするデータベース エンジンが1960 年代に数多く登場しました。

当時、もう 1 つの新しい技術として仮想メモリの概念がありました。初期のシステムでは、プログラムがデータに割り当てることができるメモリの量は、システム内のメイン メモリの量によって制限されていました。メイン メモリの量は、マシン間での移動や、他のプログラムが独自のメモリを割り当てているかどうかなどの要因によって変わる可能性があります。仮想メモリ システムは、すべてのプログラムが使用できるメモリの最大量 (通常は非常に大きな数値で、マシンの物理メモリよりもはるかに大きい) を定義することで、この問題に対処しました。プログラムが物理的に利用できないメモリの割り当てを要求した場合、メイン メモリのブロックがディスクに書き出され、そのスペースが新しい割り当てに使用されます。プログラムがオフロードされた (「ページング」または「スプール」された) メモリ領域からデータを要求すると、そのデータは目に見えない形で再びメイン メモリにロードされます。^[11]

シングルレベル ストアは、基本的に仮想メモリを内部または外部のすべてのメモリに拡張したものです。VM システムはメモリをディスクに目に見えない形で書き込みます。これはファイル システムと同じタスクなので、ファイル システムとして使用できない理由はありません。プログラムが「メイン メモリ」からメモリを割り当て、その後 VM によって他のバックアップ ストアに送信されるのではなく、すべてのメモリが VM によって即時に割り当てられます。つまり、データを保存して読み込む必要がなく、メモリに割り当てるだけで、VM システムが書き出すときにその効果が得られます。ユーザーが再度ログインすると、そのデータと、同じ統合メモリ内にあるそのデータを実行していたプログラムが、以前と同じ状態ですぐに使用できるようになります。読み込みと保存の概念全体が削除され、プログラムとシステム全体が、マシンの再起動後も元の状態に戻ります。

この概念はMulticsシステムで検討されていましたが、非常に遅いことが判明しました。しかし、これは、メインメモリがコアに実装され、ハードドライブまたはドラムの形ではるかに低速なバックアップストアが使用されている利用可能なハードウェアの副作用でした。コアと同様の速度で動作し、ハードディスクと同様のメモリ密度を持つ新しい形式の不揮発性メモリ、最も有名なのはバブルメモリ^[7]の導入により、シングルレベルストアのパフォーマンス上の欠点はなくなったように見えました。

フューチャー・システムズは、シングルレベル・ストアを新しいオペレーティング・システムの主要コンセプトにすることを計画していた。プログラマーが呼び出す別のデータベース・エンジンを用意する代わりに、システムのアプリケーション・プログラミング・インターフェース(API) でメモリを取得する呼び出しを行うだけだった。そして、それらの API 呼び出しは、IBM システムでのみ利用可能な特定のハードウェアまたはマイクロコード実装に基づいており、それによって、ハードウェアとその上で実行されるプログラムを緊密に結び付けるという IBM の目標を達成した。^[7]

もう一つの原則は、非常に高水準の複雑な命令をマイクロコードで実装することであった。例えば、命令の1つであるCreateEncapsulatedModuleは完全なリンケージエディタであった。他の命令は、 FORTRAN、COBOL、PL/Iなどのプログラミング言語の内部データ構造と操作をサポートするように設計された。事実上、FSは究極の複合命令セットコンピュータ（CISC）となるように設計された。^[7]

同じ概念を別の方法で表現すると、以前はハードウェア、オペレーティング システムソフトウェア、データベースソフトウェアなどとして実装されていた機能の集合全体が、1 つの統合システムを構成するものと見なされ、すべての基本機能が回路、マイクロコード、従来のソフトウェアなど、多くのレイヤーのいずれかで実装されるというものです。マイクロコードとコードの複数のレイヤーが検討され、ピココードまたはミリコードと呼ばれることもあります。そのため、話す相手によっては、「マシン」という概念自体が、回路として実装された機能 (ハードウェア専門家の場合) から、実装に関係なくユーザーに提供される機能の完全なセット (システム アーキテクトの場合) までの範囲に及びました。

全体的な設計では、メイン プロセッサの外部で主に入出力操作を処理する「ユニバーサル コントローラ」も必要でした。このユニバーサル コントローラの命令セットは、I/O に必要な操作に限定され、縮小命令セット コンピュータ (RISC) の概念の先駆けとなりました。

一方、初期の IBM コンピュータの主任設計者の 1 人であるJohn Cocke は、初の縮小命令セット コンピュータ ( RISC ) を設計するための研究プロジェクトを開始しました。^[要出典] 長い目で見れば、最終的に IBM のPOWER、PowerPC、およびPowerアーキテクチャへと進化したIBM 801 RISC アーキテクチャは、実装コストがはるかに安く、はるかに高いクロック レートを実現できることが証明されました。

FS プロジェクトは、1971 年の第 2 四半期に結成された特別タスク フォースの勧告に従って、1971 年 9 月に正式に開始されました。時が経つにつれ、IBM のさまざまな場所で行われた他のいくつかの研究プロジェクトが FS プロジェクトに統合されたり、関連付けられたりしました。

FS プロジェクトは、その全期間を通じて、厳重なセキュリティ対策の下で実施されました。プロジェクトは、さまざまなチームに割り当てられた多数のサブプロジェクトに分割されました。ドキュメントも同様に多数の部分に分割され、各ドキュメントへのアクセスはプロジェクト オフィスによる必要性の確認の対象となりました。ドキュメントは追跡され、いつでも呼び戻すことができました。

ソヴァのメモ（下記の外部リンクを参照）には、「こうした官僚主義の公然たる目的は、誰もシステム全体を理解できないようにすることであり、この目標は確かに達成された」と記されている。

その結果、プロジェクトに携わるほとんどの人は、期待される貢献をするために知っておく必要のあることだけしか知らず、プロジェクトについて非常に限定された見方しかしていませんでした。一部のチームは、FS について知らずに取り組んでいました。これが、FS を定義するように求められたときに、ほとんどの人が FS と自分の専門分野との共通部分に限定した非常に不完全な答えを返す理由です。

FSアーキテクチャの3つの実装が計画されていました。最上位モデルは、IBMの最大かつ最速のコンピュータが製造されたニューヨーク州ポキプシーで設計されていました。次のモデルは、ミッドレンジコンピュータを担当するニューヨーク州エンディコットで設計されていました。その下のモデルはドイツのベーブリンゲンで設計されていました。そして、最小のモデルはイギリスのハースリーで設計されていました。^[12]

4 つの実装レベルそれぞれでシステム内のプロセッサの数を変えることで、連続的なパフォーマンス範囲を提供できます。

1973 年初頭、全体的なプロジェクト管理と、すべての実装に共通するより「外側」のレイヤーを担当するチームが、Mohansic ASDD 研究所 (アーモンク/ホワイト プレーンズ本社とポキプシーの中間) に統合されました。

FS プロジェクトは 1975 年に終了しました。プロジェクト終了の理由は、質問者によって異なり、それぞれが自分の専門分野に関連する問題を挙げます。実際には、プロジェクトの成功は、回路設計と製造からマーケティングとメンテナンスまで、すべての領域における多数のブレークスルーに依存していました。個々の問題は個別に解決できたかもしれませんが、すべての問題を時間内に相互に互換性のある方法で解決できる可能性は事実上ゼロでした。

症状の 1 つは、最大の実装のパフォーマンスが低かったことですが、プロジェクトは、RISC と CISC 設計の長所に関する IBM 社内の議論など、さまざまな技術的側面に関する長引く社内論争によっても損なわれました。命令セットの複雑さも別の障害でした。IBM のエンジニアによって「理解不能」とみなされ、システム全体のシングルレベル ストアを部分的にバックアップできないという強い兆候があり、^{[説明が必要]、} IBM AS/400 が System/38 のシングルレベル ストアを分割することを予見していました。^{[13] [説明が必要]}さらに、シミュレーションでは、ハイエンド マシンでのネイティブ FS 命令の実行は、同じマシン上のSystem/370 エミュレータよりも遅いことが示されました。^[14]

FS プロジェクトは、360 アーキテクチャの顧客向けの合理的なアプリケーション移行パスがないため、顧客の受け入れが当初の予想よりもはるかに制限されることが IBM によって認識されたため、最終的に終了しました。真に革新的なシステムを設計するための最大限の自由度を確保するために、アプリケーション移行の容易さは FS プロジェクトの主要な設計目標の 1 つではなく、新しいアーキテクチャを前提としたソフトウェア移行支援によって対処されることになっていました。結局、COBOL およびアセンブリ言語ベースのアプリケーションへの大量のユーザー投資を FS に移行するコストは、多くの場合、新しいシステムを取得するコストよりも高くなる可能性が高いことがわかりました。

FSプロジェクト全体は終了したが、3台のマシンのうち最小のマシンのアーキテクチャの簡略版はロチェスターで開発が続けられた。最終的にIBM System/38としてリリースされ、プログラミングのしやすさという点では優れた設計であることが証明されたが、ひどくパワー​​不足だった。AS/400は同じアーキテクチャを継承したが、パフォーマンスが向上した。どちらのマシンでも、コンパイラによって生成された高水準命令セットは解釈されず、低水準マシン命令セットに変換されて実行される。元の低水準命令セットは、System /360命令セットといくつかの類似点を持つCISC命令セットだった。^{[15]後のマシンでは、低水準命令セットは、ジョン・コックのRISCマシンから進化した}PowerPC命令セットの拡張バージョンだった。専用のハードウェア・プラットフォームは、2008年にIBM iオペレーティング・システムを実行するIBM Power Systemsプラットフォームに置き換えられた。

FS アーキテクチャの多くを継承した System/38 と AS/400 のほかにも、Future Systems テクノロジの一部が IBM 製品ラインの次の部分に組み込まれました。

• IBM 3081メインフレームコンピュータは、基本的にポキプシーで設計された最高級のマシンで、System/370エミュレータマイクロコードを使用し、FSマイクロコードを削除して使用しました。
• 3800レーザープリンタ、そしてIBM 3279端末とGDDMにつながるいくつかのマシン
• IBM 3850自動磁気テープライブラリ
• IBM 8100ミッドレンジコンピュータは、 FS入出力処理を目的としたユニバーサルコントローラと呼ばれるCPUをベースにしていた。
• VTAMおよびNCPに関するネットワークの強化

• Aspray, Bill (2000 年 9 月 24 日)。「Gene Amdahl 口述歴史」(PDF) (インタビュー)。
• Pugh, Emerson W. (1995)。IBMの構築: 業界とテクノロジーの形成。MIT 出版。ISBN 0-262-16147-8。
• Pugh, Emerson W.; et al. (1991). IBM'S 360 and Early 370 Systems . MIT Press. ISBN 0-262-16123-0。
• Case, Richard (2006 年 12 月 7 日)。「Richard Case のオーラル ヒストリー」(PDF)。コンピュータ歴史博物館(インタビュー)。Burton Grad によるインタビュー。

• 「IBM で何が悪かったのか」に関する本のレビュー。特に、Future Systems プロジェクトと IBM の全体的な歴史との関係について論じています( Wayback Machineより、2016 年 6 月 29 日アーカイブ)
• John F. Sowaによる内部メモ。1974 年後半の FS プロジェクトの技術的および組織的な問題の概要を示します。
• IBM Future Systemsの概要