Bobを利用したRPG開発
Bobとは「Better Object Builder」の略で、IBM iのネイティブアプリケーション（*PGM、*SRVPGM、*FILEオブジェクトなど）の自動コンパイルを実行するビルド・ツールである。
これはIBM iのPASE環境で動作する。Bobはコマンドライン・ツールなので、P2TERMなどのターミナル画面からの実行も可能だが、VSCodeの拡張機能として動作するGUIのフロントエンドも用意されている。それが冒頭に紹介したIBM i Project Explorerである。
これらを使用すると、これまで挙げた問題点を解決できるのだろうか。結論を言うと、ビルドの自動化に特化したツールなので、すべての問題点を解決できるわけではない。しかし、すべてのソースをプロジェクトで一元管理できるようになり、Gitによるバージョン管理の問題は解決できそうである。
IBM i Project ExplorerとBobの概要
IBM i Project ExplorerとBobが実現する機能を簡単に言うと、IBM iネイティブアプリケーション（*PGM、*SRVPGM、*FILEオブジェクトなど）の開発を、PC上に作成したプロジェクトを使用して実行できる、ということになる。
これは、RDiのiプロジェクト機能を発展させたものと言えるが、大きく異なるのは、ソース物理ファイルを全く必要とせず、DDSやRPG IIIを含むすべてのソースをテキスト・ファイルで管理できる点と、コンパイル先ライブラリーを複数指定できる点である。これを実現しているのがBobである（どのように実現しているかは後述する）。
図表16に、IBM i Project ExplorerとBobの機能を簡単に表した。RDiとは異なり、Bobによってソース物理ファイルが不要となっている。
IBM i Project ExplorerとBobが実現する機能は、次のとおりである。
●ほぼすべてのタイプのソース・テキスト・ファイルをコンパイルできる
●iプロジェクト内のサブ・ディレクトリー単位に、コンパイル先ライブラリーを指定できる
●変更または追加されたソースを自動的にコンパイルする（増分ビルド機能）
●あるソース・ファイルが変更されたとき、依存関係にある項目も自動再コンパイルする
●コンパイル・パラメーターをソース単位にオーバーライドできる
●プロジェクトのビルド（コンパイル）は、VSCode上からボタン1つで実行できる
●ソース物理ファイルからiプロジェクトへ移行できる
IBM i Project ExplorerとBobの機能詳細
各機能の詳細を順に説明する。
ほぼすべてのタイプのソース・テキスト・ファイルをコンパイルできる
Bobがコンパイル可能なQSYSライブラリー中のオブジェクト・タイプと、対応するテキスト・ファイルの拡張子を図表17に示す。
図表17の拡張子のソースは、言語のコンパイラーによってIFS上のテキスト・ファイルから直接コンパイルされる。
ILE RPGのソース・ファイルの場合、拡張子が「.RPGLE」であればモジュール・オブジェクトに、「.PGM.RPGLE」であればプログラム・オブジェクトにコンパイルされる。またサービス・プログラムを作成する場合は、バインダー言語のソースが必須となる。
図表18の拡張子のソースは、言語のコンパイラーがテキスト・ファイルの入力をサポートしていないため、Bobに含まれるCRTFRMSTMFコマンドによってIFS上のテキスト・ファイルからコンパイルされる。
ただし注意点がある。CRTFRMSTMFコマンドは、実際にはテキスト・ファイルをQTEMP/QSOURCEにコピーしてからコンパイルを実行する仕組みなので、作成されたプログラムは、ソース・メンバーを使用したデバッグ（STRDBG、STRISDB）を行うことができない。
また、OPM COBOL（.CBL）はサポートされない（さらに筆者が試したところ、「.CLP」もサポートされないようだった。CLプログラムの拡張子は「.PGM.CLLE」に統一する必要がある）。
図表19のオブジェクト・タイプは、ソース・ファイル内に疑似CLコマンドを記述することで、オブジェクトの作成を行える。
図表20のSQLタイプのオブジェクトは、ソース・ファイル内にSQL文を記述することで、オブジェクトの作成を行える。
iプロジェクト内のサブ・ディレクトリー単位に
コンパイル先ライブラリーを指定できる
図表21は、筆者が検証に使用したiプロジェクト内のツリー構造である。コンパイル先ライブラリーなどの情報は、プロジェクト・レベルであればiproj.json内、サブディレクトリー・レベルであればibmi.json内に記述する。
RDiのiプロジェクト機能で問題だった、「1つのプロジェクトに1つのコンパイル先ライブラリーしか紐づけできない」という欠点が解消されている。
変更または追加されたソースを
自動的にコンパイルする（増分ビルド機能）
BobがIFS上のソース・ファイルをコンパイルする際は、変更および追加されたソースだけを自動的に検出してコンパイルする。
なお、この変更されたソース・ファイルの検出は、ソース・ファイルとライブラリー中のオブジェクトのタイムスタンプ比較によって行われている。このため、IBM iでBobを利用する際は、NTPクライアント機能を有効にし、システム時刻をインターネット時刻と同期させて常に正確に保つ必要がある。
あるソース・ファイルが変更されたとき
依存関係にある項目も自動再コンパイルする
プロジェクト内のディレクトリー単位に、Rules.mkファイルにオブジェクトの依存関係を記述しておくことで、たとえば物理ファイルのレイアウトを修正した際に、従属する論理ファイルとそれらを参照するプログラムが自動的にコンパイルされる。図表22はその例である。
コンパイル・パラメーターを
ソース単位にオーバーライドできる
Rules.mkファイルでは、コンパイル時コマンドのパラメーターをオーバーライドすることもできる。図表23のルールでは、モジュールTESTLIST2のデバッグ・ビューをオーバーライドしている。
現時点でBobは、下記のパラメーターのオーバーライドをサポートしている。
ACTGRP、AUT、BNDDIR、COMMIT、CURLIB、DBGVIEW、DETAIL、DFTACTGRP、DLTPCT、HLPID、HLPPNLGRP、OBJTYPE、OPTION、PAGESIZE、PGM、PMTFILE、PRDLIB、REUSEDLT、RPGPPOPT、RSTDSP、SIZE、STGMDL、SYSIFCOPT、TERASPACE、TEXT、TYPE、TGTCCSID、TGTRLS、VLDCKR
プロジェクトのビルド（コンパイル）は
VSCode上からボタン1つで実行できる
ソースをコーディングした後は、次のようにボタン１つでコンパイルできる。追加・変更されたソースは自動的に検出され、依存関係にあるソースはRules.mkに定義されているので、開発者がコンパイル対象を指定する必要はない（図表24、図表25）。
ソース物理ファイルからiプロジェクトへ移行できる
ソース物理ファイルからiプロジェクトへの移行も、非常に簡単である。
Code for IBM iのObject Browserビューには、ライブラリー中のソース物理ファイルをiプロジェクトに移行する機能が用意されている。PCのローカル・ドライブ上にプロジェクトのルートとなるフォルダを作成してiproj.jsonを配置した後、移行機能を実行するだけである（図表26）。
（PART3へつづく）
著者
佐藤 尚氏
ソリューション・ラボ・ジャパン株式会社
第１サービス事業部 第3サービス部 第１グループ
AS/400ユーザーの情報システム部門を経て、2006年にソリューション・ラボ・横浜（現ソリューション・ラボ・ジャパン）に入社。主にIBM iを中心に他のプラットフォームとの連携を行うシステムの設計・開発を行う。近年はシステム開発の傍ら、IBM i技術者向け研修サービスの講師を担当している。
