ILEのサブ・プローシージャーを調べていくと従来のサブ・ルーチンとはどのように違うのかとの
疑問が湧いてくる。
サブ・プロシージャーはサービス・プログラム(*SRVPGM) からの公開プロシージャーだけでなく、
RPG自分自身の内部でも定義できるからである。
RPGの近代化として従来のサブ・ルーチンをサブ・プロシージャーに書き換えるようにとの
推薦を目にすることがよくある。
一見、サブ・プローシージャーもサブ・ルーチンに良く似ているようであるが最も異なるのは
サブ・プロシージャーは完全にカプセル化されていることである。
つまりサブ・プロシージャーはANSI-C やVisualBASIC、VisualC++、Java などの関数または
クラスに匹敵している。

サブ・プロシージャー内部で定義された変数はローカル変数としてサブ・プロシージャーの中だけで
有効である。
これに対してサブ・ルーチンはメイン・ルーチンの一部であり、メイン・ルーチンの変数とメモリなども
共有している。
つまりサブ・ルーチンとはメイン・ルーチンの一部なのである。
サブ・ルーチンの中から GOTO 命令や CABxx などでメイン・ルーチンへジャンプすることが
できることでも、サブ・ルーチンとはメイン・ルーチンの一部であることがわかる。

変数の値がおかしいと思ったらサブ・ルーチンの中で同じ変数名が使用されていたために
障害となっていたような経験はないだろうか？
サブ・プロシージャーでローカル変数を定義としておけば、このような障害は発生しない。
さらにサブ・プロシージャーではRPG全体で定義されているグローバル変数も使用することができる。
ILEでは厳密に言えばメイン・ルーチンさえもメイン・プロシージャーという、ひとつの特殊な
プロシージャーである。
さらにはILE ではひとつひとつのプロシージャーに対して入り口点が用意されている。
( CRTPGM + F4 で「プログラム入り口プロシージャー・モジュール」を指定することができる。）

*SRVPGM をILEで開発する場合は必ず H仕様書に NOMAIN と記述する。
つまりメイン・プロシージャーは無いことを示すのもこのためである。
RPGの近代化のためにサブ・ルーチンをサブ・プロシージャーに書き換えるという手法は
変数の重複を無くすためである。
このことによって他のPGM にプロシージャーをそのままコピーしても間違いなく正常に
動作するようになる。
つまりソースの再利用の可能性が高くなるのである。
ただしメイン・ルーチンとの変数の共有を意図的に行っているサブ・ルーチンには
サブ・プロシージャーへの移行では考慮が必要となる。