診断

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

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

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

相互運用性

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

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

移植性

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

使用例

このセクションでは、tpadmcall() と tpcall() を使用して 2 つのノードを持つアプリケーションをコンフィギュレーション、アクティブ化、問い合わせ、および非アクティブ化するためのコードを抜粋しています。ローカル環境に応じて値が変わる部分には変数名を使用します。たとえば、TUXCONFIG は 2 つの要素からなる文字ポインタの配列で、それぞれ要素によってマシン上の TUXCONFIG ファイルの絶対パス名を識別します。

フィールド・テーブル

属性フィールド識別子にアクセスするには、フィールド・テーブル 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/libtmib.lib

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

初期コンフィギュレーション

以下のコードでは、FML32 バッファを作成して設定しています。このFML32 バッファは、処理のために tpadmcall() に渡されます。この例ではさらに、tpadmcall() のリターン・コードの解釈を示しています。ここで示す要求により、アプリケーションの初期コンフィギュレーションが作成されます。

 /* バッファの割り当ておよび初期化 */
 ibuf = (FBFR32 *)tpal loc("FML32", NULL, 4000);
 obuf = (FBFR32 *)tpalloc("FML32", NULL, 4000);
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
 Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
 /* T_DOMAIN クラス・オブジェクトに設定する TM_MIB(5) 属性を設定*/
 Fchg32(ibuf, TA_OPTIONS, 0, "LAN,MIGRATE", 0);
 Fchg32(ibuf, TA_IPCKEY, 0, (char *)&ipckey, 0);
 Fchg32(ibuf, TA_MASTER, 0, "LMID1", 0);
 Fchg32(ibuf, TA_MODEL, 0, "MP", 0);
 /* TA_MASTER T_MACHINE クラス・オブジェクトの TM_MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_LMID, 0, "LMID1", 0);
 Fchg32(ibuf, TA_PMID, 0, pmid[0], 0);
 Fchg32(ibuf, TA_TUXCONFIG, 0, tuxconfig[0], 0);
 Fchg32(ibuf, TA_TUXDIR, 0, tuxdir[0], 0);
 Fchg32(ibuf, TA_APPDIR, 0, appdir[0], 0);
 Fchg32(ibuf, TA_ENVFILE, 0, envfile[0], 0);
 Fchg32(ibuf, TA_ULOGPFX, 0, ulogpfx[0], 0);
 Fchg32(ibuf, TA_BRIDGE, 0, "/dev/tcp", 0);
 Fchg32(ibuf, TA_NADDR, 0, naddr[0], 0);
 Fchg32(ibuf, TA_NLSADDR, 0, nlsaddr[0], 0);
 /* tpadmcall() を使用して処理を実行 */
 if (tpadmcall(ibuf, obuf, 0) 0) {
 fprintf(stderr, "tpadmcall failed: %s¥n", tpstrerror(tperrno));
 /* 追加のエラー処理 */
 }

2 つ目のマシンの追加

以下のコードでは、前のセクションで割り当てたバッファを再利用して要求バッファを作成しています。以下に示す要求により、先に確立したコンフィギュレーションに別のマシンが追加されます。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_MACHINE", 0);
 Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
 /* T_MACHINE クラス・オブジェクトに設定する TM_MIB(5) 属性を設定*/
 Fchg32(ibuf, TA_LMID, 0, "LMID2", 0);
 Fchg32(ibuf, TA_PMID, 0, pmid[1], 0);
 Fchg32(ibuf, TA_TUXCONFIG, 0, tuxconfig[1], 0);
 Fchg32(ibuf, TA_TUXDIR, 0, tuxdir[1], 0);
 Fchg32(ibuf, TA_APPDIR, 0, appdir[1], 0);
 Fchg32(ibuf, TA_ENVFILE, 0, envfile[1], 0);
 Fchg32(ibuf, TA_ULOGPFX, 0, ulogpfx[1], 0);
 Fchg32(ibuf, TA_BRIDGE, 0, "/dev/tcp", 0);
 Fchg32(ibuf, TA_NADDR, 0, naddr[1], 0);
 Fchg32(ibuf, TA_NLSADDR, 0, nlsaddr[1], 0);
 
 tpadmcall(...) /* 詳細なエラー処理については上記の例を参照のこと */

2 つ目のマシンのバックアップ・マスタの作成

既存のバッファを再利用して、新たにコンフィギュレーションした 2 つ目のマシンをこのアプリケーションのバックアップ・マスタ・サイトとして識別します。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
 
 /* Set TM_MIB(5) T_DOMAIN attributes changing * 
 Fchg32(ibuf, TA_MASTER, 0, "LMID1,LMID2", 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

2 つのサーバ・グループの追加

バッファを再利用して、コンフィギュレーション済みのアプリケーションにサーバ・グループを 1 つずつ追加する要求を 2 つ作成します。2 つ目の要求は、単に既存の入力バッファの必要なフィールドを変更するためのものです。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_GROUP", 0);
 Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
  
/* 1 つ目のグループを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_SRVGRP, 0, "GRP1", 0);
 Fchg32(ibuf, TA_GRPNO, 0, (char *)&grpno[0], 0);
 Fchg32(ibuf, TA_LMID, 0, "LMID1,LMID2", 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */
 
/* 2 つ目のグループを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_SRVGRP, 0, "GRP2", 0);
 Fchg32(ibuf, TA_GRPNO, 0, (char *)&grpno[1], 0);
 Fchg32(ibuf, TA_LMID, 0, "LMID2,LMID1", 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

グループごとにサーバを 1 つずつ追加

割り当て済みのバッファを再利用し、グループごとに 1 つのサーバをコンフィギュレーション済みのアプリケーションに追加します。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_SERVER", 0);
 Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
 
/* 1 つ目のサーバを定義する MIB(5) 属性を設定 */ 
 Fchg32(ibuf, TA_SRVGRP, 0, "GRP1", 0);
 Fchg32(ibuf, TA_SRVID, 0, (char *)&srvid[0], 0);
 Fchg32(ibuf, TA_SERVERNAME, 0, "ECHO", 0) 
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */
 
/* 2 つ目のサーバを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_SRVGRP, 0, "GRP2", 0);
 Fchg32(ibuf, TA_SRVID, 0, (char *)&srvid[1], 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

ルーティング基準の追加

ルーティング基準の定義を追加します。ルーティング基準は、tpcall() インターフェイスを使用して同様の操作を行うことで、動作中のアプリケーションに動的に追加することもできます。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_ROUTING", 0);
 Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
 
/* ルーティング基準を定義する MIB(5) 属性を設定 */ 
 Fchg32(ibuf, TA_ROUTINGNAME, 0, "ECHOROUTE", 0);
 Fchg32(ibuf, TA_BUFTYPE, 0, "FML", 0);
 Fchg32(ibuf, TA_FIELD, 0, "LONG_DATA", 0);
 Fchg32(ibuf, TA_RANGES, 0, "MIN-100:GRP1,100-MAX:GRP2", 26);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

サービス定義の追加

上記で定義したルーティング基準に、宣言されたサービス名をマップするサービス・オブジェクトを定義します。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_SERVICE", 0);
 Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
 
