今年は梅雨明けが遅いようで、この原稿を書いている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コマンドを使用します。オブジェクト的にサービス・プログラムはモジュールの集まりですが、プログラマーから見ればあくまでプロシージャの集まりです。
モジュールをばらばらに管理するのではなく、システムに１つ、または任意の単位ごとにサービス・プログラムを管理することで、同じような処理のプロシージャが増えるのを防ぐことも容易になります。CALLPだけでなく、戻り値の指定もできますから、イメージとしてはユーザーが関数を作るようなものになります（図表4）。
RPGⅢは関数を使えない数少ない言語の1つでもありますが、RPGⅣからは便利な関数が豊富に用意されています。その関数をユーザー側で作ってみるのも非常に面白いですし、今後の開発に役立つことは間違いありません。プログラム管理、標準化、といった観点から、RPGⅣへの移行を考えてみるのもよいでしょう。
著者｜中村 潤 氏
株式会社アイ・ラーニング
IT研修本部 IBM製品研修部
ラーニング・アドバイザー
［i Magazine 2016年8月号掲載］
････････
◎ 連載｜RPG Ⅳの魅力と可能性 目次
- 第1回 RPG ⅢとRPG Ⅳのコーディングの違い
- 第2回 驚くほど簡単になる、RPG Ⅳの日付計算機能
- 第3回 静的プロシージャーによるパフォーマンス向上
- 第4回 RPGⅢからRPGⅣへの移行の実際
- 第5回 RPGⅣのフリーフォームの特長と魅力
- 第6回 RPGⅣの関数を使おう！
- 第7回 フリーフォームRPGで開発要員養成コストを削減
- 第8回 若い人の声に耳を傾けるべき時がきた
- 第9回 フリーフォームRPGで「プログラム記述」レポート印刷プログラムにトライ！
- 第10回 組み込みRPGのすすめ
- 第11回 RPG Ⅳのメリット：保守の容易性を考える
- 第12回 RPG Ⅲのよさを再考する
- 第13回 RPG資産を次世代へ引き継ぐための準備は、今が踏ん張り時
- 第14回（最終回） 独学では得られない知識・情報が詰まったIBM iの研修コース
