前回の記事では、「この言語バージョン（RPG Ⅲ）を大事にしながら、最新のバージョンである RPG Ⅳ についてもより理解を深めていきましょう。」として記事を締めくくりました。そこで、今回は RPG Ⅲの次バージョンであるRPG Ⅳを取り上げます。このバージョンは 1994 年に発表されており、22 年が経過。その間、言語としてさまざまな機能拡張がなされてきました。本記事では、まずその 22 年の間におこなわれてきた機能拡張の概要をまとめ、それらの機能拡張とそれを取り巻く環境について解説します。その上でRPG Ⅳ の中に存在する 2 つの大きな転換点についてRPG Ⅳ をまだよく知らないという方でも理解できるよう、さまざま角度から解説します。今回のポイントとなるキーワードは「ブリッジ」です。それではどうぞ、お付き合いください。
RPG Ⅳ とは何か
すでに触れたように、 RPG Ⅳ が登場して今年で22 年目となります。1994 年に発表された OS/400 V3R1 と2016 年 10 月の時点で最新のバージョンである 7.3 の間には、実に 11 のバージョンおよびリリースが存在しており、それぞれにおいてさまざまな機能拡張がおこなわれました。以下、主なものだけをまとめています。
V3R6 / V3R2
- 1つのモジュールを複数のプロシージャーを使用してコーディング可能に
モジュール・プログラミング
プロシージャーの再帰呼び出し - 整数データ・タイプのサポート
V3R7
- 10文字以上の長い名前のサポート
- さまざまな組み込み関数のサポート
V4R2
- 可変長フィールドのサポート
- 結果の標識の代わりに組み込み関数を仕様する機能（％EOF、％FOUNDなど）
- 標識変数の定義
V4R4
- UCS-2 のサポート
- スレッド環境での ILE RPG プロシージャー呼び出しのサポート
- FOR / LEAVESR などの新しい命令コードのサポート
V5R1
- Java プロシージャーの呼び出しのサポート
- 演算仕様書の完全自由形式のサポート
V5R2
- データ構造定義の拡張
- UPDATE 時の更新フィールドのリストの指定
- 数値データの31桁サポート
- +=、-= などの新しい代入演算子のサポート
- IFS ソース・ファイルのサポート
V5R3
- 配列関連の関数追加および命令コードの拡張
- パックおよびゾーンデータが63桁まで拡張
V5R4
- %XML 関数のサポート
- XML-INTO 命令コードのサポート
6.1
- RPG サイクルを使用しないメイン・プロシージャーの定義
- サブプロシージャー内でのファイルのローカル定義
- コンパイル時の外部記述取得ファイルを指定する EXTDESC キーワードの追加
7.2
- 制御、ファイル、定義およびプロシージャーの各ステートメントの自由形式の記述
改めてリスト化して振り返ってみることで、メインで使用されている言語が RPG Ⅲ の方だけでなく、RPG Ⅳ を普段使用されている方でも「こんなことができるのか」と思われる機能拡張もあったのではないでしょうか。これらさまざまな機能拡張のうち、現時点でぜひ皆さんに知っておいていただきたい機能をまとめてみました。
上記のポイント
- プロシージャーのサポート
- 処理のカプセル化をより強固に実現
- 別プログラム化するよりも呼び出しパフォーマンスが良い
- プロシージャーをユーザー定義関数としてサービス・プログラムにまとめることが可能（部品化）
- 新しいデータ・タイプのサポート
- 他言語で作成されたプログラムとの連携強化（相互呼び出し）
- 標識が必須の演算命令を組み込み関数に置き換え
- ソースのフリーフォーマット化への布石
- IFSに保存されたファイルをソースにしてコンパイル可能に
- エディターの選択肢がより広がる
- XML 形式のネイティブでのサポート
- 他システムとのデータ連携がより柔軟に
標識について
ここで、RPG Ⅲ ユーザーにはとてもなじみのある標識について触れておきたいと思います。標識とは、2 つの状態（オンとオフ、’1′ と ‘0’）のみを保持可能な特別な内部変数で、コンパイラーによりあらかじめ提供されます（ユーザーが定義する必要のないものです）。RPG Ⅲ では標識の概念は非常に重要でした。各行の実行を制御する選択標識と、命令実行結果を保存するための結果の標識があり、これを使わないとプログラムを記述することは不可能でした。
選択標識と結果の標識は記述する桁位置が決まっていたので簡単にコーディングすることができる反面、使用する主な標識が汎用標識（01-99）であり、各標識にプログラマーが自由に役割を持たせることができるため、かえってコードが読みづらくなるという欠点を持っていました。この標識の弊害は早くから認識されており、コーディングの標準化において、汎用標識それぞれに意味を持たせて使用方法を限定（60は汎用エラー標識とするなど）したり、選択標識は IF 命令で置き換えるなどの工夫で使用を控えられたものの、結果の標識に関しては文法的に記述が必須であり、代替案は存在しなかったのです。
RPG Ⅳ になると、すでに触れたようにさまざまな関数および標識フィールドの定義がサポートされ、演算仕様書のフリーフォーム化も手伝って標識をほとんど使用することなく（あるいは意識することなく）プログラムを記述することができるようになりました。これらについては、より保守性の高いプログラムを作成できるという点においてとても重要なことです。
また、V4R2 の機能拡張で標識変数の定義がサポートされたことにより、意味のある名前の標識を定義することで、標識を使わなければならない部分もある程度、可読性の向上を実現することが可能となっています。
IBM i 特有の外部記述ファイルを使用する場合は、プログラムとファイル間でエラー状態などを共有するために汎用標識を使わざるを得ないケースもあります。その場合も、ポインターの概念を使用して汎用標識とユーザーが定義する標識変数をマッピングすることにより、誰が見ても読みやすいコードとして記述することが可能となっています。
拡張演算項目２のサポート
RPG Ⅲ は 7 つの仕様書を必要に応じて選択し、記述します。プログラムで使用するファイルと使用用途の定義には F 仕様書を、ロジックを記述するには C 仕様書をというように選択します。RPG Ⅳ でも仕様書の数は 7 つと変わりませんが、RPG Ⅳ になって削除された仕様書が 2 つあり、新たに追加されたものが 2 つあります。ここでは、どちらのバージョンにも存在する C 仕様書について触れておきたいと思います。
RPG Ⅳ の演算仕様書も、定位置記入形式で記述できるようにどの桁に何を記述するかが決まっています（ただし、RPG Ⅲ の桁位置と RPG Ⅳ の桁位置は異なっています）。この桁位置が決まっていることにより、例えば CVTRPGSRC というシステム提供のコマンドで、RPG Ⅲ のソースを機械的に RPG Ⅳ に変換することができます。前回の記事で、「求められる仕様が、2001 年時点の技術では実現できないものであれば、そのプログラムは積極的に RPG Ⅳ で書き換えるべき」と書きました。この書き換えとは、具体的に以下の手順を言います。
- CVTRPGSRC コマンドで RPG Ⅲ のソースコードを RPG Ⅳ のソースコードに機械的に変換する
- 組み込み関数等を使用して、RPG Ⅲ で実現できなかった機能をロジックに追加する
RPG Ⅳ が発表になった直後、既存のプログラムを RPG Ⅳ に変換するために CVTRPGSRC を実行されたユーザーの方は多いと思うのですが、その後コンパイルして終わりというケースもかなりあったのではないかと思います。ただ、単純にソースコードを変換するだけではあまり意味がありません。RPG Ⅲ でも実現できるのであれば変換の必要がないのは前回の通りです。
RPG Ⅳ の C 仕様書は、演算項目 2 以降をフリーで記述することも可能です。演算項目２がフリーで書けるというのは、発表当時はとても衝撃的でした。これがサポートされるまでは、計算といえば四則演算の命令コードを駆使して行わなければならず、ソースをみただけではなんの計算を行っているのかを把握するのはとても困難でした。これが拡張演算項目２のサポートで計算を式で記述することが可能になり、＋やーの記号を使用して一つの式で複雑な計算を表現することができるようになったのです。
Result = Value01 * (Value02 + value03) / 100
また組み込み関数等を利用する場合も、この拡張演算項目 2 を使います。具体的には以下にあるように式の中に戻り値をサポートする組み込み関数やユーザー定義関数を記述します。このサポートによりプログラムの可読性が一段と進みました。
IF IsDataExist('ABCDEFG')
サブプロシージャー
それでは、RPG Ⅲ にはない機能の代表格であるサブプロシージャーについて解説しましょう。サブプロシージャーは、RPG Ⅳ で初めて出てきた概念です。処理をまとめて記述する点においては従来のサブルーチンと同じなのですが、それにとどまらない多くの利点を含んでいます。いくつか例を上げてみましょう。
- サブプロシージャー内でのみ参照可能なローカル変数 / ファイルの定義（処理のブラックボックス化）
- 戻り値の定義
- 再帰呼び出し（自分自身の呼び出し）
- 別モジュールからの呼び出し
- 複数プログラム間で呼び出す共通プロシージャーの作成（サービス・プログラム）
従来のサブルーチンは処理のグループ化はできますが、グループの処理が終わった後の戻り点が呼び出し元に特定されるということを除けば、GOTO 命令とさほど違いはありません。サブルーチン内部で使用する変数もファイルも、メインルーチンや他のサブルーチンと同じものを使います。これを密結合と言います。変数の変更はその変数を参照するすべてのルーチンに影響するため、プログラムに問題があった場合、その原因がどこにあるのかを特定するのが非常に困難なのです。
これに対し、処理のブラックボックス化を疎結合と言います。サブプロシージャーの場合、それに渡す引数と戻り値以外の変数をブラックボックス化して外から参照できないようにすることで、戻り値が期待通りの値でない場合は、そのサブプロシージャーの中だけを確認すれば良いようにプログラミングすることができるようになります。
戻り値の定義が可能ということは、そのサブプロシージャーを式の中に記述することができるようになるということです。つまり、コンパイラーが提供する組み込み関数で欲しい機能がなければ、ユーザーがこの関数を作ることができるということです。これをユーザー関数と言います。ユーザー関数は特別なオブジェクト（サービス・プログラム）にまとめることができ、複数のプログラム・オブジェクトから呼び出すことができるように配置することも可能です。真の意味でのモジュール・プログラミングが、このサブプロシージャーにより実現可能になりました。
プロトタイプ呼び出し
プロトタイプとは、外部プログラムおよびプロシージャーへのパラメーターおよび戻り値を定義したものです。モジュール・プログラミングにおけるインターフェイスの定義のことです。プロトタイプを利用することにより、RPG Ⅳ の式の中でプロシージャーや外部プログラムを呼び出すことが可能になります。また、Java のメソッド呼び出しや C 言語で定義されたものもプロトタイプ呼び出しが可能なので、これまで RPG Ⅲ では困難だったことが可能になります。例えば、
- Webサーバーから呼び出されるプログラムを RPG で作成する
- Java で提供される JDBC ドライバーを経由して、DB2 以外のデータベース（Oracle や SQL Server など）の操作を RPG から行う
など、他の言語でしか利用できなかったサービスが使えることで、基幹システムの開発言語だけにとどまらず、SoE の開発にも既存の RPG の知識で参加することも可能なのです。
RPGⅣの果たす役割
最初の段落でも触れましたが、RPG Ⅳ の 22 年の歴史の中では、大きな転換点が 2 つ存在していると思います。ひとつは 2001 年の V5R1 の発表で C 仕様書が完全にフリーで記述できるようになったこと、そしてもうひとつは V7.2（V7.1 は TR）でサポートされた完全フリーフォームのサポート（FFRPG）です。
- すべて定位置記入形式で記述
- 演算仕様書のみフリーフォーム化
- 完全フリーフォーム化
上記の 3 つは RPGⅣ の 3 つのコーディング方法を示していますが、それぞれ以下の橋渡しをしていると考えることができます。
- 「定位置記入形式のみ」は、RPG Ⅲ から RPG Ⅳ へのブリッジ
- 「演算仕様書のみフリーフォーム化」は、RPGプログラマーが最新の機能（特に組み込み関数）を利用可能にすることへのブリッジ
- 「完全フリーフォーム化」は、他のプラットフォーム / 他言語の開発者とのブリッジ
RPG Ⅳ は、S/38 の時代から使われてきた RPG Ⅲ のプログラム資産を最新のバージョンである「FFRPG」にソースレベルで変換するためのブリッジの役割を果たします。また、多言語の開発者が FFRPG をきっかけにして、SoR の設計および作成を行うのにも最適な言語だと言えます。まさにレガシーと最新のテクノロジーの橋渡しをする、そんな役割を RPG Ⅳ は担っているということではないでしょうか。
拡張演算項目 2 および C 仕様書のフリーフォーム化は IBM i 技術者のため、FFRPG のサポートはそれに加えて他の言語やプラットフォームの技術者のためにあると思います。この 2 つの大きな転換点であるブリッジを渡り、IBM i という OS における基幹業務開発に多くの技術者が集まってくることを願ってやみません。
そして、他言語の開発者が IBM i での開発に参加することで、PHP や Java、Python などの技術者がその言語で SoE の設計や作成をおこなうことは想像に難くありません。これらの言語はすでに IBM i でネイティブに実行できるのですから。
おわりに
ニュートンの語ったものとして「人間は壁ばかり建てて橋を作らない」と伝えられている言葉があります。自分のテリトリーを作ったり限界を作ったりということはうまいけれど、異なる考えを受け入れる「橋」は作らないという意味のようです。人間は昔も今も変わりませんが、IBM i は常に変化を遂げています。IBM i は真にオープンな言語であり、RPG という言語は壁を作るのではなくいろいろな所に橋（ブリッジ）を用意しています。実は他にも気づいてないものの、架けられている橋がまだ存在するのかもしれません。私たちが気づいていない IBM i から別の世界に架けられた橋（ブリッジ）をこの連載でもまたご紹介できればと思います。
いかがでしたか。RPG Ⅳ という言語の歴史と機能を通して、その奥深さを理解していただけたのではないでしょうか。今回のキーワードは「ブリッジ」。２つのものを結びつける橋渡しという意味でした。RPG Ⅳ は古いものと新しいものの橋渡しだけでなく、IBM i の世界をいわゆるオープン環境へと導く橋渡しの役割も期待されています。つまり、最新の RPG は、SoR と SoE のブリッジであるということなのです。IBM i はこの現代においてもなお、最新のコンピューターであり、古いものではないということをこのような側面からも理解してもらえれば嬉しい限りです。
おまけのコラム
ご存じの方もいらっしゃると思いますが、東京マラソンの抽選結果はメールで送られてくるのですが、メール本文の先頭に当落が書かれているので全文を読まなくても結果はすぐにわかります。「運命」のメールは9月16日（金）の午前中に届きました。
◇◇ 東京マラソン2017抽選結果（落選）のご報告 ◇◇
東京マラソンを走るミッションは、今回も私に課せられることはありませんでした。残すは京都マラソンのみ。こちらはなぜか当選するという根拠のない自信があったのですが・・・。
10月1日の昼に、京都マラソン事務局よりメールが届きました。東京マラソンと違い当落はメールには記載されておらず、申し込みサイトで確認しないといけません。その分東京マラソンの時よりはドキドキ感があります。そしてサイトを確認したところ京都マラソンも落選・・・。今回はこちらのミッションも課せられることはありませんでした。
マラソン・シーズンが始まる前にすでに終わってしまった感があります。メジャー大会はこの 2 つしか申し込みをしていないのです。さてさて、今年はフルマラソンは走らない？いやいや、これからでもまだ間に合うマラソン大会を探したいと思います！
それにしても、私と東京マラソンとの間のブリッジ完成にはあと何年かかるのでしょう。RPG 言語のように着々と、とはいかないものですね 。。
著者プロフィール
