前回の復習
「第十一回 サービス・プログラムの作成（３）」では引数の様々な指定方法を解説しました。サービス・プログラム内のサブ・プロシージャーが受け取る引数の指定方法が3 通りあるということと、その使い方をサンプル・プログラムを通して理解していただけたと思います。
今後のシステム開発では、他システムとの連携や他言語で作成された API などを利用するケースが増えてきます。その際のプログラム開発では、この引数の指定方法の理解が必要になってきます。サンプル・プログラムをまだ作成していない方は、実際に作成することで理解が深まるはずです。ぜひ挑戦してください。
今回の連載の最後となるこの記事のタイトルは、「IBM i でプログラムを作るということ」にしました。これまでの内容を振り返りながら、文字通り「IBM i で RPG 言語を使ってプログラムを作ること」についてその意義を考えながら、これからの可能性について皆さんとともに考えるきっかけにしたいと思います。
連載を振り返って
それでは、今回の連載の主なポイントを簡単に振り返ってみましょう。
「IBM i の “新” 必須言語〜FFRPG入門〜」では、タイトル通りフリーフォームで記述する RPG（FFRPG）のみに焦点をあてて解説してきました。RPG には RPGⅢとフリーフォームではない RPGIV があり、現在もこの２つが IBM i のシステム開発では主流です。ですから、従来の RPG の技術者の方には、今回の連載記事は初回からかなり違和感のある内容だったと思います。第一回で解説した「Hello Free Form RPG world!」と表示する icafe001.rpgle の「main」プロシージャーというのは、同じ RPG 言語とは思えないという感想を抱いた方も多かったのではないでしょうか。
この「main」プロシージャーは RPGIV から利用可能ですが、今回初めて聞いたという方も多かったと思います。プロシージャーには以下の３種類がありましたね（第三回）。
- サイクル・メイン・プロシージャー
- リニア・メイン・プロシージャー
- サブ・プロシージャー
今回の連載内の多くのサンプル・プログラムで使用しているこの「main」プロシージャーは、「リニア・メイン・プロシージャー」です。
従来の RPGⅢ や RPGIV でもっとも多いのは、サイクル・メイン・プロシージャーのみ（RPGⅢ ではプロシージャーとは言いません）を含んだプログラムです。もちろん FFRPG でもサイクル・メイン・プロシージャーのみを含んだプログラムを作成することはできますが、完全なフリーフォームの記述だと RPG のサイクル論理を利用できない（サイクル対象のファイルとして定義できない）ため、今回の連載では、メイン・プロシージャーはリニアの解説のみにとどめました。リニア・メイン・プロシージャーを使っていても、その記述の前にファイル定義や変数定義を行なうことが可能です。この場合は、ファイルに含まれるフィールドおよび定義した変数はすべてグローバル変数です。
サイクル・メイン・プロシージャーは、RPGⅢ のコードではサブルーチンを除くすべてがサイクル・メイン・プロシージャーに相当すると考えていただいて問題ありません。
リニアおよびサブ・プロシージャーを使用する利点としては、ローカル変数が使用可能であること、サブ・プロシージャーだけの利点としては引数と戻り値の定義が可能であるという点が挙げられます。これにより、サブ・プロシージャーを式の中で記述したり、サービス・プログラム化して部品化することが可能です。RPGⅢ にはないこの機能は、今後のプログラミングを行なう上で、記述を簡単にしたり保守性を高めるなどの利点になることは理解いただけたと思います。
データベース処理としては、SQL インターフェースを使用した解説を先に行いました（第四回および第五回）。IBM i 以外のプラットフォームにおける RDBMS アクセスは SQL が主流なので、それを意識してのことです。もちろん、従来通りのレコード・レベル・アクセス（物理ファイルと論理ファイルの使用）も FFRPG で可能なので、それについても２回にわけて解説をしました（第六回および第七回）。どちらのインターフェースも RPG で利用可能であるという点はとても重要です。また、従来の物理ファイルは SQL からテーブルとしてアクセス可能であることも留意しておいてください。AS/400 の時代に作成された物理ファイルは、そのまま SQL で処理可能なのです。
IBM i は時代に応じて、そのときに利用可能な様々なインターフェースを実装してきていますが、過去のものを捨て去るという選択は一切行っていません。ですから、GUI や Web に代表されるインターフェースが使われるようになる前から存在しているキャラクター・ベースのインターフェース（5250画面）は現在も利用可能です。もちろんこのインターフェスは FFRPG でも利用可能なので、第八回でその方法を解説しました。RPG 言語の技術者の方には馴染みのある内容だったと思いますが、他言語の技術者の方には逆に新鮮な内容だったのではないでしょうか。
5250 インタフェースを使用したプログラムを FFRPG で作成するのか、あるいは今まで通り RPGⅢ を使用するのかは意見が分かれるところだと思います。ここではどちらが良いのかという点については言及しませんが、どちらの選択も可能です。実際に稼働している RPGⅢ プログラムがどれだけあるのか、5250 インタフェースを使用するプログラムの新規開発があるのか、今後の保守を行なう方は誰なのかなど、いろんな要因がこの決定には絡んでくるものと思います。
第九回から前回までの三回は、サービス・プログラムについて解説しました。サービス・プログラムの利点はすでに言及した通り、なんといっても業務ロジックの部品化が可能な点が大きいと思います。部品化するとは、複数のプログラムに分散して記述している共通のロジックを一箇所にまとめるということです。まとめるという意味では、そのロジックをひとつのプログラム（*PGM）として作成すればその目的は達成します。必要に応じて CALL コマンドで呼び出すことも可能ですし、なにか変更があればそのプログラムのロジックを修正するだけで対応できるからです。従来ではこれを外部サブルーチンと呼んでいました。この方法はロジックの共通化という点では十分ですが、そのロジックをプロシージャーにまとめてサービス・プログラム化することにより、そのロジックに引数を渡して結果を戻り値として受け取ることができるようになります。CALL コマンドで動的に呼び出すのではなく、式の中に組み込んで呼び出す（静的呼び出し）ことができるのです。この記述の便利さは、FFRPG で使っていただくとその良さを一層実感していただけるはずです。RPGⅢ では作成も使用もできないこのサービス・プログラムを、利点を十分理解した上で設計し活用してみてはいかがでしょうか。
FFRPG での記述を中心とした RPGIV でのプログラミングで必要な基本的な機能については今回の連載である程度網羅できたと思っています。後から参考にするための簡単な索引をまとめましたので、必要に応じて参考にしてください。
- プログラムの作成手順（第一回）
- プログラムの基本構造（第三回）
- ソースとモジュールとプログラムの関係（第三回）
- CRTBNDRPG コマンド（第三回）
- CRTRPGMOD コマンド（第三回）
- CRTPGM コマンド（第三回）
- CRTSRVPGM コマンド（第九回）
- プロシージャーの種類について（第三回）
- ローカル変数とグローバル変数（第三回）
- 自動記記憶域と静的記憶域（第三回）
- 組込SQLプログラムのコンパイル時の注意点（第四回）
- SQL のホスト変数について（第四回）
- SQL のホスト構造について（第四回）
- 同一プログラム内でのサブ・プロシージャーの利用（第五回）
- SQL での複数レコードの処理（第五回）
- 従来のレコード・レベル・アクセスについて（第六回）
- グローバル・ファイルとローカル・ファイルについて（第六回）
- 複合キーについて（第七回）
- 表示装置ファイルと印刷装置ファイル（第八回）
- 引数と戻り値（第九回）
- サービス・プログラムの作成方法（第九回）
- プロトタイプ定義を使用する意義について（第十回）
- バインディング・ディレクトリ（第十回）
- 参照渡し、値渡し、読み取り専用参照渡し（第十一回）
開発環境について
第二回でも解説した通り、IBM i での RPG プログラム開発環境は長らく SEU（エディタ）＋ PDM（統合開発環境）が利用されてきました。もちろん現在もこの環境をメインで利用されている技術者の方は多いと思います。一方で、他言語の開発は様々なツールを組み合わせて環境を構築していくのが一般的です。それぞれのツールの利点を生かしてより効率のよい開発を実践することができるのです。
様々なツールの組み合わせで実現可能な、SEU + PDM にはない利点の主な点は以下の通りです。
- 色やテーマの選択などで視認性を高めることが可能
- コード入力時の補完機能を利用可能
- 様々なプラグインにより機能拡張や他のツールとの連携が可能
もちろん IBM i でも SEU + PDM 以外の開発ツールやエディタを利用することができます。現在の選択肢は以下の通りです。
- RDi（Rational Developer for i）
- Orion
- Visual Studio Code
RDi は統合開発環境であり、RPGⅢ から FFRPG までの開発をカバーします。プロンプト機能を使用した開発環境は RDi のみなので、既存のプログラムの保守も FFRPG の開発も行なうのであれば、開発ツールは RDi 一択でしょう。
RPGⅢ の保守は従来どおり SEU + PDM で行なうということであれば、FFRPG の開発環境としては Orion か Visual Studio Code も選択可能です。この 2 つは RDi と異なりエディタ機能がメインになります。両方ともフリーで利用可能ですが、Orion は IBM i 側に導入するオープン・ソースなので誰でも気軽に試すことができないのが難点です。自社で利用できない方はぜひ今回の実習環境を使って Orion を評価してください。
Visual Studio Code は PC にインストールするソフトウェアなので、Orion よりは手軽に始めることが可能です。導入方法や使い方、便利なプラグインの解説などインターネットから多くの情報を入手することができるので、比較的利用もしやすいのではないでしょうか。
RDi、Orion、VSCode どれを使っても実現可能でかつ最も重要なことは、git に代表されるバージョン管理システム（VCS）との連携が可能になるということだと思います。RDi を使えば、RPGⅢ のソース・コードでさえもバージョン管理が可能になるのです。RPG 言語の歴史はとても古く、ソースのバージョン管理を行なうという習慣は今まであまりありませんでした。その「伝統」は今も受け継がれており、数多くのソース・コードはバージョン管理されていないのではないかと思います。しかし、基幹システムのプログラムは今後も保守されながら使われていきます。ソースが変更されるたびに VCS で管理しておけば、誰がいつどこをどのように修正したのかをいつでも参照することが可能になるのです。
バージョン管理されていないソースコードには、いつどこを変更したのかという情報はコメントとして記述されていることが多いと思います。長期間使用されているプログラムは修正の数も多く、それだけコメント行も多くなってきます。そうすると、特に表示行の制約のある SEU だとコメント行が邪魔をしてソースコードが読みにくくなってしまい、保守の難易度が上がってしまうことにもつながりかねません。
ソース・コードをバージョン管理するようになると、ソース・コードに書かれるコメントは圧倒的に少なくなります。どこを変更したか、どの行を削除したかは VCS の履歴を見ればわかるからです。RPGⅢ のように長く使われており、今後も保守されるプログラムのソース・コードは、一日もはやくバージョン管理すべきです。
git によるバージョン管理により、以下クラウドのリポジトリ・サービスとの連携も可能になります。
- GitHub
- BitBucket
- GitLab（オンプレも可能）
これらのリポジトリ・サービス内のプライベート・リポジトリを利用すれば、ある程度のセキュリティを確保した上で、IBM i の基幹システムを他言語同様にオフショア開発することも可能ですね。
RDi と VSCode では、git のリポジトリは PC に保存されますが、Orion の場合は IBM i 上にオープン・ソースとして導入する git を利用します。つまり、開発者それぞれのリポジトリは IBM i 上で管理されるということです。また、直接クラウド上のリポジトリ・サービスとは PC を介さずに直接連携します。
Visual Studio Code を使った FFRPG プログラム開発の実際は、機会があれば記事にまとめたいと思います。
連載の最後に
「IBM i の “新” 必須言語〜FFRPG入門〜」の連載はこれで終了です。フリーフォームで記述できることの利点は、「リーダブル」なコードを書けるということに尽きると思います。基幹システムで使用されるプログラムは長期に渡って使用される宿命を背負っています。IBM i は昨年 30 周年を迎え、これからも長期に渡り使われていくシステムですから、なおさら次の世代が保守しやすいコードでプログラムを書くのは現役世代の責任です。
これから IBM i の開発に携わる技術者の方は、RPG という言語は古い言語でもないし、開発ツールも新しいものが利用できるんだということをぜひ理解していただきたいと思います。長きにわたって使われてきた RPG は今後も機能拡張されていく素晴らしい言語です。今まで必要に応じて様々な言語を学習されてきたと思いますが、FFRPG も同じように取り組んでいきましょう。
一つの言語でシステム開発を行なう時代はとっくに終わっています。これからはますます多くの言語を適材適所で使ったシステム開発が必要になってくるでしょう。Java、PHP、Python など多くの言語は IBM i で利用可能であり、安定した RDBMS である DB2 for i は今後も基幹システムの中核であり続けます。そのデータベースを基本機能として持つ IBM i という OS は、今後も使われ続けるわけで、だからこそ RPG 言語も DB2 for i 同様、基幹システム開発の中核をこれからも担っていくのです。既存の仕組みを大事にしながら、積極的に新しいものを取り込んで進化し続ける IBM i から今後も目が話せません。今回の連載が、皆さんが FFRPG を使うきっかけになってくれることを願ってやみませんし、そうなれば望外の喜びです。
内容についてはくどい文章で読みにくい部分が多々ありましたことをお詫びいたします。最後までお付き合いいただきありがとうございました。
