|
|
|
|
|
|
MIB(5)
名前
MIB-管理情報ベース
#include <fml32.h>
#include <fml1632.h> /* Optional */
#include <tpadm.h>
#include cmib.h> /* Component MIB Header */
機能説明
BEA Tuxedo システムのアプリケーションは、いくつかの異なるコンポーネント (BEA Tuxedo、Workstation など) で構成され、それぞれのコンポーネントはそのコンポーネントのために特別に定義された管理情報ベース (MIB) を利用して管理されます。これらのコンポーネントの MIB は、それぞれ、システムの特定の部分に対応した MIB 関連のマニュアル・ページで定義されています。たとえば、TM_MIB(5) のマニュアルでは、BEA Tuxedo アプリケーションの基本的な側面を管理するために使用される MIB について定義しています。
ただし、これらのコンポーネントの MIB は、必要なアクセス手段を提供するための関連インターフェイスについて十分に定義したものであるわけではありません。MIB(5) のマニュアル・ページでは、管理者、オペレータ、あるいはユーザが定義されているコンポーネント MIB と対話するための共通のインターフェイスについて説明したものです。BEA Tuxedo システムの MIB に対する共通のインターフェイスは、2 つの主要な部分から成り立っています。
共通のインターフェイスの最初の部分は、コンポーネント MIB をサポートするための管理サービスへのアクセス手段を提供する際に、BEA Tuxedo システムで現在使用しているインターフェイスがどのように使用されるかを説明したものです。BEA Tuxedo システムのバッファ・タイプの 1 つであるFML32は、コンポーネント MIB に入力データを渡したり、コンポーネントMIBから出力データを受け取ったりするための「入れ物」として使用されます。ATMI 要求/応答関数は、コンポーネント MIB に対するインターフェイスとして使用され、システムが提供するサービスとして組み込まれています。管理ユーザとコンポーネント MIB と間でFML32バッファの ATMI 関数を利用して行われるやりとりについては、このマニュアルの「FML32」および「ATMI」の各セクションで詳しく説明します。
共通なインターフェイスのもう一つの部分は、あらゆるコンポーネント MIB との間のやりとりで使用される FML32 の追加の入出力フィールドについて説明したものです。FML32 の追加のフィールドを利用した場合は、要求の機能を拡張でき (操作コードの指定などが可能になる)、新たな応答属性 (エラー・コードや説明文など) の使用が可能になるといった効果が得られます。FML32 の追加フィールドについては、このマニュアルの「入力」および「出力」のセクションで詳しく説明します。
「使用方法」のセクションでは、管理を目的としたコンポーネント MIB との対話に利用できる既存の ATMI 関数や追加の FML32 フィールドの使用例を示します。
また、このマニュアル・ページでは、アプリケーションを管理する際のユーザとコンポーネント MIB との対話方法を定義するだけでなく、コンポーネント MIB に関するマニュアルで使用されるクラス定義の形式についても明らかにします (「クラス記述」を参照のこと) 。
このリファレンス・ページでは、T_CLASS と T_CLASSATT という 2 つの共通のクラスを定義しています。これら 2 つのクラスは、管理のためのクラスを識別し、クラスや属性のパーミッションを調節するために使用されます。MIB(5) のすべてのクラス定義に関連する追加情報については、「MIB(5) に関する追加情報」を参照してください。「診断」のセクションでは、コンポーネント MIB のシステム・サービスが返す可能性のあるエラー・コードのリストを示します。
認証
ユーザがアプリケーションに結合しようとすると、その権限があるかどうかの認証が行われます (tpinit(3c) を参照)。tpinit() の実行時に、管理者およびオペレータは tpsysadm または tpsysop のクライアント名を持つアプリケーションに結合するよう求めることができます。この 2 つの cltname 値は保存され、アプリケーションの管理者とオペレータにしか関連付けられません。
アプリケーションを最初に環境設定する管理者が、特定のセキュリティ・タイプを選択することでセキュリティのレベルを決定します。以下のセキュリティ・タイプから選択できます。
セキュリティ・タイプを選択すると、管理者やオペレータがAdminAPIを介してコンポーネント MIB にアクセスする際の柔軟性とセキュリティが決まります。
最も確実で柔軟なセキュリティ・タイプは、アプリケーション・パスワード + アプリケーション固有認証サーバ (AUTHSVR(5)参照) です。この方法では、ユーザが適切なパスワードを認証サーバに提供すれば、管理者は任意のユーザまたは指定されたユーザにアクセスを許可することができます。
アプリケーション固有の認証サーバがない場合、管理者またはオペレータの特別なパーミッションを得るためには、クライアントはアプリケーションの認証要求 (「セキュリティなし」または「アプリケーション・パスワードによる認証」のどちらか) を満たし、TPINIT構造体のcltnameフィールドに特別なクライアント名の1つを指定し、さらにローカル UNIX システムの BEA Tuxedo 管理者で実行する必要があります。いずれの場合も、正常に結合されたクライアントにはシステムによってキーが割り当てられます。このキーは、クライアントが行なうすべての要求に対して与えられます。tpsysadmまたはtpsysopとして正しく認証されたクライアントは、このクライアントが特別な特権を持っていることをシステムに知らせる認証キーが割り当てられます。
管理者としての認証は、指定に従って、APIにアクセスする前にシステムに結合するクライアントにしか適用されません。APIを利用するサーバは、このサーバがサービスするクライアントと同様に扱われます。tpsvrinit()、tpsvrdone() から行われるサービス要求は管理者からの要求として処理されます。
FML32
BEA Tuxedo システムが定義したコンポーネントMIBを使用するアプリケーション管理は、FML32バッファタイプを介してしかサポートされません。MIB情報にアクセスするアプリケーション・プログラムは、FML32型付きバッファの割り当て、処理、更新を行なうように書かれていなければなりません。FML32 を使用する 2 通りの方法については、Fintro() で詳述していますが、ここで要約します。
FML32 にインターフェイスする最も直接的な方法は、標準の <fml.h> ヘッダ・ファイルではなく <fml32.h> ヘッダ・ファイルをインクルードし、次に『BEA Tuxedo FML リファレンス』で指定されている関連の各 FML インターフェイスの FML32 バージョンを使用する方法です。たとえば、Fchg() の代わりに Fchg32() を使用します。
FML32 にインターフェイスするもう 1つの方法は、<fml32.h>と<fml1632.h>の両方のヘッダ・ファイルをインクルードする方法です。この 2 つのヘッダ・ファイルは共同して機能し、ユーザはベースの FML インターフェイス (たとえばFchg()) に合わせてプログラミングできますが、実際には各インターフェイスの FML32 バージョンが呼び出されるようにします。
ATMI
アプリケーション・プログラムは、FML32型付きバッファを割り当て、要求されたデータをそのバッファに入れ、サービス要求を送出し、サービス要求に対する応答を受け取り、その応答から結果に関する情報を取り出すことによって、コンポーネント MIB 固有の属性情報のアクセスや更新を行います。FML32型付きバッファへ情報を入れたり取り出したりする操作には、前述したFML32インターフェイスが関わります。バッファの割り当て、要求の送出と応答の受信は、下記の汎用 ATMI ルーチンを使い該当する指針と制約の範囲内で行なわれます。すべてのコンポーネントに対するMIB要求は、コアのシステム/TコンポーネントMIBサービス、".TMIB" に送出する必要があります。このサービスは、TM_MIB(5) 要求を処理するエージェントとしての役割を果たすほか、他のコンポーネント MIB に対する要求を転送します。これで、ユーザ側ではサービス名を MIB やクラスとマッチングしなくても済みます。
入力
BEA Tuxedo システムの任意の MIB に対する管理要求を特徴付けたり制御したりするときに使われる複数のFML32 フィールドがあります。これらのフィールドはヘッダ・ファイル <tpadm.h> にはもとより、このマニュアル・ページにも定義されています。対応するフィールド・テーブルは、${TUXDIR}/udataobj/tpadm にあります。これらのフィールドは、管理サービス要求を行なう前に必要なコンポーネントMIB固有のフィールドのほかに、FML32 要求バッファにも付加されます。これらのフィールドについて以下に説明し、そのあとで、各フィールドが必須指定、任意指定、または未使用のコマンドをまとめて表に示します。
次表において、R は必須入力属性、O はオプションの入力属性、− は使用されない入力属性です。
|
属性 |
タイプ |
GET |
GETNEXT |
SET |
|---|---|---|---|---|
|
TA_OPERATION |
string |
R |
R |
R |
|
TA_CLASS |
string |
R |
− |
R |
|
TA_CURSOR |
string |
− |
R |
− |
|
TA_OCCURS |
long |
O |
O |
− |
|
TA_FLAGS |
long |
O |
O |
O |
|
TA_FILTER |
long |
O |
− |
− |
|
TA_MIBTIMEOUT |
long |
O |
O |
O |
|
TA_CURSORHOLD |
long |
O |
O |
− |
出力 正常終了した管理要求からの出力は、1つまたは複数のMIB固有オブジェクトと共通の出力フィールドの1オカレンスからなります。通常、複数のMIB固有オブジェクトは、返された各クラス属性の複数のオカレンスによって出力に反映されます。各属性のオカレンス 0 は最初のオブジェクトに関連し、オカレンス1は2番目のオブジェクトに関連するという風に順次関連します。この指針の例外はコンポーネントMIBのマニュアル・ページに記載されています。FML32定義の NULL フィールド値を操作実行後に持つことがあります。SET 操作が正常終了すると、操作実行後のオブジェクトを反映する単一オブジェクトが返されます。GET 操作やGETNEXT 操作が正常終了すると、要求されたオカレンス数 (下記の TA_OCCURSを参照) や MIB 固有システム・サービス内の指定されたキー・フィールドおよびスペース制限と一致したオカレンス数に応じて、0 またはそれ以上のオカレンスが返されます。 重要なのは、オブジェクトの状態、相互運用的なリリース環境、入力要求フィルタによっては、任意のクラスに対して定義されたすべての属性がどの要求についても返されるわけではないということです。管理プログラマは、出力バッファ内にある属性が存在するものと思うのではなく、属性値の存在を明示的に確認する必要があります。 繰り返しますが、正常に処理された管理要求は、すべてのMIBに適用するある共通のフィールドを含んでいます。このフィールドはヘッダ・ファイル<tpadm.h>に定義されています。対応するフィールド・テーブルは、${TUXDIR}/udataobj/tpadm にあります。共通の応答フィールドは応答バッファに追加され、コンポーネントMIB固有フィールドで返されます。以下に各共通応答フィールドについて説明します。
MIB固有システムサービス処理内で失敗した管理要求は、アプリケーション・サービス・エラーをアプリケーションに返します。これには、元々の要求とエラーの特徴を示す共通のフィールドが含まれています。アプリケーション・サービス・エラーは、tpcall() またはtpgetrply() からの TPESVCFAILエラー・リターンによって示されます。TMQFORWARD(5)サーバを介して返されたアプリケーション・サービス・エラーは、元の要求で指定されたエラー・キューに入ります (サーバのコマンドラインで-dが指定されたと仮定して)。失敗した管理要求の特徴を示す共通のフィールドを以下に示します。
使用方法
インクルード・ファイル
コンポーネント MIB とインターフェイスするために書かれたアプリケーション・プログラムは一定のヘッダ・ファイルをインクルードする必要があります。<fml32.h> は、FML32 型付きバッファのアクセスおよび更新に必要なマクロ、構造体、および関数のインターフェイスを定義します。<fml1632.h> は、汎用 FML インターフェイスのマクロ、構造体、および関数から FML32 バージョンへのマッピングを定義します。このヘッダ・ファイルのインクルードは任意です。<tpadm.h> は、このマニュアル・ページに記載されている FML32 フィールド名を定義します。さらに、任意のコンポーネント MIB 固有ヘッダ・ファイルをインクルードして、そのコンポーネント MIB に固有の FML32 フィールド定義にアクセスできるようにする必要があります。
例:
#include <fml32.h>
#include <tpadm.h>
#include <cmib.h> /* コンポーネント MIB ヘッダ */
バッファの割り当て
コンポーネント MIB と対話するためには、FML32 型付きバッファが該当するサービスに要求を送ることが必要です。ATMI 関数 tpalloc() は、FMLTYPE32 (<fml32.h> に定義されている) を使用してバッファをtype 引数の値に割り当てます。FML32 バッファのサブタイプは存在しないので、tpalloc() の subtype 引数は NULL になる場合があります。FML32 バッファのデフォルトの最小サイズは 1024 バイトです。tpalloc() の size 引数に 0 を指定すると、最小サイズのバッファが割り当てられます。これより大きなバッファが必要な場合には、システム最小値より大きな値をsizeに指定することで割り当てることができます。
例:
rqbuf = tpalloc(FMLTYPE32, NULL, 0);
MIB 要求の作成
FML32 型付きバッファが割り当てられたら、ユーザはそのバッファに共通の MIB フィールドの値とコンポーネント MIB 固有の値を入れる必要があります。要求バッファに値を追加するときに使用する最も一般的なインターフェイスは、Fadd32() とFchg32() です。要求バッファがいっぱいでフィールドを追加できない場合は、ATMI 関数 tprealloc() を使ってバッファを再割り当てする必要があります。
例:
/*
* エラー処理は含まない。bigger_size はシステム側で提供されるのではなく、
* ユーザ側で指定。バッファを再利用する場合は、Fchg32 を使用して、
* フィールド・オカレンス 0 が設定されるようにする。
*/
if (Fchg32(rqbuf, TA_MIBFIELD, 0, "ABC", 0) == -1) {
if (Ferror32 == FNOSPACE) {
rqbuf = tprealloc(rqbuf, bigger_size);
Fchg32(rqbuf, TA_MIBFIELD, 0, "ABC", 0);
}
}
MIB 要求の制御
各コンポーネント MIB に固有の属性のほかに、コンポーネント MIB から要求された操作を制御する必須および任意の属性があります (それらの属性はこのマニュアル・ページに定義されています)。
必須の共通属性は TA_OPERATION と TA_CLASS の 2 つです。
TA_OPERATION は、アクセスされる MIB 上で行われる操作を指定します。有効な操作は GET、GETNEXT および SET です。
TA_CLASSは、アクセスする MIB クラスを指定します。クラス名はコンポーネント MIB マニュアル・ページに定義されています。TA_OPERATION が GETNEXTの場合には、さらに TA_CURSOR 属性も必要です。TA_CURSOR は直前の GETまたは GETNEXT 操作で返されたフィールドです。このフィールドは、このあとの要求時に検索位置を調べるときにシステムが使用します
任意属性の TA_OCCURS、TA_FLAGS、TA_FILTER、TA_MIBTIMEOUT、および TA_CURSORHOLD は、要求をさらに細かく指定するときに必須属性に加えて使用することができます。
例:
/* 最初の 5 オブジェクトを取得 (GET)。 */
Fchg32(rqbuf, TA_OPERATION, 0, "GET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "classname", 0);
n = 5;
Fchg32(rqbuf, TA_OCCURS, 0, n, 0);
/* 要求を作成。以下の「MIB 要求の送信」参照。 */
/* 応答は rpbuf に格納。カーソルも含まれる。 */
/*
* 次の 5 オブジェクトを取得 (GETNEXT)。rpbuf からTA_CURSOR を転送。
* 上で生成された rqbuf を再利用。要求後にスナップショットを破棄
* (TA_CURSORHOLD を 0 に設定)。
*/
Fchg32(rqbuf, TA_OPERATION, 0, "GETNEXT", 0);
Fchg32(rqbuf, TA_CURSOR, 0, Ffind32(rpbuf, TA_CURSOR, 0, NULL), 0);
n = 0;
Fchg32(rqbuf, TA_CURSORHOLD, 0, n, 0);
/* 要求を作成。以下の「MIB 要求の送信」参照。 */
コンポーネント MIB フィールド
GETまたはGETNEXTで指定されたコンポーネント MIB のキー・フィールドは、オブジェクトの集合を選択するときに使用されます。キー・フィールド以外のフィールドは、コンポーネント MIB では無視されます。
SET 操作で指定されたコンポーネント MIB キー・フィールドは、更新する特定のオブジェクトを識別するために使用されます。キー・フィールド以外のフィールドは、キー・フィールドによって特定されたオブジェクトの更新値として処理されます。ユーザは、更新 (SET) が許可される前に、現在のオブジェクト・イメージと一致する必要があるプレイメージを指定することもできます。ユーザは、要求の TA_FLAGS 属性の MIB_PREIMAGE ビットをセットすることでプレイメージを指定することを示します。更新するオブジェクトを指定するキー・フィールドはプレイメージ (フィールド・オカレンス 0) から取られます。キー・フィールドがポストイメージにも指定されている場合には、それらのフィールドは正確に一致していなければなりません。さもないと、要求は失敗します。クラスの一部で、かつ入力バッファで指定された 2 つの属性値をもつ属性だけが、指定されたクラス・オブジェクト用に設定する新しい値として処理されます。
例:
Fchg32(rqbuf, TA_OPERATION, 0, "GET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "classname", 0);
Fchg32(rqbuf, TA_MIBKEY, 0, "keyvalue", 0);
n = 1;
Fchg32(rqbuf, TA_OCCURS, 0, n, 0); /* GET 1st matching occurrence */
/* 要求を作成。以下の「MIB 要求の送信」参照。応答は rpbuf に格納。 */
/* rpbuf をプレイメージとして使用し、一致する場合は
* TA_MIBFIELD の値を更新。
*/
Fcpy32(newrq, rpbuf);
Fconcat32(newrq, rpbuf); /* 2 番目の一致するコピーを追加。 */
Fchg32(newrq, TA_OPERATION, 0, "SET", 0);
n = MIB_PREIMAGE;
Fchg32(newrq, TA_FLAGS, 0, n, 0);
Fchg32(newrq, TA_MIBFIELD, 1, "newval", 0); /* ポストイメージ */
/* 要求を作成。以下の「MIB 要求の送信」参照。 */
MIB要求の送信
コンポーネント MIB 要求はすべて、コア BEA Tuxedo コンポーネント MIB サービス、.TMIB を通ります。このサービスは、TM_MIB(5) 要求を処理するエージェントとしての役割を果たすほか、他のコンポーネント MIB に対する要求を転送します。これで、ユーザ側ではサービス名を MIB やクラスとマッチングしなくても済みます。サービス要求は、ATMI 内の任意の要求/応答指向サービス (tpcall()、tpacall()、tpenqueue()) を使って生成することができます。ユーザは、これらのインターフェイス関数に対して定義されたフラグと機能にアクセスできます。ここで課せられる唯一の制約は、.TMIB サービスはトランザクションの範囲外で呼び出す必要があるといることです。つまり、トランザクション内で tpcall() や tpacall() を使って管理要求を出すときに、TPNOTRAN フラグを使用しないと異常終了する (TPETRAN) ということです。tpenqueue() を使って要求を出すときには、送出されるサービス要求をトランザクション境界の外で行なうことができるように、TMQFORWARD サーバは -n オプションを指定して起動する必要があります。
例:
/* 上に示すように要求を作成。 */
/* 要求を送信し、応答を待機。 */
flags = TPNOTRAN | TPNOCHANGE | TPSIGRSTRT;
rval = tpcall(".TMIB", rqbuf, 0, rpbuf, rplen, flags);
/* 要求を送信し、記述子を取得。 */
flags = TPNOTRAN | TPSIGRSTRT;
cd = tpacall(".TMIB", rqbuf, 0, flags);
/* キューから要求を取り出す。qctl はセットアップ済みと仮定。 */
flags = TPSIGRSTRT;
rval = tpenqueue("queue", ".TMIB", qctl, rqbuf, 0, flags);
MIB 応答の受信
コンポーネントMIBからの応答は、元の要求がどのように生成されたかによって、3通りの方法で受信できます。元の要求が tpcall() で生成された場合には、tpcall() は応答が受信されたという戻り値を返します。元の要求が tpacall() で生成された場合には、tpgetrply() を使って応答を受信できます。元の要求が tpenqueue() で生成され、かつキュー制御構造体で応答キューが指定された場合には、tpdequeue() を使って応答を受信できます。これらのさまざまな呼び出し上でサポートされているフラグを適宜使用することができます。
例:
/* 上に示すように要求を作成。 */
/* 要求を送信し、応答を待機。 */
flags = TPNOTRAN | TPNOCHANGE | TPSIGRSTRT;
rval = tpcall(".TMIB", rqbuf, 0, rpbuf, rplen, flags);
/* 呼び出し記述子を使用して応答を受信。 */
flags = TPNOCHANGE | TPSIGRSTRT;
rval = tpgetrply(cd, rpbuf, rplen, flags);
/* TPGETANY をしようして応答を受信。バッファ・タイプの変更が必要な場合もあり。 */
flags = TPGETANY | TPSIGRSTRT;
rval = tpgetrply(rd, rpbuf, rplen, flags);
/* キューから要求を取り出す。qctl はセットアップ済みと仮定。 */
flags = TPNOCHANGE | TPSIGRSTRT;
rval = tpdequeue("queue", "replyq", qctl, rpbuf, rplen, flags);
MIB 応答の解釈
コンポーネント MIB に固有の属性のほかに、特定の共通 MIB フィールドが管理要求に対して返されることがあります。これらの属性は元の要求の結果の特徴を示し、必要な場合に以降の要求で使用できる値を指定します。
GET または GETNEXT 操作は、成功すると以下の値を返します。
クラス名
取り出された一致オブジェクトの数。
まだ取り出されていない一致オブジェクトの数。
以降の検索で指定するカーソル。
負以外の戻り値TAOKにセットします。
各属性のオカレンス 0 は取り出された最初のオブジェクトを表し、オカレンス1は 2 番目のオブジェクトを表すという風に対応します。この規則の例外は、コンポーネント MIB マニュアル・ページの該当する箇所に示されています。
SET 操作は、成功すると以下の値を返します。
クラス名
負以外の戻り値にセットします。TAOK は、要求は成功したが情報は更新されなかったことを示しています。変更が指定されなかったり、指定された変更がオブジェクトの現在の状態と一致したりすると、このようなことが起こる可能性があります。TAUPDATED は 、要求が成功し情報が更新されたということを示しています。TAPARTIAL は、要求は成功したが 、更新はシステム内の一部のサイトにしか行なわれなかったことを示しています。このようなことはネットワーク障害やメッセージ輻湊が原因で起こることがあり、システムは更新されていないサイトをできるだけ早く同期させます。
一度に 1 つのオブジェクトしか更新できないので、1 つのオブジェクトしか返されません。返された属性は更新後のオブジェクトを反映しています。
タイプにかかわらず、失敗した操作は以下の値を返します。
失敗の原因を示す負以外の戻り値にセットされます。共通エラー・コードはこのマニュアル・ページの診断の項に定義されています。コンポーネントMIB固有のエラー・コード (相互にも、また共通コードとも重複していない)は各MIBマニュアル・ページに定義されています。
不良フィールドのフィールド識別子。
エラー状態のテキスト記述。
制限事項
フィールドの複数オカレンスをもつ FML32 バッファは、オカレンスのシーケンス内の空きフィールドを考慮しません。たとえば、オカレンス 1 の値をセットし、オカレンス 0 がまだ存在しない場合、FML32 は FML32 が定義したヌル値でオカレンス 0 を自動的に作成します。FML32 定義の NULL 値は、数値フィールドに対しては 0、文字列フィールドに対しては長さがゼロの (ヌル) 文字列、文字フィールドに対しては '¥0' 文字です。このような制約のために、(異なる属性セットをもつオブジェクトを返すことがある) GET 操作は、オブジェクトの状態を正確に反映しないヌルの FML32 フィールドを含まないようにするために、ユーザに返されたオブジェクトの集合を人為的に解体することがあります。
DOS、Windows、および OS/2 上のワークステーション・クライアントは現在 64K の FML32 バッファにリンクされています。このため、システムは戻りバッファのサイズをバッファあたり 64K に制限しています。
COBOL は FML32 バッファタイプを限定的にしかサポートしていないので、ATMI の COBOL バージョンでは管理 API にアクセスできません。
コンポーネント MIB に対する要求はアプリケーション・トランザクションの一部にはなりえません。したがって、コンポーネント MIB に向けられ、アクティブ・トランザクション内で実行される tpcall() または tpacall() 呼び出しでは、呼び出し時に TPNOTRAN フラグを設定する必要があります。ただし、トランザクション内で ATMI 関数 tpenqueue() を使い、コンポーネント MIB への今後の送出に備えて要求をキューに入れることができます。この要求のキューへの登録はトランザクション内で起こりますが、コンポーネント MIB 内の処理は起こりません。このコンテキストでTMQFORWARD(5) を使用するためには、要求が非トランザクション・モードで MIB サービスに送出できるように、-n コマンド行オプションを指定して TMQFORWARD を起動する必要があります。コンポーネント MIB サービスは非トランザクションの性質をもっているので、要求をリトライするのではなくサービス失敗がすぐに失敗キューに送出されるように、TMQFORWARD に対して -d オプションを指定することもお薦めします。
共通 MIB フィールドとコンポーネント MIB のフィールド識別子は 6,000 〜 8,000 の範囲で割り当てられます。したがって、管理アクションとユーザ・アクションを混合する予定のアプリケーションは、必ずフィールド識別子を適切に割り当てる必要があります。
クラス記述
各クラスの説明セクションには、4 つのサブセクションがあります。
属性表の形式
前述したように各クラスは 4 つの部分からなっており、1 つは属性表です。属性表はクラス内の属性をリストし、さらに管理者、オペレータ、一般ユーザが属性を使用してアプリケーションとインターフェイスをとる方法を示しています。属性表の各属性記述には 5 つの構成要素 (名前、タイプ、パーミッション、値、デフォルト値) があります。これらの各構成要素について以下に説明します。
TA_STATE の構文
TA_STATE 属性フィールドは、定義された各クラスのメンバです。この属性の意味はクラスごとに定義されています。簡潔にするために、TA_STATE 値は多くの場合 3 文字の簡略名で指定されます。TA_STATE値の完全名が示されるときは、3 文字の簡略名は大文字で、残りの文字 (ある場合) は小文字で表します。TA_STATE 値の入力は簡略名でも完全名でも可能で、大文字/小文字は区別されます。TA_STATE 値の出力はかならず大文字の完全名です。TA_STATE 属性の使用例を以下に示します。
完全名 :ACTive
簡略名 :ACT
出力値 :ACTIVE
有効な入力値 :ACT、act、AcTiVe、active
T_CLASSクラスの定義
概要
T_CLASS クラスは、BEA Tuxedo システム・アプリケーション内の管理クラスの属性を表します。このクラスの主な用途はクラス名を識別することです。
属性表
|
VALid |
T_CLASS オブジェクトが定義されています。このクラスのすべてのオブジェクトがこの状態で存在しています。この状態は、パーミッション・チェックに際しては INActive 同等状態です。 |
制限事項
なし
T_CLASSATT クラスの定義
概要
T_CLASSATT クラスは管理属性の特性をクラス/属性ごとに表します。
属性表
|
VALid |
T_CLASSATT オブジェクトが定義されています。このクラスのすべてのオブジェクトがこの状態で存在しています。この状態は INActive と同等で、パーミッションの確認に使用されます。 |
MIB(5) に関する追加情報
制限事項
なし
診断
コンポーネントMIBとインターフェイスする際にユーザに返されるエラーには、一般的な 2 つのタイプがあります。1 つ目は、管理要求に対する応答を検索するために使用される ATMI 関数 tpcall()、tpgetrply() 、および tpdequeue() の 3 つが返すエラーです。これらのエラーについては、いずれもそれぞれの関数のリファレンス・ページに定義されています。
第 2 のタイプのエラーは、要求がその処理機能を備えたシステム・サービスに正しく渡されたのち、そのサービスが要求を処理する際に問題があると判断した場合にアプリケーション・レベルのサービス・エラーとして返されるエラーです。サービスが要求を処理する際に問題があることが判明すると、tpcall() または tpgetrply() は tperrno() を TPESVCFAIL に設定してエラーを返すとともに、最初の要求および下に示したエラーを詳しく性格づけした TA_ERROR、TA_STATUS、あるいは TA_BADFLD フィールドを含む応答メッセージを返します。TMQFORWARD(5) 経由でシステムに転送された要求に対するサービス障害が発生すると、元の要求で識別される異常終了キューに障害応答メッセージが追加されます（TMQFORWARDに対して -d オプションが指定されたと仮定します）。
管理要求の処理中にサービス・エラーが発生すると、TA_STATUS という FML32 フィールにエラーの内容について説明したテキストがセットされ、TA_ERROR という FML32 フィールドにはエラーの原因 (下記参照) を示す値がセットされます。TA_BADFLD にセットされる値については、下記のそれぞれのエラーに関する説明のなかで示します。以下のエラー・コードは、いずれも負であることが保証されています。
以下の診断コードは TA_ERROR に戻され、管理要求が正常に完了したことを示します。これらのコードはマイナスでないことが保証されています。
相互運用性
FML32 インターフェイスへのアクセス、および BEA Tuxedo システムのアプリケーション管理に使用できるコンポーネント MIB へのアクセスは、BEA Tuxedo システム・リリース 4.2.2 以降のバージョンで可能です。共通の MIB 属性を定義したヘッダ・ファイルおよびフィールド・テーブルは、BEA Tuxedo リリース 5.0 以降のバージョンで使用できます。各コンポーネントMIBに固有の相互運用性の問題については、それぞれのコンポーネントのマニュアル・ページで考察します。
移植性
BEA Tuxedo システムの MIB を使用した管理作業をサポートするために必要な既存の FML32 および ATMI 関数、さらにこのマニュアル・ページに定義するヘッダ・ファイルとフィールド・テーブルは、すべてのサポート対象ネイティブ・プラットフォームおよびワークステーション・プラットフォームで利用可能です。
使用例
共通のMIBの処理とインターフェイスする際の既存のAPIの簡単な使用例については、前述の使用方法のセクションを参照してください。詳しい使用例は、各コンポーネントMIBのマニュアル・ページで実際のコンポーネントMIBのクラスや属性を利用して説明されています。
ファイル
${TUXDIR}/include/tpadm.h、
${TUXDIR}/udataobj/tpadm
関連項目
tpacall(3c)、tpalloc(3c)、tpcall(3c)、tpdequeue(3c)、tpenqueue(3c)、tpgetrply(3c)、tprealloc(3c)、FML 関数の紹介、Fadd、Fadd32(3fml)、Fchg、Fchg32(3fml)、Ffind、Ffind32(3fml)、AUTHSVR(5)、TM_MIB(5)、TMQFORWARD(5)
『BEA Tuxedo アプリケーションの設定』
『BEA Tuxedo アプリケーション実行時の管理』
『C 言語を使用した BEA Tuxedo アプリケーションのプログラミング』
『FML を使用した BEA Tuxedo アプリケーションのプログラミング』
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|