【第3回】TIMIはどのようにして生まれ、その効果を発揮しているのか？

IBM iの大きな特徴といえる「プログラムの継承性（プログラムの可搬性）」。これは二つの視点から優位性を捉えることができます。一つは空間的、そしてもう一つは時間的観点です。 空間的可搬性とは、「プログラムを別のマシン上でも実行できる」ことです。System/360が空間的観点からプログラムの可搬性を実現し、多くの企業に支持されたことは、前回のコラムで触れました。今回は、もう一方の時間的観点の優位性を実現するTIMIがどのようにして生まれ、その効果を発揮しているのかを紹介します。  

TIMIの誕生と、AS/400開発時に考慮された基幹業務のあり方

全面的な刷新ではなく、改善を少しずつ積み重ねながら長期的に継続・遂行される―。これがAS/400を開発する際にIBMロチェスターの開発者が想定した、企業における基幹業務のあり方でした。したがって基幹業務を支えるアプリケーション・プログラムは、それが搭載されるサーバーマシンの世代を超えて長期的に利用される、すなわち時間的可搬性が実現されていなければなりません。しかもその期間は、いずれ登場するかも知れない、全く予想もつかないようなテクノロジーにも耐えられるほどに長期である必要があります。だからといって、かつて開発したアプリケーション・プログラムを継続的に稼動させるために、新しいサーバーマシンに搭載されたテクノロジーを完全に無視するわけにもいきません。時間的可搬性を持ちながら、システムとして進化できる柔軟性が必要とされるのです。 このような一見矛盾する要件を同時に満たすことができるのでしょうか。ロチェスターの開発者の念頭にあったのは、「マシンとは何か？」という問いに対する答えでした。これまでに述べたように、黎明期のシステムにおいては、マシンとハードウェアとは同義でした。その後System/360はハードウェアにマイクロコードを上乗せしたものをマシンとすることによって、アプリケーションの空間的可搬性（プログラムを別のマシン上でも実行できること）を実現しました。マイクロコードがハードウェアの違いを吸収することができた、すなわちマシンがハードウェアからやや距離を置くようになったからです。 「将来ハードウェアがどう変化・進化するかわからない」という状況にも耐えられるよう、すなわちアプリケーション・プログラムの時間的可搬性を実現するために、マシンの定義をもっとハードウェアから遠ざけてしまおうとロチェスターは考えたのです。 それはハードウェアに積み上げるべきマイクロコードを、ハードウェアの相違を吸収するに留まらず、ミドルウェア的な機能すべて、言い換えればアプリケーション・プログラム以外の全てを包括するようなものにしてしまうという考えでした。 このことを、「インターフェース（Interface: 境界面）をどこに設置するか」という視点で見てみます。黎明期はハードウェア上に、System/360ではハードウェアの違いを吸収するマイクロコード上に、ロチェスターが考えたシステムではミドルウェア機能を含む、より大きくなったマイクロコード上に、アプリケーション・プログラムに接するインターフェースがあるわけです。この機能豊富なマイクロコード上のインターフェースが、AS/400生みの親とされるFrank Soltis博士が言うところの、マシン・インターフェース（Machine Interface : MI）であり、ハードウェア・テクノロジーから分離・独立したものであるところから、その意味を明確化してTIMI（Technology Independent Machine Interface）とも呼ばれているものの実体です。仮想的に定義されているマシン、すなわち仮想マシンと表現されることもあります。

ロチェスターが編み出した、コンパイルにおける秘策とは

通常アプリケーション・プログラム開発においては、マシンに実行させたいことを人間に「わかりやすい」言葉・文章で、すなわちソースコードを書き連ねるところから作業を始めます。さすがにマシンは自然言語を理解できるほどに賢くはありませんので（最近は大分様相が変わりつつありますが）、人間の方が多少マシンに寄り添う必要があります。それがプログラム言語という体系に具現化されているわけですが、マシンにソースコードを直接実行させようとすると、どうしても解釈しながら実行するという余計なプロセスが発生してしまい、パフォーマンス上不利になるのは免れません。 このインタープリタ方式と呼ばれる実行形式を、基幹業務を支えるサーバーとしては、受け入れるわけにはいきません。（今日においてはハードウェア能力が大分向上しているので、インタープリタ方式のプログラムであっても実用化されているケースは数多くあります）。だからと言って、予めコンパイルしてプロセッサ･テクノロジーに依存した機械語（バイナリー・コードとも呼ばれる）を一括生成し、それをマシンに実行させる方式では、ハードウェアの互換性が維持されません。つまり、アプリケーションの時間的可搬性を実現することができないのです。 そこでロチェスターが編み出した方策は、コンパイルを二段階に分けるというものでした。ソースコードから機械語に到る前の中間的なコードを一旦生成し、さらにそれをプロセッサが直接理解できる機械語に変更します。その機械語コードは独立では存在せず、生成後に中間コードと共にパッケージされ、TIMI上に配置されます。 この方式では、通常時には機械語が取り出されて実行されます。もし互換性のないハードウェア上で実行される場合は、生成済みの機械語は実行不能なため、内部的には一旦エラーとなります。そして自動的に再度中間コードが取り出されて二段階目のコンパイルが行われ、その成果物は既存の機械語コードを置き換えながら、やはり元からあった中間コードと共にパッケージされます。こうすることで、ハードウェアの互換性が失われたとしても、アプリケーション・プログラムの動作には支障がありません。

