IBM i は昨年25周年を迎えたが、その年の最後を飾るようにRPG言語に新たな機能が追加された。H、F、DおよびP仕様書のフリーフォーマット化である。今回はこのフリーフォーマット化について、開発者の立場から見た意義や我々に与える影響について考えてみたい。
RPG言語の歴史
IBMがRPGを開発したのは1960年代にまで遡る（図表1）。その後RPG Ⅱが導入され、1979年のSystem/38で改良版のRPG Ⅲが開発された。そして現在、現役で使用されているのはこのRPG Ⅲと、1994年に発表されたRPG Ⅳである。
ご存じのとおり、RPG Ⅲは仕様書ごとに桁位置が決まっており、どの桁に何を記述するかでコンパイラーに指示を出すようになっている。すべての桁位置の意味を覚えるのは大変なので、通常はエディタであるSEUが提供するプロンプト機能を利用してコーディングする。
フリーフォーマットでの記述が可能になったのは、1994年のRPG Ⅳの発表からだ。従来の定位置記入のレイアウトが変更になり、演算仕様書の拡張演算項目２で式を自由に記述できるようになった。つまり、フリーフォーマットの歴史は20年が経過していることになる。
そして、演算仕様書が完全にフリーフォーマットをサポートしたのは、2001年のV5R1の発表からである。それからすでに13年が経過した。しかし自由形式で記入できるのはあくまで演算仕様書のみであり、他の仕様書は依然として定位置記入形式で記述しなければならなかった。
しかしついに昨年のTR7リリースに伴う機能拡張で、H、F、DおよびP仕様書もフリー形式で記述が可能になり、I仕様書およびO仕様書を使わなければ、すべてをフリー形式で記述できるようになった。文法的な変更点や新たな機能拡張についてはPart1に詳しいので、本稿では視点を変えて、このフリーフォーマットが与えるさまざまな影響について考えてみたい。
RPG開発者から見たRPG Ⅳのフリーフォーマット
今でも、IBM i で実行されているプログラムはRPG Ⅲで記述されているものが多い。1979年に発表されたSystem/38で開発されたプログラムが現在でもサポートされているのは、AS/400からIBM i まで綿々と受け継がれた資産の継承というコンセプトがうまく機能していることの表れだ。
そして、RPGの機能が拡張されていっても、過去のプログラムが動かなくなることは一切ないので、新機能に移行せねばならないという半ば強制的な理由がなく、現在でもRPG Ⅲで書かれたプログラムの保守や作成は続いている。今後も過去の資産を継承することは重要なので、RPG Ⅲを捨て去る理由などまったくない。
一時期、RPG Ⅳへの移行がなかなか進まないと筆者も危惧したことがあったが、現在動いているRPG Ⅲのプログラムは、メンテナンスもRPG Ⅲ言語のままで行うのが最も効率的である。ただ、新規開発が発生した場合は最新の機能を使用するためにも、RPG Ⅳで記述するのがベストだ。つまり今後もRPG ⅢとⅣは共存していくであろう。
ここで注意しておきたいことが２つある。1つはSEUについてである。すでにご存じの方も多いと思うが、SEUの構文検査はV6.1レベルで凍結されている。つまりそれ以降の言語構文の変更には対応しない。
今回の複数仕様書でのフリーフォーマット化はV7.1以降の機能なので、SEUでは構文エラーとなってしまうことに注意が必要である。もちろんエディターレベルでのエラーチェックの話なので、エラーを無視して強制的にソースを保存すればプログラムを作成することはできる。
もう1つはRPGサイクルについてである。まだ初期の頃のRPGプログラムは、RPGコンパイラーが生成する内部論理を利用したプログラムが多かった。すなわち、自動読み取り・自動書き出しの機能である。
過去の資産の継承は最も重要なことなので、今回の機能拡張でRPGサイクルがなくなることはもちろんないが、DCL-Fを使用したファイル定義では、プライマリーおよびセカンダリー・ファイルの定義ができないこと、レコードのレベルを定義するI仕様書、および自動書き出しに使われるO仕様書はフリーフォーマット対応ではないことから、すべてをフリーフォーマットで書くと、この内部論理の多くの部分を利用できないことに注意したい。
もちろん、ファイルの自動オープンや、*INZSRサブルーチンの実行などの初期処理、LR標識がオンの場合のファイルのクローズなどはフリーフォーマット化でも有効である。
オープン系言語の開発者から見たRPG Ⅳの存在
では他言語を使用する開発者から見て、今回のRPG Ⅳのフリーフォーマット化はどのように受け取られるだろうか。確かに定位置記入形式の仕様書を使わずに、すべて自由形式で記述できるという点において違和感はないかもしれない。
しかし、それはあくまで記述方法（文法）の観点からそうであるというに過ぎない。たとえば、Java言語の場合はプログラミングの根底にオブジェクト指向という概念が存在する。PHPも同様に、オブジェクト指向での記述が可能な言語だ。
仮に他言語をJavaおよびPHPと仮定した場合、記述方法において自由形式なのは共通ではあるが、設計という観点でいえば根本部分の考え方がやはりRPGとは異なる。また、JavaやPHPは、プログラム作成時のフレームワーク利用が一般的だが、RPGにはそれがない（あるいは一般的でない）。以上のことから考えて、RPGがフリーフォーマット化されたからといって、単純に他言語からの移行や利用が促進されるとは考えづらい。
一方、データベースへのアクセス方法としては、RPGは歴史的にレコード・レベル・アクセスが主流だが、他言語の場合はSQLアクセスが一般的である。RPG Ⅳでは引き続き、DCL-Fでファイルを定義することによりレコード・レベル・アクセスが可能だが、V5R3の時点でフリー形式によるSQLの記述も可能になっており、この点は他言語の開発者がRPGを学ぶ際にも違和感のないところだと思う。
少し視点を変えると、RPG開発者がフリーフォーマット化に慣れることで、それぞれの言語の開発者がIBM i という同じプラットフォーム上で開発を進める際のコミュニケーションが円滑になるという利点はあると思う。開発環境は同じものを使うことになっていくので、この環境を触媒として、それぞれの技術者の他言語への理解が深まっていくことは十分あり得るだろう。
最新のRPG ⅣがIBM i開発者にもたらすもの
RPGはReport Program Generatorという名前が意味するとおり、もともとはデータベースの内容を見やすい形に印刷するプログラムを簡単に作れるように設計された言語である。このロジックが、コンパイラーが自動生成するRPGサイクルであり、このロジックを各仕様書の桁位置に決められた値を記述することで簡単に利用できた。
しかし現在は、5250対話型プログラムやバッチプログラムはもとより、データベースのトリガー・プログラム、フリーフォーマットの式の中に記述できる関数、WebプログラムにおけるCGI、あるいはRESTで呼び出されるプログラムなど、IBM i で必要とされるプログラムのほとんどをRPGで記述できる。
しかもRPGサイクルを利用しないプログラムが大半を占める。そこで、現在ではコンパイラーがサイクル・ロジックを生成しないよう指定するための MAIN および NOMAIN キーワードが存在する。
一方で、IBM i のすべての処理をRPGだけで記述するのではなく、適材適所に言語を使い分けるという考え方はこれからの主流になっていくだろう。
ユーザーとのインターフェースがPCやスマートフォン、タブレットになっていく中で、そのインターフェース部分の開発はPHPなどの言語に任せ、RPGはデータベースに近い部分でビジネスロジックの実装やデータベース処理に特化する。例えて言うなら、MVC（Model View Controller）でいうモデルの実装を、RPGが受け持つという感じだろうか。
前述したように、SEUの構文検査は6.1レベルで凍結されており、フリーフォーマットでの開発用エディタとしての利用ははっきり言って難しい。現在はRational Developer for i （以下、RDi） などの開発ツールに移行しており、今後はこちらが主流になっていくだろう。
RDiではSEUに代わるLPEXエディタが利用できるのだが、今回のフリーフォーマット対応以前は、演算仕様書以外はまだ定位置記入形式だったので、このエディタもプロンプト機能を使わないとコーディングが難しく、これもまた同ツールへの移行を躊躇させる要因でもあった。
今回のフリーフォーマット化により、LPEXエディタでプロンプト機能を使わなくてもプログラムを記述できるようになった点は、今後このツールへの移行を加速していくことになると思う。
RDi への移行が進めば、ソースのバージョン管理ツールとの連携や、他の言語開発では当たり前に使われているプロジェクト管理ツールやBTS（Bug Tracking System）などを、IBM iやRPG での開発で利用することも当然増えてくると思う。フリーフォーマット化によりRDiの統合開発環境への移行が促進され、このことが他言語経験者のIBM i での開発のハードルを下げてくれることになるだろう（図表2）。
フリーフォーマット化とGUIによる開発環境、および同じ環境での複数言語の開発は、他言語の開発者のみならず、RPGの若い技術者にとっても非常に魅力があるだろう。実際、彼らは学生時代に他言語でのプログラム開発とGUI環境を経験していることが多く、社会人となってIBM i のシステムを開発する時に初めてSEUに触れ、GUI開発環境との落差に愕然する。彼らは明らかに、今風の開発環境を IBM i に求めている。
RPG Ⅲをずっと使ってきたベテランの開発者にとっては、フリーフォーマットへの移行は抵抗があるかもしれない。しかしSEUの構文検査レベルが凍結している以上、新しい方式を違和感なく使うためには、否応なしにGUI環境への移行が必要となる。
そして、その環境に一歩足を踏み出せば、同じ環境で作成できるPHPなどの他の言語習得へのハードルがぐっと低くなると思う。また、バックエンドのプログラムをRPGで作成する際にも、GUI環境における便利な機能（広い画面、検索の容易さ、アウトライン機能、バージョン管理ツールとの連携など）に慣れてそのよさがわかれば、開発効率も大幅に向上するはずだ。
IBM i の若い技術者とベテランの技術者、PHPやJavaなどの他言語開発者に対する共通の開発環境は、相互のコミュニケーションと他言語理解の一助になるし、お互いの文化から刺激を受ける触媒となっていく。RPGのフリーフォーマット化がこの環境を実現するきっかけになってほしいと思う。
今回の完全フリーフォーマット化は、RPGの開発者にとって開発環境を一変させるほど重要なものになった。まだRPG Ⅳに移行していないRPG Ⅲの技術者も、また演算仕様書を定位置記入形式で記述しているRPG Ⅳの技術者も、これを機会にいち早くこのフリーフォーマット化およびGUI開発環境に移行して、効率のよいシステム開発を実践してほしい。
IBM i のユーザーにとっては、業務で利用するプログラムがフリーフォーマット形式で書かれているかどうかは、はっきり言って問題ではない。大事なことは、IBM i に保存されているデータをどのように効率よく処理してそれを参照できるか、にある。
すでに述べたように、適材適所の言語選択を行えば、データベースを処理するプログラムは、レコード・レベル・アクセスとSQLアクセス両方が可能なRPGで開発し、インターフェースは実績のあるPHPなどで実装できる。これが、IBM i ユーザーにとっての最大のメリットだろう。このメリットを提案していくことが、開発サイドの使命であると考えている。
筆者｜小川 誠 氏
ティアンドトラスト株式会社
［i Magazine 2014年2月号掲載］
