ILE を理解する上で、「活動化グループ」の概念は是非とも理解しておく必要がある。
活動化グループとは 同一ジョブ内での、CPU メモリ内の分割管理のことである。
RPG 開発の長い経験のある開発者であれば LR終了しないで、RETURN だけで
上位のプログラムに戻って、再び呼び出されたときにはメモリはリセットされないで、
前の変数値がそのまま利用できることを、ご存知であろう。
活動化グループとはこのメモリ管理をさらに一般化したものである。
サービス・プログラムの作成(CRTSRVPGM) の活動化グループの省略値は
「*CALLER」である。
つまりサービス・プログラムの呼び出し側の親プログラムの終了とともにサービス・プログラムも
メモリから解放されて LR 終了と同じ状態となる。
また、あるサービス・プログラムが同じジョブ内で同時に上位の様々なプログラムから
呼び出されたとしても *CALLER としてサービス・プログラムが作成されているのであれば、
メモリ内にロードされているサービス・プログラムは、ただひとつだけであり、上位のプログラムの
すべてで、そのサービス・プログラムが共有されていることになる。
しかし業務によっては、これはまずい場合もあるかもしれない。
そのようなときには、明示的にユーザー(開発者) が活動化グループに名前をつけて、
別々のロードとさせることができる。
ここで注意であるが、OS400 V5R3M0 からは CRTPGM コマンドの活動化グループの
省略値は従来の *NEW から *ENTMOD にIBM によって変更されてしまっているが
*ENTMOD の場合は QILE という明示的な名前の活動化グループとなってしまい、
場合によっては開発者の期待とは異なる誤動作を生む原因となってしまう。
従来の動作を継承しようと思えば、必ず活動化グループは *NEW で作成しておくことを
忘れてはならない。

プログラム・スタックの名前が示すとおり OPM ではプログラム単位でスタックが
構成されていたが、ILE での実行管理単位はプロシージャーまで細分化されている。
従ってスタックはプログラム単位ではなく、プロシージャー単位である。

巷に良く耳にする「オブジェクト指向」とは、カプセル化されて品質の保証されたオブジェクトを
再利用する記述のことであるが、その意味においても ILE がオブジェクトを組み合わせて使う、
というオブジェクト指向であると言える。

System i は、ILE が導入されて以来、実は、System i 自身も ILE として構成されている。
C言語のライブラリーは、すべて ILE のサービス・プログラムとしてOS400 自身が作成されている。
つまり C/400に提供されている関数は、実は EXPORTプロシージャーでもある。
さらに数多く提供されている API そのものも EXPORTプロシージャーとして作成されているのである。
このことを理解すれば、RPG でもIBM 提供のサービス・プログラムをバインドすることによって
使用範囲が飛躍的に拡大するのである。
QSYS 等にあるサービス・プログラムを DSPSRVPGM で EXPORT関数を参照してみれば
そのことが良く理解できるはずだ。
ILE は単に RPG III から RPG IV へ拡張されたという単純なものではない。
OS400 そのものの構成が ILE として大きく変貌して、将来への可能性を拡張しているのである。

国内はまだ普及していないが、米国での RPGサンプル・ソース・コードの大半というか
ほとんどは フリー・フォーマットの RPG である。
フリー・フォーマットの RPGソース内では、プロシージャーの呼び出しには
CALLP も EVAL も要らない。
自分独自のRPG命令が欲しいと思っていた人には好都合だ。
プロシージャーが組み合わされたフリー・フォーマットの RPGソースを眺めていると
それはあたかも C/400 や Java のような言語を見ているようであり、
とても RPG とは思えないのも確かである。
フリー・フォーマットは、いずれ紹介していくことになると思うが
RPG は、プロシージャーとともに劇的に進化していくだろう。

ILE のパワーはこればかりではない。フリー・フォーマットに至らなくても
開発手法をイノベーションするパワーが ILE には秘められている。
C, C++ から VC++, C# へと歩んだように ILE は、既に次の進化の準備が
整っているのである。
Web2.0 の時代にあってRPG が JSP, PHP や Rubby より劇的に進化するのは
すぐそこに来ている。