/* サービス・エントリを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_SERVICENAME, 0, "ECHO", 0);
 Fchg32(ibuf, TA_ROUTINGNAME, 0, "ECHOROUTE", 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

マスタ・サイトの管理プロセスのアクティブ化

T_DOMAIN クラス・オブジェクトの状態を ACTIVE に設定して、マスタ・サイトの管理プロセス (DBBL、BBL、BRIDGE) をアクティブにします。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
 Fchg32(ibuf, TA_STATE, 0, "ACT", 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

アクティブなアプリケーション管理への切り替え

これでアプリケーションがアクティブになりました。次は、アプリケーションに参加して、tpcall() インターフェイスを使用して AdminAPI 要求を作成します。

/* システムがアクティブなので、システムに管理者として参加 */ tpinfo = (TPINIT *)tpalloc("TPINIT", NULL, TPINITNEED(0));
 sprintf(tpinfo->usrname, "appadmin");
 sprintf(tpinfo->cltname, "tpsysadm");
 if (tpinit(tpinfo) < 0) {
 fprintf(stderr, "tpinit() failed: %s¥n", tpstrerror(tperrno));
 /* 追加のエラー処理 */
 }
 
 /* バッファを型付きバッファとして再初期化*/
 Finit32(ibuf, Fsizeof32(ibuf));
 Finit32(obuf, Fsizeof32(obuf));

残りのアプリケーションのアクティブ化

アプリケーションの残り部分をアクティブにします。管理者ユーザは、要求の TA_FLAGS 属性にある TMIB_NOTIFY フラグを設定して、各サーバを起動しようとする直前または直後に任意通知型メッセージを送信するよう要求します。この例では、tpcall() からのエラー・リターンの処理を示しています。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_MACHINE", 0);
 Fchg32(ibuf, TA_STATE, 0, "RAC", 0);

/* マシンを識別する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_LMID, 0, "LMID1", 0);
 
/* /AdminAPI を呼び出して結果を解釈 */
 if (tpcall(".TMIB", (char *)ibuf, 0, (char **)&obuf, &olen, 0) < 0) {
 fprintf(stderr, "tpcall failed: %s¥n", 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¥n",
 ta_error, ta_status);

 /* 追加のエラー処理 */
 }

サーバ状態の問い合わせ

アクティブなサーバの状態に関する問い合わせを生成します。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "GET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_SERVER", 0);
 flags = MIB_LOCAL;
 Fchg32(ibuf, TA_FLAGS, 0, (char *)&flags, 0);
 
/* マシンを識別する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_SRVGRP, 0, "GRP1", 0);
 Fchg32(ibuf, TA_SRVID, 0, (char *)&srvid[0], 0);
 
 tpcall(...); /* 詳細なエラー処理については上記の例を参照 */

アプリケーションの非アクティブ化

各マシンの状態を INACTIVE に設定してアプリケーションを非アクティブ化します。この操作でも TMIB_NOTIFY フラグを使用できます。

/* 要求バッファをクリア */ Finit32(ibuf, Fsizeof32(ibuf));
 
 /* 最初にリモート・マシンをシャットダウン*/
/* 要求タイプを定義する MIB(5) 属性を設定 */
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_MACHINE", 0);
 Fchg32(ibuf, TA_LMID, 0, "LMID2", 0);
 Fchg32(ibuf, TA_STATE, 0, "INA", 0);
 
 tpcall(....); /* 詳細なエラー処理については上記の例を参照 */
 
 /* つづいてマスタ・マシンのアプリケーション・サーバをシャットダウン */ 
 flags = TMIB_APPONLY;
 Fchg32(ibuf, TA_FLAGS, 0, (char *)&flags, 0);
 Fchg32(ibuf, TA_LMID, 0, "LMID1", 0);
 
 tpcall(...); /* 詳細なエラー処理については上記の例を参照 */
 
 /* アクティブなアプリケーション・アクセスを終了*/
 tpterm();
 
/* 最後にマスタ管理プロセスを終了 */
 Finit32(ibuf, Fsizeof32(ibuf));
 Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
 Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
 Fchg32(ibuf, TA_STATE, 0, "INA", 0);
 
 tpadmcall(...); /* 詳細なエラー処理については上記の例を参照 */

ファイル

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

関連項目

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

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

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

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

TMFFNAME(5)

形式

FactoryFinder およびサポートする NameManager サービスを実行するサーバ

構文

