1.4.7 RDMLの「コンパイル」
LANSA ファンクションを実行するためには、RDML のコードを高レベル言語 HLL (High-Level Language) に変換し、さらにコンパイルして実行形式にする必要があります。RDMLはインタープリタ言語ではありません。最終的には実行環境ごとのオブジェクト・プログラムになるので、各プラットフォームの特性を活かした、性能の高いアプリケーションが得られます。
RDMLのコンパイル処理や、HLLによる中間コードの生成過程は、全て透過的です。とは言え、生成されたHLLコードを開発者が確認する必要はなく、これを編集してはいけません。LANSAはコード生成器ではなく、リポジトリと第4世代言語を基盤とした、完全なアプリケーション開発環境です。HLLコードをじかに修正すると、LANSA の高レベル・アプリケーション定義の整合性が崩れてしまいます。また、特定のプラットフォーム用にHLLコードを修正すれば、ほかのプラットフォームでは実行できなくなります。
LANSA は、ターゲットの実行プラットフォームに合わせ、それぞれの高レベル言語を使用します。例えば IBM i の場合、RPG、C/C++ により、もっとも実行速度が速くなります。Windows、Linux の場合、ANSI C/C++ が使用されます。Web アプリケーションでは、 C/C++、XHTML、XML、CGI/Apache プラグイン、Web サーバー・エクステンションを使います。このように、複数の言語を使い分ける仕組みが、特定のプラットフォームに依存しないアプリケーション開発の鍵となっています。
LANSA はプラットフォーム依存のコンパイラを使用して、実行プログラムおよびオブジェクトを作成しますが、コンパイラによっては、大量の HLL コードの処理能力に違いがあることが分かりました。ある状況では、コンパイラは内部的な限界に達し、実行プログラムの生成に失敗します。このような状況を把握するには、以下について考慮する必要があります。
- コンパイラの内部制限に達する可能性を最小限に留めるために、LANSA では 1 ユニットと換算される RDML/RDMLX のコードの行数に制限をかけています。RDML ファンクションの制限は 5000 行、コンポーネントおよび RDMLX ファンクションの制限は 32000 行です。
- LANSA コマンドが生成する HLL コードの量は異なります。ワークステーションのコマンド (DISPLAY、REQUEST、POP_UPなど) 、および I/O コマンド (FETCH、SELECT、UPDATEなど) は、CHANGE、IF、BEGIN_LOOP などのコマンドよりも多くの HLL コードを生成します。
- 利用するコンパイラに対する考慮。例えば、RDML 18000 行により構成される、RDMLX の LANSA コンポーネントは、28MB の C/C++ HLL テーブルになり、このテーブルは Microsoft の 32 ビットのコンパイラでは問題なくコンパイルされましたが、 IBM i のコンパイラでコンパイルするには、コンポーネントを 9000 行まで縮小しないといけませんでした。
- RDML/RDMLX デバッグの有効化。4GL デバッグが必要な場合、追加の HLL コードが生成され、これによりコンパイラの制限を超える場合があります。例えば、前回の例の 9000 行の RDML により生成された HLL を利用した場合、IBM の IBM i C/C++ コンパイラは 4GL デバッグなしではコンパイルに成功しますが、デバッグが要求されると、失敗しました。
- 識別情報の有効化 (3GL デバッグ)時には、LANSA で作成した HLL コードを使って、実行プログラムのデバッグをしなければならない場合があるでしょう。この機能を要求する場合も、コンパイルできる HLL コードの量に影響を与えます。例えば、識別情報を有効にした場合、 9000 行の RDML は、4500 行まで縮小しないと IBM i のコンパイルでコンパイルできませんでした。
