Case 2: Just Wait|What the Application May Do|DBCAREA - ケース2: 待機のみ - Call-Level Interface Version 2

Teradata® Call-Level Interfaceバージョン2 リファレンス - ワークステーション接続システム - 17.20

Product
Call-Level Interface Version 2
Release Number
17.20
Published
2022年10月10日
Language
日本語
Last Update
2022-11-21
dita:mapPath
ja-JP/zws1641280432166.ditamap
dita:ditavalPath
ja-JP/obe1474387269547.ditaval
dita:id
B035-2418
Product Category
Teradata Tools and Utilities
DBCHINIを呼び出した後で、クラッシュ/遅延のオプションが次のように設定されている場合には、以下のようになります。
  • Tell About Crash(またはTell About Delay)が'N'
  • Wait Across Crash(またはWait Across Delay)が'Y'
オプションがこの組み合わせであれば、データベースのクラッシュ/遅延が発生した場合の手順は次のようになります。
  1. アプリケーションで、何らかの関数のDBCHCLを呼び出します。
  2. DBCHCLからの情報を受け取る前か受け取ったあとでシステムがクラッシュ、またはAPがリセットします。
  3. アプリケーション プログラムは、クラッシュまたはリセットの通知を受けず、制御も獲得しません。
  4. Teradataシステムが再始動するか、APのリセットが完了します。
  5. アプリケーション プログラムに、EM_OK(0)の戻りコードでCLIから制御が戻ります。
  6. アプリケーションでFetch関数のDBCHCLを呼び出すと、次の情報が得られます。
    • データベースは、そのリクエスト番号のリクエストについては何も知りません(エラー コード2825のErrorパーセル)
    • データベースは、そのリクエストをアボートしました(失敗コード2828のFailureパーセル)
    • リクエストは正常に完了しましたが、応答は喪失しました(エラー コード2826のErrorパーセル)
  7. アプリケーション プログラムで、アプリケーションにとって適切な処置をとります。

リクエストを再び実行依頼しなければならない場合には、リクエストを実行依頼する前にリクエストのコピーを保存しておきます。 トランザクションを再び実行依頼しなければならない場合には、トランザクションが複数のリクエストにまたがっていれば、そのトランザクション内の各リクエストのコピーを保存しておきます。

ログオフ リクエスト時に再始動が生ずる場合には、CLIは自動的にリクエストを再発行します。

Wait For Responseの設定値は、上記の処理に影響を及ぼしません。