RPG Ⅳのメリット:保守の容易性を考える ~連載|RPG Ⅳの魅力と可能性◎第11回

 今年は梅雨明けが遅いようで、この原稿を書いている7月下旬では、まだ東京地方の梅雨明け宣言が出ていません。私はどの季節が好きかと聞かれれば、間違いなく「夏!」と答えていた、自称・夏男でしたが、梅雨が明けない秋のような東京の気候に、このまま秋になってくれ、などと考えるようになったのは、やはり歳のせいでしょうか。さて、今回も元気にRPGⅣのお話をしていきましょう!

 

保守を容易にする:標準化

 RPGⅣにはRPGⅢにないメリットがたくさんあります。その1つがILE、統合言語環境(Integrated Language Environment)であることは、本連載の第3回で触れたとおりです。その回では、ILEのよさの1つにパフォーマンスがある、という話でしたが、今回は「保守の容易性」について解説します。

 みなさんがおもちのRPGⅢプログラムは、1つのソースメンバー当たり何ステップくらいあるでしょうか。RPGはCOBOLよりもはるかに少ないステップ数でコーディングが可能ですが、それでも1プログラム(1ソースメンバー)当たり1000〜2000ステップはざらにあると思います。1万ステップ以上も少なくはないでしょう。

 この膨大なステップ数のプログラムの保守を、限られた人員、限られた期間で行うのは決して容易ではありません。そのためにもプログラムのソースを誰が見てもわかりやすいものにする必要があります。

 この方法について述べれば、それだけで1冊の本になりそうですが、その1つは「標準化」です。サブルーチンの配置の仕方、サブルーチンやフィールドの名前のつけ方、標識の番号の意味づけ(60番台は画面制御、90番台はファイル操作、のように)、ファイル仕様書は入力ファイルを先に、出力ファイルを後に指定するなど、項目はいろいろありますが、それでもRPGⅢの場合は他の言語と比べて、それほどたくさんの決め事にはならないと思います。

 この標準化も「ルール」ですので、ルールを作る人、ルールを守らせる人、やはりそれなりに運用は大変です。アイ・ラーニングのRPG研修への受講者に「みなさんのチームでは標準化のルールは設けていますか」とお尋ねすると、ほぼ全員が首をかしげます。聞いたこともない、というのが実情のようです。

 

保守を容易にする:モジュール化

 ソース・プログラムを誰が見てもわかりやすいものにする、もう1つの方法は、プログラムのモジュール化です。これは、すべての処理をいくつかの単位に分割して作成し、CALL命令で呼び出して実行させるものです。分割したプログラムはソースメンバーも、コンパイルしたプログラムオブジェクトもまったく別物です。そして別プログラムであるがゆえに、「ステップ数が少ない」「複数の人員による並行開発/保守ができる」というメリットが生まれます。RPGⅢでは、この開発方法をOPM(Original Program Model)と呼びます。図表1のプログラムは、MAIN001から、サブプログラムSUB001を呼び出し、パラメータに得意先番号と受注金額を受け渡しています。

 

 

 しかし、この方法でプログラムを分割するパターンはそれほど多く見られません。すべてを1つのプログラムで処理するパターンのほうが非常に多く見受けられます。理由としては、別プログラム(いわゆるサブプログラム)をCALLすることによって、多くのリソースを消費する、さらに同じプログラムを何度も実行することによって発生するオーバーヘッドを避けたい、ということがあります。

 パフォーマンスについては、近年のIBM iでは昔ほど神経質にならずとも強力なPOWERプロセッサのおかげで、格段に優れたものになっています。しかし私を含めて、システム36やシステム38時代からRPGでプログラムを書いている人にとっては、プログラムの分割にはどうしても抵抗があるようです。ILE環境でプログラム開発を行うことによって、リソース、パフォーマンスの問題が一挙に解決することは、第3回でお話ししたとおりです。

 

 

プロシージャを活用する

 ILEではプログラムの単位を「プロシージャ」と言います。プロシージャではRPGの内部論理で行われる初期処理が大幅に軽減されます。

 分割したプロシージャはモジュール(オブジェクト・タイプ:*MODULE)としてコンパイルされ、関連し合うモジュールをバインド(結合)することによって、実行可能なプログラム・オブジェクトが作成されます。

 プロシージャ呼び出しをCLコマンドで行うことはできません。あくまでプロシージャ内からプロシージャ呼び出し(RPG ⅣのCALLP命令、戻り値がある場合は関数形式の代入文でも実行できます)を行い、あたかもEXSRで内部サブルーチンを実行するかのように高速に呼び出せます。

 図表2では、MAINというプロシージャから、CALLP命令でプロシージャSUB001を実行し、関数形式で戻り値をRESULTに代入する形でSUB002を実行しています。この3つのプロシージャはCRTRPGMODコマンドでそれぞれモジュールにコンパイルされ、CRTPGMコマンドで結合されてPGM001というプログラムになります。

 

 これにより、「個々のプログラムステップ数が少ない」「複数の人員による並行開発/保守ができる」というメリットを、安心して享受できます。結合されるプログラムはRPGだけでなく、COBOL、C、CLプログラムでも可能です。

 

 

サービス・プログラムを使用する

 また、サービス・プログラムの使用により、プログラム管理がより簡単になります。サービス・プログラムは、すべてのプロシージャから参照可能なプロシージャの集まりです。プログラマーは入口プロシージャ(メインとなるプログラム)を作成し、そのプロシージャからサービス・プログラム内のプロシージャを呼び出します。プログラムを結合する際には、入口プロシージャと、呼び出されるプロシージャを含むサービス・プログラムを指定します(図表3)。

 

 サービス・プログラム作成には、一連のモジュール作成後、CRTSRVPGMコマンドを使用します。オブジェクト的にサービス・プログラムはモジュールの集まりですが、プログラマーから見ればあくまでプロシージャの集まりです。

 モジュールをばらばらに管理するのではなく、システムに1つ、または任意の単位ごとにサービス・プログラムを管理することで、同じような処理のプロシージャが増えるのを防ぐことも容易になります。CALLPだけでなく、戻り値の指定もできますから、イメージとしてはユーザーが関数を作るようなものになります(図表4)。

 

 

 RPGⅢは関数を使えない数少ない言語の1つでもありますが、RPGⅣからは便利な関数が豊富に用意されています。その関数をユーザー側で作ってみるのも非常に面白いですし、今後の開発に役立つことは間違いありません。プログラム管理、標準化、といった観点から、RPGⅣへの移行を考えてみるのもよいでしょう。

 

著者|中村 潤 氏

株式会社アイ・ラーニング
IT研修本部 IBM製品研修部
ラーニング・アドバイザー

[i Magazine 2016年8月号掲載]

・・・・・・・・

◎ 連載|RPG Ⅳの魅力と可能性 目次

 

More Posts