移植性

LAUTHSVR は、Tuxedo System/T に付属のサービスとして非 Workstation プラットフォームでサポートされます。

使用例

# LAUTHSVR の使用例
*RESOURCES
AUTHSVC   "..AUTHSVC"
SECURITY  ACL

*SERVERS 
LAUTHSVR SRVGRP="AUTH" SRVID=100 
CLOPT="-A -- -f /usr/tuxedo/udataobj/tpldap"

MIB(5)

名前

MIB-管理情報ベース

#include <fml32.h> 
#include <fml1632.h> /* オプション */ 
#include <tpadm.h> 
#include <cmib.h>  /* コンポーネント MIB ヘッダ */

機能説明

ただし、これらのコンポーネントの MIB は、必要なアクセスを提供するための関連インターフェイスについて十分に定義したものではありません。この MIB(5) リファレンス・ページでは、管理者、オペレータ、あるいはユーザが、定義済みコンポーネント MIB と相互作用するための汎用的なインターフェイスを記述しています。BEA Tuxedo システムの MIB に対する汎用インターフェイスは、2 つの主要部分から構成されます。

認証

アプリケーションを最初にコンフィギュレーションする管理者が、特定のセキュリティ・タイプを選択することでセキュリティのレベルを決定します。選択できるセキュリティ・タイプは以下のとおりです。

セキュリティ・タイプを選択することで、管理者やオペレータが AdminAPI を介してコンポーネント MIB にアクセスする際の柔軟性とセキュリティが決まります。

アプリケーション固有の認証サーバが存在しない場合、クライアントはアプリケーションの認証要求 (「セキュリティなし」または「アプリケーション・パスワードによる認証」のどちらか) を満たし、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

入力

BEA Tuxedo システム MIB に対する管理要求の特徴付けや制御には、それぞれ特定の FML32 フィールドを使用します。これらのフィールドは、ヘッダ・ファイル <tpadm.h> だけでなく、このリファレンス・ページでも定義されています。対応するフィールド・テーブルは、${TUXDIR}/udataobj/tpadm にあります。これらのフィールドは、管理サービス要求を行う前に必要なコンポーネント MIB 固有のフィールドのほかに、FML32 要求バッファにも追加されます。以下ではこれらのフィールドについて説明し、最後に各フィールドが必須、任意、または未使用となる操作をまとめて表に示します。

次の表では、R は必須の INPUT 属性、O はオプションの INPUT 属性、− は使用されない INPUT 属性を示します。

出力

正常終了した管理要求からの出力は、1 つまたは複数の MIB 固有オブジェクトと汎用出力フィールドの 1 つのオカレンスからなります。通常、複数の MIB 固有オブジェクトは、返された各クラス属性の複数のオカレンスによって出力に反映されます。各属性のオカレンス 0 は 1 番目のオブジェクトに、オカレンス 1 は 2 番目のオブジェクトに関連します (オカレンス 2 以降も同様)。このガイドラインの例外は、コンポーネント MIB のリファレンス・ページに記載されています。特定の属性値が設定されていない中間オカレンスでは、プレース・ホルダとして FML32 定義の NULL フィールド値が挿入されます。SET 操作が正常終了すると、操作実行後のオブジェクトを反映した単一のオブジェクトが返されます。GET 操作または GETNEXT 操作が正常終了すると、要求されたオカレンス数 (後述の TA_OCCURS を参照) や MIB 固有システム・サービス内の指定されたキー・フィールドおよびスペース制限と一致したオカレンス数に応じて、0 またはそれ以上のオカレンスが返されます。

重要な点は、任意のクラスに対して定義されたすべての属性が、どの要求に対しても返されるわけではないことです。属性が返されるかどうかは、オブジェクトの状態、相互運用のリリース環境、入力要求フィルタによって決まります。管理プログラマは、属性値が出力バッファ内に存在することを前提にするのではなく、属性値が存在するかどうかを明示的に確認する必要があります。

繰り返しになりますが、正常に処理された管理要求には、すべての MIB に適用する汎用のフィールドが含まれています。これらのフィールドは、ヘッダ・ファイル <tpadm.h> に定義されています。対応するフィールド・テーブルは、${TUXDIR}/udataobj/tpadm にあります。汎用応答フィールドは応答バッファに追加され、コンポーネント MIB 固有フィールドで返されます。以下では、各汎用応答フィールドについて説明します。