Oracle Tuxedo のファイル形式とデータ記述方法

セクション 5 - ファイル形式、データ記述方法、MIB、およびシステム プロセスのリファレンス

テーブルとファイルの紹介

説明

このセクションでは、各種のテーブルとファイルの形式ついて説明します。

compilation(5) ページでは、アプリケーションのソース コードをコンパイルするときに必要なヘッダ ファイル、ライブラリ、および環境変数について要約しています。

このセクションには、Oracle Tuxedo システム提供のサーバの説明が含まれています。アプリケーションで Oracle Tuxedo システム提供のサーバを使用する場合は、そのアプリケーションのコンフィグレーション ファイルにそれらのサーバを指定してください。

servopts のページでは、アプリケーション サーバの CLOPT パラメータとしてコンフィグレーション ファイルに指定できるオプションについて説明します。

Oracle Tuxedo 管理情報ベースについては、MIB(5) リファレンス ページと次に示すコンポーネント MIB ページで説明します。

ACL_MIB(5)

名前

ACL_MIB - ACL の管理情報ベース

形式

#include <fml32.h>
#include <tpadm.h>

説明

Oracle Tuxedo MIB は、アクセス制御リスト (ACL) を管理するためのクラスの集合を定義します。これらのクラスに対してアクセスや変更を行う前に、SECURITY を USER_AUTH、ACL、または MANDATORY_ACL に設定して Oracle Tuxedo のコンフィグレーションを作成しておく必要があります。管理要求のフォーマットと管理応答の解釈を行うには、ACL_MIB(5) を共通 MIB リファレンス ページ MIB(5) と一緒に使用します。このリファレンス ページで説明するクラスや属性を使用し、MIB(5) の説明に従ってフォーマットした要求を使用すると、アクティブなアプリケーションの既存の ATMI インタフェースの 1 つを通じて管理サービスを要求できます。ACL_MIB(5) のすべてのクラス定義の追加情報については、「ACL_MIB(5) に関する追加情報」を参照してください。

ACL_MIB(5) は、次のクラスで構成されています。

各クラスの説明セクションには、次の 4 つのサブセクションがあります。

概要

属性表

属性の意味

制限事項

属性表の形式

前述のように、この MIB に含まれる各クラスは、4 つの部分に分けて以下に定義されています。その 1 つが属性表です。属性表はクラス内の属性のリファレンス ガイドであり、管理者、オペレータ、一般ユーザがそれらの属性を使用してアプリケーションと対話するための方法を説明しています。属性表の各属性の説明には、5 つの構成要素 (名前、型、パーミッション、値、デフォルト値) があります。各要素については、MIB(5) を参照してください。

TA_FLAGS 値

MIB(5) は、共通 TA_FLAGS 属性を定義します。この属性は long 型で、共通 MIB フラグ値とコンポーネント MIB 固有フラグ値の両方を持ちます。現時点では、ACL_MIB(5) 固有のフラグ値は定義されていません。

FML32 フィールド テーブル

このリファレンス ページで説明する属性のフィールド テーブルは、システムにインストールした Oracle Tuxedo システム ソフトウェアのルート ディレクトリからの相対パスで指定される udataobj/tpadm ファイルにあります。${TUXDIR}/udataobj ディレクトリは、FLDTBLDIR 環境変数で指定されるコロン区切りのリストにアプリケーションによって追加される必要があり、フィールド テーブル名 tpadm() は、FIELDTBLS 環境変数で指定されるカンマ区切りのリストに追加される必要があります。

制限事項

この MIB のヘッダ ファイルとフィールド テーブルには、Oracle Tuxedo リリース 6.0 以降が実行されているサイト (ネイティブとワークステーションの両方) からのみアクセスできます。

T_ACLGROUP クラスの定義

概要

T_ACLGROUP クラスは、Oracle Tuxedo アプリケーションのユーザおよびドメインのグループを表します。

属性表

属性の意味

TA_GROUPNAME: string[1..30]

TA_GROUPID: 0 <= num < 16,384

TA_STATE:

制限事項

1 人のユーザは 1 つの ACL グループにのみ関連付けることができます。複数のロールを持つユーザまたは複数のグループに関連付けられるユーザについては、複数のユーザ エントリを定義する必要があります。

T_ACLPERM クラスの定義

概要

T_ACLPERM クラスは、Oracle Tuxedo システム エントリにアクセスできるグループを表します。これらのエンティティ名は文字列です。現在この名前はサービス名、イベント名、およびアプリケーション キュー名を表しています。

属性表

属性の意味

TA_ACLNAME: string

TA_ACLTYPE: ENQ | DEQ | SERVICE | POSTEVENT

TA_ACLGROUPIDS: string

TA_STATE:

制限事項

パーミッションは、個別のユーザ識別子ではなく、グループ レベルで定義されます。

T_ACLPRINCIPAL クラスの定義

概要

T_ACLPRINCIPAL クラスは、Oracle Tuxedo アプリケーションにアクセス可能なユーザまたはドメイン、およびそれらに関連付けられるグループを表します。特定ユーザとしてアプリケーションに参加するには、ユーザ固有のパスワードを提示する必要があります。

属性表

属性の意味

TA_PRINNAME: string

TA_PRINCLTNAME: string

TA_PRINID: 1 <= num < 131,072

TA_PRINGRP: 0 <= num < 16,384

TA_PRINPASSWD: string

TA_STATE:

制限事項

1 人のユーザまたは 1 つのドメインは 1 つの ACL グループにのみ関連付けることができます。複数のロールを持つユーザまたは複数のグループに関連付けられるユーザについては、複数のプリンシパル エントリを定義する必要があります。

ACL_MIB(5) に関する追加情報

診断

ACL_MIB(5) への接続時には、2 つの一般的なタイプのエラーがユーザに返される場合があります。1 つは、管理要求に対する応答を検索する 3 つの ATMI 関数 (tpcall()、tpgetrply()、および tpdequeue()) が返すエラーです。これらのエラーは、該当するリファレンス ページの記述に従って解釈されます。

ただし、要求がその内容に対応できるシステム サービスに正常にルーティングされても、システム サービス側でその要求を処理できないと判断されると、アプリケーション レベルのサービス障害としてエラーが返されます。このような場合、tpcall() と tpgetrply() は、tperrno() を TPESVCFAIL に設定してエラーを返し、以下のようにエラーの詳細を示す TA_ERROR、TA_STATUS、および TA_BADFLD フィールドと一緒に、元の要求を含む応答メッセージを返します。TMQFORWARD(5) サーバ経由でシステムに転送された要求に対してサービス障害が発生すると、元の要求で識別される異常終了キューに障害応答メッセージが追加されます (TMQFORWARD に対して -d オプションが指定されたと見なされる)。

管理要求の処理中にサービス エラーが発生すると、TA_STATUS という FML32 フィールドにエラーの内容を説明したテキストが設定され、TA_ERROR という FML32 フィールドにはエラーの原因 (下記参照) を示す値が設定されます。以下のエラー コードは、いずれもマイナスであることが保証されています。

以下の診断コードは TA_ERROR で戻されるもので、管理要求が正常に完了したことを示します。これらのコードはマイナスでないことが保証されています。

[other]

相互運用性

このリファレンス ページで定義されているヘッダ ファイルおよびフィールド テーブルは、Oracle Tuxedo リリース 6.0 以降で利用できます。これらのヘッダやテーブルで定義するフィールドはリリースが変わっても変更されません。ただし、以前のリリースで定義されていない新しいフィールドが追加される場合があります。AdminAPI には、要求を作成するために必要なヘッダ ファイルとフィールド テーブルがあれば、どのサイトからでもアクセスできます。T_ACLPRINCIPAL、T_ACLGROUP、および T_ACLPERM クラスは、Oracle Tuxedo リリース 6.0 で追加されたものです。

移植性

Oracle Tuxedo システムの MIB を使用した管理作業をサポートするために必要な既存の FML32 および ATMI 関数、さらにこのリファレンス ページに定義するヘッダ ファイルとフィールド テーブルは、すべてのサポート対象ネイティブ プラットフォームとワークステーション プラットフォームで使用可能です。