拡張機能のための柔軟性はAS/400の最大の特徴だ

ロチェスターがTIMIを採用したのは、将来にわたって進化させることができるようAS/400 の柔軟性を担保することが狙いでした。ユーザー企業のアプリケーション資産を保護することだけを実現するのであれば、テクノロジーを進化させないという、乱暴な選択肢もあったはずです。オフコンと呼ばれるタイプのサーバーを提供しているのは、IBM一社のみではありませんが、IBM i と他社サーバーとの決定的な違いは機能拡張のための柔軟性にあります。それはマシンとは何か、という冒頭に挙げた命題にも深く関わってきます。 IBM i におけるマシン、すなわち TIMI はソフトウェア的に定義されています。新たな機能が必要になった場合は、必ずしもハードウェアやTIMIよりも上位の階層においてではなく、マイクロコードでそれを実現しても構わないわけです。例えばIBM i におけるSQLエンジンは、従来はTIMIよりも上位にあるソフトウェアの階層、最新のものはTIMIよりも下位のマイクロコード上に実装されています。アプリケーション・プログラムから見ると、SQLエンジンを備えたマシンになっているのです。これはオーバーヘッドが小さくて済む、というパフォーマンス上のメリットにつながります。 TIMIよりも下の階層には他にも、セキュリティ、トランザクション管理、ネットワークなど数多くのミドルウェア機能、アプリケーション・プログラム以外の全てが包含されていると言っても過言ではありません。これら全てはIBM i の標準機能の一部として提供されますので、ユーザーはシステム導入後に直ちに利用を開始できると共に、その後も個々の機能間の整合性やバージョンを管理する必要がありません。 TIMIはソフトウェア的に定義された仮想マシンですので、プログラマにとって都合の良いように設計しても構わないことになります。TIMIが採用するファイル・システムの特徴の一つは、記憶領域としてのディスクは存在せず、メモリしか備えていない点にあります。もちろんハードウェアの実体としてはディスクとメモリとを備えているのですが、ソフトウェア的に、もしくは仮想的に記憶領域全域をメモリとして扱っています。これは単一レベル記憶と呼ばれるテクノロジーで、TIMIの下層に位置しています。プログラミングにおいて、ディスク上のディレクトリ構造を持つファイルと、アドレスで管理されるメモリにあるデータと、違いを意識しながらアクセスする必要がありません。  

IBM i でも頑なに引き継がれているTIMIの強み

TIMIに関して、柔軟性を保ちながらも一切の妥協がなされていない点、1988年のAS/400登場以来、頑なに守られ続けている点を、二つ紹介します。 まず、アプリケーション・プログラムから見た、より正確にはアプリケーション・プログラムをコンパイルする過程において生成される、中間コードから見たマシンとしての姿が不変であることです。例えば1995年に、従来の48ビットCISCプロセッサから64ビットRISCプロセッサへとテクノロジーの切り替えがなされた際にも、この考え方は継続されました。他のサーバーならばアプリケーション・プログラムは書き直しが必要になるような状況下においても、ユーザーはコンパイルのやり直しをすることなく（コンパイルの二段階目の作業は内部のマイクロコードによって密かに行われていましたが）、この大きな転換点を乗り越えることができました。 もう一つはTIMIを回避したプログラミングやシステム操作・運用はできない、という点です。プログラムやユーザーはTIMIの下のマイクロコードに直接アクセスできないよう、完全にシャットアウトされています。TIMIは言わばAPIの塊だとも言えます。APIはシステムのサービスを提供するために用意されているものですが、他のサーバーにおいてはAPIへのアクセスは必須ではなく、必要があれば直接ハードウェアにアクセスするプログラミングを行っても構いません。この考え方は悪意をもったプログラマに立ち入る隙を与えます。 IBM i においてはこの手段は完全に閉ざされており、マイクロコードにアクセスするためにはTIMIを経由せざるを得ないようになっています。過去28年の歴史において、TIMI利用を回避する手段、ないしその抜け穴が見つかったこともありません。全てがTIMIの制御下にあるというこの特質は、IBM i のセキュリティ・レベルを保つ上で役立っています。 これまで見てきたように、TIMIはアプリケーションの互換性を保っているだけでなく、マシンの機能拡張を実現するための柔軟性を担保する仕組みであり、プログラミングのしやすさと、セキュリティを守る要ともなっています。そしてIBM i を、他にはないユニークな特質を持ちながら、圧倒的な優位性を持ったサーバーとして位置付けているのです。 次回の連載はこちら ＜バックナンバー＞ 【第1回】戦時中に産声をあげたコンピュータの原風景 【第2回】究極のビジネスマシン開発のために考え抜かれた「哲学」 【第4回】ITトレンドの中のIBM i サバイバル