実稼働環境のプログラムは、以下の任意の特性を備えます。
このセクションは、アプリケーションの主要なテストを完了して、最終段階のチューニングに入った後で、Debug Tool のテスト機能をどの程度継続して使用する必要があるかを判断する場合に役立ちます。プログラム・サイズとパフォーマンス上の考慮点についての 検討、フック、ステートメント・テーブル、シンボル・テーブルを除去した 場合の結果、最適化プログラムに関する Debug Tool の使用法などを取り上げています。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
初期テストの後に、パフォーマンスの向上やサイズの縮小に使用できる以下の オプションについて考慮することが必要です。
プログラムのパフォーマンスを向上させる 1 つのオプションは、最小限の フックを使用して、またはフックを使用しないでコンパイルすることです。
独自の研究によれば、PL/I ではフックのオーバーヘッドによるパフォーマンス低下は、無視できる程度ということです。さらに、アテンション割り込みを要求しなければならないイベントでは、コンパイル時に 組み込んだフックがないと、Debug Tool は制御を受け取ることができません。組み込んであれば、割り込みを 3 回要求することができます。3 回目の要求の後に、Debug Tool は、プログラムの実行を停止 し、QUIT または GO を入力するようにプロンプトを出す ことができます。QUIT を入力すると、Debug Tool セッションは終了します。GO を入力すると、制御はアプリケーションに戻ります。
TEST コンパイラー・オプションの特定のサブオプションが指定されてコンパイルされたプログラムには、コンパイル時にフックが挿入されます。ただし、動的デバッグ機能が活動化され (デフォルト)、特定のコンパイラーでプログラムがコンパイルされると、コンパイル時に挿入されたフックが実行時のフックによって置き換えられます。 この置き換えによって、Debug Tool のパフォーマンスが向上します。 動的デバッグ機能の使用時には、特定のパス・フック関数は使用が制限されます。 これらの関数を使用可能にするには、動的デバッグ機能を非活動化する SET DYNDEBUG OFF コマンドを入力します。 これらのコマンドについて詳しくは、「Debug Tool リファレンスおよびメッセージ」を参照してください。
特定プログラムに関して、パフォーマンス・オーバーヘッドに照らして、フックを保持する利点があるのかを調べるのはよい考え方です。
プログラムのサイズが問題と考える場合は、初期テスト期間が過ぎてから、シンボル・テーブルまたはステートメント・テーブル、もしくはその両方 を除去することができます。C および PL/I プログラムでは、オプション TEST(NOSYM) を使用してコンパイルすると、シンボル・テーブルの作成を禁止することができます。
ただし、これらを除去する前に、その利点を考慮してください。ステートメント・テーブルを使用すると、オフセットではなくステートメント番号の 付いた実行ヒストリーを表示することができ、エラー・メッセージはエラーが生じて いるステートメント番号を示します。シンボル・テーブルを使用すると、名前で変数およびプログラム制御定数を 参照することができます。したがって、プログラムのサイズと、シンボル・テーブルおよびステートメント・テーブルを持つ利点を相殺して考察する必要があります。
以下のコンパイラーで TEST コンパイラー・オプションの SEPARATE サブオプションを使用してコンパイルしたプログラムに対して、シンボル・テーブルが分離デバッグ・ファイルに保存されます。この構造では、シンボル・テーブル情報を保存でき、プログラムのサイズを小さくすることができます。
z/OS バージョン 1.6 以降の C/C++ コンパイラーでコンパイルされた C および C++ プログラムでは、DEBUG コンパイラー・オプションの FORMAT(DWARF) サブオプションを使用してコンパイルし、デバッグ情報を分離デバッグ・ファイルに保存できます。これにより、より小さいプログラムが生成されます。
Debug Tool は、TEST ランタイム・オプションの PROMPT サブオプションによって、プログラムの初期設定時に制御を得ることができます。 すべてのフック、ステートメント、およびシンボル・テーブルを実動プログラムから除去した場合でも、Debug Tool は、TEST ランタイム・オプションに ALL または ERROR を指定した場合に プログラムで条件が発生したとき、あるいは __ctest()、CEETEST、または PLITEST が実行されるときに、制御を受け取ります。
このように限定された環境で Debug Tool が制御を得る場合には、どのステートメント にエラーがあるのかは不明となり (ステートメント・テーブルがないため)、また、変数を探し出すこともできません (シンボル・テーブルがないため)。したがって、アドレスを使用し、16 進データ値を解釈して変数を調べる必要があります。この限られた環境で実行できる内容は、次のとおりです。
list (%LOAD, %CU, %BLOCK);
または
list (%LOAD, %PROGRAM, %BLOCK);list (%ADDRESS, %EPA); (where %EPA is allowed)
LIST STORAGE (0x20058);COBOL または PL/I プログラム内のアドレス 20058 の内容を表示するには、次のように 入力します。
LIST STORAGE (X'20058');
LIST REGISTERS;
DESCRIBE CU; (for C) DESCRIBE PROGRAM; (for COBOL)
LIST CALLS;
SYSTEM ...;
GO;
QUIT;
プログラムにステートメントまたはシンボル・テーブルが入っていない場合 は、セッション変数を使用して、より容易に変数値を調査するタスクを 生成することができます。
この限られた環境でも、HLL ライブラリー・ルーチンを使用することができます。
以下のコンパイラーとコンパイラー・オプションの組み合わせでコンパイルしたプログラムは、全デバッグ機能を保持しながら、最適のパフォーマンスと最小のモジュール・サイズを実現できます。
最適化された COBOL プログラムをデバッグする前に、正しいコンパイラー・オプションを使用して、プログラムをコンパイルしておく必要があります。COBOL プログラムでの TEST または NOTEST コンパイラー・サブオプションの選択を参照してください。
以下に、最適化された COBOL プログラムのデバッグ中に実行できるタスクについて挙げます。
コンパイラーに対する機能強化により、最適化されていないプログラムをデバッグするのと同じ方法でデバッグできるプログラムを作成できますが、以下の例外があります。
ソース・ウィンドウには最適化プログラムが削除した変数やステートメントが表示されますが、そのような変数やステートメントに対してどの Debug Tool コマンドも使用することはできません。例えば、最適化プログラムが削除した変数の値をリストすることはできません。