RPG IV のことを ILE-RPG とも表現するときがあるが、国内でも多くの開発者が
RPG IV は、単に RPG III の拡張版として CRTBNDRPG を使ってのコンパイルが
まだまだ多いのかも知れない。
ILE-RPG と呼ばれる背景は、ILE (Integrated Langage Enviroment =統合化開発環境) として
RPG だけでなく、System i で複数の言語で開発されたモジュールを統合化して
新しいモジュールとして再作成できる、という点にある。
つまり既に完成されて品質が保証されているオブジェクトを再利用することによって
短期間に品質に優れたオブジェクトの開発を行うという、いわゆる「オブジェクト指向」の
開発を可能にするものである。
RPG III の延長として RPG IV を考えるのもよいのだが、折角、ILE として機能が与えられている
のであるから、ここで一度、ILE としての RPG を考えてみよう。
今、米国誌では「適用業務の近代化」(Modernization) が、まっさかりであり、いずれ日本にも
RPG の近代化の波が押し寄せてくるだろう。
RPG の近代化や MVCモデル化には、ILE の理解が最も基本として必要となる。
ILE とは何か? ILE をどのように利用すべきか ? を、このシリーズで紹介しよう。
■ OPM と ILE
旧 RPG III の開発言語は OPM (Origibal Program Model) と呼ばれており、
のようにして、CRTRPGPGM コマンドによって、実行可能な *PGM を生成することは
良く知られている。
これに対して、RPG IV は ILE(Integrated Language Envoroment) と呼ばれており、
または、
または、
のコンパイル形式を取る。
ILE-RPG では、コンパイラー・コマンド CRTRPGPGM が CRTBNDRPG に変更されたと考えてはいけない。
CRTRPGMOD + CRTPGM が、ILE本来のコンパイルの方法である。
それでは従来、CRTRPGPGM ひとつだけで事足りたのに、何故、CRTRPGMOD + CRTPGM という、
2段階の手間を必要とするのであろうか ?
それは ILE では、一般的には複数のモジュールやサービス・プログラムから、ひとつのプログラムが
生成されるという考え方が標準であるからである。
【 ①複数のモジュールから生成される場合 】
【 ②複数のサービス・プログラムから生成される場合 】
【 ③ 上記の①と②が混在して生成する場合 】
(略)
■ モジュールとサービス・プログラムの違いとは ?
モジュールはILE では、プログラム(*PGM) を生成するための中間オブジェクトであり、
モジュール自体は、プログラムのように呼び出して実行することはできない。
CRTPGM コマンドによってモジュールの実体はプログラム(*PGM) の中に組み込まれるので
プログラム(*PGM) ができてしまえば、モジュールの存在は全く、不要なものとなる。
このため CRTRPGMOD などによってモジュールはライブラリー QTEMP に作成することが多い。
Microsoft の VC++ でもモジュールに相当する、「.obj」(オブジェクト) という
中間オブジェクトが生成されるようになっている。
モジュールに対して、サービス・プログラム(*SRVPGM) は Windows の DLL (Dynamic
Linc Library) に相当するものであり、サービス・プログラム自体は、やはり実行することは
できないが、プログラムからサービス・プログラムの機能(関数=プロシージャー) を
呼び出して利用するようになっている。
これは Widnows で .exe プログラムが DLL (.dll) を呼び出すのと全く同じ関係である。
先に CRTPGM を行うとモジュールの実体はプログラムに組み込まれると説明したが、
これに対してサービス・プログラムは CRTPGM によって新たなプログラムに組み込まれたとしても
サービス・プログラムの実体がプログラムに組み込まれることはない。
プログラムは実行時に初めて、自分が参照すべきサービス・プログラム(*SRVPGM) を
読み出すのである。
従ってサービス・プログラムは、親となるプログラムの実行時にも存在していなければ
ならない。
■ なぜ ILE が必要なのか ?
例えば、日付計算の処理だけをあるRPGソースに組み込んでおくものとする。
この日付計算の処理を多くのプログラムで共有して利用したい場合を想定して欲しい。
RPG III であってもサブ・ルーチン化して /COPY でインクルードすればよいと
考えることができるが、それでは日付計算の処理が変更されたときには、
その /COPY を参照しているすべてのプログラムを調べ上げて、すべてを
再コンパイルする必要がある。
これは管理上、大変、労力を必要とするだけでなくコンパイル漏れによる障害を
発生する可能性がある。
それではサブ・プログラムとして CALL 命令によって呼び出すようにしてはどうだろうか?
CALL 命令は、動的な呼び出しであり、CALL 命令によって呼び出されたときに
初めて子プログラムがメモリ上にロードされるため、最初はもちろん繰り返し呼び出しには
オーバー・ヘッドを生じてしまう。
これに対してサービス・プログラムしてILE で利用される場合は、最初のプログラムの
ロード時点で必要なサービス・プログラムも同時にロードされるために、
あたかも、ひとつのプログラムの中のロジックのように高速で動作することが
IBM によって保証されている。
サービス・プログラム(*SRVPGM) の場合、プログラム配下の各モジュールが
それぞれ同じサービス・プログラム(*SRVPGM) を呼び出していたとしても
サービス・プログラムの活動化グループは多くの場合、*CALLER として作成されているので、
実際にメモリにロードされねのは、ひとつだけである。
■ モジュールか？サービス・プログラムか ?
モジュールの場合でも、どこかのモジュールだけを保管するライブラリーに
モジュールを保管しておいて CRTPGM によって参照すればサービス・プログラムと
同じことであると思われるかも知れないが、先に説明したようにモジュールの実体は
プログラムの中に組み込まれてしまっている。
従ってモジュールの基となるRPGソースに変更が発生して、モジュールを再作成した場合には
そのモジュールによって生成されたプログラムも、再作成(コンパイル) する必要がある。
これでは、折角の ILE の利点を生かすことができない。
保管モジュールを利用する手法も必要な場面が発生することもあるのは確かであるが
一般の適用業務の開発でオブジェクト指向としてオブジェクトの再利用を考えるのであれば
サービス・プログラムを活用すべきである。
Java がオブジェクト指向として注目された点も、ここにあり、Java の場合は
すべてのオブジェクト .class が、同時にサービス・プログラムとしての再利用を
行うことができるからである。
( ただし Java はボインターを扱うことができないという、プロユースとしては
問題となる点を含んでいる。)
ILE-RPG においても サービス・プログラム(*SRVPGM) の利用が ILEを活用する点で
大きなポイントなる。
次の章ではサービス・プログラムの作成方法を解説する。