09/08/2020 スーザン・ガントナー＆ジョン・パリス
デバッグは多くのプログラマーが話したがらない話題の１つです。多分彼らは、いつか彼らが自分たちのプログラムをデバッグする必要があるかもしれないと（自分自身に対してさえも）認めたくないのでしょう。しかし、私たちの経験からすると、デバッグはプログラマーが誰か他の人がそれについて話すのを聞くのを好むように見えることの多い話題です。Rational® Developer for i（以下RDiと略記）デバッグ・セッションは、たとえば私たちのRPG & DB2サミット会議のような多くのイベントの題目の中でしばしば最も人気のあるものの１つです。
私たちが前回IBM System Magazine向けにRDiデバッガーに関する記事を書いたのはずっと昔のことです。あまりに昔の事なので、私たちが現在RDiという名前で知っている製品は、あの時から今日に至る年月の間に3回も名前を変えました！幸い、現在の名前は長い間変わっていません。そして更に幸いなことにRDiは改良され続けており、役に立つ機能強化のペースは近年早まってきています。
RDiデバッガーはRPGプログラマーの間で依然として人気の話題であるように見受けられるので、この話題を再度取り上げることにしました。ここでは最近の2つの機能強化について説明しますが、私たちの主要な使命はRDiデバッガーを使い始める手助けをすることにあります。
RDiデバッグ・セッションを開始する
RDiを使ったデバッグで多くの人を一番困惑させると思われる部分は、デバッグ・セッションの開始の仕方です。デバッグ・セッションを開始する主な方法は２つあります。
- デバッグ構成を作成し、使用する
- サービス・エントリー・ポイントを使用する
これら2つの選択肢の内、私たちのお気に入りの方法は、サービス・エントリー・ポイント（以下、SEPという）を使う方法です。本稿ではSEPに焦点を当て、デバッグ構成を使う方法については将来の記事で取り上げる予定です。SEPを使う場合、いくつかの制限事項がありますが、それについては少し後で説明します。ですから、両方のデバッグの開始法を知っているのは常に良いことです。
この話題に入る前に、設定可能なプリファレンス（注：RDi内では「設定」と訳されています）があるのを知っていると良いでしょう。少なくとも１つはSEPを使用する前に多分よく調べておくべきです。
RDiの「設定」メニューを開き、左側のパネル上部の近くにあるフィルターボックスに「デバッグ」と入力します。このフィルターされた一覧の中の「IBM i デバッグ」を選びます。ここで、ほとんどの人が変更する必要があるのが「実働ファイルの更新」です。私たちが一緒に仕事をしているIBM iの使用企業のほとんどが、その設定をオンにする必要があります（デフォルト値はオフです）。同じパラメーターに対してグリーンスクリーンでデバッグするときに通常必要な設定を何であれ選びます。これで設定ができましたので、SEPを使ったデバッグを開始しましょう。
デバッグSEPとは？
デバッグSEPはデバッグのために実行中のプログラムの制御を獲得する簡単な方法です。デバッグSEPは、特定のユーザープロファイルによってシステム上の任意の場所で実行開始している特定のプログラム（またはプロシージャ）の組み合わせを監視するIBM i上の一種のモニターです。そのプログラムとユーザーの組み合わせが見つかると、システムはプログラムの実行をコードの最初の行で停止し、ジョブ及びプログラム上のSTRSRVJOB（Start Service Job）及びSTRDBG(Start Debug)とほぼ等価な操作を行います。次にそれはSEPをセットした開発者にプログラムがデバッグできる状態にあることを通知します。
SEPデバッグ・セッションを開始するステップ
1. デバッグするプログラムを選ぶ
リモートシステム（またはオブジェクトテーブル）で、デバッグしたいプログラム上、あるいは少なくとも呼び出しスタックの最初のプログラム上で右クリックします。必要であれば後でそのセッションにプログラムを追加できます。コンテクストメニューから「デバッグまたはコードカバレッジ（サービス・エントリー）」を選びます。ソースメンバーまたは*PGMオブジェクトないし*SRVPGMオブジェクトに対してこれが実行できます。確実に望みのコードをデバッグするためにオブジェクトを使うのが私たちの好きな方法です。
2. SEPの設定を確認する
SEPが設定されるまでに２～３秒要するかもしれません。設定されると、それはSEPビュー内（一般的にはエディターの直下）に表示されます。そこからSEPに関するデフォルト値が必要な値に設定されていることを確認できます。それはプログラム内のすべてのプロシージャとモジュールを選択し、あなた自身のユーザープロファイル、つまりRDiコネクションで使っているユーザープロファイルを使用します。もしデバッグするプログラムが異なるユーザープロファイルの下で実行されるならば、ここでユーザーIDを修正しなければなりません。（図１の右上にあるバグアイコンにより）デバッグモードが選択されていることを確認します。代替モード（バグアイコンの右にあるアイコン）はコードカバレージのためのものです。コードカバレージはSEPを使用する別のツールです。ですから、デバッグ用に正しいモードが設定されていることを確認してください。デフォルトの選択に対して加える必要のあるすべての変更は、SEPリスト内のエントリーに対するコンテクストメニューから行うことができます。
3. デバッグするコードを実行する
ここでSEPは異彩を放ちます。なぜなら、プログラムをどのように実行するかも、デバッグするプログラムが対話型（グリーンスクリーン）ジョブまたはバッチ投入されたジョブあるいはサーバー型のジョブであろうと、SEPには関係ないからです。指定されたユーザーIDが指定されたプログラムを実行開始すれば、いつでもどこでもシステムはそれを検知し、RDiワークベンチでデバッグ・セッションを開始します。もしデバッグパースペクティブがまだ開いていなければ、RDiはそれを開きます。始めにパースペクティブを切り替えるかどうかを尋ねるプロンプト画面が表示されるかもしれません。また（コンパイル時に指定したオプションに応じて）ソースまたはコードのリスト・ビューが編集ウィンドウに表示されます。その外観は下の図２のようなものです。これでデバッグを行う準備は整いました。
新機能：デバッグ・セッション自体で何ができるかを説明する前に、上の画像（図１）の中により最近のデバッガー機能拡張の最初のものを見ることができます。SEPビューの中の「条件」列に注目してください。これはRDi 9.6.0.7の新機能で、プログラムの開始時にテストされる条件を指定できます。たとえば、プログラムに特定のパラメーター値が渡された場合にだけSEPを動かすといった条件付けができます。
ブレークポイントを使う
図２で、 既に命令行136と141の2か所にブレークポイントが設定されているのが見て取れます。ブレークポイントは命令行の左をダブルクリックすることで、あるいはエディターのコンテクストメニューで、設定（または解除）できます。ブレークポイントは解除することなく無効にすることもできます。デバッグパースペクティブ・ビューの右上の領域（ただし、図２の前景ではありません）にブレークポイント・ビューがあります。そこからすべてのブレークポイントを見ることができ、それらを管理（解除、無効化、編集）できます。
ブレークポイントを条件付けするために、（エディターまたはブレークポイント・ビューから表示した）コンテクストメニューで編集します。条件入力フィールドは編集ダイアログの第2パネル上にあります。ブレークポイントの監視はいかなるコードとも関連がなく、指定された変数の値が変わった場合に常に停止します。ブレークポイントはブレークポイント・ビューから設定、管理することもできます。
RDiのブレークポイントのとりわけ有用な機構の１つは、現行のデバッグ・セッションが終了した後でもブレークポイントが記憶されることです。セッション中にバグを発見できなかった場合、何時間あるいは何日か経ってからデバッグを再開することができ、デバッグを再試行するためにブレークポイントが準備完了状態でそこに残っています。このため、別の問題のための直近のデバッグ・セッションの後でブレークポイントを解除し忘れた場合に備え、ブレークポイント・ビューで一度にすべてのブレークポイントを素早く解除できることを知っていると便利です。コンテクストメニューまたは2重Xアイコンをクリックすることで、すべてのブレークポイントが解除されます。それらのブレークポイントが再度必要になると思う場合には、ブレークポイントを無効にすることができます。
最後のもう１つのブレークポイントは、技術的にはブレークポイントではありません。コードの命令行の上で右クリックをし、実質的に一時的な1回限りのブレークポイントを設定するために「指定行まで実行」を選びます。
コードをステップスルーできる？
RDiで可能なデバッグステップには4つのタイプがあります。ホストベース（グリーンスクリーン）のデバッガーで利用可能なオプションには、ステップオーバー（グリーンスクリーンでのF10、RDiでのF5）とステップイン（グリーンスクリーンでのF22、RDiでのF6）の２つがあります。これらはアイコン（図３で強調表示された内の真中の２つ）からも実行できますし、ショートカットキーあるいは実行メニューからステップ・オプションを使って実行することもできます。
図３の最右端にあるステップアイコンはステップリターン・オプションです。プログラムまたはプロシージャにステップインした後、そのコードの各ステップを追跡し続けたくないと判断した場合、呼び出し元に戻って次の命令行で停止するためにステップリターンを使うことができます。この機能はステップインしたコードがILE言語で作成されている場合に限り動作します。つまり、ステップインした先のプログラムまたはプロシージャがRPGLE、CBLLEないしCLLEであれば動作し、ステップインした先がCLプログラムまたはRPGプログラムの場合は動作しません。もちろん後者の場合、エディターで呼び出し元に戻るように切り替えを行い、呼び出し命令の次の命令で停止するようブレークポイントを設定してから図３のステップボタン群の左に表示されている緑色のレジュームボタンを使うか、F8または実行メニューからレジュームオプションを使うことでそのブレークポイントまでコードを実行させることができます。
上記の強調表示された４つのステップアイコンの最初のものは、コードの流れに十分精通しておらず、どこにブレークポイントを設定するか分らない場合に大いに役に立ちます。それはアニメーション表示ステップインです。それは自動的にステップイン動作を実行し、その間あなたは手を出すことなく起こっていることを見守るだけです。ステップの速さはアイコンの隣の矢印を使って制御できます。これはこの後すぐに説明する様に、いくつかの変数値をモニターする様に設定した場合にとりわけ役に立ちます。
変数の値はどうするか？
デバッグを行う際、いくつかの特定の変数の現在の値がどうなっているかを知ることがしばしば必要になります。RDiデバッグパースペクティブを使うと、いくつかの方法で変数の値を見たり変更したりすることができます。
値を素早く見る一番単純な方法はエディター上で変数名の上にカーソルを合わせることです。デバッグ・セッションが活動中であれば現在の値が表示されます。また、デバッグパースペクティブの右上の象限（前にブレークポイント・ビューを見た同じ領域内のタブ）に変数ビューもあります。これは活動中のプログラムまたはプロシージャの中のすべての変数の値を表示します。これはコードの大変小さな一部分に対してはうまく機能しますが、多くの古いRPGプログラムやCOBOLプログラムのような非常に大きいプログラムの場合、デバッガーの動きが極めて遅くなる可能性があります。その理由は、各ブレークポイントあるいはステップで数百、数千の値をロードするのに時間が掛るからです。ですから、大きなプログラムをデバッグする場合には、変数ビューを前景に残さないようにすることをお勧めします。前景に対する私たちのお気に入りについてはこの先をお読みください。
デバッグ時に前景に何を表示するべきでしょうか？一般的にモニター・ビューを前景にするのが我々の好みです。モニターを使うことで、ブレークポイントあるいはステップでコードが停止する度に、自分自身で選んだいくつかの特定の変数値を監視できます。これにより、最も興味のある変数の値を迅速に調べられるだけでなく、前回プログラムが停止した時点以降に変更されたすべての値が赤字で強調表示もされます。下の図４はこの様子を示しています。
モニター・ビューでも変更したい値をダブルクリックして入力ボックスを表示し、モニターされている変数の値を変更することができます。
新機能：RDiデバッガーの第2の新機能は、変数値を見ることに関係するものです。RDi 9.6.0.7以降でデバッグ中に長い変数値を見ることができます。それ以前の4096バイトというサイズ上限は、XML文書やJSON文書のようなものを格納している大きな変数を取り扱う際に問題になる可能性がありました。
SEPの制約事項
SEPが使用できないいくつかのケースがあると前に述べました。
SEP経由でデバッグ・セッションを開始するのに使用するプログラムは、RPGLE、CBLLE、CLLEのようなILE言語プログラムでなければなりません。ひとたびSEPデバッグ・セッションが開始したなら、RPG、CLPおよびCBLを含む任意のプログラムをデバッグすることができます。ILEでなければならないのは、デバッグ・セッションを開始するプログラムだけです。デバッグしたいRPGプログラムないしCLプログラムがある場合に使われるのを見たことがある1つの回避策は、単にRPGプログラムまたはCLプログラムを呼び出すだけのCLLEプログラムを作成することです。CLLEプログラムからSEPを開始し、次にRPGプログラムないしはCLプログラム及び／または含める必要のある他の任意のプログラムにステップインします。
もう1つの制約は、デバッグしたいプログラムのインスタンスが既に活動中であってはならないというものです。たとえば、デバッグされるプログラムが終了しないプログラム（NEP：Never Ending Program）である場合や、プログラムが稼働中に恐らくエラーまたはグリーンスクリーン表示装置が原因で停止した場合などです。SEPはプログラムが最初に始動するときに、プログラムの制御権を獲得できなければなりません。
そうした場合でも依然としてRDiデバッガーを使うことはできます。プロセスを開始するためにSEPを使うことができないだけです。
SEPを使用するのは、単にデバッグ・セッションを開始させるためであることを覚えておくことは重要です。セッション開始状態にするためにSEPを使おうがデバッグ構成を使おうが、セッションが開始された後はブレークポイント、ステップ実行、そして変数値の表示、変更、監視の使用法は同じです。
デバッグ構成の使用法を説明する紙幅はここにはありません。しかし、それについては将来の記事でRDiデバッガーの使い方に関する他のいくつかの詳細情報と共に説明する予定です。
それまでの間、RDiデバッグ・セッションの開始の方法について、スーザンが作成した短いビデオをご覧になりたければこちらを見てください。
