アプリケーション資産継承
さて、ビジネスのためのシステムを開発しようというゴールは決まっています。そのために満たすべき要件とは何なのかを、具体的に明らかにしてゆかねばなりません。性能、価格、使い易さ、信頼性、セキュリティ、などが考えられますし、最近だと消費電力量など環境への悪影響も気になるところです。でもこれらは必ずしもビジネス用途に限ったものではありませんし、何かもっと他に見落としてしまっているものがあるかもしれません。ここで一見回り道ではありますが、コンピュータの発展経緯を眺めるところから始めてみたいと思います。
そもそも1940年代半ばにコンピュータと呼ばれる機械が誕生した当初は、ハードウェアが全てでした。1946年の米ENIAC（Electronic Numerical Integrator and Computer）という大砲の弾道計算を実行することを目的に開発されたコンピュータにおいては、プログラミングを行うということは、システムの配線を変更することを意味していました。ソフトウェアはハードウェアから分離されていなかったのです。その後現在と変わらないノイマン型と呼ばれるコンピュータに発展することで、システム利用に柔軟性が生まれます。ハードウェアに一切手を加えなくても、プログラムとデータを用意すれば、それらに基づいて様々な処理を行うことができるようになります。それでも個々のプログラムは特定の構成をもった特定のコンピュータに対するものである、という制約がありました。ちなみに世界初のノイマン型コンピュータは、1949年の英EDSAC（Electronic Delay Storage Autonomic Calculator）だと言われています。
マイクロコードの登場
プログラムの可搬性、すなわち作ったプログラムを別構成のマシン上でも実行できるという、それまでに無かった概念が初めて実現されたのは、1964年に登場したIBM のシステム 360 においてでした。現在のIBM zSystemsの源流にあたるシステムです。シリーズ化されたモデル・ラインアップは、様々なハードウェア構成を持ち得るものでしたが、プログラムから見たマシンの姿は不変となるような工夫が施されました。それを可能にしたのがハードウェアとプログラムの中間に位置するマイクロコードです。プログラムはハードウェアに対して記述されるものですが、マイクロコードを上手く活かしてハードウェア構成の差異を覆い隠したのです。最初は小型機を導入しておいて、企業のビジネス規模の拡大に伴って上位機に置き換えたとしても、それまでに蓄積されたソフトウェア資産は活かされるというメリットがあります。このシステムは大ヒットし、IBMを業界における巨人と言われる地位に押し上げる原動力となりました。同一シリーズ内という条件はありましたが、一つのプログラムを様々なモデル上で実行できるという考え方、すなわち可搬性の価値を市場が認知したのです。
時間的可搬性の重要性
ここでちょっと視点を変えて、業務用途のシステムについて考えてみましょう。会社の中の仕事のやり方は他では通用しないかもしれませんが、大きく変わることは滅多にありません。業務を支えるアプリケーション・プログラムは、小規模な改修を積み重ねることはあるにしても、長期的・安定的に使われ続けることになります。5年とも7年とも言われるマシン本体の寿命を大きく超えるのも珍しいことではありません。これもプログラムのもう一つの可搬性です。すなわち、業務プロセスを支えるためには、マシンの世代を超えた可搬性も考慮しなければならないということです。システム360が実現した仕組みを空間的可搬性と呼ぶならば、こちらの方は時間的可搬性とでも呼べるでしょう。
時間的可搬性の実装は難しい
時間的可搬性を実現するのは実はかなり厄介です。空間的可搬性を実現するにあたって、対象となるハードウェア構成やテクノロジーは、様々であるにせよ概ね既に「見えている」ものばかりです。ところが時間的可搬性の方は、将来どうなるのかわからないハードウェアを相手にしなければなりません。将来のテクノロジーを見越してシステムを設計・開発すれば良い、という理屈はその通りかもしれませんが、そもそもどこでどのくらいの影響度のある技術革新の芽が生まれるのか、誰も制御・統制する事はできません。マイクロコードに反映されるべき変更規模を予想できないだけでなく、対処可能な限界を超えてしまう可能性すら付きまといます。
ソフトウェア・マシンの発想
そこでIBM i の開発者は発想の転換を図ります。無駄な抵抗は止めて、不可能であることを謙虚に受け入れよう、しかしながら業務を支えるアプリケーション・プログラムに影響が及ぶのは是非とも避けたいので、いっその事プログラムをハードウェアから完全に分離し隔離してしまおう、と考えます。マイクロコードの目的はハードウェアの差分吸収にあるとしたら、もっと徹底的にソフトウェア的にマシンを作り上げてしまうわけです。
このハードウェア・テクノロジーとプログラムの中間に位置する分離層はTIMI （Technology Independent Machine Interface）、すなわちテクノロジーから独立したマシン・インターフェース、短縮してマシン・インターフェースとも呼ばれます。プログラムからはあたかもマシンであるかのように見えるので、仮想マシンと呼ばれることもあります。JAVAにおけるJVMのようなものだと思えば良いでしょう。その実態はAPIの塊です。通常のシステムにおいては、APIをバイパスしてハードウェアに直接アクセスするようなプログラムも記述できますが、TIMIにおいてはAPIをバイパスすることは完全にブロックされています。このことはシステムとしての安全性を確保する上で役立っています。そしてTIMIを形作っているのはSLIC（System Licensed Internal Code）、言わばIBM i のマイクロコードです。
Javaとの違い
JAVA言語ではコンパイルを行うことによって中間コードとも呼ばれるバイトコードを一旦生成し、それを一文一文解釈しながら実行するインタープリタ方式が取り入れられています。今でこそチューニングが進みハードウェアの能力が向上したので、インタープリタ方式でも比較的良好なパフォーマンスを得られますが、それでもあらかじめ実行コードを一括生成しておくコンパイラ方式を凌ぐことはありません。IBM i においても最適なパフォーマンスを得るために、後者のコンパイラ方式を採用しています。この方式においては、事前に生成される実行コードはハードウェアに依存しているので、そのテクノロジーが変わったらプログラムは動かなくなってしまう可能性があります。せっかくの仮想マシンの発想はどうなっているのでしょうか。
テクノロジーの転換点
歴史的に見ると、IBM i の実行コードは不変ではなく、過去に何回かの大きな転換点がありました。テクノロジー刷新がその背景にあります。最初が1988年のシステム38からAS/400に切り替わる時、次に1995年の48ビットCISCプロセッサから64ビットRISCプロセッサに置き換わる時、最近のものは2008年バージョン6.1登場時に内部実行コードの形式が変更された時、の三回です。これら転換点においては、実行コードの互換性は失われました。特に二度目のプロセッサ・テクノロジの刷新は、私の知る限りIBM i の歴史における最大の変革です。しかしながらIBM i のコンパイル済みアプリケーションは、これら転換点を乗り越えて、コンパイルのやり直しといったプロセスを経ずに利用できた、という実績があります。コンパイラ方式を採用しながらも、互換性の無いハードウェアで問題無くプログラムが稼働するようなシステムは通常あり得ません。他システムの常識はIBM i には必ずしも通用しないというわけです。IBM i におけるコンパイラの生成物は、実行コードだけではない、というのがポイントです。
二段階のコンパイル・プロセス
IBM i のコンパイルは、内部では二段階のプロセスに分かれています。最初にソースコードを取り出してTIMI用に中間コードを生成する、オペレーティング・システムより上位層にあるプロセスが動きます。JAVAで言うところのバイトコード生成のようなものです。引き続いてその中間コードからハードウェア用の実行コードを生成するために、下位層にあるトランスレータが起動されます。これはIBM i のマイクロコードに相当するSLIC内で実行されます。そして実行コードは既に生成済みの中間コードと共に統合（カプセル化）され、最終成果物となります。これがコンパイル済みのロードモジュールです。すなわち通常のシステムのコンパイル済みモジュール（実行コード）に加えて、中間コードが常にセットになっているというわけです。そしてプログラム実行にあたって、このセットの中から実行コードが取り出されます。中間コードは無駄にストレージ空間を食い潰しているだけのようにも見えますが、実は可搬性を維持する上で、重要な役割を果たしています。
互換性の無いハードウェアでは
ではこのコンパイル済みモジュールを、ハードウェア互換性のない将来の後継マシンに導入し、実行しようとしたら何が起こるでしょうか。もちろん古いマシン上で生成された実行コードは動作することはできません。通常のマシンならば、この段階でエラー・メッセージを吐き出してプロセスを終了します。IBM i においても同様に内部で一旦エラーが発生しますが、続きのプロセスが自動的に起動されます。SLICトランスレータが中間コードを取り出して、新しいハードウェア用に再度実行コードを生成し、コンパイル済みモジュールの中に含まれていた古い実行コードを置き換えます。その後あらためて新しい実行コードを拾い上げて実行します。この一連のプロセスはユーザーには意識されないところで行われます。
プログラム実行時にトランスレータ起動という「余分な」仕事が追加されるので、パフォーマンス上不利になるのは間違いありません。しかしながらこの余分な仕事は一度きりのものであり、次回以降は常に新しい実行コードが参照されるので、何も対策を打たなくてもパフォーマンスの懸念は自然に解消されます。一度きりではあっても本番業務への影響を避けたいのであれば、新しい実行コードをあらかじめまとめて生成しておくこともできます。
資産継承を実現するのはTIMI上の中間コード
IBM i アプリケーション資産が保護される事とは、より具体的にはTIMI用中間コードの上位互換性が実現されている事に他なりません。ハードウェア・テクノロジーの変化や進化において、実行コードの互換性が保たれる事を期待するのは無理がありますし、将来どうなるのかを予測する事はできません。一方で中間コードは常に互換性を保つように設計されています。両者のギャップを埋めているのは、マイクロコードに匹敵するSLICと呼ばれる階層であり、トランスレータです。JAVAにおけるバイトコードやJVMの存在は、非常に幅広い空間的可搬性を実現する上で効果的ですが、時間的可搬性は実現するべき属性として追求されていないようです。ユニークでIBM i にとって最も重要なテクノロジーは、SLICが形作るTIMIであるとされる所以でもあります。
| 前章「コンセプトがアーキテクチャに至るまで」へ | 「IBM i とは」TOP | 次章「セキュリティ」へ |