使用例

以下に、ユーザをグループに追加し、当該グループに対するパーミッションをサービス名に追加するコードを示します。

フィールド テーブル

属性フィールド識別子にアクセスするには、フィールド テーブル tpadm が必要です。そのためには、次のようにシェルで入力します。

$ FIELDTBLS=tpadm 
$ FLDTBLDIR=${TUXDIR}/udataobj
$ export FIELDTBLS FLDTBLDIR

ヘッダ ファイル

次のヘッダ ファイルがインクルードされます。

#include <atmi.h> 
#include <fml32.h>
#include <tpadm.h>

ユーザの追加

以下のコードでは、デフォルト グループ "other" にユーザを追加します。

/* 入力バッファと出力バッファを割り当てる */ 

ibuf = tpalloc("FML32", NULL, 1000);

 obuf = tpalloc("FML32", NULL, 1000);
 
 /* 要求タイプを定義する MIB(5) 属性を設定 * 
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_ACLPRINCIPAL", 0);
 
 /* ACL_MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_PRINNAME, 0, ta_prinname, 0);
 Fchg32(ibuf, TA_PRINID, 0, (char *)ta_prinid, 0);
 Fchg32(ibuf, TA_STATE, 0, (char *)"NEW", 0);
 
 Fchg32(ibuf, TA_PRINPASSWD, 0, (char *)passwd, 0);
 
 
 /* 要求を作成 */
 if (tpcall(".TMIB", (char *)ibuf, 0, (char **)obuf, olen, 0) 0)  {
 fprintf(stderr, "tpcall failed: %s\en", tpstrerror(tperrno));
 if (tperrno == TPESVCFAIL) {
 Fget32(obuf, TA_ERROR, 0,(char *)ta_error, NULL);
 ta_status = Ffind32(obuf, TA_STATUS, 0, NULL);
 fprintf(stderr, "Failure: %ld, %s\en",
 ta_error, ta_status);
 }
 /* 追加のエラー処理 */
 }

ファイル

${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)、MIB(5)、TM_MIB(5)

『Oracle Tuxedo アプリケーションの設定』

『C 言語を使用した Oracle Tuxedo アプリケーションのプログラミング』

『FML を使用した Oracle Tuxedo アプリケーションのプログラミング』

APPQ_MIB(5)

名前

APPQ_MIB - /Q の管理情報ベース

形式

#include <fml32.h>
#include <tpadm.h>

説明

/Q MIB は、アプリケーション キューを管理するためのクラスを定義します。

管理要求のフォーマットと管理応答の解釈を行うには、APPQ_MIB(5) を共通 MIB リファレンス ページ MIB(5) と一緒に使用します。このリファレンス ページで説明するクラスや属性を使用し、MIB(5) の説明に従ってフォーマットした要求を使用すると、アクティブなアプリケーションの既存の ATMI インタフェースの 1 つを通じて管理サービスを要求できます。非アクティブなアプリケーションのアプリケーション キューは、tpadmcall() 関数インタフェースを使用して管理できます。APPQ_MIB(5) のすべてのクラス定義の追加情報については、「APPQ_MIB(5) に関する追加情報」を参照してください。

APPQ_MIB(5) は、次のクラスで構成されています。

この MIB は、サーバ キュー (TM_MIB(5) コンポーネントの T_QUEUE クラス) ではなく、アプリケーションで定義される永続的 (信頼性の高いディスクベースの) キューおよび非永続的 (メモリ内の) キュー (つまり /Q キュー) を示していることに注意してください。

各クラスの説明セクションには、次の 4 つのサブセクションがあります。

概要

属性表

属性の意味

制限事項

属性表の形式

この MIB に含まれる各クラスは、4 つの部分に分けて定義されています。その 1 つが属性表です。属性表はクラス内の属性のリファレンス ガイドであり、管理者、オペレータ、一般ユーザがそれらの属性を使用してアプリケーションと対話するための方法を説明しています。

属性表の各属性の説明には、5 つの構成要素 (名前、型、パーミッション、値、デフォルト値) があります。各要素については、MIB(5) を参照してください。

TA_FLAGS 値

MIB(5) は、共通 TA_FLAGS 属性を定義します。この属性は long 型で、共通 MIB フラグ値とコンポーネント MIB 固有フラグ値の両方を持ちます。APPQ_MIB(5) コンポーネントには、次に示すフラグ値が定義されます。これらのフラグ値は、共通 MIB フラグと一緒に使用する必要があります。

QMIB_FORCECLOSE

QMIB_FORCEDELETE

QMIB_FORCEPURGE

FML32 フィールド テーブル

このリファレンス ページで説明する属性のフィールド テーブルは、システムにインストールした Oracle Tuxedo ソフトウェアのルート ディレクトリからの相対パスで指定される udataobj/tpadm ファイルにあります。${TUXDIR}/udataobj ディレクトリは、FLDTBLDIR 環境変数で指定されるパス リスト (Windows の場合はセミコロンで区切り、それ以外はコロンで区切る) にアプリケーションによって追加される必要があり、フィールド テーブル名 tpadm() は、FIELDTBLS 環境変数で指定されるカンマ区切りのリストに追加される必要があります。

制限事項

この MIB は、Oracle Tuxedo システム 6.0 以降が実行されているサイト (ネイティブおよび Workstation の両方) からのみアクセスできます。

Oracle Tuxedo 6.0 より前のリリースが実行されているサイトがアプリケーション内でアクティブ化された場合、この MIB による管理アクセスは次のとおり制限されます。

T_APPQ クラスの定義

概要

T_APPQ クラスは、アプリケーション キューを表します。1 つのアプリケーション キュー スペースには、1 つまたは複数のアプリケーション キューが存在します。

制限事項

すべてのキー フィールドを未設定にすると、このクラスのインスタンスをすべて検索できません。反対に、1 つのアプリケーション キュー スペースを明示的に指定するには、適切なキー フィールドを指定する必要があります。これらの必須キー フィールドは、TA_APPQSPACENAME、TA_QMCONFIG、および TA_LMID です。ただし、アプリケーションの環境がコンフィグレーションされていない (TUXCONFIG 環境変数が設定されていない) 場合を除きます。この場合、TA_LMID を省略する必要があります。たとえば、tpcall() を使用して、要求で TA_APPQSPACENAME、TA_QMCONFIG、および TA_LMID 属性を設定した場合、指定したキュー スペース内のすべての T_APPQ オブジェクトが検索されます。

属性表

^a T_APPQ クラスの属性はすべてローカルです。

^b アプリケーションがコンフィグレーションされていない (TUXCONFIG 環境変数が設定されていない) 場合を除き、TA_LMID はキー フィールドとして指定する必要があります。

^c T_APPQ オブジェクトのすべての操作 (GET と SET) は、関連付けられているキュー スペースを自動的に開きます。つまり、キュー スペースの状態が OPEn または ACTive になっていない場合、暗黙的に OPEn に設定します。キュー スペースが大きいと、この操作は時間がかかります。

^d アプリケーション キューの作成後は、TA_APPQORDER を変更できません。

^e Oracle Tuxedo 8.0 以前のリリースの場合、この属性の文字列の長さは最大 78 バイトです。

^f 1 つのアプリケーション キュー スペースを明示的に指定するには、GET 操作で適切なキー フィールドを指定する必要があります。

属性の意味

TA_APPQNAME: string[1..15]

TA_APPQSPACENAME: string[1..15]

TA_QMCONFIG: string[1..78]

TA_LMID: string[1..30] (no comma)

TA_STATE:

TA_APPQORDER:

TA_CMD: shell-command-string[0..127]

TA_CMDHW: 0 <= num[bBm%]

TA_CMDLW: 0 <= num[bBm%]

TA_CMDNONPERSIST: shell-command-string[0..127]

TA_CMDNONPERSISTHW: 0 <= num[bB%]

