ストアード・プロシージャーのデバッグ

ストアード・プロシージャーをデバッグする場合は、通常のアプリケーション・プログラムで使用する手法と異なる手法を使用する必要がある場合があります。 例えば、TSO TEST など通常使用されるデバッグ・ツールの中には、ストアード・プロシージャーが実行される環境で使用できないものがあります。

ストアード・プロシージャーをデバッグするには、以下のアクションを 1 つ以上実行します。

• 以下の 1 つ以上の汎用アクションを行います。これらは、ストアード・プロシージャーを使用する多くの場合で有用です。
  • すべてのストアード・プロシージャーが、すべての SQL エラーを処理するように記述されていることを確認します。
  • ワークステーション上のスタンドアロン・プログラムとしてストアード・プロシージャーをデバッグします。

    ワークステーションにデバッグツールがある場合は、 z/OS® にストアドプロシージャをインストールする前に、ワークステーション上で開発とテストのほとんどを行うことを検討してください。このテクニックを使用すると、 z/OS でのデバッグ作業が大幅に削減されます。

  • ストアード・プロシージャーのデバッグ・メッセージをディスク・ファイルまたは JES スプール・ファイルに記録します。
  • デバッグ情報を表に保管します。 この技法は、リモート・ストアード・プロシージャーの場合に特に役立ちます。
  • DISPLAY コマンドを使用して、特定のストアード・プロシージャーに関する情報を表示します (統計やスレッド情報など)。
  • デバッグしているストアード・プロシージャーで、DISPLAY コマンドを発行します。 DISPLAY の結果を SDSF 出力で表示できます。 この DISPLAY の結果から、WLM アプリケーション環境のアドレス・スペースに関連付けられた開始タスクに関する情報を検索できます。
  • 必要な場合、STOP PROCEDURE コマンドを使用して、1 つ以上の問題のあるストアード・プロシージャーに対する呼び出しを停止します。 それらを後で再始動できます。
• ストアード・プロシージャー・アドレス・スペースに CEEDUMP データ・セットが割り振られている場合は、CEEDUMP 出力の診断情報を参照します。
• COBOL、C、および C++ ストアドプロシージャについては、 Debug Tool for z/OS を使用してください。
• COBOL ストアード・プロシージャーで、CEEDUMP 出力にフォーマット済みローカル変数ダンプを含める場合は、オプション TEST(SYM) を指定してストアード・プロシージャーをコンパイルします。
• ネイティブ SQL プロシージャ、外部 SQL プロシージャ、および Java™ ストアド・プロシージャには、 統合デバッガを使用します。
• 外部ストアード・プロシージャーの場合、以下のいずれか (または両方) のアクションを行います。
  • ドライバー・アプリケーションを使用します。
  • PARAMETER STYLE SQL オプションを含めるようにストアード・プロシージャー定義を作成または変更します。 このオプションを使用すると、ストアード・プロシージャーは任意のエラー情報を呼び出し側アプリケーションと共有できます。 ご使用のプロシージャーがストアード・プロシージャーのリンケージ規約に従っていることを確認してください。
• WLM アプリケーション環境のストアード・プロシージャーまたは始動 JCL プロシージャーを変更した場合は、WLM 環境のリフレッシュが必要かどうかを判別します。 特定のストアード・プロシージャー変更を有効にするには、WLM 環境をリフレッシュする必要があります。