IBM i のウンチクを語ろう
～ その2：コンセプトがアーキテクチャーに至るまで
皆さん、こんにちは。日本アイ・ビー・エムの安井です。前回は IBM i には「ビジネスのためのサーバー」といったコンセプトがある、といった話をさせていただきました。今回のテーマは、米国ロチェスターの開発者達が、どのようにしてそのコンセプトから製品アーキテクチャーに辿り着いたのか、その思考過程を追跡してみます。もちろん私自身が現場に居合わせたわけではありませんが、AS/400の産みの親といわれる Dr. F.ソルティス氏が「Fortress Rochester: The Inside Story of the IBM iSeries」（ISBN-13: 978-1583040836）に臨場感溢れる記録を残しています。残念ながら邦訳版はありませんが。
さて、ビジネスのためのシステムを開発しようとしているのですから、満足させるべき要件とは何かを明らかにするところから始まります。性能、価格、使い易さ、信頼性、セキュリティ、などが考えられますし、オープン性とか消費電力量も懸念事項になるでしょう。でもこれらはビジネス用途でなくても考慮されるべき要件ですし、何かもっと独自のものがありそうな感じがします。
そもそも1940年代半ばにコンピュータと呼ばれる機械が誕生した当初は、ハードウェアが全てでした。米国のENIAC（Electronic Numerical Integrator and Computer）という大戦中に弾道計算を実行することを目的としたコンピュータにおいては、プログラミングを行うということは、機械の配線を変更することを意味していました。これは正確には、ワイヤリングと表現するべき作業ですね。その後、内蔵されたプログラムとデータに基づいて種々の処理を行う、現在と変わらないノイマン型コンピュータ（世界初は1949年の英EDSAC : Electronic Delay Storage Autonomic Calculatorだと言われています）に発展することで、システム利用に柔軟性が生まれます。それでもプログラムは特定の構成をもった特定の機械に対するものである、という制約がありました。
プログラムの可搬性、すなわち作ったプログラムを別のマシン上でも実行できるという、それまでになかった概念が初めて実現したのは、IBM のシステム 360 においてでした。シリーズ化されたモデル・ラインアップは、様々な構成を持ち得るものでしたが、プログラムから見たマシンの姿は不変となるような工夫が施されました。それを可能にしたのがハードウェアとプログラムの中間に位置するマイクロコードです。プログラムは必ずマイクロコードを通してハードウェアにアクセスしますので、うまくやれば構成の差異を見えないようにする事もできるわけです。このシステムは大ヒットしました。ひとつのプログラムを様々なモデル上で実行できるという考え方、すなわち可搬性の価値を市場が認知したのです。
では業務用途のシステムという具合に絞り込んで考えてみましょう。会社の中の仕事のやり方は、他では通用しないかもしれませんが、長期的には大きく変わることはまずありません。したがって業務を支えるアプリケーション・プログラムも、長期的・安定的に使われ続ける必要があります。これもプログラムのもう一つの可搬性です。
仕事のやり方、すなわち業務アプリケーションを数年毎に全面刷新するなんてあり得ませんね。プログラムの可搬性には、システム 360 が実現した空間的なものと、業務プロセスを支えるための時間的なものがあるわけです。
時間的可搬性に対処するのは厄介です。プログラムはマシンすなわちハードウェアに対して記述されます。ハードウェア・テクノロジーが変化したら、プログラムはその影響を受けますので、作り直しが必要になります。マイクロコードでテクノロジーの変化を吸収する事も考えられますが、そもそもどこでどのようにして技術革新の芽が生まれるのかわからないので、マイクロコードに反映されるべき変更規模を、誰も制御・統制する事はできません。そこで無駄な抵抗は止めて、不可能であることを謙虚に受け入れよう。しかしながら業務を支えるアプリケーション・プログラムに影響が及ぶのは是非とも避けたいので、いっその事プログラムをハードウェアから分離し隔離してしまおう、という発想が生まれます。マイクロコードの目的はハードウェアの仮想化だとしたら、もっと徹底的にソフトウェア的に仮想マシンを作ってしまうわけです。
このハードウェア・テクノロジーとプログラムの中間に位置する分離層はTIMI （Technology Independent Machine Interface）、すなわちテクノロジーから独立したマシン・インターフェース、短縮してマシン・インターフェースと呼ばれます。プログラムからはあたかもマシンであるかのように見えるので、仮想マシンと呼ばれることもあります。JavaにおけるJVMのようなものだと思えば良いでしょう。
Java言語ではコンパイルを行うことによってバイトコードを得、それを一文一文解釈しながら実行するインタープリター方式が取り入れられています。今でこそハードウェアの能力は高くなってきているので、その方式でも良好なパフォーマンスを得られますが、昔のハードウェアではそうはいきません。実はIBM i でもプログラム実行に先立って、ハードウェアに依存した実行コードを生成しておく、コンパイラ方式が採用されています。せっかくの仮想マシンの発想がこれでは台無しになってしまいそうです。次回はこのあたりのカラクリに言及してみます。ではまた。
