【第4回】　コネクト – フリーフォーム RPG

前回は「ブリッジ」をキーワードに、RPG Ⅳ の歴史と役割について解説しました。その中で RPG Ⅳ の歴史には以下、大きな二つの転換点があることを紹介しました。

1. 演算仕様書のみフリーフォーム化
2. 完全フリーフォーム化

演算仕様書のみのフリーフォーム化は「RPG プログラマーと、最新の機能（特に組込関数）」との間のブリッジ、そして完全フリーフォーム化は「他のプラットフォーム / 他言語の開発者」との間のブリッジであると定義しました。今回は IBM i の外の世界を意識しながら、その世界とのブリッジの役割を提供する RPG Ⅳ の完全フリーフォーム化について詳しく扱っていきます。この記事では文法的な解説はおこなわず、フリーフォーム化するにあたっての必要な前提知識とその意味について考えていきたいと思います。今回のキーワードは「コネクト」です。

FFRPGもRPG Ⅳ

RPG Ⅳ が 1994 年に登場した際、ユーザーはこのバージョンを RPG Ⅲ と同様の完全な定位置記入形式で記述するものとして捉えていたように思います。この形式はRPG Ⅲ のソースコードを CVTRPGSRC コマンドを使って変換できるので、RPG Ⅲ ユーザーにも違和感なく使って頂ける形式です。もちろん拡張演算項目 2 に組込関数を使ったり複雑な計算をおこなう式を記述することもできましたが、ユーザーはすぐにその機能を利用することはありませんでした。 一方、フリーフォーム RPG は、すべての行をフリーで記述する、つまり桁位置が決まっていない書き方です。RPG Ⅳ が発表された時とはくらべようがないぐらいユーザーにはインパクトのある変化であり、定位置記入形式と比較するとまったく別の言語のようにも見えるのですが、実はこの完全フリーフォーム RPG（以下 FFRPG）も RPG Ⅳ に内包されるものです。FFRPG という別バージョンが存在するわけではない点に注意してください。今後、FFRPG に関する多くの情報や記事をいろんな雑誌やネットで皆さんも見る機会が増えると思いますが、バージョンとしてはあくまでも RPG Ⅳ であるので混乱しないようにしましょう。 今回は文法的な観点の解説はおこないませんが、一つだけ以下の点に注意してください。定位置記入形式でも FFRPG でもモジュールを生成するコマンドは CRTBNDRPG で共通です。従って、コンパイラーはソースが定位置記入形式で書かれているのか FFRPG なのかを判別する仕組みが必要になります。プログラム・ソースが完全フリーフォームで書かれていることをコンパイラーに伝えるためにはソースの 1 行目の 1 桁目に **free を指定してください。この記述がないとコンパイラーは定位置記入形式で記述されている前提で文法チェックをおこなうので注意してください。

Modern RPG

海外の RPG に関する記事を読むと「Modern RPG」という単語を目にすることがあります。日本語のニュアンスとしては「モダン」という言葉を使うことがそもそもちょっと古めかしい印象がありますが、ここでの「Modern」という言葉はそのまま「今風、最新」といった意味で使われています。IBM の資料によると「Modern RPG programs」とは、以下の要件を満たしたものを指すようです。

1. フリーフォームで書かれていること
2. プログラムがモジュール化されていること

モジュールはもともと設計上の概念ですが、プログラム的にはロジックがカプセル化されていて再帰的に呼び出すことが可能なものを言います。RPG IV でこれを実現するために用意されているのがプロシージャーであることは前回の記事で紹介しました。すなわち、「Modern RPG programs」とは、FFRPG で記述され、プロシージャーを駆使して書かれたプログラムということになります。しかも各プロシージャーはカプセル化を実現するためにグローバル変数ではなくローカル変数を極力使用し、外部とのデータ受け渡しはパラメータか戻り値を利用するように設計されていることが重要です。これを徹底することによりプロシージャーの部品化が実現でき、再利用することも可能になります。設計時には、各部品をとても小さい独立したプログラムのように考えることが重要です。ではもう少しこの点を RPG という言語の構造を通して考えていきましょう。

プログラムの構造

RPG Ⅳプログラムは、一つあるいは複数のモジュール・オブジェクト（*MODULE）で構成されています。コンパイル単位はモジュールであり、一つのソースから一つのモジュール・オブジェクトが生成されることになります。モジュール・オブジェクトは実行することはできませんので、CRTPGM というコマンドを使用して実行可能なオブジェクトを生成する必要があります。一つのプログラムには、さまざまな言語で作成されたモジュールを含めることが可能です。RPG と C 、COBOL で作成した各モジュールを一つのプログラムにまとめるなどです。 ではこのモジュールをさらに詳しく見ていきましょう。一つのモジュールは一つあるいは複数のプロシージャーで構成されます。プロシージャーにはメイン・プロシージャーとサブ・プロシージャーがあり、メイン・プロシージャーは最大一つ、サブ・プロシージャーは複数含めることができます。モジュール・オブジェクトとして可能なプロシージャーの組み合わせは以下の通りです。

