text：高橋 昌宏 ソリューション・ラボ・横浜
スキルに応じた
FF RPG習得ステップ
それではFF RPGの導入を決めた場合、どのような手順で進めていくべきだろうか。FF RPGをいきなり導入するのは難しく、いくつかの段階を経て導入すべきである。
まず、RPG Ⅲ技術者の場合は以下の3段階での学習が必要となる（図表7）。
＜RPG Ⅲ技術者の場合＞
① RDiの基本操作の習得
起動方法からプログラムソースコードの編集、プログラムのコンパイル方法など、RDiを使用した開発の基本を学ぶ。
② ILE RPGの基礎
FF RPGはILE RPGのフリーフォーム版であるため、ILE RPGの基礎の習得は必要不可欠である。とくに「I仕様書」に変わる「D仕様書」については記述方式の変更、機能の拡充があるため、しっかりと学ぶ必要がある。
③ フリーフォームの記述方法
既存の使用中のプログラムをFF RPGへ変換後、RPG Ⅲのプログラムと変換後のプログラムを比較対比し、RPG Ⅲでのコーディング方法はどのように変わるかを学んでいく（図表8）。画面系、帳票系、バッチ系の3パターンを変換し、学習するのがよいだろう。
＜オープン系技術者の場合＞
① ILE RPGの基礎と応用
D仕様書、モジュール・プロシージャーの実装、呼び出し方法、関数をメインに学習していく。SQLの利用を前提にする場合はF仕様書やREAD、CHAINは不要となるだろう。
② DSPF、PRTFについて
画面、帳票周りについては、FF RPGでも変化はないため、しっかりと学ぶ必要がある。とくに画面周りは、サブファイルについてはしっかりと学び、EXFMTによる画面の制御、DDS上での標識の存在、ファンクションについての理解が必要である。
また、DDSの作成は5250を使用せず、LPEXエディタで編集可能であり、スクリーンデザイナーとレポートデザイナーというGUIツールも利用できる（図表9）。
③ IBM iの基本の習得
OBJやJOBの概念を理解する必要がある。コンパイルによって作成される、PGMやDSPF、PRTF、PF、LFといったOBJの種類について理解し、PFとLFの関係とLFの役割・機能はとくに重要となる。
また、WRKACTJOBやWRKSPLFなど基本的なコマンドはシステム開発時に必要で、運用・保守の観点からも欠かせない。
5250画面からのコマンド入力に違和感があれば、「IBM i Access Client Solutions 」（ACS）のIBM Navigator for iを利用すれば、ブラウザから利用可能となる（図表10）。
FF RPGの実装
以上の学習を終えたら、実装段階へと移行していこう。ここでFF RPGを使ってプログラムを作成していくのだが、何もない状態からスクラッチでプログラム作成を行うのは難しい。やはり、既存のプログラムをFF RPGへツールで変換するのがよいだろう。
RPG Ⅲからは、いったんILE RPGへの変換が必要となる。この時点で、関数に置き換え可能な箇所や計算式をまとめられる箇所があれば、書き換えを実施しておきたい。そうすることで、RPG Ⅲの単純変換を回避できる。
変換するプログラムも、エントリー系、照会系（サブファイル系とそれ以外）、マスタメンテ系、帳票系とそれぞれのパターン選択をしていこう。
それらをベースプログラムとし、新規プログラムを作成していく。ある程度の数のプログラムを作成したところで、FF RPGでの基本的なプログラム作成に慣れる。
SQLの実装
さらに次のステップとして、SQLを実装する。RPG Ⅲ技術者であれば、SQLの基本から学習していこう。
SQLについては書籍も多く、ネット上にも豊富な情報があるので、基本の習得にはさほど苦労はしないだろう。
IBM i技術者向けのコラム記事で、SQLを使い慣れたQueryに置き換えた場合の記事を書いているので参考にしてほしい。
注意する点は、データベースによりSQLの文法に違いがあることだ。
IBM iではDb2 for iとなるが、MySQLやOracleに関する書籍やネット記事に記載されている手法が、Db2 for iでは使用できない場合がある。
また同じDBであるように思われるIBM Db2でも、同様の現象があるので注意が必要だ。ただし、基本的な部分では問題は発生しない。
そしてSQLを導入した場合は、忘れずにアクセスパスの管理を実施する。適切なアクセスパスの管理には「索引アドバイザー」を利用しよう。コラム記事に使用方法を載せているので、参考にしてほしい。
SQLに変更することで、F仕様書への記述が不要となる（DSPF、PRTFを除く）。読み込み条件によるLFの指定、KEYLISTの指定からも解放され、ロジックが減ることでバグの発生率も抑えられる。
SQLを利用する場合は、利用されるアクセスパス（LF）を管理し、作成することが重要である。そうすることで、SQL発行時にシステムが適切なアクセスパスを利用して処理する。プログラマーは意識することなく、物理ファイルを指定すればよい。
ここでSQLのよさを説明するために、照会系のプログラムを例にとってみよう。
RPG Ⅲでは抽出条件によって、条件分を作成し、LFの選別を行い、SETLLやREADEのロジックをパターン分、記述する必要がある。
一方SQLであれば、WHERE句を条件に合わせて作成すれば、指定するファイル記述は1カ所で済む。また並び替えも、ORDER BY句で簡単に指定可能である。
もう1つの例として、コントロールブレイクの処理を挙げる。売上ファイルを読み込んで、得意先ごとの売上金額を集計する場合、得意先コード順に読み込み、得意先コードが変わるまで売上金額を加算し、得意先コードが変わった時点の集計値が得意先ごとの売上金額となる。
ここには得意先コードの新旧の比較、売上金額の加算、得意先コードブレイク時の比較コードの変更、集計ワークのクリアなど、多くのロジックが必要となる。SQLではSUMを使用し、GROUP BY句を使用すれば、一発で得意先ごとの金額を集計できる。このようにSQLを使用することでロジック部分が大幅に減り、バグの発生を抑え、保守性を向上できる（RPG ⅢでもSQLの利用は可能である）。
モジュールや
サービスプログラムの実装
最後にモジュールやサービスプログラムを実装しよう。
まず、しっかりと設計を行う必要がある。共通的な処理を洗い出して、モジュールとすべきものを決める。簡単なところでは、外部サブルーチンとなっている個所をモジュールにしていくとよいだろう。
ほかにはマスタの存在チェックをモジュール化することで、プログラム上ではモジュールを呼び出すだけで、マスタの存在チャックが可能となる。プログラマーはマスタチェックの振る舞い（仕様）を気にすることなく、モジュールを利用するだけとなる。
またマスタチェックの仕様が変更になった場合も、モジュールを変更し、利用プログラムは再バインドを行うだけとなり、修正の作業が格段と容易になる。
FF RPGの導入が進むにつれ、問題となるのが既存のRPG Ⅲ資産をFF RPGに変換するかどうかである。
筆者はFF RPGを導入したからといって、すべての資産を変換する必要はないと考える。理由は前述したように、ツールを使用してRPG ⅢをFF RPGにしても機能的なメリットをあまり得られないからだ。
FF RPG導入の初期段階では、RPG ⅢとFF RPGの「資産」と「技術者」は共存状態にあるはずだ。FF RPGでプログラムを作成するのは、新規プログラムが順当な手順になる。新規プログラムはFF RPG技術者が担当し、既存プログラムの保守はRPG Ⅲ技術者が担当する。
その過程でRPG Ⅲ技術者がILE RPGを習得し、FF RPGをマスタした時点で既存プログラムの変換を検討していけばよい。
最後になるが、FF RPGの検討を契機にRPG Ⅲからの脱却をぜひ実施してほしい。そして、Power Systemsという高性能サーバー、その上で稼働するIBM i という素晴らしいOSの恩恵を十分に享受してほしい。
著者｜高橋 昌宏氏
ソリューション・ラボ・横浜株式会社
ソリューション事業統括
西日本支店 支店長
福岡県生まれ 50歳。22年間、福岡のSIerでIBM i関連の仕事に従事。2020年に転職後も同様にIBM i関連の仕事を継続。長年、IBM iのテクノロジーに魅了され、技術者としてさまざまな取り組みを実施。近年はプロジェクトマネジメントに主軸に置きながら、Web対応をはじめとした新しいIBM i活用の取り組みを行っている。
特集 ILE & FF RPGのススメ
❶FF RPG採用のメリット｜IBM i技術者問題を解決し、ソース管理を高度化する「ILE & FF RPGのススメ」 ～RPG Ⅲを脱却し、プログラム資産をより有効に活用
❷FF RPG導入の課題｜FF RPGの技術者が乗り越えるべき課題
❸FF RPGの習得｜ILE RPGの理解がFF RPGをより魅力的にする
❹FF RPGの導入と習得｜RPG Ⅲ技術者とオープン系開発者 スキルに応じた習得ステップ
❺特別座談会｜FF RPGをメインに据えたRPG研修サービスを展開
［i Magazine 2021 Autumn（2021年10月）掲載］