TA_CMDNONPERSISTLW: 0 <= num[bB%]

TA_CURBLOCKS: 0 <= num

TA_CURMSG: 0 <= num

TA_DEFAULTEXPIRATIONTIME:

TA_DEFDELIVERYPOLICY:

TA_MAXRETRIES: 0 <= num

TA_OUTOFORDER: {NONE | TOP | MSGID}

TA_RETRYDELAY: 0 <= num

TA_CURNONPERSISTBYTES: 0 <= num

TA_CURNONPERSISTMSG: 0 <= num

T_APPQMSG クラスの定義

概要

T_APPQMSG クラスは、アプリケーション キューに格納されたメッセージを表します。メッセージは管理者が作成するのではなく、tpenqueue() 呼び出しによって作成されます。メッセージは、tpdequeue() 呼び出しまたは管理者によって削除されます。また、管理者はメッセージの特定の属性を変更できます。たとえば、管理者はメッセージを同一キュー スペース内の別のキューに移動したり、メッセージの優先順位を変更したりできます。

制限事項

すべてのキー フィールドを未設定にすると、このクラスのインスタンスをすべて検索できません。反対に、1 つのアプリケーション キュー スペースを明示的に指定するには、適切なキー フィールドを指定する必要があります。これらの必須キー フィールドは、TA_APPQSPACENAME、TA_QMCONFIG、および TA_LMID です。ただし、アプリケーションの環境がコンフィグレーションされていない (TUXCONFIG 環境変数が設定されていない) 場合を除きます。この場合、TA_LMID を省略する必要があります。たとえば、tpcall() を使用して、要求で TA_APPQSPACENAME、TA_QMCONFIG、および TA_LMID 属性を設定した場合、指定したキュー スペース内のすべての T_APPQMSG オブジェクトが検索されます。

属性表

^a T_APPQMSG クラスの属性はすべてローカルです。

^b アプリケーションがコンフィグレーションされていない (TUXCONFIG 環境変数が設定されていない) 場合を除き、TA_LMID はキー フィールドとして指定する必要があります。

^c T_APPQMSG オブジェクトのすべての操作 (GET と SET) は、関連付けられているキュー スペースを自動的に開きます。つまり、キュー スペースの状態が OPEn または ACTive になっていない場合、暗黙的に OPEn に設定します。キュー スペースが大きいと、この操作は時間がかかります。

^d 1 つのアプリケーション キュー スペースを明示的に指定するには、GET 操作で適切なキー フィールドを指定する必要があります。

属性の意味

TA_APPQMSGID: string[1..32]

TA_APPQNAME: string[1..15]

TA_APPQSPACENAME: string[1..15]

TA_QMCONFIG: string[1..78]

TA_LMID: string[1..30] (no comma)

TA_STATE:

TA_CURRETRIES: 0 <= num

TA_CORRID: string[0..32]

TA_EXPIRETIME:

TA_LOWPRIORITY: 1 <= num <= 100
TA_HIGHPRIORITY: 1 <= num <= 100

TA_MSGEXPIRESTARTTIME:
TA_MSGEXPIREENDTIME:

TA_MSGSIZE: 0 <= num

TA_MSGSTARTTIME:
TA_MSGENDTIME:

TA_NEWAPPQNAME: string[1..15]

TA_PERSISTENCE:

TA_PRIORITY: 1 <= num <= 100

TA_REPLYPERSISTENCE:

TA_TIME:

T_APPQSPACE クラスの定義

概要

T_APPQSPACE クラスは、アプリケーション キュー スペースを表します。アプリケーション キュー スペースとは、Oracle Tuxedo システム デバイス内の領域です。デバイスとその属性については、TM_MIB(5) の T_DEVICE クラスを参照してください。一般に、各キュー スペースには 1 つまたは複数のアプリケーション キューがあり、各キューにはメッセージが格納されます。

キュー スペースには、名前 (TA_APPQSPACENAME 属性)、キュー スペースが存在するデバイス (TA_QMCONFIG 属性)、およびデバイスが存在する論理マシン (TA_LMID 属性) によってユニークに識別されます。

キュー スペースは通常、コンフィグレーション済みのアプリケーションの中では 1 つのサーバ グループだけに関連付けられます。キュー スペース名とデバイス名は、T_GROUP オブジェクトの TA_OPENINFO 属性のコンポーネントです。

制限事項

すべてのキー フィールドを未設定にすると、このクラスのインスタンスをすべて検索できません。反対に、アプリケーション キュー スペースを 1 つでも明示的に指定するには、すべてのキー フィールドを指定する必要があります。コンフィグレーションされていない (TUXCONFIG 環境変数が未設定の) アプリケーションのコンテキストで tpadmcall() を介してローカル キュー スペースにアクセスすると、例外が 1 つ発生します。この場合、TA_LMID キー フィールドを省略する必要があります。

/Q MIB 内のすべてのオブジェクトに対する操作は暗黙的にキュー スペースを使用するため、上記のキュー スペースのアクセスに関する制限は、T_APPQ、T_APPQMSG、および T_APPQTRANS オブジェクトにも適用されます。

属性表

a. T_APPQSPACE クラスの属性はすべてローカルです。

b. アプリケーションがコンフィグレーションされていない (TUXCONFIG 環境変数が設定されていない) 場合を除き、TA_LMID はキー フィールドとして指定する必要があります。

c. T_APPQ、T_APPQMSG、および T_APPQTRANS オブジェクトのすべての操作 (GET と SET) は、関連付けられているキュー スペースを自動的に開きます。つまり、キュー スペースの状態が OPEn または ACTive になっていない場合、暗黙的に OPEn に設定します。キュー スペースが大きいと、この操作は時間がかかります。

d. キュー スペースの作成後は、TA_MAXQUEUES を変更できません。

属性の意味

TA_APPQSPACENAME: string[1..15]

TA_QMCONFIG: string[1..78]

TA_LMID: string[1..30] (no comma)

TA_STATE:

TA_BLOCKING: 0 <= num

TA_CURACTIONS: 0 <= num

TA_CURCURSORS: 0 <= num

TA_CUREXTENT: 0 <= num <= 100

TA_CURHANDLES: 0 <= num

TA_CURMEMFILTERS: 0 <= num

TA_CURMEMNONPERSIST: 0 <= num

TA_CURMEMOVERFLOW: 0 <= num

TA_CURMSG: 0 <= num

TA_CUROWNERS: 0 <= num

TA_CURPROC: 0 <= num

TA_CURQUEUES: 0 <= num

TA_CURTMPQUEUES: 0 <= num

TA_CURTRANS: 0 <= num

TA_ERRORQNAME: string[0..15]

TA_FORCEINIT: {Y | N}

TA_HWACTIONS: 0 <= num

TA_HWCURSORS: 0 <= num

TA_HWHANDLES: 0 <= num

TA_HWMEMFILTERS: 0 <= num

TA_HWMEMNONPERSIST: 0 <= num

TA_HWMEMOVERFLOW: 0 <= num

TA_HWMSG: 0 <= num

TA_HWOWNERS: 0 <= num

TA_HWPROC: 0 <= num

TA_HWQUEUES: 0 <= num

TA_HWTMPQUEUES: 0 <= num

TA_HWTRANS: 0 <= num

TA_IPCKEY: 32769 <= num <= 262143

TA_MAXACTIONS: 0 <= num

TA_MAXCURSORS: 0 <= num

TA_MAXHANDLES: 0 <= num

TA_MAXMSG: 0 <= num

TA_MAXOWNERS: 0 <= num

TA_MAXPAGES: 0 <= num

TA_MAXPROC: 0 <= num

TA_MAXQUEUES: 0 <= num

TA_MAXTMPQUEUES: 0 <= num

TA_MAXTRANS: 0 <= num

TA_MEMFILTERS: 0 <= num

TA_MEMNONPERSIST: 0 <= num [bB]

TA_MEMOVERFLOW: 0 <= num

TA_MEMSYSTEMRESERVED: 0 <= num

