アプリケーションからのストアード・プロシージャーの呼び出し

ストアドプロシージャを実行するには、クライアントプログラムから呼び出すか、 Db2 command line processor から起動します。

アプリケーションからストアード・プロシージャーを呼び出すには、次のようにします。

1. IN パラメーターおよび INOUT パラメーターに値を割り当てます。
2. オプション： アプリケーションのパフォーマンスを向上させるには、LOB出力パラメータの長さをゼロに初期化します。
3. ストアード・プロシージャーがリモート・ロケーションに存在する場合、以下のアクションを実行します。
   1. OUT パラメーターに値を割り当てます。

      リモートの場所でストアドプロシージャを呼び出すと、ローカル Db2サーバーはパラメータが入力（IN）または出力（OUTまたはINOUT）パラメータかを判断できません。 したがって、リモート・ロケーションのストアード・プロシージャーを呼び出す前に、 すべての出力パラメーターの値を初期化する必要があります。

   2. オプション： リモートサーバーに接続するための明示的なCONNECTステートメントを発行します

      明示的にこのステートメントを発行しない場合、次のステップで 3 部構成の名前を使用してストアード・プロシージャーを識別することにより暗黙的にサーバーに接続できます。

      明示的な CONNECT ステートメントを発行する利点は、次のステップで説明する CALL ステートメントを他のオペレーティング・システムに移植可能であるということです。 暗黙的に接続する利点は、この余分な CONNECT ステートメントを発行する必要がないということです。

      要件 ：リモートサーバーに暗黙的または明示的に接続するかを決定する際には、ASSOCIATE LOCATORまたはDESCRIBE PROCEDURE文を実行するプログラムの要件を考慮すること。 CALL ステートメントと ASSOCIATE LOCATORS または DESCRIBE PROCEDURE ステートメントで、同じ形式のプロシージャー名を使用する必要があります。
4. SQL CALL ステートメントを使ってストアード・プロシージャーを呼び出します。 必ず互換性があるパラメーター・データ・タイプを渡してください。

   ストアード・プロシージャーがリモート・サーバーに存在し、明示的な CONNECT ステートメントを発行しなかった場合、3 部構成の名前を指定してストアード・プロシージャーを識別し、そのストアード・プロシージャーがあるサーバーに暗黙的に接続します。

   ネイティブ SQL プロシージャーの場合、デフォルトでストアード・プロシージャーのアクティブ・バージョンが呼び出されます。 オプションで、アクティブ・バージョン以外のストアード・プロシージャーのバージョンを指定できます。

   パラメーターに NULL 値を使用できるようにするには、標識変数を使用します。

5. オプション： 手続きのステータスを取得します
6. OUT パラメーターと INOUT パラメーターを組み込んで、出力を処理します。
7. ストアード・プロシージャーが複数の結果セットを返す場合は、それらの結果セットを取得します。
   推奨： 結果セットを取得したらすぐに閉じ、頻繁にコミットを発行して、 Db2 のストレージ不足やEDM POOL FULLの状態を回避します。
8. PL/I アプリケーションの場合、以下のアクションも実行します。
   1. ソース・コードにランタイム・オプション NOEXECOPS を組み込みます。
   2. コンパイル時オプション SYSTEM( MVS ) を指定してください。
   これらの追加手順により、 z/OS においてリンキング規約が正しく機能することが保証されます。
9. C アプリケーションの場合、ソース・コードに次の行を組み込みます。

   #pragma runopts(PLIST(OS))

   このコードにより、 z/OS においてリンクの規約が正しく機能することが保証されます。

   このオプションは、その他のオペレーティング・システムには適用できません。 z/OS 以外の他のプラットフォームで C ストアドプロシージャを使用する場合は、次の例に示す条件付きコンパイルの形式のいずれかを使用して、 z/OS でコンパイルする場合のみこのオプションを含めます。

   形式 1

   #ifdef MVS
    #pragma runopts(PLIST(OS))
   #endif
   

   形式 2

   #ifndef WKSTN
    #pragma runopts(PLIST(OS))
   #endif

10. アプリケーションをプリコンパイル、コンパイル、およびリンク・エディットして DBRM をバインドすることにより、その他のアプリケーションの場合と同様にアプリケーションを準備します。

    アプリケーションがリモート・ストアード・プロシージャーを呼び出す場合、DBRM をバインドするときに以下の追加の手順を実行します。

    • DBRM をローカル Db2 サーバーのパッケージにバインドします。 bindオプションにDBPROTOCOL(DRDA)を使用します。 ストアード・プロシージャー名を実行時まで解決できない場合は、バインド・オプション VALIDATE(RUN) も指定します。 ストアード・プロシージャー名に変数を使用する場合、またはストアード・プロシージャーがリモート・サーバーに存在する場合は、ストアード・プロシージャー名を実行時に解決できない可能性があります。
    • リモート Db2 サーバーでDBRM をパッケージにバインドします。 クライアント・プログラムが複数のサーバーにアクセスする場合は、それぞれのサーバーでプログラムをバインドします。
    • すべてのパッケージをローカル Db2 サーバーの計画にバインドします。 bindオプションにDBPROTOCOL(DRDA)を使用します。
11. ストアード・プロシージャーが正常に完了したことを確認します。
    ストアード・プロシージャーが異常終了すると、 Db2 は以下のアクションを実行します。

    • 呼び出し側プログラムは、ストアード・プロシージャーが失敗した ことを知らせる SQL エラーを受け取ります。
    • Db2 は、呼び出し側プログラムの作業単位を、ロールバックの状態にします。
    • Db2 は、以下条件のいずれかの場合、ストアード・プロシージャーを停止し、後続の呼び出しは失敗します。
      • 異常終了回数が、ストアード・プロシージャーの STOP AFTER n FAILURES 値に等しい。
      • 異常終了回数が、サブシステムのデフォルトの MAX ABEND COUNT 値に等しい。
    • このストアドプロシージャは異常終了状態を処理せず、 Language Environment がアプリケーションが使用するストレージを回復できるよう環境をリフレッシュします。 Db2 ほとんどの場合、環境を再始動する必要はありません。
    • ストアード・プロシージャー・アドレス・スペースを開始する JCL プロシージャーの DD ステートメント CEEDUMP でデータ・セットが割り振られます。 この場合、 Language Environment はこのデータセットに小さな診断ダンプを出力します。 ダンプ内の情報を使用してストアード・プロシージャーをデバッグします。
    • データ共有環境では、ストアード・プロシージャーが STOPABN 状況に設定されるのは、異常終了が発生したメンバーに対してのみです。 呼び出し側プログラムは、データ共有グループの他のメンバーからストアード・プロシージャーを呼び出すことができます。 他のすべてのメンバーの状況は STARTED です。