ウェイン O エバンス
30年以上も前、S/38が開発されていた頃には、まだマイクロソフトもネットスケープもこの世にありませんでした。しかし当時のコンピューターの巨人IBMとライバル会社の市場シェアをめぐる戦いは、今日の次世代ブラウザをめぐる戦いのように熾烈なものでした。IBMはアムダールなどの互換機ベンダーによってハードウェアの売り上げを失っていました。クローン機ではIBMのオペレーティング・システムを同等の速度でより安く使うことができたのです。ハードウェアの売り上げはIBMの主要な収益源であったため、IBMの重役にとってクローン機による侵蝕は深刻な問題でした。
汎用機の分野で、IBMはフューチャー・システム(FS)として知られる計画を中止したばかりでしたが、これは既存のメインフレーム製品群の革新的な後継機となるはずでした。数年にわたる作業、打ち合わせ、膨大な仕様作成の後、IBMの重役は計画がIBMにとってすら野心的にすぎると判断し、1970年代の中頃にプロジェクトを断念しました。
ミネソタ州ロチェスターのトウモロコシ畑の真ん中で、S/3とその後継システムのS/32とS/34は幸せな生涯を終えようとしていました。次期システムの時代が近づきつつありました。それまでにS/34のクローン機は存在しませんでしたが、IBMの重役にとって現存のハードウェアを置き換えるクローン機の脅威は現実の心配事でした。FS失敗の知らせはロチェスターにすぐには届かなかったので、未来の中小規模ビジネス向けシステムを設計するスタッフは独自のアプローチを続けていました。誰もが今は年老いたS/34より大きく、速く、優れた、そして安いマシンを求めていました。しかしどうすればIBMがこの離れ業を成し遂げることができるかということだけが未だ分かっていませんでした。
1975年の始め、私はS/34の後継となるシステムを開発するおよそ25人のグループに加わりました。この小さなグループには様々なバックグラウンドから才能を持った人々が集まりました：S/3、S/32およびS/34のデザインチームから来た人もいれば大型のS/360とS/370バックグラウンドの人もいました。
その計画に参加した頃、グループでは革新的なアイディアが議論されていました。「オブジェクト」、「カプセル化」、「抽象マシン」といった言葉は私やほとんどのシステムプログラマーにとって新しいものでした。技術者にコンピューターの命令を設計させるのではなく、プログラマー(システムの真のユーザー)が抽象マシンの命令セットを定義していきました。これらの命令はハードウェアに最適化されたものではなく、ソフトウェアアプリケーションを書くために設計されていました。この抽象マシンインターフェースは最終的にマシンインターフェース(MI)あるいはIBMが現在呼んでいるように技術非依存マシンインターフェース(TIMI)として知られるものとなりました。抽象マシンインターフェースはプログラミングをより効率的でエラーが発生し難くするようないくつかの先進的な概念を規定しました。プログラマーはデータを処理する際にハードウェアのレジスターにデータをロードするといったことを行わず、新しい概念を使った抽象マシンに対してプログラムを書くことができました。この新しい抽象マシンでは、プログラムがアドレス・ポインターを操作して記憶域を変更できないようになるため、プログラマーはプログラムの信頼性を向上させることができました。さらに、MIプログラムを使うと、プログラマーはポインターを操作できましたが抽象マシンはポインターが不正となるような変更を許しませんでした。
基本的に、プロジェクト・チームはプログラマーを自分自身から守るために抽象マシンインターフェースを設計しました。以前のハードウェアでは、プログラマーはポインターのアドレッシング構造を知っており、メモリーをいじってアドレスを変更することすらできましたが、これがしばしばプログラムの信頼性に問題をひきおこしました。抽象マシン上では、ポインターはカプセル化されました(ポインターの実際の内容はアプリケーション・プログラムに対して公開されません)。この技術革新は、プログラムは記憶域を変更してポインターを作成できないということを意味します：ポインター命令によってのみポインターを変更することが可能となります。プログラマーによるポインターを含む記憶域の改変のいかなる試みも不正なポインターを引き起こす可能性があります。抽象マシンのポインターはいかなるハードウェアレジスターより大きく、システムのマイクロコードはポインターを実際のハードウェアレジスターに変換することができました。
実際のマシンハードウェアと抽象マシンを分離した事により、CISCハードウェアからRISCハードウェアへ成功裏に移行することができたのです。他のプラットフォームでは32ビットあるいは64ビットアドレスにするため一生懸命プログラムを書き直しています(2005年に完了を予定しているプラットフォームもあります)。真に驚くべきことですが、全てのAS/400アプリケーションはお客様の、あるいはOS/400のプログラムに一切変更を加える事無く64ビットで稼動しています。
この抽象マシンインターフェースの第二の主要コンセプトはタスク管理や機密保護、さらにはデータベースといった伝統的なOSの機能の多くをマイクロコードに移したことです。これらの機能はハードウェアインターフェースに近いところに実装されたので、効率的なプログラムが出来ました。IBMにとってより重要であったのは、OS機能のハードウェアマイクロコードへの統合により、S/38のハードウェアをコピーするのがより困難になったことです。この事実一つだけでもS/38のプロジェクトはIBMの重役から資金を引き出すことが確実でした。
今日では、AS/400での経験によって抽象マシンは非常に意味のあるものだと証明されていますが、1970年代のシステムプログラマー達にとってこのアイディアは急進的でした。
25年前、抽象マシンインターフェースというアイディアにははっきりした批判がありました。数名のとても優れた技術専門家は抽象マシンインターフェースは学術的には有りうるが、このインターフェースによるオーバーヘッドが大きいためプログラムの実行は非常に低速になると激しく論駁しました。非常な努力(および強い感情)がハードウェア直接あるいはマイクロコード実装のパフォーマンスを証明、もしくは反証することに注がれました。
この問題が解決された日のことを覚えています。ロチェスターでのある寒い冬の日、開発研究所で主要テクニカルスタッフのミーティングが開かれました。抽象マシンの賛成者と反対者がプログラミング・システム・マネージャーのグレン・ヘンリーの会議室に集まりました。グレンはきわめて知的な人でしたが、本当に才能のある人間の多くがそうであるように、きれいな人間関係というものを重んじる人ではありませんでした。グレン・ヘンリーは明らかな回答を見つけると、飾り気の全く無いわずかな言葉でそういいます。グレンは討論の終結を宣言しました。非常な情熱をもって彼は抽象マシンインターフェース(後にMIとして知られる事になる)が唯一の選択であると説明しました。グレンはこの抽象マシンがどれだけIBMの投資を互換機ベンダーから保護するであろうかを詳しく述べました。彼は次のように締めくくりました。「このプログラムに取り掛かろう、それがいやなら誰がどこに異動するのでも喜んでサインしよう」
今当時を振り返り、この抽象マシンインターフェースがAS/400の最も優れたアーキテクチャーの一つであった事が分かります。ソフトウェアを実際のハードウェアから分離することにより、ソフトウェアの修正無しに物理的なハードウェアを根本的に変更が可能となりました。抽象マシンインターフェースのおかげで、AS/400のユーザーはアプリケーションを壊すこと無しにCISCからRISCへ移行できたのです。
抽象マシンの決定を下した後、他の設計事項に取り掛かりました。これは新しいマシンだったので、全ての設計上のパラメーターに議論が必要でした。決定すべき事項の一つにオブジェクト名の長さをいくつであるべきかという事がありました。S/34と互換性を持たせて8文字にするという提案がありました。MIでサポートされる32文字の「自分を説明する名前」を提案した人もいました。データベース設計チームがMIで許される32文字の中にファイル、ライブラリー、メンバーを記憶させる必要があると決定した事から我々は決断しました。我々は最大の名前の長さ(32)を3で割って名前を10文字と決め、このようにしてS/38の名前の長さ(そしてAS/400の名前)を10文字に制限したのです。
CLコマンド言語の一貫性と構造は容易に認識できます。しかし、コマンド名の動詞-オブジェクトの構造は自然にできたものではありません；これはCLの開発初期に見つかった問題の直接の結果なのです。別々の開発チームがコマンドを考え出し、自分のコマンドに一貫性の無い名前を付けました。最後には「用語警察」が動詞-オブジェクトの厳密な命名ルールを強制し、オペレーティング・システム全体に渡って共通の略語を採用しました。この一貫した命名ルールはオペレーティング・システムからライセンス・プログラムまでも含むように拡張されました。
しかしながら動詞-オブジェクトの構造だけでは十分ではありませんでした、なぜなら略称間の分かれ目を認識するのが困難である事が明らかになったのです。そこで基準はコマンド名の最後の語を除いて略語を3文字に標準化するように拡張されました。CL言語を覚え易く使い易いと感じる何千ものAS/400ユーザーは、コマンド命名基準を選択し、強制した言語警察に感謝してもよいでしょう。
使用性能検査(ユーザビリティ・テスト)でユーザーはコマンド名、パラメーターのキーワード、そして許される値を記憶できないという事が分かりました。最初はそれぞれのコマンドに個別の画面を作成し、これらを一致される努力がなされました。コマンドの数が増加すると、IBMは個々に作成される画面インターフェースのコストを負担しきれない事が明らかになりました。IBMの設計者は、ある時は画面を利用でき、それ以外は利用できないというように、コマンドに優先順位を付けようとしました。日に日にコマンドの数は増え、ユーザーインターフェース部門はこのような画面を全ては開発できない、あるいは後追いすることすらできませんでした。そこで彼らは記憶されているコマンド定義オブジェクトに基づき、これらの画面の生成を自動化することを提案しました。
最終的な結果は革命的なコマンドプロンプトとなりましたが、これは1,500以上のIBM提供コマンドにとって計り知れないほど貴重であるとともに、ユーザーコマンドに対しても使用できるものです。コマンド名の前に疑問符を付ければCLプログラムで簡単に入力プロンプトを使用できます。
IBMがFS計画を中止した直後、経営陣はロチェスターの開発作業に焦点を合わせはじめました。当時の疑問はミネソタのトウモロコシ畑中のこんな小さなグループ(コード名パシフィックとして知られていました)が、どうやって東・西海岸の精鋭多数を集めたFS設計チームができなかったことを成し遂げられるのかということでした。システム監査がパシフィック計画の状況を裁定するために行われ、計画の将来は監査の結果次第となりました。ロチェスターでは進捗状況について良いことだけ述べるように最大の努力が払われました。私たちは詳細なハードウェアとソフトウェアの計画を用意し、監査員に説明しました。監査員に既定の事実として提出されたものがインクも乾いていないような最新デザインだということもありました。設計チームのメンバーはシステムの将来が監査員の手に委ねられていると知っていたので、非常に大きなストレスがかかった時期でした。パシフィック計画は監査を切り抜け、S/38とAS/400がその結果となりました。
監査はオペレーティング・システムの設計を固めるのに重要な役割を果たしました。システム監査の前までは、個々の設計者が毎週のように設計を変更(改善)し、往々にしてシステムの他の分野の設計を混乱させていました。システム監査で設計チームは設計上の意思決定を行い、文書化するように強いられたのです。
デザイン・レビューがうまく行った後、設計とプログラミングのグループのスタッフは急速に増えはじめました。ロチェスターのIBM施設ではすべての人間を収容することすらできませんでした。そこで、IBMはパシフィック計画(設計とプログラミング)全体をロチェスターの廃棄されたデパートに移しました。全プロジェクトをそのまま新しい施設に移したので、ハードウェアとソフトウェアの設計グループはいっしょのままであり、開発者はホールに行って開発者と関連する分野の話をすることができました。私はFSを実装する複数サイトでの試みが失敗し、一方ロチェスターのプロジェクトが成功したのはこのコミュニケーションの容易さが理由の一つであると思っています。
3つの設計チーム(ハードウェア、マイクロコード、そしてオペレーティング・システム)は、皆設計と実装に焦点を合わせていました。これら設計チームはきっちりとマシンのアーキテクチャーを象徴していました。この異なるグループの間のコミュニケーションはすばらしいものでしたが、私はしばしばバベルの塔にいると感じました。異なるグループが同一のデータ処理用語(たとえばキュー)で類似した概念を描きましたが、詳細な機能は大きく異なっていました。このような用語上の不一致は控えめに言っても紛らわしいものでした。様々な分野の設計者が会話をするとき、皆お互いを理解していると思っていましたが、実際の理解には大きな差異があることが頻繁にありました。そこで、オペレーティング・システムのプログラマーと技術者が会話をするときは、そのわずかな違いを解説する翻訳者として役立つような貴重な人間を一人、引っつかんでくるという事をよくやりました。
ハードウェア、マイクロコード、そしてオペレーティング・システムはすべてパラレルに開発が進められました。計画の初期の段階では、プログラミングのチームが使用できるハードウェアはありませんでした。代わりに、そのチームではS/370上にマシンのハードウェア命令のシミュレーターを開発しました。このシミュレーターのおかげでマイクロコードの開発者は実物のハードウェアが無くても機能を設計し、テストすることができるようになりました。しかし、ハードウェア命令のシミュレーションはどう頑張っても低速でした。私はコマンド解析の主開発者でしたが、シミュレーターでは1個のCLコマンドの文法チェックにコンピューターに負荷がかかっていなければおよそ30から45分かかりました。複数のシミュレーションが動いていると、同じテストに最大2時間かかりました。結果として、多くの人(私を含む)が勤務時間外に仕事をして応答時間を良くしようとしました(1個の文法チェックに30分かかるのを良い応答時間と言えればの話ですが)。
頻繁にプログラムは落ちました、そして問題がコードにあるのか、マイクロコードのバグなのか、シミュレーターの所為なのかを判別するのは骨でした。オペレーティング・システムを開発するために我々はPL/Iから派生したPL/MI(Programming
Language/Machine Interface)というプログラミング言語を使用しました。これに似たPL/Sという言語でS/370のコードが開発されたので、我々開発チームはコマンド解析の最初のプログラム・デバッグのかなりの部分でS/370を使用しました。このデバッグは不可欠でした、なぜなら制御プログラム機能(CPF)と呼ばれたS/38のオペレーティング・システム上で開発チームが個々のコマンドをテストするために、CLコマンド解析はそれより前に必要とされたのです。
最終的には技術部門によってハードウェアの一部が使えるようになっていきましたが、新たな問題が引き起こされました。シミュレーター上で使っていたコードをステップ実行するようなツールはハードウェア上には存在しなかったので、プログラマーはプログラムのデバッグに全く新しい手法を取得しなくてはなりませんでした。初期の段階ではデバッグのためのツールは存在しなかったので、プログラムをテストする唯一の方法はハードウェアのアドレスによる停止点を設定することでした。
今ではAS/400は高い信頼性で知られていますが、S/38のハードウェアとマイクロコードの初期バージョンは不安定でした。システムが落ちることなく30分動けば奇跡でした。そのシステムで一番良く使われたプログラムは2to1コピーと呼ばれたツールでした。マイクロコードとオペレーティング・システムのすべては1台のディスク(ピッコロ・ドライブ)に収まりました。当時を振り返ると、最初のステップでシステム全体をドライブ2からドライブ1へコピーするのですが、これに15分から30分かかりりました。2番目のステップでプログラムを追加します。プログラマーが幸運であった場合は、ドライブにプログラムを追加し、システムをシャットダウンし、ドライブ1をドライブ2にコピーして戻します。頻繁にシステムはハングし、2to1コピーをもう一度最初から始めるのが唯一の選択肢でした。8割方はディスクドライブのコピーが走っており、わずか2割が実際のテストが行われた時間でした。
毎週、開発者は最新の修正と完成に近づきつつあるマイクロコードを合わせた新しいドライバーを入手しました。保管、復元機能は動いていなかったので、ドライバーのビルド・チームはディスクドライブをシステムに接続し、お馴染みの2to1コピーを走らせたものです。不幸なことにこの過程でシステムを完全に再ロードする必要があったため、新しいテストプログラムを毎回システムに追加しなくてはなりませんでした。週ごとにシステムはより安定しはじめました。
2to1コピー以外で一番役に立ったプログラムとして思い付くのはITSWITCHというツールです。このプログラム無しではS/38のオペレーティング・システム、CPFは完成する事はなかったでしょう。このプログラムは豊富な機能を持っており、例えばエントリー・ポイントのテーブルを設定し、コンパイルされた日付と時刻を判別することができました。しかしながら、最も重要な機能は予期しないエラーを監視し、捜査員がマニュアルで回復手順を取れる機能でした。それぞれのシステムに2台の端末が接続されました。1台をテストに使用し、他方でITSWITCHを走らせました。
コマンド解析のコードは早い時期に終わったので、私はシステム機能のデモの開発に移ることができました。このプロジェクトは最終的に1978年の発表初日に使われるS/38機能デモとなりました。デモはデータベースを更新し、結果を表示するシンプルな受注入力アプリケーションでした。今日の標準からすればこれはシンプルなアプリケーションですが、CPFの開発途上では、これは巨大なアプリケーションでした。複数の端末が全て同じファイルにアクセスし、データファイルへの更新を行っていると想像してください。在庫数から受注数を引くときに0以下にならないようにしないと予期しない事態が起こり得るため、細心の注意を払って全てが台本化されました。デモはすばらしいものでしたが、不安定でした。システムにはプリンターが接続されていましたが、もし誰かが印刷しようとし、そして同時に受注入力を行うと、システムはハングしました。私たちは注意深くデモの振り付けを行い、ユーザーにまず受注入力を見せ、それから出力を見るために聴衆をプリンターの所へ移動しました(受注入力が動いていない間)。システム障害に備えてITSWITCHが裏で常に監視を行っていました。
このサンプル受注入力アプリケーションを見て重役はS/38が発表できると確信しましたが、実際はそうではありませんでした。結果としてシステムの発表日が承認されましたが、システムの信頼性とパフォーマンスが最低基準に達しなかったため、初出荷の日程は変更されました。これは開発チームにとっては汚点でしたが、システムを動かし続けるのに必要なITSWITCHをお客様は持っていないのですから、不可欠な延期でした。
発表の日を振り返り、私はS/38が統合されたデータベース、サブファイル、ユーザー定義コマンド、そしてプログラムとしてコンパイル可能なCL言語といった数々のエレガントな機能を備えていたことを実感します。しかし欠けていた機能もまた多数ありました。例をとると、通信機能はリリース2まで追加されませんでした。
CPFリリース2の開発過程でCLチームがおかした設計ミスが明らかになりました。IBMですでに存在するCLコマンドにキーワードを追加すると、そのコマンドを使用する全てのプログラムを再コンパイルする必要がありました。このためコンパイル済みのCLプログラムで使われていた手法の再設計が発生しました。この再設計の代償としてリリース2が使用可能になった時点で、お客様は全てのCLプログラムを再コンパイルしなくてはなりませんでした。S/38に対する関心は非常に高かったものの、お客様の多くはご購入に至ってはいなかったので、プログラムの再コンパイルを強制した事はほんのわずかの早期導入者だけへの影響で済みました。興味深いこととして記憶にとどめておきたいのですが、S/38とAS/400の長い歴史の中でお客様のアプリケーションの再コンパイルを強制したのはこの時だけです。上位互換性によりお客様はプログラムを再コンパイルしないでCISCハードウェアからRISCハードウェアへプログラムを復元することができます。システムがプログラムが復元されるときに自動的に変換を行います。新しいリリースにほんのわずかな、あるいは全く影響無しにアップグレードできるので、AS/400はお客様から高いご満足をいただいています。
CPFの最初のリリースで、IBMはファイルコピーを簡単に行うための今で言うウィザードを出荷しました。対話型ファイルコピーは基本的に簡略されたファイルコピーコマンドのプロンプトをユーザーに提示し、ユーザーのプロンプトへの応答によって別のプロンプトを表示しました。これはユーザーにプロンプトを提示する複数のCLコマンドとして実装され、ファイルコピー(CPYF)コマンドを簡単にしました。オプションの数が増えるにつれてこの方法は不可能になったため、対話型でファイルをコピー(CPYFINT)はリリース2で廃止されました。
メインメモリーのコストは非常に大きかったので、S/38はAS/400が今日サポートしているような大きなメモリーを使うことはできませんでした。初期のハードウェアシステムは512Kメモリーで出荷されており、256Kメモリーから利用できるようにするために大変な設計上の努力が払われました。S/38およびAS/400のパフォーマンスは主記憶を追加することで劇的に向上しました。私は未だに初期のシステムを512Kで(非常に遅いにしても)稼動させることができたという事が信じられません。
AS/400のユーザーはS/38のオペレーティング・システムの名前、CPF(Control
Program Facility)を知らないかもしれません。この略称は全てのメッセージで使われており、ユーザー・プログラムはメッセージの監視にこれを指定します。必要なメッセージの数が予想したより多いと言う事が明らかになり、2文字の略称、CPで始まるバリエーションが追加されました。今度みなさんがAS/400からCPFメッセージを受け取ったら、S/38の才能長けた設計チームの初期の奮闘をほんの少し思い起こしてください。このチームがAS/400に貴重な遺産を残したのです。
マスコミはS/36とS/38が記録的な期間でいかにうまくAS/400に移行したかを書き立てました。私から見れば、S/38の初期の開発者はS/38をAS/400に移行させた人々よりはるかに困難な技術上の問題に直面していました。S/38で大部分のアーキテクチャー上の基本ルールが確立されており、開発者はすでに存在するS/38ハードウェアを使ってAS/400を開発、テストする事ができました。
S/38の実装は私のコンピューター人生の中で最も重要なものです。S/38とその後継であるAS/400はこれまで、そしてこれからも多くのコンピューター技術者の主要な仕事であり続けるでしょう。
ウエイン O エバンス氏はAS/400のセキュリティ・コンサルタントであり、セキュリティの話題でしばしば演壇に立ちます。IBMに在籍した27年の間、AS/400のセキュリティのデザインに携わっていました。ウエイン氏はセキュリティの前にはメッセージ処理と実行管理を担当し、S/38のコマンド定義とCL言語のチーム・リーダーでもありました。
----------------------------------------------------------------------------
Copyright © 1999 Midrange Computing
IBM® and AS/400® are registered trademarks
of IBM.
All other product names are trademarked or
copyrighted by their respective holders.
Reprinted with permission from Midrange Computing
Magazine, published by Midrange Computing,
IIR Publications, Inc., in Carlsbad, CA;
760-931-8615; http://www.midrangecomputing.com.
Original article can be found in the April 1999 issue of
Midrange Computing Magazine.
ミッドレンジ・コンピューティング・マガジン1999年4月号に掲載された記事を発行元の許可をいただいて翻訳/掲載しています。原文はこちらで読むことができます。
[Home]