TA_MEMTOTALALLOCATED: 0 <= num

TA_PERCENTINIT: 0 <= num <= 100

T_APPQTRANS クラスの定義

概要

T_APPQTRANS クラスは、アプリケーション キューに関連付けられるトランザクションの実行時属性を表します。

制限事項

すべてのキー フィールドを未設定にすると、このクラスのインスタンスをすべて検索できません。反対に、1 つのアプリケーション キュー スペースを明示的に指定するには、適切なキー フィールドを指定する必要があります。たとえば、tpcall() を使用して、TA_XID を除くすべてのキー フィールドを要求で設定した場合、指定されたキュー スペースに対応する T_APPQTRANS オブジェクトがすべて検索されます。

このクラスのオブジェクトで表現されるトランザクションは必ずしも検索対象のアプリケーションに関連付けられないので注意してください。トランザクションは実際には別のアプリケーションに属していたり、別のアプリケーションに影響を与えたりする場合があるため、トランザクションをヒューリスティックにコミットまたはアボートするときには注意が必要です。TA_XID 属性の値は、アプリケーション間でユニークであるとは限りません。

属性表

a. T_APPQTRANS クラスの属性はすべてローカルです。

b. T_APPQTRANS オブジェクトのすべての操作 (GET と SET) は、関連付けられているキュー スペースを自動的に開きます。つまり、キュー スペースの状態が OPEn または ACTive になっていない場合、暗黙的に OPEn に設定します。キュー スペースが大きいと、この操作は時間がかかります。

c. 1 つのアプリケーション キュー スペースを明示的に指定するには、GET 操作で適切なキー フィールドを指定する必要があります。

属性の意味

TA_XID: string[1..78]

TA_APPQSPACENAME: string[1..15]

TA_QMCONFIG: string[1..78]

TA_LMID: string[1..30] (no comma)

TA_STATE:

APPQ_MIB(5) に関する追加情報

移植性

Oracle Tuxedo システムの MIB を使用した管理作業をサポートするために必要な既存の FML32 および ATMI 関数、さらにこのリファレンス ページに定義するヘッダ ファイルとフィールド テーブルは、すべてのサポート対象ネイティブ プラットフォームとワークステーション プラットフォームで使用可能です。

相互運用性

この MIB は、Oracle Tuxedo 6.0 以降が実行されているサイト (ネイティブおよび Workstation の両方) からのみアクセスできます。

Oracle Tuxedo 6.0 より前のリリースが実行されているサイトがアプリケーション内でアクティブ化された場合、この MIB による管理アクセスは次のとおり制限されます。

リリースが異なるサイト (共にリリース 6.0 以降) を相互運用する場合、当該リリースの MIB リファレンス ページに定義されるように、旧サイト上の情報はアクセスおよび更新可能で、以降のリリースで利用可能な情報のサブセットとなります。

使用例

以下に、アプリケーション キュー スペース、キュー、メッセージ、およびトランザクションに対する各種操作の実行方法を示すコードを示します。

各コードの前には、次のように、FML32 型付きバッファを割り当てるコードを追加してください。

rqbuf = tpalloc("FML32", NULL, 0);

バッファにデータを入力したら、各コードの後には、次のような、要求を送信し、応答を受信するコードを追加します。

flags = TPNOTRAN | TPNOCHANGE | TPSIGRSTRT;
rval = tpcall(".TMIB", rqbuf, 0, rpbuf, rplen, flags);

詳細については、MIB(5) を参照してください。

フィールド テーブル

属性フィールド識別子にアクセスするには、フィールド テーブル tpadm が必要です。そのためには、次のようにシェルで入力します。

$ FIELDTBLS=tpadm 
$ FLDTBLDIR=${TUXDIR}/udataobj
$ export FIELDTBLS FLDTBLDIR

ヘッダ ファイル

次のヘッダ ファイルが必要です。

#include <atmi.h> 
#include <fml32.h>
#include <tpadm.h>

ライブラリ

${TUXDIR}/lib/libtmib.a, ${TUXDIR}/lib/libqm.a、${TUXDIR}/lib/libtmib.so.<rel>、${TUXDIR}/lib/libqm.so.<rel>、${TUXDIR}/lib/libqm.lib

buildclient を使用するときには、ライブラリを手動でリンクする必要があります。この場合は、-L${TUXDIR}/lib -ltmib -lqm を指定する必要があります。

アプリケーション キュー スペースの作成

通常、アプリケーション キュー スペースを作成するには 2 つの操作が必要です。最初の操作ではキュー スペースを割り当てる Oracle Tuxedo システム デバイスを作成し、次の操作ではキュー スペース自体を作成します。

/* 上記を参照してバッファを割り当てる */ 
 
