各データベースは、 トランザクション・マネージャー (TM) に対して別個のリソース・マネージャー (RM) として定義されているので、 xa_open ストリングによって識別する必要があります。 DB2 の xa_open ストリングの形式については、xa_open および xa_close ストリングの使用法を参照してください。
データベース・マネージャーの xa_open ストリングには、2 つの形式があります。 1 つは DB2 バージョン 7 で新しく使用される形式です。 2 番目の形式は DB2 の以前のバージョンで使われるもので、 バック・レベル互換性のために保持されています。 新しく実装する際には新しい形式を使用すべきであり、以前に実装したものは、 可能であれば新しい形式に移行してください。 DB2 の将来のバージョンでは、 古い形式の xa_open ストリングをサポートしない可能性があります。 以前の xa_open ストリング形式については、以前のバージョンの DB2 の xa_open ストリング形式を参照してください。
データベースをリソース・マネージャーとして設定する場合、 xa_close ストリングは必要ありません。 このストリングを指定しても、 データベース・マネージャーによって無視されます。
以下の xa_open ストリング形式は DB2 バージョン 7 で新しく使用されるものです。
parm_id1 = <parm value>,parm_id2 = <parm value>, ...
パラメーターは任意の順序で指定できます。
parm_id の有効値は、以下の表のとおりです。
パラメーター名 | 値 | 必須かどうか | 大文字小文字の区別 | デフォルト値 |
---|---|---|---|---|
DB | データベース別名 | はい | なし | なし |
データベースへのアクセスにアプリケーションが使用するデータベース別名。 | ||||
UID | ユーザー ID | いいえ | あり | なし |
データベースへの接続を許可されているユーザー ID。 パスワードが指定される場合に必要。 | ||||
PWD | パスワード | いいえ | あり | なし |
ユーザー ID に関連したパスワード。 ユーザー ID が指定される場合に必要。 | ||||
TPM | トランザクション処理モニター名 | いいえ | なし | なし |
使用されている TP モニターの名前。 サポートされている値については、TPM 値および TP_MON_NAME 値を参照してください。 このパラメーターを指定すると、 複数の TP モニターで単一の DB2 インスタンスを使用できます。 ここで指定した値は、 データベース・マネージャー構成パラメーター tp_mon_name に 指定された値をオーバーライドします。 | ||||
AXLIB | TP モニターの ax_reg 関数 および ax_unreg 関数を含むライブラリー。 | いいえ | あり | なし |
この値は、必要な ax_reg 関数 および ax_unreg 関数のアドレスを得るために DB2 によって使用されます。 この値を使って、TPM パラメーターに基づく仮定値をオーバーライドできます。 または、TPM のリストに現れない TPM モニターがこの値を使用することもできます。 | ||||
CHAIN_END | xa_end チェーニング・フラグ。 有効な値は、T、F、または値なしです。 | いいえ | なし | F |
XA_END チェーニングとは、 ネットワーク・フローを減らすために DB2 が使用することのできる最適化です。 xa_end 呼び出しに続いてただちに 同じスレッド (またはプロセス) で 必ず xa_prepare が呼び出されるような TP モニター環境では、CHAIN_END がオンであれば、 xa_end フラグは xa_prepare コマンドと連結され、 こうしてネットワーク・フローが 1 つ減ります。 値 T は CHAIN_END がオンであることを示し、 値 F は CHAIN_END がオフであることを示します。 値を指定しない場合、CHAIN_END はオンになります。 また、このパラメーターを使用して、 特定の TPM 値から派生した設定をオーバーライドできます。 | ||||
SUSPEND_CURSOR | トランザクションの制御スレッドが中断されている場合にカーソルを保持するかどうかを指定します。 有効な値は、T、F、または値なしです。 | いいえ | なし | F |
トランザクション分岐を中断する TP モニターは、 中断されたスレッドまたはプロセスを他のトランザクション用に再使用できます。 このような状況では、 新しいトランザクションがカーソルを継承しないようにするために、 カーソルを閉じる必要があります。 中断されたトランザクションが再開されると、 アプリケーションは再びカーソルを取得する必要があります。 SUSPEND_CURSOR がオンであれば、開いたカーソルはいずれも閉じられませんが、 スレッドまたはプロセスを他のトランザクション用に再使用することはできません。 中断されたトランザクションの再開だけが可能です。 値 T 値は SUSPEND_CURSOR がオンであることを示し、 値 F 値は SUSPEND_CURSOR がオフであることを示します。 値を指定しない場合、SUSPEND_CURSOR はオンになります。 また、このパラメーターを使用して、 特定の TPM 値から派生した設定をオーバーライドできます。 | ||||
HOLD_CURSOR | トランザクションのコミット後に次のコミットまでカーソルを保持するかどうかを指定します。 有効な値は、T、F、または値なしです。 | いいえ | なし | F |
通常、TP モニターは、 スレッドまたはプロセスを複数のアプリケーション用に再使用します。 新しくロードされたアプリケーションが、 以前のアプリケーションによって開かれたカーソルを継承しないようにするために、 カーソルはコミット後に閉じられます。 HOLD_CURSOR がオンであれば、 トランザクションのコミット後も次のコミットまでカーソルを保持します。 値 T 値は HOLD_CURSOR がオンであることを示し、 値 F 値は HOLD_CURSOR がオフであることを示します。 値を指定しない場合、HOLD_CURSOR はオンになります。 また、このパラメーターを使用して、 特定の TPM 値から派生した設定をオーバーライドできます。 |
xa_open ストリングの TPM パラメーターと
データベース・マネージャー構成パラメーター tp_mon_name は、
使用中の TP モニターを DB2 に示すために使われます。
tp_mon_name 値は DB2 インスタンス全体に適用されます。
TPM パラメーターは、特定の XA リソース・マネージャーにのみ適用されます。
TPM 値は tp_mon_name パラメーターをオーバーライドします。
TPM および tp_mon_name パラメーターの有効値は以下のとおりです。
表 23. TPM および tp_mon_name の有効値
TPM 値 | TP モニター製品 | 内部設定 |
|
---|---|---|---|
CICS | IBM TxSeries CICS |
AXLIB=libEncServer (Windows の場合) =/usr/lpp/encina/lib/libEncServer (UNIX ベースのシステムの場合) HOLD_CURSOR=T CHAIN_END=T SUSPEND_CURSOR=F |
|
ENCINA | IBM TxSeries Encina Monitor |
AXLIB=libEncServer (Windows の場合) =/usr/lpp/encina/lib/libEncServer (UNIX ベースのシステムの場合) HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F |
|
MQ | IBM MQSeries |
AXLIB=mqmax (Windows の場合) =/usr/mqm/lib/libmqmax.a (AIX の場合) =/opt/mqm/lib/libmqmax.a (Solaris の場合) HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F |
|
CB | IBM Component Broker |
AXLIB=somtrx1i (Windows の場合) =libsomtrx1 (UNIX ベースのシステムの場合) HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F |
|
SF | IBM San Francisco |
AXLIB=ibmsfDB2 HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F |
|
TUXEDO | BEA Tuxedo |
AXLIB=libtux HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F |
|
MTS | Microsoft Transaction Server |
| MTS 用に DB2 を構成する必要はありません。 MTS は DB2 の ODBC ドライバーによって自動的に検出されます。 |
JTA | Java Transaction API |
| IBM WebSphere などの Enterprise Java Server (EJS) 用に DB2 を 構成する必要はありません。 DB2 の JDBC ドライバーは、この環境を自動的に検出します。 |
db2 update dbm cfg using tp_mon_name CICS「領域 (Region)」->「リソース (Resources)」->「製品 (Product)」->「XAD」 ->「リソース・マネージャー初期化ストリング (Resource manager initialization string)」で、 CICS に対して定義された各データベースごとに以下のように指定します。
db=dbalias,uid=userid,pwd=password
db=dbalias,uid=userid,pwd=password,tpm=cics
db2 update dbm cfg using tp_mon_name MQ「領域 (Region)」->「リソース (Resources)」->「製品 (Product)」->「XAD」 ->「リソース・マネージャー初期化ストリング (Resource manager initialization string)」で、 CICS に対して定義された各データベースごとに以下のように指定します。
uid=userid,db=dbalias,pwd=password
uid=userid,db=dbalias,pwd=password,tpm=mq
pwd=password,uid=userid,tpm=cics,db=dbalias
db=dbalias,uid=userid,pwd=password,tpm=mq
db2 update dbm cfg using tp_mon_name myaxlibその後、XA TM に定義されている各データベースごとに、 xa_open ストリングを以下のように指定します。
db=dbalias,uid=userid,pwd=password
db=dbalias,uid=userid,pwd=password,axlib=myaxlib
db=dbalias,uid=userid,pwd=password,axlib=myaxlib,chain_end=T
db=dbalias,uid=userid,pwd=password,axlib=myaxlib,chain_end
以前のバージョンの DB2 は、ここで説明する xa_open ストリング形式を使用します。 この形式は、互換性のためにサポートされています。 可能な限り、 アプリケーションを新しい形式 (DB2 バージョン 7 での新しい xa_open ストリング形式を参照) に移行してください。
各データベースは、トランザクション・マネージャー (TM) に対して 別個のリソース・マネージャー (RM) として定義されているので、 次の構文の xa_open ストリングによってデータベースを識別する必要があります。
"database_alias<,userid,password>"
database_alias は必須であり、データベースの別名を指定するものです。 データベース作成後に明示的に別名をカタログ化したのでない限り、 この別名はデータベース名と同じになります。 ユーザー名とパスワードは任意指定であり、認証方式によっては、 データベースに認証情報を提供するのに使用します。
データベースをリソース・マネージャーとして設定する場合、 xa_close ストリングは必要ありません。 このストリングを指定しても、 データベース・マネージャーによって無視されます。
XA トランザクション・マネージャーのアーキテクチャーによっては、 ホストおよび AS/400 データベース・サーバーを更新することができます。 異なるプロセスからの連続コミットをサポートするには、 DB2 コネクト・コンセントレーターが使用可能でなければなりません。 DB2 コネクト EE コンセントレーターを使用可能にするには、 データベース・マネージャー構成パラメーター max_logicagents を、 maxagents より大きな値に設定します。 異なるプロセスからの連続 XA コミットを DB2 コネクト EE コンセントレーターが サポートするためには、 DB2 バージョン 7.1 クライアントが必要であることに注意してください。 この環境で使用できる SQL ステートメントについては、 アプリケーション開発の手引き を参照してください。 コンセントレーターについては、DB2 コネクト 使用者の手引き を参照してください。
ホストまたは AS/400 データベース・サーバーを更新する場合は、 DB2 同期点マネージャー (SPM) が構成されている DB2 コネクトが必要です。 詳しくは、概説およびインストール を参照してください。
このセクションでは、次のトピックについて説明します。
RELEASE ステートメントを用いてデータベースへの接続を解放する場合は、 SET CONNECTION ではなく CONNECT ステートメントを用いてそのデータベースに再接続してください。
区分データベース環境では、 ユーザー・データが複数のデータベース区画にまたがって分散されることがあります。 このデータベースにアクセスするアプリケーションは、 データベース区画 (調整プログラム・ノード) のいずれかに接続し、要求を送信します。 異なったアプリケーションが異なったデータベース区画に接続することや、 同じアプリケーションが異なった接続について異なったデータベース区画を選択することができます。
区分データベース環境のデータベースに対するトランザクションについては、 同一の データベース区画から、 すべてのアクセスが行われなければなりません。 つまり、 トランザクションの開始からそのトランザクションがコミットされる時まで (この時点も含む)、 同じデータベース区画を使用しなければならないということです。
区分データベースに対するトランザクションは、 切断前にコミットされる必要があります。
XA 準拠のトランザクション・マネージャー (トランザクション処理モニター) は、 2 フェーズ・コミット・プロセスについてで説明されているように、 DB2 トランザクション・マネージャーが使用するのと同様な 2 フェーズ・コミットを使用します。 これら 2 つの環境の主な違いは、 DB2 トランザクション・マネージャーおよびトランザクション・マネージャー・データベースの機能の代わりに、 TP モニターがトランザクションのロギングや制御の機能を提供することです。
DB2 トランザクション・マネージャーについて論じられたエラー (2 フェーズ・コミット時の問題を回復する参照) と同様のエラーが、 XA 準拠のトランザクション・マネージャー使用中にも起きることがあります。 DB2 トランザクション・マネージャーと同様、 XA 準拠のトランザクション・マネージャーは未確定トランザクションの再同期を試行します。
何らかの理由で、 トランザクション・マネージャーが自動的に未確定トランザクションを解決するまで待てない場合は、 未確定トランザクションを手動で解決するための措置がいくつかあります。 この手動の処理は、「発見的手法の決定」と呼ばれることもあります。
(WITH PROMPTING オプションとともに) LIST INDOUBT TRANSACTIONS コマンドを使用して、 または関連する API のセットを使用して、未確定トランザクションの照会、 コミット、およびロールバックを行うことができます。 さらに、ログ・レコードを削除してログ・スペースを解放することにより、発見的 手法でコミットまたはロールバックされたトランザクションを「忘れる」こともできます。 UNIX ベースのシステム、Windows オペレーティング・システム、 または OS/2 の DB2 UDBから未確定トランザクション情報を得るには、 データベースに接続し、 LIST INDOUBT TRANSACTIONS WITH PROMPTING コマンドまたは これに対応する API を発行します。 このコマンドまたは関連する管理 API については、 コマンド解説書 または 管理 API 解説書 を参照してください。
ホストまたは AS/400 データベース・サーバーに関連した未確定トランザクション情報は、 以下の 2 つの方法のいずれかで取得できます。
DB2 (OS/390 版) から未確定情報を直接取得するには、 DISPLAY THREAD TYPE(INDOUBT) コマンドを呼び出します。 発見的手法を使用するには、RECOVER コマンドを使用します。 DB2 (OS/400 版) から未確定情報を直接取得するには、 wrkcmtdfn コマンドを呼び出します。
DB2 コネクト・サーバーから未確定情報を取得するには、 まず、データベース・マネージャー構成パラメーター spm_name の値で 示される DB2 インスタンスに接続することによって、 DB2 同期点マネージャーに接続します。 次に、未確定トランザクションを表示して発見的手法を使用するために、 LIST DRDA INDOUBT TRANSACTIONS WITH PROMPTING コマンドを発行します。
これらのコマンド (または関連する API) は、あくまでも最後の手段として、 細心の注意 を払って使用してください。 最善の方法は、トランザクション・マネージャーが再同期操作を始めるまで待つことです。 ある参加データベースでは手動でコミットまたはロールバックを行い、 別の参加データベースでは正反対の処置を取るならば、 データ保全の問題が生じかねません。 データ保全の問題から回復するには、 アプリケーション論理を理解し、変更またはロールバックされたデータを識別して、 次いで所定時間内にデータベースを回復するか、 または手動で変更の取り消し (またはやり直し) をする必要があります。
トランザクション・マネージャーが再同期を開始するまで待てず、 かつ未確定トランザクションに結び付けられているリソースを解放しなければならない場合は、 発見的手法の操作が必要です。 このような状況は、 トランザクション・マネージャーが長時間使用できないために再同期を実行することができず、 緊急に必要なリソースが未確定トランザクションによって拘束されている場合に発生する可能性があります。 トランザクション・マネージャーまたはリソース・マネージャーが使用不能になる前に未確定トランザクションに関連していたリソースは、 依然としてそのトランザクションに結び付けられています。 データベース・マネージャーの場合、これらのリソースには、表や索引のロック、ログのスペース、 およびそのトランザクションにより占有されている記憶域などが含まれます。 各未確定トランザクションごとに、 データベースで処理できる並行トランザクションの最大数も (1 つずつ) 減っていきます。
発見的手法の操作を行う単純明快な方法というものはありませんが、 一般的な指針を以下に示します。
発見的手法でコミットまたはロールバックされたトランザクションが原因で ログ満杯状態が発生した場合 (LIST INDOUBT TRANSACTIONS コマンドからの出力に示される) を除き、 発見的手法の forget 関数は実行しないでください。 発見的手法の forget 関数を実行すると、 未確定トランザクションが占有していたログ・スペースが解放されます。 つまり、トランザクション・マネージャーが この未確定トランザクションに関して再同期操作を実行すると、 このリソース・マネージャーにはトランザクションのログ・レコードがないために、 他のリソース・マネージャーのコミットやロールバックを行うという 間違った決定を下す危険性があります。 一般に、ログ・レコードが「欠落」しているということは、 リソース・マネージャーがトランザクションをロールバックしたことを暗示します。
TP モニターは一連のサーバー・プロセスを事前に割り振り、 それらのサーバー・プロセスの ID 下で異なるユーザーからトランザクションを実行します。 データベース側からすれば、各サーバー・プロセスは、 そのサーバー・プロセスに関連した同じ ID で実行中の多くの作業単位を持つ 1 つの巨大なアプリケーションのように見えます。
たとえば、CICS を使用している AIX 環境では、TXSeries CICS 領域が始動すると、 その領域は定義されている AIX ユーザー名に関連付けられます。 すべての CICS アプリケーション・サーバー・プロセスも、 この TXSeries CICS の「マスター」ID (通常 "cics" と定義されている) で実行されます。 CICS ユーザーは DCE ログイン ID で CICS トランザクションを呼び出すことができ、 CICS にいる間は、CESN サインオン・トランザクションを使用して ID を変更することもできます。 どちらの場合も、RM にはエンド・ユーザーの ID を使用できません。 結果として、CICS アプリケーション・プロセスは多くのユーザーの代行としてトランザクションを実行することになりますが、 RM からは、それらが同じ "cics" ID の多くの作業単位を伴う単一プログラムのように見えます。 オプションとして xa_open ストリングにユーザー ID とパスワードを指定すると、 データベース接続時には、"cics" ID ではなくそのユーザー ID が使用されます。
静的 SQL ステートメントの場合は、エンド・ユーザーの特権ではなく、 バインド側の特権を使用してデータベースにアクセスするので、あまり影響はありません。 ただし、これは、データベース・パッケージの EXECUTE 特権を エンド・ユーザー ID ではなくサーバー ID に与える必要がある というわけではありません。
実行時にアクセス確認を行う動的ステートメントの場合は、 データベース・オブジェクトへのアクセス特権は、 それらのオブジェクトの実際のユーザーではなく、 サーバーの ID に付与する必要があります。 データベースによって特定のユーザーのアクセスを制御するのではなく、 TP モニター・システムを利用して、 どのユーザーがどのプログラムを実行できるかを判別する必要があります。 サーバー ID には、SQL ユーザーが必要とするすべての特権を付与することが必要です。
だれがデータベース表または視点にアクセスしたかを調べるためには、 以下のステップを実行することができます。
TP モニター環境を設定する場合は、次の構成パラメーターを考慮してください。
このデータベース・マネージャー構成パラメーターは、 使用される TP モニター製品の名前を識別します (たとえば CICS や ENCINA)。
このデータベース・マネージャー構成パラメーターは、 データベース・クライアントが APPC 通信プロトコル使用してデータベース・サーバーに割り振り要求を出すときに、 使用しなければならないリモート・トランザクション・プログラムの名前を指定します。 値はサーバーの構成ファイルで設定されます。 この値は SNA トランザクション・プログラムに構成されている トランザクション・プロセッサー (TP) の名前と同じでなければなりません。 詳細については、概説およびインストール を参照してください。
DB2 は XA 環境でトランザクションを調整しない ので、 このデータベース・マネージャー構成パラメーターは、 XA 調整済みトランザクションには使用されません。
このデータベース構成パラメーターには、 活動状態のアプリケーションの許容最大数を指定します。 このパラメーターの値は、接続されるアプリケーションの合計数に、 2 フェーズ・コミットまたはロールバックを同時に完了しようとする 可能性のあるアプリケーションの数を加えた値より大きいか等しくなければなりません。 さらに、任意の時点で存在する可能性のある未確定トランザクションの数を、 この合計に加算してください。 未確定トランザクションについて詳しくは、2 フェーズ・コミット時の問題を回復するを参照してください。
TP モニター環境 (たとえば TXSeries CICS) の場合は、 maxappls パラメーターの値を大きくする 必要があるかもしれません。 こうすれば、すべての TP モニター・プロセスを確実に記憶できるようになります。
このデータベース構成パラメーターには、 必要に応じて RESTARTDATABASE ルーチンを自動的に呼び出すかどうかを指定します。 省略時値は YES (呼び出す) です。
未確定トランザクションが含まれているデータベースは、 データベースの再始動操作によって始動する必要があります。 データベースへの最後の接続が除去される ときに autorestart が使用可能でない場合、 その次の接続は失敗し、再び RESTART DATABASE を明示的に呼び出す必要があります。 この状態は、トランザクション・マネージャーの再同期操作によって、 または手動による管理者の発見的手法の操作によって、 未確定トランザクションが除去されるまで続きます。 RESTART DATABASE コマンドが発行されるとき、 データベースに未確定トランザクションが存在していれば、メッセージが戻されます。 管理者は、 LIST INDOUBT TRANSACTIONS コマンドなどのコマンド行プロセッサーのコマンドを使用することによって、 それらの未確定トランザクションについての情報を検索できます。
DB2 ユニバーサル・データベースは、 X/Open CAE Specification Distributed Transaction Processing: The XA Specification で定義されている XA91 仕様をサポートしますが、以下は例外です。
XA 仕様では、インターフェースで非同期サービスを使用することができます。 このサービスを使用すると、要求の結果を後で調べることができます。 データベース・マネージャーでは、要求を同期モードで呼び出す必要があります。
XA インターフェースでは、静的登録と動的登録という 2 つの RM 登録方法が可能です。 DB2 ユニバーサル・データベースは、 より高機能で効率的な動的登録のみをサポートしています。 これら 2 つの方法についての詳細は、リソース・マネージャー (RM) を参照してください。
DB2 ユニバーサル・データベースは、 制御スレッド間のトランザクション移行をサポートしていません。
xa_open ストリングおよび xa_close ストリングの使用法については、 xa_open および xa_close ストリングの使用法を参照してください。
XA インターフェースとして必要とされるものとして、データベース・マネージャーには、 XA スイッチ構造体を TM に戻すために使う xa_switch_t 型の外部 C 変数 db2xa_switch が用意されています。 さまざまな XA 関数のアドレス以外に、以下のフィールドが返されます。
DB2 ユニバーサル・データベースが動的登録を使用し、 TM は関連の移行を使用してはならないことを明示的に示します。 非同期操作がサポートされないことを暗黙的に示します。
XA アーキテクチャーでは、 XA トランザクション・マネージャー (TM) が リソース・マネージャー (RM) の xa_ ルーチンに アクセスできるようにするスイッチ を、 RM が提供しなければなりません。 RM のスイッチは、xa_switch_t と呼ばれる構造体を使用します。 スイッチには、RM の名前、RM の XA 入り口点への 非空ポインター、フラグ、 およびバージョン番号が含まれます。
DB2 UDB のスイッチは、以下の 2 つの方法のいずれかによって得られます。
#define db2xa_switch (*db2xa_switch)
しかし、これは db2xa_switch を使用する前に行います。
DB2 UDB は、 db2xa_switch 構造体のアドレスを戻すこの API を提供します。 この関数のプロトタイプは次のとおりです。
struct xa_switch_t * SQL_API_FN db2xacic( )
いずれの場合も、libdb2 (UNIX ベースの システム) または db2api.lib (OS/2) を使用して、 アプリケーションをリンクする必要があります。
xa_switch 構造体 db2xa_switch を示すポインターは DLL データとしてエクスポートされます。 したがって、この構造体を使用する Windows NT アプリケーションは、 次の 3 つのいずれかの方法でこれを参照する必要があります。
#define db2xa_switch (*db2xa_switch)ただし、これは db2xa_switch を使用する前に行います。
extern __declspec(dllimport) struct xa_switch_t db2xa_switch
DB2 UDB は、 db2xa_switch 構造体のアドレスを戻すこの API を提供します。 この関数のプロトタイプは次のとおりです。
struct xa_switch_t * SQL_API_FN db2xacic( )
いずれの方式でも、 db2api.lib を使用してアプリケーションをリンクする必要があります。
以下のコードは、 任意の DB2 UDB プラットフォーム上の C プログラムで db2xa_switch にアクセスするいくつかの方法を示しています。 必ずアプリケーションを適切なライブラリーとリンクしてください。
#include <stdio.h> #include <xa.h> struct xa_switch_t * SQL_API_FN db2xacic( ); #ifdef DECLSPEC_DEFN extern __declspec(dllimport) struct xa_switch_t db2xa_switch; #else #define db2xa_switch (*db2xa_switch) extern struct xa_switch_t db2xa_switch; #endif
main( ) { struct xa_switch_t *foo; printf ( "%s \n", db2xa_switch.name ); foo = db2xacic(); printf ( "%s \n", foo->name ); return ; }
TM からの XA 要求時にエラーが検出された場合、 アプリケーション・プログラムは TM からそのエラー・コードを入手することはできません。 ご使用のプログラムが異常終了したり、 TP モニターまたは TM からの暗号戻りコードを受け取ったりした場合、 基本障害保守ログを調べてください。 診断レベルが 3 以上であればここに XA エラー情報が報告されています。 基本障害保守ログの詳細について、問題判別の手引き を参照してください。
その他に、コンソール・メッセージ、TM エラー・ファイル、 またはご使用の外部トランザクション処理ソフトウェア製品固有の情報も調べてください。
データベース・マネージャーは、XA 固有のエラーを基本障害保守ログに書き込み、 その際 SQLCODE -998 (トランザクションまたは発見的手法のエラー) と該当する理由コードを指定します。 最も一般的なエラーには、以下のようなものがあります。
以下の例は、 (xa_open ストリングがないために) AIX で生成される xa_open エラーの エラー・ログを示しています。
Tue Apr 4 15:59:08 1995 toop pid(83378) process (xatest) XA DTP Support sqlxa_open Probe:101 DIA4701E Database "" could not be opened for distributed transaction processing. String Title : XA Interface SQLCA pid(83378) SQLCODE = -998 REASON CODE: 4 SUBCODE: 1 Dump File : /u/toop/diagnostics/83378.dmp Data : SQLCA