ILEのサブ・プローシージャーを調べていくと従来のサブ・ルーチンとはどのように違うのかとの

疑問が湧いてくる。

サブ・プロシージャーはサービス・プログラム(*SRVPGM) からの公開プロシージャーだけでなく、

RPG自分自身の内部でも定義できるからである。

RPGの近代化として従来のサブ・ルーチンをサブ・プロシージャーに書き換えるようにとの

推薦を目にすることがよくある。

一見、サブ・プローシージャーもサブ・ルーチンに良く似ているようであるが最も異なるのは

サブ・プロシージャーは完全にカプセル化されていることである。

つまりサブ・プロシージャーはANSI-C やVisualBASIC、VisualC++、Java などの関数または

クラスに匹敵している。

サブ・プロシージャー内部で定義された変数はローカル変数としてサブ・プロシージャーの中だけで

有効である。

これに対してサブ・ルーチンはメイン・ルーチンの一部であり、メイン・ルーチンの変数とメモリなども

共有している。

つまりサブ・ルーチンとはメイン・ルーチンの一部なのである。

サブ・ルーチンの中から GOTO 命令や CABxx などでメイン・ルーチンへジャンプすることが

できることでも、サブ・ルーチンとはメイン・ルーチンの一部であることがわかる。

変数の値がおかしいと思ったらサブ・ルーチンの中で同じ変数名が使用されていたために

障害となっていたような経験はないだろうか？

サブ・プロシージャーでローカル変数を定義としておけば、このような障害は発生しない。

さらにサブ・プロシージャーではRPG全体で定義されているグローバル変数も使用することができる。

ILEでは厳密に言えばメイン・ルーチンさえもメイン・プロシージャーという、ひとつの特殊な

プロシージャーである。

さらにはILE ではひとつひとつのプロシージャーに対して入り口点が用意されている。

( CRTPGM + F4 で「プログラム入り口プロシージャー・モジュール」を指定することができる。）

*SRVPGM をILEで開発する場合は必ず H仕様書に NOMAIN と記述する。

つまりメイン・プロシージャーは無いことを示すのもこのためである。

RPGの近代化のためにサブ・ルーチンをサブ・プロシージャーに書き換えるという手法は

変数の重複を無くすためである。

このことによって他のPGM にプロシージャーをそのままコピーしても間違いなく正常に

動作するようになる。

つまりソースの再利用の可能性が高くなるのである。

ただしメイン・ルーチンとの変数の共有を意図的に行っているサブ・ルーチンには

サブ・プロシージャーへの移行では考慮が必要となる。