CRTSRVPGMコマンドを使いこなす － 平穏を保つためのオプション
CRTSRVPGMを実行する際に、パラメーターにあまり注意を払ったことはないという人は、少なくないかもしれません。デフォルト設定を受け入れて先へ進んだ結果、容易には気付かないバグや不必要な頭痛の種が、それらのデフォルト設定によってもたらされることがあるのだと後になって気付く開発者も多いようです。単純なコマンドのように見えますが、このコマンドには、作業を容易に行えるようにすることもあれば、システム内に時間爆弾を作り出してしまうこともあるオプションがたくさんあります。まずは、最も重要な2つのオプションについて見てみましょう。
特に注意を払う必要があるパラメーターの1つは、OPTIONです。デフォルトでは、このパラメーターはブランクであり、害はなさそうに思えますが、そのブランクという値は、サービス プログラムで重複プロシージャーおよび変数を許可することを意味します。つまり、実質的にはOPTION(*DUPPROC *DUPVAR)ということです。見た目には、柔軟性があるように思えるかもしれませんが、実際は、混乱を招き入れているようなものです。異なるモジュールに同じ名前を持つ2つのプロシージャーが存在すれば、デバッグは悪夢になります。明示的にOPTION(*NODUPPROC *NODUPVAR)を設定することによって、コンパイル時に重複を防ぐことができます。重複があるとビルドはすぐに失敗するでしょうが、本当の話、後でランタイム エラーを追いかけるのに比べたら、その方がはるかに対処しやすい問題です。
バインディング ディレクトリーも、論争を引き起こすことの多いパラメーターです。プログラム作成を単純化してくれるので、バインディング ディレクトリーに惚れ込んでいる開発者もいます。ディレクトリーを指定して、コンパイルすれば、すべてうまく行くということです。その一方で、バインディング ディレクトリーは、あまりに多くのものを開発者に見えなくさせてしまうという見方もあります。私の見方はこうです。バインディング ディレクトリーは、計画的に、一貫したルールに則って使用されている場合は素晴らしいものです。サービス プログラムの参照を一元化するため、中に入るものについてきちんと制御がなされている場合は、保守が容易になります。単一の「何でも入れられる」ディレクトリーに何でもかんでも放り込むのだとしたら、メリットは失われ、結局、後からでは解決するのが難しい混乱に陥るはめになるでしょう。
私のショップでは、さらに一歩進んで、どのプロシージャーがどのサービス プログラムに属しているか混同しようがなくなるような命名規則を使用するようにしています。プロシージャー名は、すべてサービス プログラムの名前から始まるようにします。たとえば、MSHRMUTILSというサービス プログラムでは、MSHRMUTILS_SAVE_NEW_SPECIESやMSHRMUTILS_IS_EDIBLEというようなプロシージャーが見られるかもしれません。これには、大きなメリットが2つあります。第1に、異なるサービス プログラム全般にわたって重複するプロシージャー名を完全に避けることができます。第2に、プロシージャーの呼び出しを見たときに、バインディング ディレクトリーやモジュール定義を調べるまでもなく、それがどのサービス プログラムに由来するのかがすぐに分かります。
私たちのショップでは、同じ命名規則をグローバル変数に適用しています（もっとも、グローバル変数の使用は控えめにしていますが）。ほとんどの場合、ローカル変数の方が、可読性のためにも、意図せぬ副作用を避けるためにも、より良い選択肢です。ローカル変数がデフォルトであるべきである理由が気になる方は、そのテーマについて深掘りした記事、「 プロシージャー主導型RPGでは、変数はローカルに保たれる」を参照してください。
時間を取って、OPTIONのようなパラメーターを明示的に設定し、じっくり考えてバインディング ディレクトリーを設計しておけば、サービス プログラムは保守が容易になり、予測可能性が一段と高まります。コンパイル時にすでに防止してあるため、重複するプロシージャー名が問題を引き起こさないか考える必要もありません。そして、こうした命名規則は、ドキュメンテーションのひな型になり、将来の開発者から感謝されることになるはずです。