1. サイクル・メイン・プロシージャーと０または１つ以上のサブ・プロシージャー
2. リニア・メイン・プロシージャーと０または１つ以上のサブ・プロシージャー
3. 一つあるいは複数のサブ・プロシージャーのみ

実行可能なプログラムは、プログラム入口プロシージャーを含むモジュールを一つ以上含んでいなければなりません。この入口プロシージャーはメイン・プロシージャーでなければなりません。1 と2 は、それぞれサイクルおよびリニアという異なる種類のメイン・プロシージャーを含んでいるモジュールなので、入口プロシージャーとして指定できます。 サイクル・メイン・プロシージャーは RPG 言語がもともと持っているサイクル論理を含んでおり、何も指定しなくてもメイン・プロシージャーとなります。リニア・メイン・プロシージャーは、どのプロシージャーをメインとするかを main キーワードで明示的に指定します。この場合、サイクル論理は含まれない点に注意してください。サイクル論理については後ほど解説します。サイクル・メイン・プロシージャーで定義した変数をグローバル変数と言い、それ以外のプロシージャー内で定義した変数をローカル変数と言います。ローカル変数はそのプロシージャー内でのみ参照可能な変数で、他のプロシージャーからは参照できません。Modern RPG はグローバル変数ではなく極力ローカル変数を使うという決まりのため、サブ・プロシージャーを含まないサイクル・メイン・プロシージャーだけのモジュールで作成されるプログラムはモダンではないということになります。ちなみに、この形式が CVRTRPGSRC コマンドで単にソースを変換しただけの RPG Ⅳ プログラムです。

FFRPGとサイクル

ではここで、RPG のサイクル論理について少し触れておきましょう。これから IBM i をお使いになる方はこのサイクルを使用する機会はなかなかないと思いますが、RPG という言語を理解する上でとても重要な概念ですのでしばらくお付き合いください。 RPG という名前は Report Program Generator のアクロニム（頭字語※1）です。読んでおわかりのように、もともとは印刷プログラムを簡単に作成できるよう設計された言語です。印刷プログラムはどのようなものであれ、おおよそ以下の機能が必要になるはずです。

1. 印刷するデータを含むファイルをオープンする ・データを読む ・印刷前の計算を行う ・印刷する
2. 上記を繰り返し、小計があれば印刷する
3. 全データを処理し終わったら合計を印刷する
4. ファイルをクローズする
5. プログラムを終了する

RPG のサイクル論理とは、上記のロジックをあらかじめコンパイラーが自動生成したものです。サイクル論理を使うことで、プログラマーは自動で読ませるファイル、小計のタイミング、印刷するイメージだけを指定すれば良く、プログラムの記述量が少なくて済むという利点があります。サイクル論理に自動的に読ませるファイルをプライマリー、あるいはセカンダリー・ファイルといえます。 もちろん RPG 言語は印刷以外の処理をおこなうプログラムを作成することも可能です。むしろ現在ではそちらのほうが圧倒的に多いでしょう。しかし、印刷以外の機能を持つ RPG プログラムを作成する場合であっても、コンパイラーはこのサイクル論理を自動生成してしまいます。モジュールにサイクル論理を生成させないという選択は、IBM i 6.1 からサポートされた main キーワードを待つしかありませんでした。 ではFFRPG に話を戻しましょう。サイクル論理で自動的に読ませるプライマリーおよびセカンダリーをどのファイルにするかは、ファイルの定義をおこなうために使用する F 仕様書のある桁に P もしくは S を指定することで決まるのですが、FFRPG ではこの F 仕様書を使いません。替わりに DCL-F で処理するファイル指定します。実は、この DCL-F 命令ではプライマリーおよびセカンダリーのファイル指定がサポートされないのです。つまり、FFRPG ではサイクル論理を使うことができないということになります。ただ、通常のプログラムの書き方をしているとサイクル論理はコンパイラーによって生成されてしまいます。そこで先ほど触れた main キーワード（ctl-opt nomain(プロシージャー名)）の出番です。これを指定することで、このモジュールにはサイクル・メイン・プロシージャーはなく、指定されたプロシージャーをリニア・メイン・プロシージャーとして定義することができるのです。不要なロジックが生成されないので、プログラム・オブジェクトのサイズも小さくなります。 サイクル論理が生成されないことで逆に注意すべき点もあります。例えばファイルのクローズ処理はサイクル論理の中に含まれていることに注意してください。RPG プログラマーはこのお陰でサイクル論理を使うか使わないかにかかわらず、ファイルのクローズ処理を意識しないで、プログラム終了処理として単に LR 標識をオンにするだけで良かったのです。この標識がオンだと、サイクル論理内のファイルのクローズ処理が実行されます。ちなみに LR は Last Record の略です。 しかし、リニア・メイン・プロシージャーではサイクル論理が生成されないので、ファイルの暗黙的なクローズはおこなわれません。プログラマーはプログラムを完全に終了させるときは CLOSE 命令を実行して明示的にファイルをクローズする必要があります。以前からのRPGに慣れている、ベテランの RPG 技術者の方には特に注意していただきたいところです。 _{※1 頭字語（とうじご）とは、主にヨーロッパ言語のアルファベットにおける略語の一種で、複数の単語から構成された合成語の頭文字を繋げて作られた語のこと。（Wikipediaより）}

