バインディング ディレクトリーは近道か、混乱の源か？
IBM i 開発者にバインディング ディレクトリーについて尋ねると、普通、返ってくる反応は、2つのうちのどちらかです。すなわち、感謝の頷きか、あざけりの眼差しです。一部の人にとっては、バインディング ディレクトリーは救いの手だということです。コンパイル コマンドをよりクリーンにし、プロジェクトを管理しやすくしてくれるからです。一方、それらは時限爆弾のようなものだと言う人もいます。隠れた依存関係を取り込んで、何か月か後によみがえって来て悩ませられるのです。
私は、その両方の面を目にしたことがあります。実際、私が目撃した最悪のコンパイルの日の大惨事の1つは、とある悪意のない開発者が、1つのサービス プログラムをグローバルなバインディング ディレクトリーに追加したことが始まりでした。突然、そのショップのプログラムの半分が、プロシージャーの間違ったバージョンにリンクするようになりました。時間を節約するはずだったものが、大混乱へと変わります。そして、結局のところ、ツール自体が「悪い」のではなく、単に管理が不十分だったことが問題なのです。
プログラムまたはサービス プログラムをビルドする際、コンパイラーは、どのモジュールおよびサービス プログラムにバインドするべきか知っている必要があります。CRTPGMまたはCRTSRVPGMコマンドで1つ1つ明示的に指定することもできますが、そうした作業は面倒であり、間違いの元になりがちです。バインディング ディレクトリーは、こうした問題を解決するために作成されました。バインディング ディレクトリーは、サービス プログラムおよびモジュールの買い物リストのようなものだと考えるとよいでしょう。コンパイルするたびに同じリストを書き直す代わりに、それらすべてをバインディング ディレクトリーに入れ、そのディレクトリーを一度参照して、残りはシステムに把握させます。
以下に、シンプルな例を示します。
CRTBNDDIR BNDDIR(MYLIB/MSHRMBDIR)
ADDBNDDIRE BNDDIR(MYLIB/MSHRMBDIR) OBJ((MYLIB/MSHRMUTILS *SRVPGM))
CRTPGM PGM(MYLIB/MYPGM) MODULE(MYLIB/MYPGM) BNDDIR(MYLIB/MSHRMBDIR) この例では、MSHRMBDIRが中心的なリストになります。それによって構築されたプログラムは、どれも自動的にMSHRMUTILSにバインドするため、すべてのコンパイル コマンドでサービス プログラム名を入力し直し続ける必要はありません。
バインディング ディレクトリーは、大規模なプロジェクトまたはチームで本領を発揮します。開発者は、何十もの依存関係を記憶しておくのではなく、単一のディレクトリーを指定するだけです。これにより、新しいチーム メンバーをオンボーディングしやすくなり（「MSHRMBDIRを使用するだけ」）、誤入力や、モジュールを思い出せなくなることも少なくなります。また、慎重に使用すれば、メンテナンスも簡素化されます。新たなユーティリティ サービス プログラムを追加する場合に、すべてのコンパイル スクリプトを修正する必要はありません。バインディング ディレクトリーを更新するだけです。そうすれば、それ以降のすべてのコンパイルで処理されます。統制が取れていて、変更についての情報のやり取りがなされているチームにとっては、バインディング ディレクトリーは生産性を向上させる超能力のように思えるかもしれません。
しかし、隠れた負の側面もあります。すなわち、バインディング ディレクトリーは、実際に何がバインドされているのかを見失いやすくさせます。バインディング ディレクトリーを使用するときは、システムレベルのリストに制御を委譲することになります。全員の認識が一致していれば申し分ないのですが、多くのショップでは、これらのディレクトリーは有機的に成長します。誰かが新たなサービス プログラムをこちらに追加し、別の開発者があちらで何かに少し変更を加えます。そうこうしていると、やがてはそのディレクトリーの中にどのようなものがあるのか誰もはっきり分からなくなってしまいます。
さらに悪いことに、2つのサービス プログラムが、同じ名前を持つプロシージャーをエクスポートする場合、システムは、そのディレクトリーで最初に見つかったものをそのままバインドします。プログラムが実行時に間違ったバージョンを呼び出すまでは、何かがおかしいことに気付きません。私は、これを直に目にしたことがあります。すなわち、グローバルなバインディング ディレクトリーへ1つ追加したことにより、何十ものプログラムが間違ったプロシージャーに対してコンパイルされることになりました。その結果どうなったか。何時間もの死に物狂いのデバッグと責任追及です。変更を行った開発者は不注意でありませんでした。彼らは良かれと思ってのことでした。問題は、境界がなかったことでした。
では、バインディング ディレクトリーは完全に使用を避けるべきなのでしょうか。そんなことはありません。ほとんどのツールと同様に、重要なのは、意図を持って使用することです。効果的に機能する戦略を紹介します。まず、ディレクトリーをアプリケーション固有にします。1つの巨大なシステム全体に及ぶディレクトリーではなく、アプリケーションまたはサブシステムごとに個別のディレクトリーを作成します。これにより、変更が封じ込められます。分かりやすい名前を付けるようにします。MSHRMBDIRというような名前であれば、その中にどのようなものがあるか想像しやすいでしょう。すべてを文書化します。バインディング ディレクトリーは、開けてみるまで中身が分からないミステリー ボックスのようであってはなりません。中に何があるか開発者が正確に分かるように、プロジェクト文書に簡単なリストを記録しておくようにします。そして、共有ライブラリーは慎重に扱うようにします。日付ユーティリティ ライブラリーのように、サービス プログラムが本当に普遍的であるのなら、申し分ありません。しかし、複数のバインディング ディレクトリーに追加する場合は、事前に安定的であることを確認するようにします。
知り合いの何人かの開発者は、バインディング ディレクトリーを一切使用しないようにしています。彼らは、CRTPGMおよびCRTSRVPGMコマンドですべてのモジュールおよびサービス プログラムを明示的に指定しています。それでまったく問題はありません。最も安全なアプローチです。何がバインドされているか常に正確に分かっているからです。しかし、代償はあります。すなわち、手作業が多くなることです。明示的なバインディングは、完全な制御が必要とされるクリティカルなコードまたはプロジェクトの場合に合理的です。一方、バインディング ディレクトリーは、適切なプロセスが備えられている場合には、日々の開発作業を迅速化するのに効果的です。統制の取れたチームである場合には、2つのアプロ―チが混在できない理由はありません。クリティカルでないプロジェクト向けにはディレクトリーを使用し、制御が必要なところでは明示的なアプローチを採用します。
バインディング ディレクトリーは、有害なものではありません。それらは、使い方次第で、作業を楽にすることもあれば、隠れた依存関係のもつれを生み出すこともあるツールです。重要なのは、意図を持って使用することです。すなわち、それらを整理し、文書化し、特定のアプリケーションに限定されるようにします。ご自分のショップで、誰も完全に理解していない単一の巨大なバインディング ディレクトリーを使用している場合は、整理するべき良い時です。まずは小さく始めて、アプリケーションごとにディレクトリーを作成し、一番重要なところでは明示的にします。バインディング ディレクトリーが、混乱を引き起こすことなく、真に生産性を向上させる機能になることがお分かりいただけるでしょう。
次回の記事では、全体的な視点から、サービス プログラムのライフサイクル管理について取り上げます。すなわち、サービス プログラムを進化させる際に、安全に変更を行い、環境全体に展開し、本番の中断を回避するには、どのようにすればよいかということについて見て行きます。
