メインフレーム上のLinuxへのアプリケーションの移植
どのプロジェクトでもそうだが、アプリケーションを移植する投資効果を見極めるには、予想されるメリットとコストを比較検討する必要がある。移植が良い結果を生む見込みがあるのは、次の2つの場合である。
- アプリケーションの移植が非常に簡単で、わずかな投資をすぐに回収できる。
- アプリケーションをメインフレーム上のLinuxで動かすことにより、必要な投資に十分に見合うだけの大きなメリットが期待できる。
自社開発のアプリケーションを業務で使用している会社では、メインフレーム・ハードウェアの品質と融通性を活用できる可能性がある。また、仮想化、ハイパーソケット、暗号化機構、64ビット・アーキテクチャなどのzSeriesの機能も活用できる。さらに、メインフレームの仮想通信方式を利用して、統合サーバ環境のアプリケーションをより緊密に統合できる場合もある。
メインフレーム用のLinuxアプリケーションに対する需要は増加している。ソフトウェア・ベンダにとっては、「メインフレーム上のLinux」版のアプリケーションを持っていることが、競争で優位に立つ決め手になる場合もある。多くの主要なソフトウェア・ベンダが、既に戦略上重要ないくつかのソフトウェアをメインフレーム上のLinuxに移植している。
移植の候補となるアプリケーションを選定する前に、アプリケーションが依存しているほかのソフトウェアを把握し、どちらのメインフレーム・アーキテクチャを移植先にするか（31ビットか64ビットか）を決定し、種類の異なるディストリビューション・レベルとディストリビューションをサポートするかどうかを決める必要がある。
アプリケーションが依存する補助ソフトウェアがある場合は、そのソフトウェアの移植も必要になる。必要な補助ソフトウェアが、サードパーティの独自アプリケーションやミドルウェアであれば、移植はそのサードパーティがソフトウェアを移植する意思があるかどうかによって左右される。
企業やソフトウェア・ベンダは、ディストリビューションに依存しないアプリケーションを作成しなければならないことがある。アプリケーションを複数のディストリビューションに対応させるために必要な作業量は、コードがディストリビューションの細部にどの程度強く依存するか、およびディストリビューション間の違いがどの程度あるかによって決まる。たいていは、アプリケーションを動かす予定のディストリビューションごとにテストを行う程度で済むだろう。
メインフレーム上のLinuxアプリケーションは、31ビットまたは64ビット・アーキテクチャ用に作成することができる。メインフレームの原則に従って、zSeriesアーキテクチャでは31ビットの先行機種で動作していたすべてのソフトウェアがサポートされる。31ビット用に作成されたアプリケーションは、zSeriesとS/390のどちらのマシンでも動作する。
zSeriesアーキテクチャの新しい機能（たとえば64ビット・アドレッシング）が必要なアプリケーションは、64ビットのディストリビューション専用に作成することができる。31ビットのアプリケーションを64ビットのディストリビューションで動かすことは可能だが、31ビットのアプリケーションでは64ビットの共有ライブラリを利用できない。アプリケーションに必要なすべてのライブラリが31ビット形式で提供されていなければならない。
アーキテクチャ依存のコード
下位のハードウェアやソフトウェア・プラットフォームについて、暗黙的または明示的な前提条件があるアプリケーション・コードは、おそらくメインフレーム上のLinuxで実行するために修正する必要があるだろう。
メインフレーム上のLinuxと、ほかのプラットフォーム上のLinuxとの違いについては、「ELF Application Binary Interface Supplement」に説明がある。
zSeriesのLinux用のアセンブラコードは、GNUアセンブラの構文規則に従っているが、zSeries（S/390）のマシンコードを使用している。zSeriesはビッグエンディアンのシステムなので、リトルエンディアンのシステムで生成されたバイト指向のデータを処理するアプリケーション・コードは、修正が必要な場合がある。
詳細については、IBMの移植のヒントと秘訣を参照してほしい。
アーキテクチャ依存のコードの修正に必要な作業量は、アプリケーションの構造によって異なる。きちんと設計されたアプリケーションでは、そうしたコードがごくわずかな特定のモジュールにまとめられていることがある。その場合、修正すべきコードの部分は切り離されていて、容易に見つけることができる。
必要な作業量
アプリケーションの移植に必要な作業量は、そのアプリケーションが記述されている言語と、対象になっているプラットフォームによって大きく異なる。非常に簡単に済むこともあるが、最悪の場合、書き直すのと変わらないこともある。
アプリケーションがすべてJavaで書かれている場合は、必要なJava環境が用意されているどのプラットフォームでもそのまま実行できる。実行時にコンパイルされない高級言語（CやC++など）で書かれたアプリケーションやモジュールの場合は、zSeriesアーキテクチャ用にコンパイルし直す必要がある。オペレーティング・システムやハードウェアに依存するアプリケーションやモジュールは、インタフェースの違いに対処するために修正する必要がある。
一般に、プログラミング言語が低級であるほど、そしてコードで使われているプラットフォーム固有の機能が多いほど、より多くの移植作業が必要になる。場合によっては移植をあきらめて、CやJavaなどの移植性のある高級言語で書き直した方が賢明なこともある。
アプリケーションをメインフレーム上のLinuxに移植するために必要なスキルは、普通のソフトウェア開発のスキルである。開発チームには、アプリケーションの作成に必要なLinuxアプリケーション開発ツールを使いこなすスキルも要求される。標準のLinux開発ツール一式（コンパイラやエディタなど）は、メインフレームLinuxのディストリビューションに含まれている。
GNUコンパイラおよびバイナリ・ユーティリティは、クロスコンパイル環境をサポートするように設定できる。クロスコンパイルでは、コンパイルの対象プラットフォームと、コンパイルを実行するプラットフォームが異なる。zSeriesプラットフォームを対象にしたアプリケーション・コードを、PCやローエンド・サーバでコンパイルすることができる。多くの企業では、移植作業の大部分をワークステーション上で行っている。
当然、移植したアプリケーションの最終テストは、移植先のメインフレーム環境で行う必要がある。zSeriesのテスト環境の操作には、ある程度のzSeriesのスキルと、場合によってはz/VMのスキルも必要になる。
既にメインフレーム・マシンを所有している場合は、LPARまたはz/VMゲストをテスト環境として簡単にセットアップすることができる。メインフレームがない場合は、IBMに支援してもらえるかもしれない。IBMのLinux Community Development System Webサイトにアクセスし、移植したアプリケーションのテストにIBMのメインフレームを利用するための諸条件を確認してほしい。
まとめ
UnixからLinuxへのアプリケーションの移植は、特にJavaやC/C++のアプリケーションの場合は、わずかな作業で済むことがある。移植したアプリケーションでは、メインフレーム・ハードウェアを活用できる。たとえば、ハイパーソケットや暗号化機構を利用することができる。また、仮想ネットワークを利用して、同一マシン上のほかのアプリケーションとの緊密な統合を実現することもできる。
移植作業の大部分は、開発者の好みのLinux環境で行うことができる。最終テストでは、移植先の「メインフレーム上のLinux」環境にアクセスする必要がある。利用可能なリソースが十分にあるのなら、簡単に作成できるz/VMのテスト・イメージを使用する。
アプリケーションの移植に必要なほとんどのものは、Linuxディストリビューションに含まれている。いくつかのWebサイトでは、移植に役立つツール、ドキュメント、その他のリソースを提供している。「メインフレーム上のLinux」テスト環境を利用できる可能性もあるので、アプリケーションをメインフレーム上のLinuxに移植するために、必ずしもメインフレーム・マシンを自前で用意する必要はない。
2003年6月に出版予定のEisenhaendler、Matthaeus、Eilert、Salm共著『Linux on the Mainframe』（Prentice Hall PTR, ISBN 0131014153）からの抜粋。