FFRPG のコーディング・スタイル

次に、コードをフリーフォーム化することの利点について考えてみましょう。まず大きな利点は、読みやすいコードが書けるということだと思います。読みやすさの基準は人それぞれだと思いますが、例えばインデントすることによりコードの構造を視覚的に読み取りやすくできます。また、定位置記入の場合の桁位置の制約を受けることがないので、不必要な改行などもする必要がありません。読みやすくなるということは、それだけプログラムの保守性が向上するということに繋がります。なぜ保守性が向上するのかという点については「お役立ち記事 – フリーフォーム RPG を使う 5 つの理由とは？」にとてもわかりやすくまとめてあるのでそちらの記事もぜひお読みください。 プログラムの保守性をより確かなものにするために、開発プロジェクト内でコーディング・スタイルを定義してそれを適用されることが多いと思います。RPG はもちろんですが、開発人口の多い Java や C 言語にもたくさんの優れたコーディング・スタイルが存在しています。ただ、RPG のコーディング・スタイルは、その言語の特殊性から、かなり制約された中で定義するしかありませんでした。その特殊性とはここまでも既に何度か出てきている、定位置記入形式に起因します。例えば、RPG　Ⅲ では変数名は 6 桁までという制約があったので、変数の命名規則も非常に制約のあるものしか作れなかったのです。 では、FFRPG ではどのようなことが期待できるのでしょうか？例えばインデントを何桁にするのか、変数の命名規則をどうするか、コメントの書き方など、定位置記入の制約から完全に開放されるので、他の言語と同じレベルでコーディング・スタイルを定義することが可能になります。さらに、他言語で一般的に使用されているスタイルを FFRPG にそのまま適用することさえも実現できそうです。

RPGに新しいプログラマーを呼び込めるか？

他言語の技術者が RPG 言語に対して持つ違和感は、多言語の記述方式では考慮することのない、定位置記入形式の特殊性にあるということは誰もが認めるところでしょう。しかし、FFRPG では定位置記入形式での記述が不要なので、この特殊性が排除されます。さらに、先ほど触れたように他言語のコーディング・スタイルを FFRPG に適用すれば、言語間の違和感もほとんどなくなり、IBM i のシステム開発と新しいプログラマーの「コネクト」を実現できるはずです。

FFRPG + 他言語と共通のコーディング・スタイル

ただしこれはコードの書き方の話であり、もう一つ大事な要素が欠けています。それは開発環境です。どんなにコードの書き方において他言語との違和感がなくなっても、そのコードを記述するエディターなどのツールや環境が一般的なものでなければ、新しいプログラマーは習得に抵抗を感じてしまうことでしょう。 エディターを含む開発環境やツールに関しては次回以降の記事で詳細を説明しますが、この点についても IBM i はきちんと解決策を用意しています。つまり、ある意味ガラパゴス化していた IBM i のシステム開発を刷新し、新しい技術者を招く準備は既にできているということです。RPG がフリーフォーム化し、習得しやすくなったことにより、SoR （System Of Records）の構築に必要な人材の裾野は今後大きく広がることになるでしょう。 IBM i の開発責任者であるスティーブ・ウィル氏は次のように語っています。「RPGのフリーフォーム化は、ここ10年の機能強化の中で、最も速く取り入れられ、広まったものといえます。フリーフォームRPGを教えるクラスやコンサルタントの増加や、若手技術者がRPGを使って数多くのプロジェクトを手がけることにより、急速に広まりました。米国でも欧州でも同じような現象がみられます。若手プログラマーにとって、RPGの敷居がグンと下がっているのではないでしょうか。PHP、C、Perl経験者にとって、オブジェクト指向のjavaやC++よりも入りやすいはずです。」 参考：開発責任者に聞く！IBM i はどこへ進む？IBMの本気度は？ アメリカやヨーロッパだけでなく、日本でも若手技術者に FFRPG を広めていきたいですね。

おわりに

「メルクマール」というドイツ語があります。外国語なのでもともとの意味を正確には理解していませんが、日本では到達点とか臨界点、あるいは転換点などという意味で使われているようです。無理やりこじつけるならば、FFRPG はガラパゴス化した IBM i の開発を外の世界に向かってオープンにした転換点、つまりメルクマールといえるかもしれません。IBM i の開発を新しい世界と「コネクト」する、この FFRPG に今後も注目していきたいと思います。

著者プロフィール