TMFFNAME SRVGRP="identifier" SRVID="number"
[CLOPT="[-A] [servopts options]
[-- [-F ] [-N | -N -M [-f filename]]]"]

機能説明

TMFFNAME は BEA Tuxedo が提供するサーバで、FactoryFinder およびサポートする NameManager サービス (アプリケーションが提供する名前とオブジェクト・リファレンスとのマッピングを管理する) を実行します。

パラメータ

NameManager は、アプリケーションが提供する名前とオブジェクト・リファレンスとのマッピングを管理する BEA Tuxedo-固有のサービスです。このサービスの用途の 1 つとして、アプリケーション・ファクトリ名とオブジェクト・リファレンス間の対応関係を示すリストを維持することが挙げられますNameManager サービスは、-M オプションを使用してマスタ・ロールとして起動できます。-M オプションを指定しない場合、NameManager はスレーブになります。スレーブの NameManager はマスタから更新データを取得します。1 つのアプリケーションでマスタとして指定できる NameManager は 1 つだけです。

マスタ NameManager は、リモート・ドメインにあるファクトリ・オブジェクトをローカル・ドメインでアクセスできるようにコンフィギュレーションできます。また、ローカル・ドメインにあるファクトリ・オブジェクトをリモート・ドメインからアクセスできるようにコンフィギュレーションすることもできます。これらのコンフィギュレーションはいずれも、FactoryFinder Domains コンフィギュレーション・ファイル、factory_finder.ini で指定します。

factory_finder.ini ファイルの場所は、マスタ NameManager の -f コマンド行オプションで指定します。-f オプションを指定しても factory_finder.ini ファイルが見つからない場合、マスタ NameManager の初期化が失敗します。-f オプションを指定しない場合、ローカル・アプリケーションからはローカルに登録されたファクトリ・オブジェクトにしかアクセスできず、リモート・ドメイン内のアプリケーションからはローカル・ファクトリ・オブジェクトにアクセスできません。

注記 同じサービスを実行する TMFFNAME プロセスを 1 つまたは複数起動できます。信頼性を高めるには、異なるマシンで少なくとも 2 つ以上の NameManager サービスをコンフィギュレーションする必要があります。

相互運用性

TMFFNAME サーバは、BEA Tuxedo 4.0 以降のソフトウェアで動作します。

注意

アプリケーションの UBBCONFIG (TMFFNAME -N) でコンフィギュレーションされている NameManager サービスが 2 つに満たない場合、サーバは起動中に終了し、ユーザ・ログにエラー・メッセージを書き込みます。

アプリケーションの UBBCONFIG ファイルでコンフィギュレーションされていないマスタ NameManager サービスがスレーブ NameManager サービスの開始時に実行されていると、サーバは起動中に終了し、ユーザ・ログにエラー・メッセージを書き込みます。また、マスタがダウンしている場合は、マスタが再起動するまでファクトリを登録および登録解除できません。

TMSYSEVT サーバがアプリケーションの UBBCONFIG ファイルでコンフィギュレーションされておらず、NameManager サービスの開始時に実行されていない場合、サーバは起動中に終了し、ユーザ・ログにエラー・メッセージを書き込みます。

NameManager サービスがアプリケーションの UBBCONFIG ファイルでコンフィギュレーションされていない場合に FactoryFinder サービスが開始されると、サーバは起動中に終了し、ユーザ・ログにエラー・メッセージを書き込みます。

使用例

*SERVERS
TMSYSEVT SRVGRP=ADMIN1 SRVID=44 RESTART=Y
CLOPT="-A"

TMFFNAME SRVGRP=ADMIN1 SRVID=45 RESTART=Y
CLOPT="-A -- -F"

TMFFNAME SRVGRP=ADMIN1 SRVID=46 RESTART=Y
CLOPT="-A -- -N -M -f c:¥appdir¥import_factories.ini"
TMFFNAME SRVGRP=ADMIN2 SRVID=47 RESTART=Y
CLOPT="-A -- -N"
TMFFNAME SRVGRP=ADMIN3 SRVID=48 RESTART=Y
CLOPT="-A -- -F"
TMFFNAME SRVGRP=ADMIN4 SRVID=49 RESTART=Y
CLOPT="-A -- -F"

関連項目

TMIFRSVR(5)

名前

インターフェイス・リポジトリ・サーバ

形式

TMIFRSVR SRVGRP="identifier" SRVID="number" RESTART=Y GRACE=0 CLOPT="[servopts options] -- [-f repository_file_name]"

機能説明

パラメータ

使用例

*SERVERS

#このサーバはデフォルトのリポジトリ TMIFRSVR を使用する
SRVGRP="IFRGRP" SRVID=1000 RESTART=Y GRACE=0

#このサーバはデフォルト以外のリポジトリ TMIFRSVR を使用する
SRVGRP="IFRGRP" SRVID=1001 RESTART=Y GRACE=0
CLOPT="-- -f /nfs/repository.ifr"

関連項目

TMQFORWARD(5)

名前

TMQFORWARD-メッセージ転送サーバ

形式

TMQFORWARD SRVGRP="identifier" SRVID="number" REPLYQ=N CLOPT=" 
[-A] [servopts options] -- -q queuename[,queuename...] 
[-t trantime ] [-i idletime] [-e] [-d] [-n] [-f delay] "

機能説明

メッセージ転送サーバは BEA Tuxedo システムが提供するサーバで、tpenqueue() で格納されたメッセージを後処理のために転送します。アプリケーション管理者は、SERVERS セクションでこのサーバをアプリケーション・サーバとして指定することにより、アプリケーション・サーバのメッセージ処理を自動化できます。

位置指定、サーバ・グループ、サーバ識別子、その他の汎用サーバ関連パラメータは、サーバ用に定義されているコンフィギュレーション・ファイル機構を使用して、このサーバに関連付けられます。次に、カスタマイズに使用できる追加コマンド行オプションの一覧を示します。

メッセージは、それが読み取られるキューと同じ名前のサービスを提供するサーバに送信されます。キューへのメッセージ登録時に優先順位を指定した場合は、その優先順位がメッセージの優先順位になります。指定していない場合、優先順位はコンフィギュレーション・ファイルで定義されているサービスの優先順位か、またはデフォルト (50) になります。

メッセージは、1 つのトランザクションの中でキューから取り出され、サーバに送信されます。サービスが正常終了すると、トランザクションはコミットされ、メッセージはキューから削除されます。メッセージが応答キューに関連付けられている場合は、サービスからの応答はいずれも、返された tpurcode と共に応答キューに登録されます。.応答キューが存在しない場合、応答はドロップされます。

元のメッセージをキューに登録する場合、アプリケーションではメッセージに対する応答のサービス品質を指定することができます。応答のサービス品質が指定されていない場合、応答キューに指定されているデフォルトの配信ポリシーが使用されます。デフォルトの配信ポリシーは、メッセージに対する応答がキューに登録されるときに決定される点に注意してください。つまり、元のメッセージがキューに登録されてから応答が登録されるまでの間に、応答キューのデフォルトの配信ポリシーが変更された場合、応答が最後に登録される時点で有効な方針が使用されます。

サービスが異常終了した場合、そのキューに対する再試行制限によって指定されている回数の範囲内でトランザクションがロールバックされ、メッセージがキューに戻されます。メッセージがキューに戻される際、そのメッセージが最初にキューに登録されたときに適用された順位付けルールおよびキューからの取り出しルールは、delay 秒の間、一時的に効力を失います。これにより、たとえば、順位付けの低いメッセージが、キューに戻されたメッセージより先に取り出される可能性が出てきます。

-d オプションを指定した場合、サービスが異常終了し、かつサーバから応答メッセージが受信されるとメッセージはキューから削除されます。また、応答メッセージ (および関連する tpurcode) は、異常終了キューがそのメッセージに関連付けられており、かつ存在していればそのキューに登録されます。キューに設定されている再試行の制限に達すると同時にメッセージが削除されるようになっている場合、元の要求メッセージはエラー・キューに移されます。

コンフィギュレーションの条件によっては、TMQFORWARD がキューからメッセージを取り出せないか、メッセージを転送できないことがあり、その場合はサーバを起動できなくなります。こうした条件では、次のことが必要です。

アプリケーション・バッファ・タイプの処理

呼び出し元によって組み込まれるファイルには、アプリケーション・バッファ・タイプ・スイッチおよびサポートされる必須のルーチンのみを入れてください。buildserver は、サーバ・オブジェクト・ファイル $TUXDIR/lib/TMQFORWARD.o とアプリケーション・タイプ・スイッチのファイル (複数可) を結合し、これに必要な BEA Tuxedo システム・ライブラリをリンクするために使用されます。次の例を使用して、詳細を説明します。

buildserver -v -o TMQFORWARD -r TUXEDO/QM -f ${TUXDIR}/lib/TMQFORWARD.o -f apptypsw.o

buildserver オプションは次のとおりです。

サービスを宣言するための -s を指定してはなりません。

移植性

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

相互運用性

TMQFORWARD は相互運用するアプリケーションで実行できますが、BEA Tuxedo リリース 4.2 以降のノードで実行する必要があります。

使用例

*GROUPS # Windows の場合、:myqueue を ;myqueue にする 
TMQUEUEGRP LMID=lmid GRPNO=1 TMSNAME=TMS_QM 
   OPENINFO="TUXEDO/QM:/dev/device:myqueue"
# CLOSEINFO は必要ない 
 
*SERVERS # 推奨値は RESTART=Y GRACE=0 
TMQFORWARD SRVGRP="TMQUEUEGRP" SRVID=1001 RESTART=Y GRACE=0
   CLOPT=" -- -qservice1,service2" REPLYQ=N 
TMQUEUE SRVGRP="TMQUEUEGRP" SRVID=1000 RESTART=Y GRACE=0 
   CLOPT="-s ACCOUNTING:TMQUEUE"

関連項目

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

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

TMQUEUE(5)

名前

TMQUEUE-メッセージ・キュー・マネージャ

形式

TMQUEUE 
SRVGRP="identifier" 
SRVID="number" CLOPT=" [-A][servopts options] -- [-t timeout]"

機能説明

メッセージ・キュー・マネージャは BEA Tuxedo システムが提供するサーバで、tpenqueue() および tpdequeue() を呼び出すプログラムの代わりにキューへのメッセージの登録とキューからのメッセージの取り出しを実行します。アプリケーション管理者は、SERVERS セクションでこのサーバをアプリケーション・サーバとして指定することにより、アプリケーションでキューに対するメッセージの登録および取り出しを行うことができます。

位置指定、サーバ・グループ、サーバ識別子、その他の汎用サーバ関連パラメータは、サーバ用に定義されているコンフィギュレーション・ファイル機構を使用して、このサーバに関連付けられます。次に、カスタマイズに使用できる追加コマンド行オプションの一覧を示します。

TMQUEUE サーバはアプリケーションの一部として起動され、アプリケーションから関連するキュー・スペースへのアクセスを容易にします。キュー・スペースはキューの集まりです。

コンフィギュレーションの条件によっては、TMQUEUE がキューにメッセージを登録できないか、キューからメッセージを取り出せないことがあり、その場合 TMQUEUE サーバは起動時に異常終了します。SRVGRP では、TMSNAME が TMS_QM に設定されている必要があり、OPENINFO には関連するデバイスおよびキュー・スペースの名前が設定されている必要があります。

メッセージ要求時のキューの名前

tpenqueue() および tpdequeue() 関数は、第 1 引数としてキュー・スペースの名前をとります。この名前は、TMQUEUE によって宣言されたサービスの名前でなければなりません。デフォルトでは、TMQUEUE はサービス "TMQUEUE" だけを提供します。キュー・スペースを 1 つだけ使用するアプリケーションの場合はこれで十分ですが、複数のキュー・スペースを持つアプリケーションでは、異なるキュー・スペース名を必要とすることがあります。また、アプリケーションによっては、キュー・スペースと同じ名前のより説明的なサービス名を指定したい場合もあります。追加サービス名の宣言は、使用例にもあるように、標準のサーバ・コマンド行オプション -s を使用して行うことができます。また、この後の項で説明するように、カスタム TMQUEUE プログラムを生成するときにサービスをハード・コード化してこれを行うこともできます。

これらの方法 (サーバ・コマンド行オプション、またはカスタマイズされたサーバ) は、キュー・スペースにメッセージの静的ルーティングを行う場合に使用できますが、データ依存型ルーティングを使用して動的なルーティングを行うこともできます。この場合、各 TMQUEUE サーバは同じサービス名を宣言しますが、コンフィギュレーション・ファイルの ROUTING フィールドが使用されて、待機メッセージ内のアプリケーション・データに基づくルーティング基準が指定されます。ルーティング関数は、サービス名とアプリケーションの型付きバッファ・データに基づいて、GROUP を返します。この GROUP を使用して、指定のグループにあるサービスにメッセージが転送されます (なお、キュー・スペースは、OPENINFO 文字列に基づいて GROUP につき 1 つしか存在できません)。

アプリケーション・バッファ・タイプの処理

buildserver で記述されるカスタマイズは、サーバ用にサービス名をハード・コード化する場合にも使用できます。

呼び出し元によって組み込まれるファイルには、アプリケーション・バッファ・タイプ・スイッチおよびサポートされる必須のルーチンのみを入れてください。buildserver は、サーバ・オブジェクト・ファイル $TUXDIR/lib/TMQUEUE.o とアプリケーション・タイプ・スイッチのファイル (複数可) を結合し、これに必要な BEA Tuxedo システム・ライブラリをリンクするために使用されます。次の例を使用して、詳細を説明します。

buildserver -v -o TMQUEUE -s qspacename:TMQUEUE -r TUXEDO/QM ¥
-f ${TUXDIR}/lib/TMQUEUE.o -f apptypsw.o

buildserver オプションは次のとおりです。

移植性

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

相互運用性

TMQUEUE は相互運用するアプリケーションで実行できますが、BEA Tuxedo リリース 4.2 以降のノードで実行する必要があります。

使用例

*GROUPS 
# Windows の場合、:myqueue を ;myqueue にする 
TMQUEUEGRP1 GRPNO=1 TMSNAME=TMS_QM
   OPENINFO="TUXEDO/QM:/dev/device1:myqueue"
# Windows の場合、:myqueue を ;myqueue にする 
TMQUEUEGRP2 GRPNO=2 TMSNAME=TMS_QM
   OPENINFO="TUXEDO/QM:/dev/device2:myqueue"
 
*SERVERS 
# この例では、キュー・スペース名 myqueue に ACCOUNTING というエイリアスが付けられている
TMQUEUE SRVGRP="TMQUEUEGRP1" SRVID=1000 RESTART=Y GRACE=0 
    CLOPT="-s ACCOUNTING:TMQUEUE" 
TMQUEUE SRVGRP="TMQUEUEGRP2" SRVID=1000 RESTART=Y GRACE=0 
    CLOPT="-s ACCOUNTING:TMQUEUE" 
TMQFORWARD SRVGRP="TMQUEUEGRP1" SRVID=1001 RESTART=Y GRACE=0 REPLYQ=N 
    CLOPT=" -- -qservice1" 
TMQFORWARD SRVGRP="TMQUEUEGRP2" SRVID=1001 RESTART=Y GRACE=0 REPLYQ=N 
    CLOPT=" -- -qservice1" 
*SERVICES 
ACCOUNTING ROUTING="MYROUTING" 
*ROUTING 
MYROUTING FIELD=ACCOUNT BUFTYPE="FML" 
RANGES="MIN - 60000:TMQUEUEGRP1,60001-MAX:TMQUEUEGRP2"

この例では、2 つのキュー・スペースを使用できます。どちらの TMQUEUE サーバも同じサービスを提供し、ルーティングはアプリケーションの型付きバッファの ACCOUNT フィールドを介して行われます。

関連項目

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

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

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

TMSYSEVT(5)

名前

TMSYSEVT-システム・イベント通知プロセス

形式

TMSYSEVT SRVGRP="identifier" SRVID="number" 
  [CLOPT="[-A] [servopts options] 
  [-- [-S] [-p poll-seconds] [-f control-file]]"]

機能説明

TMSYSEVT は BEA Tuxedo システムが提供するサーバで、システム・エラーや潜在的なエラー状態に関するイベント通知を処理します。イベント・レポートはフィルタを通され、1 つまたは複数の通知アクションを開始できます。

1 つまたは複数の二次的な TMSYSEVT プロセスを起動して、可用性を高めることができます。追加サーバは、「セカンダリ・サーバ」であることを示すコマンド行オプション -S を指定して起動する必要があります。

相互運用性

TMSYSEVT は、BEA Tuxedo リリース 6.0 以降のマシンで実行する必要があります。

注意事項

プライマリ TMSYSEVT サーバを別のマシンに移行するには、システム管理者は現在の制御ファイルのコピーを提供する必要があります。セカンダリ TMSYSEVT サーバは、最新のコピーを自動的に維持します。

TMSYSEVT は、システム・イベントを定義した FML32 フィールド・テーブルへのアクセス手段が必要になります。FLDTBLDIR32 には $TUXDIR/udataobj が、FIELDTBLS32 には evt_mib がそれぞれ含まれている必要があります。これらの環境変数は、マシンまたはサーバの環境設定ファイルで設定できます。

使用例

*SERVERS 
TMSYSEVT SRVGRP=ADMIN1 SRVID=100 RESTART=Y GRACE=900 MAXGEN=5 
  CLOPT="-A --" 
TMSYSEVT SRVGRP=ADMIN2 SRVID=100 RESTART=Y GRACE=900 MAXGEN=5 
  CLOPT="-A -- -S -p 90"

関連項目

tmtrace(5)

名前

tmtrace-実行時のトレース機能

機能説明

実行時トレース機能を使用すると、アプリケーション管理者および開発者は、BEA Tuxedo アプリケーションの実行をトレースできます。

実行時トレースは、アプリケーション実行時の注意すべき条件または遷移をマークする、trace point の概念に基づいています。トレース・ポイントの例としては、tpcall などの ATMI 関数へのエントリ、BEA Tuxedo メッセージの到着、トランザクションの開始などがあります。

トレース・ポイントに到達すると、次のことが発生します。まず、フィルタfilter が適用され、トレース・ポイントを処理すべきかどうかを決定します。トレース・ポイントを処理すべき場合、trace record が receiver に発行されます。receiver はファイルか (将来は) バッファです。最後に、プロセスの中止などの action が起動されます。レシーバへの発行およびトリガはどちらもオプションであり、トレース・ポイントがフィルタを通らない場合には発生しません。

トレース・ポイントは、以下に列挙するような trace categories に分類されます。各トレース・ポイントは 1 つのカテゴリに属します。フィルタは、処理するトレース・カテゴリを記述し、フィルタを通らないトレース・ポイントには最小限の処理が行われます。

また、実行時トレーシングは、クライアントがサーバに送信したメッセージ (またはそのサーバから他のサーバへ) を dye 設定する機能を提供します。プロセスがメッセージをダイ設定するように選択した場合、発信元プロセスによってダイ設定が自動的に、発信元プロセスから直接または間接的にメッセージを受信するすべてのプロセスに渡されます。プロセスがダイ設定されたメッセージを受け取ると、atmi トレース・カテゴリが自動的にオンになり、ユーザ・ログへのトレース・レコードの発行が開始されます (発行が行われていなかった場合)。

ダイ設定は、トレース指定の dye トリガと undye トリガによって明示的にオンまたはオフにできます。また、ダイ設定は、ダイ設定されたメッセージが受信されたときに暗黙的にオンになり、tpreturn() および tpforward() によって暗黙的にオフにできます。ダイ設定が暗黙的にオフされた場合、ダイ設定がオンであったときに有効であったトレース指定が復元されます。

トレース・カテゴリ

トレース・カテゴリは以下のとおりです。

xa

トレース指定

トレース指定は、filter-spec: receiver-spec [ : trigger-spec] という構文で指定する文字列です。filter-spec は、検査または無視するトレース・カテゴリを記述します。receiver-spec は、トレース・レコードのレシーバです。オプションの trigger-spec は、実行するアクションを記述します。

ヌル文字列も有効なトレース指定です。ヌル文字は、他の指定がない場合のすべての BEA Tuxedo プロセスのデフォルトです。

文字列 on と off も指定できます。on は atmi:ulog:dye のエイリアスで、off は : :undye と等価です。

フィルタ指定

トレース指定の最初の要素であるフィルタ指定の構文は次のとおりです。

[ { + | - } ] [ category ] ...

ここで category は、上記にリストしたカテゴリの 1 つです。category の位置に記号 * を使用すると、すべてのカテゴリを表すことができます。接頭辞 + または - は、後続のカテゴリを現在有効なカテゴリのセットに追加またはそのセットから削除することを示します。+ または - の次にカテゴリがない場合、現在有効なカテゴリは変更されません。

フィルタが空の場合、カテゴリが 1 つも選択されず、トレースが使用不可になります。

トレース・ポイントが発生すると、そのカテゴリがフィルタ指定と比較されます。カテゴリがフィルタ指定に含まれている場合、トレース・ポイントは、レシーバおよびトリガ指定に従ってさらに処理されます。カテゴリが含まれていない場合、トレース・ポイントの処理はこれ以上発生しません。

レシーバ指定

レシーバは、トレース・レコードの送信先となるエンティティです。各トレース・レコードには、最大 1 つのレシーバがあります。

トレース指定の 2 番目の要素であるレシーバ指定の構文は次のとおりです。

[/ regular-expression /] receiver

ここでは、オプションの正規表現を使用して、フィルタを通過するトレース・ポイントの一部を選択できます。正規表現は、トレース・レコードと比較されます。空のレシーバ指定も有効であり、この場合、トレース・レコードは発行されません。

現在のところ、receiver の有効値は次の 1 つだけです。

トリガ指定

トリガは、トレース・レコードの発行後に実行されるオプションのアクションです。フィルタを通過した各トレース・レコードに対して、最大 1 つのアクションが実行されます。

トレース指定の 3 番目の要素であるトリガ指定の構文は次のとおりです。

[/ regular-expression /] action

ここでは、オプションの正規表現を使用して、フィルタを通過するトレース・ポイントの一部に対してだけトリガが実行されるよう設定できます。正規表現は、トレース・レコードと比較されます。

有効なアクションは次のとおりです。

トレース・レコード

トレース・レコードは、次の形式の文字列です。

cc:data

ここで cc はトレース・カテゴリの最初の 2 文字で、data はトレース・ポイントに関する追加情報です。

トレース・レコードがユーザ・ログに表示されるとき、その行は次のようになります。

hhmmss.system-name!process-name.pid: TRACE:cc:data

注意事項

MAC プラットフォームで動作するワークステーション・クライアントのレシーバやトリガに対しては、マッチ・パターンを指定することはできません。

tmadmin changetrace コマンドは、/WS クライアントに対するトレース・レベルを変更するために使用できません。

使用例

クライアントをトレースし、アプリケーション・サーバがそのクライアントの代わりに行ったすべての ATMI 呼び出しをトレースするには、クライアントの環境に TMTRACE=on を設定してエクスポートします。この指定により、クライアント内のすべての明示的な ATMI トレース・ポイントがログに記録され、メッセージのダイ設定がオンになります。こクライアントの代わりにサービスを実行するアプリケーション・サーバ・プロセスは、すべての明示的な ATMI トレース・ポイントを自動的にログに記録します。

すべての (明示的および暗黙的な) クライアント・トレース・ポイントを確認するには、次のように設定してエクスポートします。

TMTRACE="*:ulog:dye:" 

前述の例で、クライアントからのサービス要求はトレースし、クライアントからの出力のトレースを tpcall 要求についての最低限の情報に制限するには、次のように設定しエクスポートします。

TMTRACE=atmi:/tpacall/ulog:dye 

この指定により、クライアントで行われるすべての tpacall 呼び出しがログに記録され、メッセージのダイ設定がオンになります。クライアントの代わりにサービスを実行するアプリケーション・サーバ・プロセスは、すべての ATMI トレース・ポイントを自動的にログに記録します。tpacall() トレース・レコードに含まれるクライアントの識別子は、クライアントの代わりに呼び出されたサービス・ルーチンに渡される TPSVCINFO パラメータの値と相互に関連させることができます。

アプリケーション・サーバによって実行されたすべてのサービス要求の呼び出しをトレースするには、次のように設定します。

TMTRACE=atmi:/tpservice/ulog 

これは、参加しているすべてのマシン上のサーバ ENVFILE に設定します。

メッセージのダイ設定をオンにして、アプリケーションを通してすべてのトレース・カテゴリの実行時トレースを有効にするには、次のように設定してエクスポートします。

TMTRACE=*:ulog:dye 

これは、すべてのクライアント環境および参加しているすべてのマシン上のサーバ ENVFILE に設定します。この設定では、BBL と DBBL を含むすべてのプロセスがトレース・レコードを発行するので、管理できない量の出力が生成される可能性があります。

グループ GROUP1 内の実行中のすべてのサーバで、起動後に ATMI のトレースをオンにするには、次のように tmadmin の changetrace コマンドを呼び出します。

changetrace -g GROUP1 on 

changetrace は現在存在しているプロセスに対してのみ影響します。つまり、グループ GROUP1 内で起動していないサーバのトレース・コンフィギュレーションは変更されません (サーバのデフォルトのトレース・コンフィギュレーションを設定するには、サーバの ENVFILE に TMTRACE を設定します)。

現在実行中のすべてのアプリケーション・プロセスでトレーシングをオフにするには、次のように changetrace を使用します。

changetrace -m all off 

グループ GROUP1 内で識別子が 1 の実行中のサーバ・プロセスを tpreturn の実行時に中止するには、tmadmin に対して次のように指定します。

changetrace -i 1 -g GROUP1 "atmi::/tpreturn/abort" 

関連項目

TMUSREVT(5)

名前

TMUSREVT-ユーザ・イベント通知プロセス

形式

TMUSREVT SRVGRP="identifier" SRVID="number" 
  [CLOPT="[-A] [servopts options] 
  [-- [-S] [-p poll-seconds] [-f control-file]]"]

機能説明

1 つまたは複数の二次的な TMUSREVT プロセスを起動して、可用性を高めることができます。追加サーバは、「セカンダリ・サーバ」であることを示すコマンド行オプション -S を指定して起動する必要があります。

相互運用性

TMUSREVT は、BEA Tuxedo リリース 6.0 以降のマシンで実行する必要があります。

注意事項

プライマリ TMUSREVT サーバを別のマシンに移行するには、システム管理者は現在の制御ファイルのコピーを提供する必要があります。セカンダリ TMUSREVT サーバは、最新のコピーを自動的に維持します。

tppost() をトランザクション・モードで呼び出す場合は、すべての TMUSREVT サーバ・グループがトランザクション機能 (TMS プロセス) を備えている必要があります。

TMUSREVT サーバの環境変数は、メッセージにフィルタを適用したりフォーマットする際に必要となる FML フィールド・テーブルや VIEW ファイルを使用できるように設定しておく必要があります。これらの環境変数は、マシンまたはサーバの環境設定ファイルで設定できます。

使用例

*SERVERS
TMUSREVT SRVGRP=ADMIN1 SRVID=100 RESTART=Y MAXGEN=5 GRACE=3600
CLOPT="-A --"
TMUSREVT SRVGRP=ADMIN2 SRVID=100 RESTART=Y MAXGEN=5 GRACE=3600
CLOPT="-A -- -S -p 120"

関連項目

tperrno(5)

名前

tperrno-BEA Tuxedo システム・エラー・コード

形式

#include <atmi.h>

機能説明

エラー条件のシンボル名によって表される数値は、BEA Tuxedo システム・ライブラリ・ルーチンの実行時に発生するエラー用の tperrno に割り当てられます。

tperrno は、int 型の変更可能な lvalue の拡張です。lvalue の値は、複数の BEA Tuxedo システム・ライブラリ・ルーチンによって正のエラー番号に設定されます。tperrno はオブジェクトの識別子である必要はなく、lvalue 関数呼び出しの結果、変更可能な lvalue に拡張される場合があります。tperrno がマクロであるかまたは外部リンクで宣言される識別子であるかは特定されていません。実際のオブジェクトをアクセスするための tperrno マクロの定義が抑止されている場合、または、あるプログラムが名前 tperrno を使用して識別子を定義している場合、動作は不確定です。

BEA Tuxedo システム・ライブラリ・ルーチンのリファレンス・ページには、各ルーチンのエラー条件とそのコンテキストにおけるエラーの意味が掲載されています。掲載されているエラーの順番は重要ではなく、優先順位を示すものでもありません。tperrno の値は、エラーが指摘された後にのみ検査します。すなわち、構成要素の戻り値がエラーを示していて、構成要素の定義で tperrno のエラー時の設定が指定されている場合です。tperrno の値を検査するアプリケーションは、ヘッダ・ファイル <atmi.h> をインクルードしなければなりません。

以下に、各エラーの一般的な意味を示します。

使用法

ルーチンには、エラーの戻り値がないものもあります。tperrno をゼロに設定するルーチンはないため、アプリケーションは、tperrno をゼロに設定し、ルーチンを呼び出してから、エラーが発生したかを調べるために再度 tperrno をチェックできます。

関連項目

個々の BEA Tuxedo ライブラリ・ルーチンの ERRORS の項を参照してください。

tpurcode(5)

名前

tpurcode-アプリケーションが指定する戻りコードのための BEA Tuxedo システムのグローバル変数

形式

#include <atmi.h>

機能説明

tpurcode は、atmi.h で定義されるグローバル変数です。その値は、tpreturn() の rcode 引数の値として使用されているものと同じ長さの整数です。tpurcode はアプリケーションで使用され、アプリケーション・サービスを呼び出すプロセスに追加的な情報を返す場合があります。詳細については、tpreturn() を参照してください。

アプリケーションが tpurcode の値に意味を割り当てます。

使用例

以下に、tpurcode の使用例を示します。

アプリケーション・サービスで rcode により値 myval を返す場合、次のようになります。

.
.
.
tpreturn(TPSUCCESS, myval, rqst->data, 0L, 0);
.
.
.

モジュールのコードは、次のようになります。

.
.
.
ret = tpcall("TOUPPER", (char *)sendbuf, 0, (char **)&rcvbuf, ¥ &rcvlen, (long)0);
.
.
.
(void) fprintf(stdout, "Returned string is: %s¥n", rcvbuf);
(void) fprintf(stdout, "Returned tpurcode is:%d¥n", tpurcode);

サンプル・クライアント simpcl を "My String," という値で呼び出した場合、次のように出力されます。

%simpcl "My String"
Returned string is: MY STRING
Returned tpurcode is: myval

myval の意味はアプリケーションで定義する必要があります。

関連項目

tuxenv(5)

名前

tuxenv-BEA Tuxedo システムでの環境変数のリスト

機能説明

アプリケーションのクライアントとサーバをコンパイルし、BEA Tuxedo システムを実行するには、正しい環境変数の設定とエクスポートが重要です。ここでは、最も使用頻度の高い変数について説明します。

環境変数は、以下のセクションにグループ分けされています。

オペレーティング・システム変数

これらの変数についての詳細は、UNIX システムのリファレンス・ページ environ(5) を参照してください。

キー BEA Tuxedo システム変数

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

これらの変数の詳細については、『C 言語を使用した BEA Tuxedo アプリケーションのプログラミング』、『BEA Tuxedo アプリケーションの設定』、および『BEA Tuxedo アプリケーション実行時の管理』を参照してください。

フィールド・テーブル・ファイルおよび VIEW ファイル用の変数

FML および VIEWS で使用される環境変数は以下のとおりです。

これらの変数の詳細については、『BEA Tuxedo アプリケーションの設定』、『BEA Tuxedo アプリケーション実行時の管理』、『C 言語を使用した BEA Tuxedo アプリケーションのプログラミング』、および『FML を使用した BEA Tuxedo アプリケーションのプログラミング』を参照してください。

ファイル・システムおよび TLOG 変数

以下の変数は、BEA Tuxedo システムのファイル・システムおよびトランザクション・ログで使用します。

ワークステーション変数

以下の変数は、/WS クライアント・マシンで使用します。

これらの変数の詳細については、『BEA Tuxedo Workstation コンポーネント』を参照してください。

BEA Tuxedo /Q 変数

以下の変数は、BEA Tuxedo /Q で使用します。

詳細については、『BEA Tuxedo /Q コンポーネント』を参照してください。

COBOL 変数

以下の環境変数は、COBOL で使用します。

COBDIR

これらの変数の詳細については、『COBOL を使用した BEA Tuxedo アプリケーションのプログラミング』を参照してください。

その他の変数

以下の環境変数も使用できます。

関連項目

UNIX システムのリファレンス・マニュアルの cc(1)、environ(5)

tuxtypes(5)

名前

tuxtypes-バッファ・タイプ・スイッチ、BEA Tuxedo システムによって提供されるバッファ・タイプの説明

形式

デフォルトのバッファ・タイプ・スイッチ

/*
 * 以下の定義は、
 * $TUXDIR/lib/tmtypesw.c に指定されている
 */

#include <stdio.h>
#include <tmtypes.h>

/* 
 * バッファ・タイプ・スイッチの初期化
 */

struct tmtype_sw_t tm_typesw[] = { 
{
      "CARRAY",     /* type */
      "*",          /* subtype */
      0             /* dfltsize */
      NULL,         /* initbuf */
      NULL,         /* reinitbuf */
      NULL,         /* uninitbuf */
      NULL,         /* presend */
      NULL,         /* postsend */
      NULL,         /* postrecv */
      NULL,         /* encdec */
      NULL,         /* route */
      NULL,         /* filter */
      NULL,         /* format */
      NULL,         /* presend2 */
      NULL          /* multibyte code-set encoding conversion */
},
{
      "STRING",        /* type */
      "*",             /* subtype */
      512,             /* dfltsize */
      NULL,            /* initbuf */
      NULL,            /* reinitbuf */
      NULL,            /* uninitbuf */
      _strpresend,     /* presend */
      NULL,            /* postsend */
      NULL,            /* postrecv */
      _strencdec,      /* encdec */
      NULL,            /* route */
      _sfilter,        /* filter */
      _sformat,        /* format */
      NULL,            /* presend2 */
      NULL             /* multibyte code-set encoding conversion */
},
{
      "FML",           /* type */
      "*",             /* subtype */
      1024,            /* dfltsize */
      _finit,          /* initbuf */
      _freinit,        /* reinitbuf */
      _funinit,        /* uninitbuf */
      _fpresend,       /* presend */
      _fpostsend,      /* postsend */
      _fpostrecv,      /* postrecv */
      _fencdec,        /* encdec */
      _froute,         /* route */
      _ffilter,        /* filter */
      _fformat,        /* format */ 
      NULL,            /* presend2 */
      NULL             /* multibyte code-set encoding conversion */
},
{ 
      "VIEW",          /* type */
      "*",             /* subtype */
      1024,            /* dfltsize */
      _vinit,          /* initbuf */
      _vreinit,        /* reinitbuf */
      NULL,            /* uninitbuf */
      _vpresend,       /* presend */
      NULL,            /* postsend */
      NULL,            /* postrecv */
      _vencdec,        /* encdec */
      _vroute,         /* route */
      _vfilter,        /* filter */
      _vformat,        /* format */
      NULL,            /* presend2 */
      NULL             /* マルチバイト・コード・セット符号化変換 */
},
{
      /* XATMI - CARRAY と同じ */ 
      "X_OCTET",       /* type */
      "*",             /* subtype */
      0                /* dfltsize */
},
{    /* XATMI - VIEW と同じ */ 

      {'X','_','C','_','T','Y','P','E'},      /* type */
      "*",             /* subtype */
      1024,            /* dfltsize */
      _vinit,          /* initbuf */
      _vreinit,        /* reinitbuf */
      NULL,            /* uninitbuf */
      _vpresend,       /* presend */
      NULL,            /* postsend */
      NULL,            /* postrecv */
      _vencdec,        /* encdec */
      _vroute,         /* route */
      _vfilter,        /* filter */
      _vformat,        /* format */
      NULL,            /* presend2 */
      NULL             /* マルチバイト・コード・セット符号化変換 */
},
{
     /* XATMI - VIEW と同じ */ 
      {'X','_','C','O','M','M','O','N'},      /* type */
      "*",             /* subtype */
      1024,            /* dfltsize */
      _vinit,          /* initbuf */
      _vreinit,        /* reinitbuf */
      NULL,            /* uninitbuf */
      _vpresend,       /* presend */
      NULL,            /* postsend */
      NULL,            /* postrecv */
      _vencdec,        /* encdec */
      _vroute,         /* route */
      _vfilter,        /* filter */
      _vformat,        /* format */
      NULL,            /* presend2 */
      NULL             /* マルチバイト・コード・セット符号化変換 */
},
{
      "FML32",         /* type */
      "*",             /* subtype */
      1024,            /* dfltsize */
      _finit32,        /* initbuf */
      _freinit32,      /* reinitbuf */
      _funinit32,      /* uninitbuf */
      _fpresend32,     /* presend */
      _fpostsend32,    /* postsend */
      _fpostrecv32,    /* postrecv */
      _fencdec32,      /* encdec */
      _froute32,       /* route */
      _ffilter32,      /* filter */
      _fformat32,      /* format */
      _fpresend232     /* presend2 */

      _fmbconv32       /* マルチバイト・コード・セット符号化変換 */
},
{
      "VIEW32",        /* type */
      "*",             /* subtype */
      1024,            /* dfltsize */
      _vinit32,        /* initbuf */
      _vreinit32,      /* reinitbuf */
      NULL,            /* uninitbuf */
      _vpresend32,     /* presend */
      NULL,            /* postsend */
      NULL,            /* postrecv */
      _vencdec32,      /* encdec */
      _vroute32,       /* route */
      _vfilter32,      /* filter */
      _vformat32,      /* format */
      NULL,            /* presend2 */
      NULL             /* マルチバイト・コード・セット符号化変換 */
},
{
     "XML",            /* type */ 
      "*",             /* subtype */ 
      0,               /* dfltsize */ 
      NULL,            /* initbuf */ 
      NULL,            /* reinitbuf */ 
      NULL,            /* uninitbuf */ 
      NULL,            /* presend */ 
      NULL,            /* postsend */ 
      NULL,            /* postrecv */ 
      NULL,            /* encdec */ 
      _xroute,         /* route */ 
      NULL,            /* filter */ 
      NULL,            /* format */
      NULL,            /* presend2 */
      NULL             /* マルチバイト・コード・セット符号化変換 */
},
{
      "MBSTRING",     /* type */
      "*",            /* subtype */
      0,              /* dfltsize */
      _mbsinit,     /* initbuf */
      NULL,           /* reinitbuf */
      NULL,           /* uninitbuf */
      NULL,           /* presend */
      NULL,           /* postsend */
      NULL,           /* postrecv */
      NULL,           /* encdec */
      NULL,           /* route */
      NULL,           /* filter */

      NULL,           /* format */
      NULL,           /* presend2 */
      _mbsconv      /* マルチバイト・コード・セット符号化変換 */
},
{
""
} 
};

struct tmtype_sw_t _TM_FAR *
_TMDLLENTRY
_tmtypeswaddr(void)
{
  return(tm_typesw);
}

機能説明

次の表に、BEA Tuxedo システムの 11 のバッファ・タイプを示します。

すべての VIEW、X_C_TYPE、および X_COMMON バッファは同じルーチン・セットで処理され、特定の VIEW の名前はそのサブタイプの名前です。

カスタム・バッファ・タイプを指定する場合には、上記の tm_typesw 配列にインスタンスを追加します。新しいバッファ・タイプを追加したり、既存のバッファ・タイプを削除したりする場合は、上に示したように配列の最後に NULL エントリを残しておく必要があります。バッファ・タイプに NULL 名を指定することはできません。

デフォルトの配列のコピーは $TUXDIR/lib/tmtypesw.c で配布され、開始点として使用されます。新しいバッファ・タイプ・スイッチをインストールする手順として推奨されるのは、tmtypesw.c をコンパイルし、libbuft というライブラリ内に唯一の要素として格納することです。

共有オブジェクト機能を持つシステムでは、$TUXDIR/lib の下に libbuft.so. という新しいインスタンスを作成およびインストールします。WSH などの BEA Tuxedo システム・プロセスを含むすべてのプロセスは、再コンパイルしなくても新しいタイプ・スイッチに自動的にアクセスできるようになります。Windows のワークステーションでは、バッファ・タイプ・スイッチのための共有オブジェクトは WBUFT.DLL です。これは、$TUXDIR¥bin に格納される必要があります。

ファイル

$TUXDIR/tuxedo/include/tmtypes.h-タイプ・スイッチの定義
$TUXDIR/lib/tmtypesw.c-デフォルト・タイプ・スイッチのインスタンス
$TUXDIR/lib/libbuft.so.-タイプ・スイッチ共有オブジェクト 
$TUXDIR/lib/libbuft.a-タイプ・スイッチ・アーカイブ・ライブラリ

関連項目

typesw(5)

名前

typesw-バッファ・タイプ・スイッチ構造体、各バッファ・タイプに必要なパラメータとルーチン

形式

バッファ・タイプ構造体

/*
 * 以下の定義は、$TUXDIR/include/tmtypes.h に存在する
 */
#define TMTYPELEN  ED_TYPELEN 
#define TMSTYPELEN ED_STYPELEN

struct tmtype_sw_t {
   char type[TMTYPELEN];      /* バッファのタイプ */
   char subtype[TMSTYPELEN];  /* バッファのサブタイプ */
   long dfltsize;             /* バッファのデフォルト・サイズ */
   /* バッファ初期化関数ポインタ */
   int (_TMDLLENTRY *initbuf) _((char _TM_FAR *, long));

   /* バッファ再初期化関数ポインタ */
   int (_TMDLLENTRY *reinitbuf) _((char _TM_FAR *, long));

   /* バッファ非初期化関数ポインタ */
   int (_TMDLLENTRY *uninitbuf) _((char _TM_FAR *, long));

   /* バッファ送信前操作関数ポインタ */
   long (_TMDLLENTRY *presend) _((char _TM_FAR *, long, long));

   /* バッファ送信後操作関数ポインタ */
   void (_TMDLLENTRY *postsend) _((char _TM_FAR *, long, long));

   /* バッファ受信後操作関数ポインタ*/
   long (_TMDLLENTRY *postrecv) _((char _TM_FAR *, long, long));

   /* XDR 符号化/復号化関数ポインタ */
   long (_TMDLLENTRY *encdec) _((int, char _TM_FAR *, long, char _TM_FAR *, long));

   /* ルーティング関数ポインタ */
   int (_TMDLLENTRY *route) _((char _TM_FAR *, char _TM_FAR *, char _TM_FAR *, 
       long, char _TM_FAR *));

   /* バッファ・フィルタ関数ポインタ */
   int (_TMDLLENTRY *filter) _((char _TM_FAR *, long, char _TM_FAR *, long));

   /* バッファ・フォーマット関数ポインタ */
   int (_TMDLLENTRY *format) _((char _TM_FAR *, long, char _TM_FAR *, 
       char _TM_FAR *, long));

   /* 送信前のバッファの処理、コピーを生成する場合がある */
   long (_TMDLLENTRY *presend2) _((char _TM_FAR *, long, 
       long, char _TM_FAR *, long, long _TM_FAR *));

   /* マルチバイト・コード・セット符号化変換関数ポインタ*/
   long (_TMDLLENTRY *mbconv) _((char _TM_FAR *, long, 
       char _TM_FAR *, char _TM_FAR *, long, long _TM_FAR *));

   /* この領域は将来の拡張のために予約されている */
   void (_TMDLLENTRY *reserved[8]) _((void));
};
/* 
 * アプリケーション・タイプ・スイッチ・ポインタ
 * テーブルへのアクセス時には常にこのポインタを使用
 */
extern struct tmtype_sw_t *tm_typeswp;

機能説明

ファイル

$TUXDIR/tuxedo/include/tmtypes.h-タイプ・スイッチの定義
$TUXDIR/lib/tmtypesw.c-タイプ・スイッチのインスタンス

関連項目

UBBCONFIG(5)

名前

UBBCONFIG-テキスト形式の BEA Tuxedo コンフィギュレーション・ファイル

機能説明

BEA Tuxedo UBBCONFIG ファイルにはどのような名前を付けることもできますが、ファイルの内容はこのリファレンス・ページで説明する形式に準拠している必要があります。また、TUXCONFIG ファイルにも任意の名前を付けることができますが、実際の名前は TUXCONFIG 環境変数で指定されたデバイス・ファイル名またはシステム・ファイル名になります。

定義

サーバとは、要求を受け付け、その応答をクライアントや別のサーバに送信するプロセスです。一方、クライアントは要求を送信し、その応答を受け取ります。

リソース・マネージャとは、情報やプロセス (またはその両方) の集まりへのアクセスを提供するインターフェイスおよび関連ソフトウェアです。リソース・マネージャの例としては、データベース管理システムがあります。リソース・マネージャのインスタンスとは、DBMS によって制御される、特定のデータベースのインスタンスのことです。分散トランザクションとは、複数のリソース・マネージャのインスタンスにまたがるトランザクションのことで、tpbegin() で開始され、tpcommit() または tpabort() で完了します。

サーバ・グループはリソース・マネージャのインスタンスであり、特定のマシン上に配置されたこのリソース・マネージャ・インスタンスへのアクセスを提供するサーバやサービスの集合です。このサーバ・グループに関連付けられている XA インターフェイスは、トランザクション管理に使用されます。サーバがリソース・マネージャのインスタンスにアクセスしないか、または分散型トランザクションの一部としてリソース・マネージャのインスタンスにアクセスしない場合は、そのサーバはサーバ・グループにあって、空の XA インターフェイスを持つ必要があります。NULL同様に、クライアントは GROUPS セクションで指定する必要のない、特別なクライアント・グループ内で動作します。このクライアント・グループはリソース・マネージャには関連付けられません。

リモート・ドメインは、この BEA Tuxedo システム・コンフィギュレーションの掲示板が使用できない環境として定義されます。リモート・ドメインは UBBCONFIG コンフィギュレーション・ファイルには指定せず、ホスト固有のリファレンス・ページに指定されているホスト固有の環境変数を介して定義します。

コンフィギュレーション・ファイルの形式

UBBCONFIG ファイルは、9 つの指定セクションで構成されます。先頭にアスタリスク (*) が付いている行は、指定セクションの始まりを示します。このような行にはそれぞれ、* のすぐ後にセクション名が含まれています。使用可能なセクションは次のとおりです。

RESOURCES および MACHINES セクションは、この順序で最初に置く必要があります。GROUPS セクションは、SERVERS、SERVICES、および ROUTING セクションの前になければなりません。NETGROUPS セクションは、NETWORK セクションの前になければなりません。

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

予約語の DEFAULT で始まる行にはパラメータ指定が含まれており、セクション内の以降の該当するすべての行に対して適用されます。デフォルトの指定は RESOURCES セクション以外のすべてのセクションで使用することができ、また 1 つのセクションで複数回使用することもできます。これらの行のフォーマットは次のとおりです。

DEFAULT: [optional KEYWORD=value pairs]

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

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

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

注記 識別子を二重引用符で囲む必要はありません。

整数でも識別子でもない値は、二重引用符で囲む必要があります。この値はユーザ定義の string です。ユーザ定義の文字列は、最後のヌル文字を除き最大 78 文字 (バイト) です。この規則には、以下のような例外があります。

ROUTING セクションの RANGES パラメータでは、特定の文字はバックスラッシュを用いることによって文字列の中でエスケープすることができます。

"¥¥" は 1 つのバックスラッシュ
"¥"" は二重引用符
"¥n" は復帰改行
"¥t" はタブ
"¥f" は用紙送り
"¥O+" は 8 進数の値が 0+ である文字と解釈

O+ は 1 桁、2 桁、または 3 桁の 8 進文字を表します。"¥0" は、埋め込みヌル文字と解釈されます。"¥xH+" または "¥XH+" は、16 進数の値が H+ である文字と解釈されます。H+ は 1 桁または複数桁の 16 進文字です。"¥y" (‘y’ は上記以外のすべての文字) は、‘y’ と解釈されます。

"#" (シャープ記号) はコメントを示します。復帰改行文字でコメントを終了します。

識別子または数値定数には、常に空白類 (スペースまたはタブ文字)、復帰改行文字、または句読文字 (シャープ記号、等号、アスタリスク、コロン、カンマ、バックスラッシュ、またはピリオド) が付加されます。

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

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

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