/* SITE1 に新しいデバイスを作成するための要求を作成 */
Fchg32(rqbuf, TA_OPERATION, 0, "SET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "T_DEVICE", 0);
Fchg32(rqbuf, TA_STATE, 0, "NEW", 0);
Fchg32(rqbuf, TA_CFGDEVICE, 0, "/dev/q/dsk001", 0);
Fchg32(rqbuf, TA_LMID, 0, "SITE1", 0);
size = 500;
Fchg32(rqbuf, TA_DEVSIZE, 0, (char *)size, 0);
 
/* 上記を参照して要求を作成 */
 
/* 再使用のために同じバッファを再初期化する */
Finit32(rqbuf, (FLDLEN) Fsizeof32(rqbuf));
 
/* キュー スペースを作成するための要求を作成 */
Fchg32(rqbuf, TA_OPERATION, 0, "SET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "T_APPQSPACE", 0);
Fchg32(rqbuf, TA_STATE, 0, "NEW", 0);
Fchg32(rqbuf, TA_APPQSPACENAME, 0, "QSPACE1", 0);
Fchg32(rqbuf, TA_QMCONFIG, 0, "/dev/q/dsk001", 0);
Fchg32(rqbuf, TA_LMID, 0, "SITE1", 0);
Fchg32(rqbuf, TA_ERRORQNAME, 0, "errque", 0);
ipckey = 123456;
Fchg32(rqbuf, TA_IPCKEY, 0, (char *)ipckey, 0);
maxmsg = 100;
Fchg32(rqbuf, TA_MAXMSG, 0, (char *)maxmsg, 0);
maxpages = 200;
Fchg32(rqbuf, TA_MAXPAGES, 0, (char *)maxpages, 0);
maxproc = 50;
Fchg32(rqbuf, TA_MAXPROC, 0, (char *)maxproc, 0);
maxqueues = 10;
Fchg32(rqbuf, TA_MAXQUEUES, 0, (char *)maxqueues, 0);
maxtrans = 100;
Fchg32(rqbuf, TA_MAXTRANS, 0, (char *)maxtrans, 0);
 
/* 上記を参照して要求を作成 */

アプリケーション キュー スペースへのキューの追加

以下のコードでは、上の例で作成したキュー スペースに新しいキューを作成します。

/* 要求を作成 */ 
Fchg32(rqbuf, TA_OPERATION, 0, "SET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "T_APPQ", 0);
Fchg32(rqbuf, TA_STATE, 0, "NEW", 0);
Fchg32(rqbuf, TA_APPQNAME, 0, "errque", 0);
Fchg32(rqbuf, TA_APPQSPACENAME, 0, "QSPACE1", 0);
Fchg32(rqbuf, TA_QMCONFIG, 0, "/dev/q/dsk001", 0);
Fchg32(rqbuf, TA_LMID, 0, "SITE1", 0);
Fchg32(rqbuf, TA_APPQORDER, 0, "PRIO", 0);
 
/* 上記を参照して要求を作成 */

アプリケーションが認識しているアプリケーション キュー スペースの表示

アプリケーションが認識しているアプリケーション キュー スペースを表示するには、2 段階の検索を行います。まず、/Q トランザクション マネージャ TMS_QM を使用するグループがアプリケーション環境設定から検索され、次に各グループが参照しているキュー スペースが検索されます。以下のコードは、キュー スペースを使用する各 GROUP エントリに 1 つの論理マシンが対応付けられていると仮定します (つまり、サーバ移行は未使用)。

/* すべての TMS_QM グループを検索する要求を作成 */
Fchg32(rqbuf, TA_OPERATION, 0, "GET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "T_GROUP", 0);
Fchg32(rqbuf, TA_TMSNAME, 0, "TMS_QM", 0);
fldid1 = TA_OPENINFO;
fldid2 = TA_LMID;
Fchg32(rqbuf, TA_FILTER, 0, (char *)fldid1, 0);
Fchg32(rqbuf, TA_FILTER, 0, (char *)fldid2, 1);
 
/* アプリケーションに参加したと見なして要求を作成 */
rval = tpcall(".TMIB", rqbuf, 0, rpbuf, rplen, flags);
 
/* TMS_QM グループごとに、キュー スペースを検索する要求を作成 */
rval = Fget32(*rpbuf, TA_OCCURS, 0, (char *)occurs, NULL);
for (i = 0; i occurs; i++) {
 
 
  /* バッファを再初期化して、すべての共通属性を設定 */
  Finit32(rqbuf, (FLDLEN) Fsizeof32(rqbuf));
  Fchg32(rqbuf, TA_OPERATION, 0, "GET", 0);
  Fchg32(rqbuf, TA_CLASS, 0, "T_APPQSPACE", 0);
 
  /* デバイスとキュー スペース名を調べるための OPENINFO を取得 */
  /* OPENINFO の形式は、<resource-mgr>:<qmconfig>:<appqspacename> */
  /* Windows の場合は、<resource-mgr>:<qmconfig>;<appqspacename> */
  rval = Fget32(rpbuf, TA_OPENINFO, i, openinfo, NULL);
 
  /* デバイスは、OPENINFO の 2 つ目のフィールド */
  qmconfig = strchr(openinfo, ':') + 1;
  /* キュー スペース名は、OPENINFO の 3 つ目のフィールド */
 
#if defined(_TMDOWN) || defined(_TM_NETWARE)
#define pathsep ";" /* PATH の区切り文字 */
#else
#define pathsep ":" /* PATH の区切り文字 */
#endif
  appqspacename = strchr(qmconfig, pathsep);
  appqspacename[0] = '\e0'; /* qmconfig を NULL で終了するように指定 */
  appqspacename++; /* NULL に値を追加 */
 
  /* APPQSPACENAME と QMCONFIG キーを設定 */
  Fchg32(rqbuf, TA_APPQSPACENAME, 0, appqspacename, 0);
  Fchg32(rqbuf, TA_QMCONFIG, 0, qmconfig, 0);
 
  /* LMID を取得 (このグループに対する移行はないものと見なす) */
  rval = Fget32(rpbuf, TA_LMID, i, lmid, NULL);
  Fchg32(rqbuf, TA_LMID, 0, lmid, 0);
 
  /* 要求を作成 */
  rval = tpcall(".TMIB", rqbuf, 0, rpbuf2, rplen2, flags);
}

上記のコードでは、キュー スペースが作成されていても、アプリケーションのコンフィグレーションに対応する GROUP エントリがないと、キュー スペースは検索されません。このようなキュー スペースは、キュー スペースのキー フィールド (TA_APPQSPACENAME、TA_QMCONFIG、および TA_LMID) の優先順位が分かっていなければ検索できません。

アプリケーション キュー内のメッセージの表示

以下のコードでは、論理デバイス SITE1 上のデバイス /dev/q/dsk001 のキュー スペース QSPACE1 内のキュー STRING にあるメッセージをすべて検索します。

/* 要求を作成 */ Fchg32(rqbuf, TA_OPERATION, 0, "GET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "T_APPQMSG", 0);
Fchg32(rqbuf, TA_APPQNAME, 0, "STRING", 0);
Fchg32(rqbuf, TA_APPQSPACENAME, 0, "QSPACE1", 0);
Fchg32(rqbuf, TA_QMCONFIG, 0, "/dev/q/dsk001", 0);
Fchg32(rqbuf, TA_LMID, 0, "SITE1", 0);
/* 上記を参照して要求を作成 */

キュー スペースを使用するトランザクションの表示

以下のコードでは、キュー スペース QSPACE1 の中の任意のキューを使用するトランザクションをすべて検索します。

/* 要求を作成 */ Fchg32(rqbuf, TA_OPERATION, 0, "GET", 0);
Fchg32(rqbuf, TA_CLASS, 0, "T_APPQTRANS", 0);
Fchg32(rqbuf, TA_APPQSPACENAME, 0, "QSPACE1", 0);
Fchg32(rqbuf, TA_QMCONFIG, 0, "/dev/q/dsk001", 0);
Fchg32(rqbuf, TA_LMID, 0, "SITE1", 0);
/* 上記を参照して要求を作成 */

ファイル

${TUXDIR}/include/tpadm.h
${TUXDIR}/udataobj/tpadm

関連項目

tpacall(3c)、tpadmcall(3c)、tpalloc(3c)、tpcall(3c)、tpdequeue(3c)、tpenqueue(3c)、tpgetrply(3c)、tprealloc(3c)、「FML 関数の紹介」、Fadd、Fadd32(3fml)、Fchg、Fchg32(3fml)、Ffind、Ffind32(3fml)、MIB(5)、TM_MIB(5)

『Oracle Tuxedo アプリケーションの設定』

『Oracle Tuxedo アプリケーション実行時の管理』

『C 言語を使用した Oracle Tuxedo アプリケーションのプログラミング』

『FML を使用した Oracle Tuxedo アプリケーションのプログラミング』

AUTHSVR(5)

名前

AUTHSVR - サーバ提供のユーザ単位の認証

形式

AUTHSVR SRVGRP=”identifier“ SRVID=number other_parms CLOPT="-A”

説明

AUTHSVR は、Oracle Tuxedo に用意されている、認証サービスを備えたサーバです。このサーバを保護されたアプリケーションで使用することにより、クライアントがアプリケーションに参加するときにユーザ単位の認証を行うことができます。このサーバは、アプリケーションへのアクセスを要求しているクライアント プロセスのための TPINIT 型付きバッファを含むサービス要求を受け付けます。TPINIT 型付きバッファのデータ フィールドをユーザのパスワードとして使用し、そのパスワードを設定済みパスワードと比較することにより、要求の妥当性をチェックします。要求が妥当であると認められると、クライアントが使用するためのチケットとしてアプリケーション キーが返されます。

アプリケーション キーの設定には、tpreturn(3c) の rcode パラメータが使用されます。このパラメータは、妥当性検査に合格するか、パーミッションが拒否されたときに、tpinit(3c) を呼び出したコードに (tpurcode で) 返されます。

AUTHSVR の詳細については、「AUTHSVR に関する追加情報」を参照してください。

SECURITY USER_AUTH

SECURITY が USER_AUTH に設定されている場合は、強制的にユーザ単位での認証が実行されます。UBBCONFIG ファイルの RESOURCES セクションの AUTHSVC パラメータを使用して、アプリケーションに対する認証サービスの名前を設定することができます。たとえば、次の AUTHSVC パラメータ設定では、SECURITY が USER_AUTH に設定されている場合に AUTHSVR によって宣言されるサービス (AUTHSVC) が指定されます。

*RESOURCES
SECURITY   USER_AUTH
AUTHSVC    AUTHSVC

AUTHSVC パラメータを設定しない場合、認証サービスはデフォルトによって AUTHSVC となります。

デフォルトでは、アプリケーションの APPDIR 変数で定義される最初のパス名で参照されるディレクトリのファイル tpusr はパスワード情報の検索に使用されますが、このファイルが存在しない場合は /etc/passwd が使用されます。ただし、このファイルはシャドー パスワード ファイルを使用しているシステムでは正しく使用できません。ファイルは、サーバのコマンドライン オプションの "-f filename" オプションでファイル名を指定することによってオーバーライドすることができます (例 : CLOPT="-A -- -f /usr/tuxedo/users”)。マスタ マシンからコンフィグレーションで指定された他のマシンへのユーザ ファイルの自動伝播は、$APPDIR/tpusr を使用した場合にのみ実行されます。

ユーザ ファイルでは、(与えられた名前と) 一致するユーザ名とクライアント名が検索されます。ユーザ ファイルには、4 つのタイプのエントリがあります。これらをユーザの妥当性検査を行う際の一致の優先度の順に並べると、次のようになります。

認証要求は、最初に一致するパスワード ファイルのエントリに対してのみ認証されます。これらのセマンティクスを使用すれば、同じユーザが (通常異なるクライアント名の) 複数のエントリ名を持つことができ、ユーザ名にワイルドカードを使用できます。これらのセマンティクスを使用できるのは、tpaddusr()、tpdelusr()、および tpmodusr() を利用してユーザ ファイルを管理する場合です。ただし、これらのセマンティクスを使用した場合、ACL と MANDATORY_ACL のセマンティクスとの互換性はなく、これらのセキュリティ レベルへの移行は困難になります。ACL セキュリティとの互換性のため制限的なセマンティクスを得るには、tpusradd()、tpusrdel()、および tpusrmod() の各プログラムを利用してユーザ ファイルを管理する必要があります。

認証要求を処理する際には、特殊なクライアント名の値、つまり tpsysadm (システム管理者) と tpsysop (システム オペレータ) は AUTHSVR(5) によって特別に扱われます。これらの値は、ユーザ ファイルのワイルドカードを利用したクライアント名と一致させることはできません。

AUTHSVR によって返されるアプリケーション キーは、ユーザ ID です。このアプリケーション キーは、TPSVCINFO というデータ構造の appkey 要素に含まれるすべてのサービスに渡されます。

標準仕様の AUTHSVR は、システムの一部として ${TUXDIR}/bin/AUTHSVR に格納された状態で出荷され、上記で説明したセマンティクスを持っています。ソース コードのサンプルは、${TUXDIR}/lib/AUTHSVR.c に収められています。AUTHSVR の代わりに、(Kerberos などを利用して) それぞれのアプリケーションに適した方法でユーザやユーザ データ (パスワードは不可) の妥当性を検査するアプリケーション認証サーバを使用することができます。AUTHSVR の代わりに他のアプリケーション認証サーバを使用する場合、このリファレンス ページで後述する警告に特に留意してください。また、使用する認証サービスが (それぞれのサービスに渡す) アプリケーション キーとして返す値も、それぞれのアプリケーションによって異なります。

tpsysadm と tpsysop に対応するアプリケーション キーは、それぞれ 0x80000000 と 0xC0000000 です。

SECURITY ACL または MANDATORY_ACL

SECURITY が ACL または MANDATORY_ACL に設定されている場合、ユーザ単位の認証が強制的に実行され、サービスや、アプリケーションのキュー、イベントにアクセスするためのアクセス制御リストがサポートされます。UBBCONFIG ファイルの RESOURCES セクションの AUTHSVC パラメータを使用して、アプリケーションに対する認証サービスの名前を設定することができます。たとえば、次の AUTHSVC パラメータ設定では、SECURITY が ACL または MANDATORY_ACL に設定されている場合に AUTHSVR によって宣言されるサービス (..AUTHSVC) が指定されます。

*RESOURCES
SECURITY   ACL
AUTHSVC    ..AUTHSVC

AUTHSVC パラメータを設定しない場合、認証サービスはデフォルトによって ..AUTHSVC となります。

ユーザ ファイルは、$APPDIR/tpusr でなければなりません。このファイルは、マスタ マシンからコンフィグレーションで指定された他のアクティブ マシンに自動的に伝播されます。マスタ マシンでは、AUTHSVR の 1 つのインスタンスが実行されている必要があります。コンフィグレーションで指定された別のアクティブ マシンでは、AUTHSVR の新たなコピーを実行できます。

ユーザ ファイルでは、(与えられた名前と) 一致するユーザ名とクライアント名が検索されます。ユーザ名は、ユーザ ファイルのエントリと正確に一致している必要があります。クライアント名は正確に一致している必要がありますが、代替手段としてユーザ ファイルのクライアント名の値をあらゆるクライアント名に該当するワイルドカード (*) として指定する方法も利用できます。ユーザ ファイルのエントリは 1 人のユーザにつき 1 つだけで、ユーザ名にワイルドカードを使用することはできません。ユーザ ファイルは、tpusradd()、tpusrdel()、および tpusrmod() の各プログラム、グラフィカル ユーザ インタフェース、または管理インタフェースを使用して管理できます。

認証要求を処理する際には、特殊なクライアント名の値、つまり tpsysadm (システム管理者) と tpsysop (システム オペレータ) は AUTHSVR(5) によって特別に扱われます。これらの値は、ユーザ ファイルのワイルドカードを利用したクライアント名と一致させることはできません。

AUTHSVR によって返されるアプリケーション キーは、下位 17 ビットのユーザ ID と、それに続く 14 ビットのグループ ID で構成されます (上位ビットは管理キーとして予約されています)。tpsysadm と tpsysop に対応するアプリケーション キーは、それぞれ 0x80000000 と 0xC0000000 です。このアプリケーション キーは、TPSVCINFO というデータ構造の appkey 要素に含まれるすべてのサービスに渡されます。

SECURITY ACL または MANDATORY_ACL の場合、システムの一部として ${TUXDIR}/bin/AUTHSVR に収められている AUTHSVR を使用する必要があります。

AUTHSVR に関する追加情報

使用方法

移植性

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

使用例

# USER_AUTH の使用
*RESOURCES
SECURITY  USER_AUTH
AUTHSVC   AUTHSVC

*SERVERS 
AUTHSVR SRVGRP="AUTH" CLOPT="-A -- -f /usr/tuxedo/users" \
 SRVID=100 RESTART=Y GRACE=0 MAXGEN=2
#
#
# ACL の使用
*RESOURCES
SECURITY  ACL
AUTHSVC   ..AUTHSVC

*SERVERS
AUTHSVR SRVGRP="AUTH" SRVID=100 RESTART=Y GRACE=0 MAXGEN=2
#
#
# カスタム認証サービスの使用
*RESOURCES
SECURITY  USER_AUTH
AUTHSVC   KERBEROS

*SERVERS
KERBEROSSVR SRVGRP="AUTH1" SRVID=100 RESTART=Y GRACE=0 MAXGEN=2

関連項目

tpaddusr(1)、tpusradd(1)、UBBCONFIG(5)

『Oracle Tuxedo アプリケーションの設定』

『Oracle Tuxedo アプリケーション実行時の管理』

『C 言語を使用した Oracle Tuxedo アプリケーションのプログラミング』

Accesslog(5)

名前

Accesslog(5) - Tuxedo クライアントの有効性のモニタ

説明

Accesslog(5) は、クライアントのログイン/ログオフ アクションをタイムスタンプと場所情報とともに記録するのに役立ちます。Accesslog はアクセス ログを作成し、Tuxedo ULOG ファイルに 1 行追加します。詳細については、「使用例」および「ULOG ファイル エントリ」を参照してください。

Accesslog は、24 時間ごとに新しいファイルをアクセス ログ ファイルに自動生成します。アクセス ログの出力ファイルは、以下の形式で生成されます。

hhmmss.uname!pname.pid.tid.ctx: total client ($currentclientcount), $event: $protocol [IP ($clientip)] cltname ($clientname) [usrname ($username)] success.

$currentclientcount = numeric_value

$event = enum_value

$protocol = enum_value

$clientip = string_value

$clientname = string_value

$username = string_value

使用例

コード リスト 2 は、Accesslog のファイル出力の例を示しています。

112749.ubuntu!?proc.31212.3079091888.0: total client (2), logon: NATIVE cltname () success

112749.ubuntu!?proc.31212.3079091888.0: total client (2), logoff: NATIVE cltname () success

112749.ubuntu!WSH.31211.3078347248.0: total client (2), logon: /WS IP (//127.0.1.1:39224), cltname () success

112749.ubuntu!WSH.31211.3078347248.0: total client (2), logoff: /WS IP (//127.0.1.1:39224), cltname () success

ULOG ファイル エントリ

ULOG の各ログ エントリのヘッダには、最大クライアント数が自動的に記録されます。

ULOG 出力ファイルには、以下の形式の行が挿入されます。

hhmmss.uname!pname.pid.tid.ctx: mm-dd-yyyy: client high water ($highwater), total client ($currentclientcount)

コード リスト 3 は、Accesslog(5) の行が追加された ULOG ファイルの例を示しています。

145622.ubuntu!tmloadcf.4568.3079399872.-2: 12-17-2008: client high water (0), total client (0)

/*BBL によって出力されない*/

145625.ubuntu!tmloadcf.4568.3079399872.-2: 12-17-2008: client high water (), total client ()

$highwater = numeric-value

$currentclientcount = numeric-value

環境変数

以下の環境変数を設定およびエクスポートします。

ALOGPFX

ALOGRTNSIZE=numeric_value

compilation(5)

名前

compilation - Oracle Tuxedo ATMI システムのアプリケーション コンポーネントのコンパイル命令

説明

アプリケーションのクライアントとサーバ、および Oracle Tuxedo システムにリンクされているサブルーチンをコンパイルする場合、プログラマは以下のことを知っておく必要があります。

コード モジュールの記述が済み、実行可能プログラムを構築する準備が整ったプログラマは、以下の作業を行う必要があります。

Oracle Tuxedo システムには、この両方の操作をクライアント モジュールとサーバ モジュールで実行するための 2 つのコマンド、buildclient() と buildserver() が用意されています。いずれかのコマンドを実行して両方の操作を実行する場合、ファイルをリンクするためのライブラリを必ずコマンドラインで指定してください (詳細については、『Tuxedo コマンド リファレンス』の「buildclient(1)」および「buildserver(1)」を参照)。

リンクを行うには buildclient または buildserver を実行する必要がありますが、より柔軟なコンパイル方法も用意されています。必要に応じて、自分が選択したコンパイル コマンドを使用してファイルをコンパイルし、次に buildclient または buildserver を実行してリンク編集を行うこともできます。

このリファレンス ページの残りの部分では、各種のプログラムで必要なヘッダ ファイルと環境変数を示します。

基本的な Oracle Tuxedo システム

UNIX システムのヘッダ ファイルは、必ず Oracle Tuxedo システムのヘッダ ファイルの前にインクルードします。一般的に使用される UNIX システムのヘッダ ファイルは stdio.h と ctype.h です。

環境変数

以下の環境変数を設定およびエクスポートします。

TUXDIR

PATH

ULOGPFX

共有ライブラリを使用してシステムが構築された場合、クライアントを実行する前に、共有ライブラリの位置を定義する環境変数を設定する必要があります。

FML プログラム

FML 関数を呼び出す C プログラムには、以下のヘッダ ファイルをここに示す順序でインクルードします。

#include <UNIX_header_files> (アプリケーションで必要な場合)
#include "fml.h”

FML プログラムのコンパイル

FML の関数を含むプログラムをコンパイルするには、次のようにコマンドを実行します。

cc pgm.c -I $TUXDIR/include -L $TUXDIR/lib -lfml -lengine -o pgm

ここで、pgm は実行可能ファイルの名前です。

-L オプションがローカルでサポートされていない場合、代わりに次のコマンドを使用します。

cc pgm.c -I $TUXDIR/include $TUXDIR/lib/libfml.a $TUXDIR/lib/libengine.a -o pgm

FML VIEWS のコンパイル

FML VIEW コンパイラを使用するには、次のようにコマンドを実行します。

viewc view_file

ここで view_file は、VIEW 用のソース記述が格納されている 1 つまたは複数のファイルです。

FML の環境変数

FML を使用するアプリケーションを実行するときは、以下の環境変数を設定してエクスポートします。

FIELDTBLS

FLDTBLDIR

viewc を実行するときは、以下の環境変数を設定してエクスポートします。

FIELDTBLS

FLDTBLDIR

VIEWDIR

関連項目

buildclient(1)、buildserver(1)、viewc、viewc32(1)
UNIX システムのリファレンス マニュアルの cc(1)、mc(1)

DMADM(5)

名前

DMADM - ドメイン管理サーバ

形式

DMADM SRVGRP = ”identifier“
SRVID = ”number“ 
REPLYQ = ”N”

説明

Domains 管理サーバ (DMADM) は、BDMCONFIG ファイルに実行時にアクセスするための Oracle Tuxedo システム提供のサーバです。

DMADM は、DMADMGRP などのグループ内で動作するサーバとして、UBBCONFIG の SERVERS セクションで記述されます。このグループ内で動作する DMADM は 1 つだけで、応答キューが存在していてはいけません (REPLYQ を N に設定する必要がある)。

SERVERS セクションでは、DMADM サーバのパラメータとして、SEQUENCE、ENVFILE、MAXGEN、GRACE、RESTART、RQPERM、および SYSTEM_ACCESS も指定できます。

BDMCONFIG 環境変数は、バイナリ形式の DMCONFIG ファイルが入っているファイルのパス名に設定する必要があります。

移植性

DMADM は、サポートされているすべてのサーバ プラットフォームで Oracle Tuxedo システム提供のサーバとしてサポートされます。

相互運用性

DMADM は、Oracle Tuxedo リリース 5.0 以降にインストールする必要があります。リリース 5.0 のゲートウェイが存在するドメイン内の他のマシンの場合は、リリース 4.1 以降でも構いません。

使用例

次の例は、UBBCONFIG ファイルで管理サーバとゲートウェイ グループを定義する方法を示しています。この例では、GWTDOMAIN ゲートウェイ プロセスを使用して別の Oracle Tuxedo ドメインと通信します。

#
*GROUPS
DMADMGRP LMID=mach1 GRPNO=1
gwgrp    LMID=mach1 GRPNO=2
#
*SERVERS 
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y GRACE=0
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y GRACE=0
GWTDOMAIN SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=Y RESTART=Y MIN=1 MAX=1

関連項目

dmadmin(1)、tmboot(1)、DMCONFIG(5)、GWADM(5)、servopts(5)、UBBCONFIG(5)

『Oracle Tuxedo アプリケーションの設定』

『Oracle Tuxedo アプリケーション実行時の管理』

『ATMI アプリケーションでの Oracle Tuxedo TOP END Domain Gateway の使用』

DMCONFIG(5)

名前

DMCONFIG - テキスト形式の Domains コンフィグレーション ファイル

説明

Domains コンフィグレーションは、Oracle Tuxedo Domains コンポーネントを使用して通信およびサービス共有を行うことができる 2 つ以上のドメイン (ビジネス アプリケーション) の集まりです。複数のドメインを接続する方法や複数のドメイン間で相互にアクセスできるサービスについては、Domains コンフィグレーションに参加する各 Oracle Tuxedo ドメインの Domains コンフィグレーション ファイルで定義されます。テキスト形式の Domains コンフィグレーション ファイルは DMCONFIG と呼ばれますが、ファイルの内容がこのリファレンス ページで説明する形式に従っている限り、任意の名前を付けることができます。

DMCONFIG ファイルは、dmloadcf(1) ユーティリティによって構文解析され、バイナリ形式のファイル BDMCONFIG にロードされます。DMCONFIG ファイルと同じように、BDMCONFIG ファイルにも任意の名前を付けることができます。実際の名前は、BDMCONFIG 環境変数で指定されたデバイス ファイル名またはシステム ファイル名です。BDMCONFIG ファイルは、Domains コンフィグレーションに参加する Tuxedo ドメインごとに 1 つ必要です。

DMCONFIG ファイルと BDMCONFIG ファイルの関係は、Oracle Tuxedo ドメインの定義に使用される UBBCONFIG ファイルと TUXCONFIG ファイルの関係に似ています。UBBCONFIG ファイルと TUXCONFIG ファイルについては、UBBCONFIG(5) を参照してください。

DMCONFIG ファイルの詳細 (例を含む) については、「DMCONFIG(5) に関する追加情報」を参照してください。ATMI と CORBA の両環境向けの Oracle Tuxedo Domains コンポーネントについては、「Oracle Tuxedo Domains コンポーネント」を参照してください。

定義

Oracle Tuxedo ドメインは、単一の TUXCONFIG ファイルに記述された環境として定義されます。Oracle Tuxedo 用語では、ドメインとアプリケーション (ビジネス アプリケーション) は同義です。

Domains コンフィグレーションに含まれる各 Oracle Tuxedo ドメインでは、1 つの Domains 管理サーバ (DMADM) プロセスが実行されます。DMADM は、特定の Oracle Tuxedo ドメインで実行されるすべてのドメイン ゲートウェイ グループ用の管理サーバです。

ドメイン ゲートウェイ グループは、Oracle Tuxedo システムのゲートウェイ管理サーバ (GWADM) プロセスと Oracle Tuxedo システムのドメイン ゲートウェイ プロセスで構成されます。

Oracle Tuxedo システムのドメイン ゲートウェイ プロセスは、特定のタイプのトランザクション処理 (TP) ドメインとの通信サービスを提供します。たとえば、GWTDOMAIN プロセスを使用すると、Oracle Tuxedo アプリケーションは他の Oracle Tuxedo アプリケーションと通信できます。ドメイン ゲートウェイは、別のドメインへの要求を中継し、応答を受信します。

ローカル ドメイン アクセス ポイントは、他のドメイン (リモート ドメイン) が使用できる Oracle Tuxedo ドメインの一連のサービスを表すユーザ指定の論理名です。ローカル ドメイン アクセス ポイントはドメイン ゲートウェイ グループにマップされるため、どちらも同義語として使用されます。

リモート ドメイン アクセス ポイントは、ローカル ドメインが使用できるリモート ドメインの一連のサービスを表すユーザ指定の論理名です。リモート ドメインは、別の Oracle Tuxedo アプリケーションまたは別の TP システムで動作するアプリケーションです。

リモート サービスは、ローカル ドメインがリモート ドメイン アクセス ポイントとローカル ドメイン アクセス ポイントを介して使用できるリモート ドメインのサービスです。

ローカル サービスは、リモート ドメインがローカル ドメイン アクセス ポイントを介して使用できるローカル ドメインのサービスです。

コンフィグレーション ファイルの目的

DMCONFIG ファイルは、次の目的で使用します。

コンフィグレーション ファイルの形式

DMCONFIG ファイルは、次のセクションで構成されます。

DMCONFIG ファイル内のアスタリスク (*) で始まる行は、指定セクションの開始を表します。アスタリスク (*) の直後にはセクション名が表示されます。アスタリスクは、セクション名を指定するときに必要です。DM_LOCAL セクションは、DM_REMOTE セクションの前になければなりません。

このリファレンス ページでは、GWTDOMAIN ゲートウェイ プロセスによって実装される TDOMAIN (TDomain ゲートウェイ) をコンフィグレーションする方法について説明します。SNAX、OSITP、または OSITPX ドメイン ゲートウェイのコンフィグレーションについては、「Oracle eLink」を参照してください。

パラメータは通常、KEYWORD = value という形式で指定します。等号 (=) の前後には空白またはタブ文字を使用できます。この形式により、KEYWORD が value に設定されます。有効なキーワードについては、以下の各セクションで説明します。

予約語の DEFAULT で始まる行にはパラメータ仕様が含まれており、セクション内の以降の該当するすべての行に対して適用されます。デフォルト仕様はすべてのセクションで使用でき、同じセクション内で複数回使用できます。これらの行の形式は次のとおりです。

DEFAULT: [KEYWORD1 = value1 [KEYWORD2 = value2 [...]]]

この行で設定した値は、別の DEFAULT 行によってリセットされるか、セクションが終わるまで有効です。これらの値は、DEFAULT でない行の省略可能なパラメータによってオーバーライドされる場合もあります。DEFAULT でない行におけるパラメータ設定は、その行でのみ有効です。以降の行ではデフォルト設定に戻ります。DEFAULT が行頭に表示されると、それ以前に設定されたすべてのデフォルト値はクリアされ、システムのデフォルト値に戻ります。

値が numeric の場合は、C の標準表記法を使用して基数を示します。つまり、基数 16 (16 進) の接頭辞は 0x、基数 8 (8 進) の接頭辞は 0、基数 10 (10 進) には接頭辞が付きません。数値パラメータで指定できる範囲については、各パラメータの項で説明します。

値が identifier (TYPE パラメータの TDOMAIN のように Oracle Tuxedo Domains コンポーネントにとって既知の文字列値) の場合、一般的に標準 C 規則が使用されます。標準 C の identifier の先頭には英字またはアンダースコア (_) を使用し、以降の識別子には英数字またはアンダースコアを使用する必要があります。identifier の長さは最大 30 バイトです (最後の NULL を除く)。

識別子を二重引用符で囲む必要はありません。整数でも識別子でもない値は、二重引用符で囲む必要があります。

入力フィールドは、1 つ以上の空白 (またはタブ) 文字で区切ります。

"#" はコメントを示します。復帰改行文字でコメントを終了します。

空白行とコメントは無視されます。

コメントは任意の行の最後に自由に入力できます。

行は、復帰改行の後に最低 1 つのタブを置いて継続できます。コメントを継続することはできません。

Domains 関連の新しい用語

Oracle Tuxedo のリリース 7.1 以降では、Domains 用の MIB で、ローカル ドメインとリモート ドメインとの相互作用を記述するため、クラスと属性の用語が改善されています。新しい用語は、DMCONFIG(5) リファレンス ページ、セクション名、パラメータ名、エラー メッセージ、および DM_MIB(5) リファレンス ページ、クラス、エラー メッセージに適用されます。

下位互換性のため、Oracle Tuxedo 7.1 より前に使用されていた DMCONFIG 用語と Domains 用の MIB の新しい用語との間でエリアスが提供されています。Oracle Tuxedo リリース 7.1 以降の DMCONFIG では、両方のバージョンの用語を使用できます。次の表に、DMCONFIG ファイルの旧用語と新用語の対応を示します。

Oracle Tuxedo のリリース 7.1 以降の dmunloadcf コマンドでは、デフォルトで新しいドメイン関連の用語を使用する DMCONFIG ファイルが生成されます。以前のドメイン関連の用語を使用する DMCONFIG ファイルを出力するには、-c オプションを使用します。次に例を示します。

プロンプト > dmunloadcf -c > dmconfig_prev

DM_LOCAL セクション

このセクション (DM_LOCAL_DOMAINS セクションともいう) では、1 つまたは複数のローカル ドメイン アクセス ポイント識別子と、それらに関連付けるゲートウェイ グループを定義します。このセクションには、UBBCONFIG ファイルで指定されたアクティブなゲートウェイ グループごとにローカル ドメイン アクセス ポイントのエントリが必要です。各エントリでは、グループで実行されるドメイン ゲートウェイ プロセスに必要なパラメータを指定します。

DM_LOCAL セクションのエントリの形式は次のとおりです。

LocalAccessPoint required_parameters [optional_parameters]

LocalAccessPoint は、UBBCONFIG ファイルで定義された特定のゲートウェイ グループを表すローカル ドメイン アクセス ポイント識別子 (論理名) です。LocalAccessPoint は、Domains コンフィグレーションに含まれるローカルおよびリモート ドメイン間でユニークでなければなりません。DM_EXPORT セクションで説明するとおり、ローカル ドメイン アクセス ポイントはローカル サービスを特定のゲートウェイ グループに関連付けるために使用します。ローカル ドメイン アクセス ポイントを通じて利用可能なローカル サービスは、1 つ以上のリモート ドメインのクライアントから利用できます。

DM_LOCAL セクションの必須パラメータ

GWGRP = identifier

TYPE = identifier