|
|
Oracle Tuxedo /Qの管理者は、次の3つのタスクを行います。
構成やキューの属性には、アプリケーションの要件が反映されていなければなりません。そのため、アプリケーション開発者とプログラマがよく協力することが大切です。
キュー機能の使い方を簡単に示すサンプルがソフトウェアに提供されています。詳細は、「サンプル・アプリケーション」を参照してください。
Oracle Tuxedo /Qコンポーネントには、3つのサーバーが提供されています。1つは、TMS_QMというOracle Tuxedo /Qリソース・マネージャ用のトランザクション・マネージャ・サーバー(TMS)です。このサーバーは、キュー機能でグローバル・トランザクションを管理します。このサーバーは、構成ファイルのGROUPSセクションで定義されていることが必要です。
ほかの2つは、TMQUEUE(5)およびTMQFORWARD(5)で、ユーザーにサービスを提供します。この2つのサーバーは、構成ファイルのSERVERSセクションで定義されている必要があります。
TMQFORWARDの機能がアプリケーションのニーズを完全には満たさない場合、アプリケーション独自のキュー・サーバーを作成することもできます。たとえば、エラー・キューに移動したメッセージをキューから取り出す特別なサーバーが必要な場合があります。
アプリケーションでは、ピア・ツー・ピア通信を選択することもできます。この通信では、転送サーバーを使用せずに、アプリケーションはほかのアプリケーションと、クライアントはほかのクライアントと通信します。
標準要件であるグループ名のタグおよびGRPNOの値(詳細についてはUBBCONFIG(5)を参照)のほかに、アプリケーションが使用するキュー・スペースごとに1つのサーバー・グループを定義する必要があります。TMSNAMEおよびOPENINFOパラメータを設定する必要があります。次は、この2つのパラメータの例です。
TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:<device_name:<queue_space_name>"
TMS_QMは、Oracle Tuxedo /Qのトランザクション・マネージャ・サーバーの名前です。OPENINFOパラメータのTUXEDO/QMは、$TUXDIR/udataobj/RMにあるリソース・マネージャのリテラル名です。<device_name>および<queue_space_name>の値は、状況に応じて決定され、汎用デバイス・リストのパス名、およびキュー・スペースに関連付けられた名前をそれぞれ設定する必要があります。これらの値は、qmadmin(1)を使用して、Oracle Tuxedoの管理者が指定します。
| 注意: | これらの値は、時系列順に指定されている必要はありません。構成ファイルは、キュー・スペースを定義する前でも定義した後でも作成できます。構成が定義され、以前に作成されたキュー・スペースとキューが使用できることが重要です。 |
GROUPSセクションのエントリごとに、キュー・スペースを1つだけ使用できます。CLOSEINFOパラメータは使用されません。
次は、TMQUEUE(5)のリファレンス・ページから引用した例です。
*GROUPS
TMQUEUEGRP1 GRPNO=1 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device1:myqueuespace"
TMQUEUEGRP2 GRPNO=2 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device2:myqueuespace"
TMQUEUE(5)リファレンス・ページでは、構成ファイルのSERVERSセクションについて詳しく説明しています。ここでは、特に大切な内容について説明します。
TMQUEUEでタイムアウトが認識されるのは、CLOPTパラメータで2つのダッシュ(--)の後に-t timeoutオプションが指定されている場合です。このタイムアウト値は、サーバーでトランザクションが有効ではないことが検出された場合に、サーバー内で開始された操作に適用されます。つまり、クライアントがtpbegin(3c)を呼び出さずにtpenqueue(3c)またはtpdequeue(3c)を呼び出した場合、トランザクションは有効になっていません。または、クライアントがトランザクションを開始し、TPNOTRANフラグを設定してクライアントのトランザクションでキューにリクエストを登録しない場合に、tpenqueue()またはtpdequeue()を呼び出したときも、トランザクションは有効になっていません。timeoutのデフォルト値は30秒です。tpdequeueリクエストの応答でflagsにTPQWAITが設定されている場合、待ち時間が-t timeoutに指定された時間(秒単位)を超えると、TPETIMEエラーが返されます。
| 注意: | ctlは、TPQCTL型の構造体で、tpenqueue(3c)およびtpdequeue(3c)で使用されて、呼出し側プロセスとシステム間でパラメータの受け渡しが行われます。TPQWAITは、tpdequeueのフラグ設定の1つで、プロセスが応答メッセージを待機することを示します。この構造体の詳細は、「TPQCTL構造体」および「TPQUEDEF-REC構造体」を参照してください。COBOLでこれに相当するものは、TPQUEDEF-RECレコードです。 |
キュー・スペース名、キュー名、およびサービス名は、混同しやすいので注意してください。まず、メッセージ・キュー・サーバーTMQUEUEの指定では注意が必要です。このサーバーを構成ファイルで指定する場合は、CLOPTパラメータの-sフラグを使用して、サーバーのあるインスタンスからサービスを受け取るキュー・スペースの名前を指定できます。これは、関数TMQUEUEで宣言されたサービスと同じです。キュー・スペースを1つだけ使用するアプリケーションでは、CLOPT -sオプションを指定する必要はありません。デフォルトの-s TMQUEUE:TMQUEUEが使用されます。アプリケーションに複数のキュー・スペースが必要な場合、キュー・サーバーのSERVERSセクションの-sオプションの引数として、キュー・スペースの名前を指定します。
この指定を行う別の方法としては、buildserver(1)を使用してメッセージ・キュー・サーバーを再度ビルドし、同じように-sオプションを使用してキュー・スペースの名前を指定することができます。この方法では、実行可能サーバーにサービス名が固定、つまり「ハード・コーディング」されます。
# The following two specifications are equivalent:
*SERVERS
TMQUEUE SRVGRP="TMQUEUEGRP1" SRVID=1000 RESTART=Y GRACE=0 \
CLOPT="-s myqueuespace:TMQUEUE"
and
buildserver -o TMQUEUE -s myqueuespace:TMQUEUE -r TUXEDO/QM \
-f ${TUXDIR}/lib/TMQUEUE.o
followed by
..
..
..
TMQUEUE SRVGRP="TMQUEUEGRP1" SRVID=1000 RESTART=Y GRACE=0 \
CLOPT="-A"
前の節で、メッセージ・キュー・サーバー内のサービス(キュー・スペース名)の指定について説明しました。この機能を使用すると、キューのデータ依存型ルーティングを行うことができます。データ依存型ルーティングでは、メッセージがキューに登録されて、メッセージ・バッファのフィールド値に応じて特定のグループ内のサービスによって処理されます。その場合、同じキュー・スペース名を2つの異なるグループに指定します。そして、ルーティングを構成ファイルで設定して、キューにあるメッセージの処理を行うグループを指定します。次は、TMQUEUE(5)のリファレンス・ページから引用した例です。キュー・スペース名は変えてあります。
*GROUPS
TMQUEUEGRP1 GRPNO=1 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device1:myqueuespace"
TMQUEUEGRP2 GRPNO=2 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device2:myqueuespace"
*SERVERS
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"
*SERVICES
ACCOUNTING ROUTING="MYROUTING"
*ROUTING
MYROUTING FIELD=ACCOUNT BUFTYPE="FML" \
RANGES="MIN-60000:TMQUEUEGRP1,60001-MAX:TMQUEUEGRP2"
TMQUEUEでは、ATMIのすべての標準バッファ・タイプがサポートされています。アプリケーションでほかのバッファ・タイプを追加する必要がある場合は、$TUXDIR/tuxedo/tuxlib/types/tmsypesw.cをコピーし、独自のバッファ・タイプのエントリを追加し、最終行のNULLが残っていることを確認し、変更したファイルをbuildserver(1)コマンドへの入力として使用します。buildserverコマンドの使用例については、TMQUEUE(5)のリファレンス・ページを参照してください。
追加したサーバー名は、CLOPTパラメータ(前述を参照)に指定せずに、buildserverコマンドの-sオプションを使用してTMQUEUEに関連付けることができます。
バッファのサブタイプはtpalloc(3c)サブタイプ・パラメータを使用して割り当てることができ、tptypes(3c)関数を使用して後でそれを取得できます。この機能により、ユーザー定義のATMIバッファ・タイプを新しく作成せずに、データに型を割り当てることができます。これは、文字配列(CARRAY)または文字列(STRING)を含むバッファで特に有用です。
TMQFORWARD(5)は、Oracle Tuxedo /Qで提供される3番目のサーバーです。このサーバーは、指定されたキューからメッセージを取り出し、tpcall(3c)を介してそのメッセージをOracle Tuxedoサーバーに渡し、対応する応答メッセージを処理します。構成ファイルでサーバーを定義する方法については、TMQFORWARD(5)のリファレンス・ページを参照してください。ここでは、特に大切な内容について説明します。
TMQFORWARDは1つのサーバーであり、アプリケーションで使用される各インスタンスは、構成ファイルのSERVERSセクションで定義されていなければなりません。ただし、TMQFORWARDには、通常のサーバーとは異なる次のような特徴があります。例:
TMQFORWARDのインスタンスは、キューに対応するサーバー・グループを使用して、そのキュー・スペースに結び付けられます。特に、そのグループのOPENINFO文の第3フィールドを使用して、キュー・スペースと結び付けられます。以下に、これ以外の主なパラメータ、特に2つのダッシュに続くCLOPTパラメータについて説明します。
-qqueuename,queuenameは必須パラメータです。 . .このパラメータは、サーバーのこのインスタンスが確認する1つ以上のキューを指定します。queuenameは、最大127文字までのNULLで終了する文字列です。これはTMQFORWARDによって一度キューから取り出された待機メッセージを処理するアプリケーション・サービス名と同じです。また、この名前は、メッセージ・キュー・サーバーTMQUEUEを呼び出す準備をするときに、プログラマがtpenqueue(3c)またはtpdequeue(3c)の2番目の引数として指定する名前でもあります。
TMQFORWARDは、TMQFORWARDが開始して終了するトランザクション内で機能します。-t trantimeオプションは、トランザクションがタイムアウトになるまでの時間(秒単位)を指定します。TMQFORWARDがキュー上にメッセージがあることを確認すると、トランザクションが開始されます。応答が応答キューまたは異常終了キューのいずれかに登録されると、そのトランザクションがコミットされます。そのため、トランザクションには、メッセージを処理するサービスの呼出しと応答の受信が含まれています。デフォルト値は60秒です。
TMQFORWARDは一度呼び出されると、割り当てられているキューを定期的に確認します。キューが空であった場合は、-i idletime秒間停止してから再度確認を行います。値が指定されていない場合、デフォルト値の30秒が使用されます。この値を0に設定すると、キューが継続的に確認されます。これは、キューが空の場合が多いときは、CPUリソースを浪費することになります。
-eオプションが指定されていると、キューが空の場合にサーバーが正常に停止し、ユーザー・ログ・メッセージが生成されます。この機能は、キューに指定するしきい値コマンドに対して使用します。-eオプションとしきい値コマンドの詳細は、「キュー・スペースとキューの作成」を参照してください。
サービス・リクエストがTMQFORWARDから呼び出された後で異常終了した場合、トランザクションはロールバックされ、後で再試行できるようにメッセージは(キューに指定された再試行の制限回数まで)キューに戻されます。-dオプションを使用すると、次の処理も行われます。つまり、異常終了したサービスでNULL以外の応答が返された場合、異常終了キューがメッセージに関連付けられ、キューが存在するときは、応答(および、それに関連付けられたtpurcode)が異常終了キューに登録されて元のリクエスト・メッセージは削除されます。また、-dオプションを使用すると、キューに設定されてた再試行回数の制限値に達すると同時に元のリクエスト・メッセージが削除され、元のリクエスト・メッセージはエラー・キューに登録されます。
このオプションで重要なことは、ただむやみに再試行するのではなく、発信元のライアントが異常終了メッセージを調べ、再試行が必要であるかどうかを判断するようにコーディングできることです。これにより、本質的な問題、たとえば、アカウントが存在していないために、レコードが「見つからない」場合などが原因で失敗した場合に、それを処理する方法が提供されます。
カスタマイズしたアプリケーション・バッファ・タイプをタイプ・スイッチに追加し、buildserver(1)コマンドを使用してTMQFORWARDに組み込むことができます。ただし、TMQFORWARDをカスタマイズした場合は、-sオプションでサービス名を指定することはできません。
構成パラメータについて、UBBCONFIGパラメータの観点から説明してきました。ただし、GROUPSセクションおよびSERVERSセクション内の指定は、tmconfig(1)を使用して、実行中のアプリケーションのTUXCONFIGファイルに追加することもできます。「tmconfig、wtmconfig(1)」を参照してください。グループおよびサーバーは、一度定義したら再起動する必要があります。
ここでは、qmadmin(1)の3つのコマンドについて説明します。これらのコマンドは、Oracle Tuxedo /Qコンポーネントのリソースを設定するために使用します。APPQ_MIB管理情報ベース(MIB)を使用すると、Oracle Tuxedo /Qをプログラムで管理できるようになります。MIBの詳細については、APPQ_MIB(5)のリファレンス・ページを参照してください。
qmadminのほとんどの主なコマンドでは、位置パラメータが使用されています。コマンドの呼出し時に、コマンドラインに位置パラメータ(オプションの前にダッシュ(-)が付かないパラメータ)が指定されていない場合、必要な情報を入力するようにqmadminで要求されます。
汎用デバイス・リスト(UDL)は、Oracle Tuxedoで制御されるVTOCファイルです。このファイルは、Oracle Tuxedoを実行するマシンに物理的な記憶空間をマッピングします。UDLのエントリは、キューとキュー・スペースのメッセージが格納されるディスク領域を指定します。Oracle Tuxedoはその領域への入出力を管理します。Oracle Tuxedoの新規インストールの一部としてキュー機能がインストールされる場合、構成ファイルの初回のロード時に、tmloadcf(1)によってUDLが生成されます。
キュー・スペースを作成する前に、UDLにそのキュー・スペースのエントリを作成する必要があります。次は、コマンドの例です。
# First invoke the /Q administrative interface, qmadmin
# The QMCONFIG variable points to an existing device where the UDL
# either resides or will reside.
QMCONFIG=/dev/rawfs qmadmin
# Next create the device list entry
crdl /dev/rawfs 50 500
# The above command sets aside 500 physical pages beginning at block # 50
# If the UDL has no previous entries, offset (block number) 0 must # be used
既存のOracle Tuxedo UDLにエントリを追加する場合は、QMCONFIG変数の値にはTUXCONFIGで指定されたパス名と同じ値を指定する必要があります。qmadminを一度呼び出したら、新しいエントリを作成する前に、lidlコマンドを実行してどの領域を使用できるのかを確認します。
キュー・スペースでは、IPCリソースが使用されます。そのため、キュー・スペースを定義する場合は、共用メモリー・セグメントとセマフォを割り当てることになります。前述のように、このコマンドを使用する簡単な方法はプロンプトを表示することです。また、APPQ_MIB(5)のT_APPQSPACEクラスを使用して、キュー・スペースを作成することもできます。プロンプトは以下の順で表示されます。
> qspacecreate
Queue space name: myqueuespace
IPC Key for queue space: 230458
Size of queue space in disk pages: 200
Number of queues in queue space: 3
Number of concurrent transactions in queue space: 3
Number of concurrent processes in queue space: 3
Number of messages in queue space: 12
Error queue name: errq
Initialize extents (y, n [default=n]):
Blocking factor [default=16]: 16
このプログラムでは、最後の3行を除くすべてのプロンプトに値を入力する必要があります。この例からわかるように、最後の2つのプロンプトではデフォルト値が使用されています。error queue nameの名前はほとんどの場合に必要ですが、必須ではありません。ここで名前を指定した場合は、qcreateコマンドを使用してエラー・キューを作成する必要があります。error queue nameの名前が指定されていないと、通常は(たとえば、再試行回数の上限値に達した場合などに)エラー・キューに送られるメッセージは、永続的に失われることに注意してください。
共用メモリーの予約領域は、キュー・スペース内のすべてのキューの永続的ではないメッセージを格納するために使用されます。プログラムでは、この予約領域のサイズを指定するように要求されません。永続的ではない(メモリー・ベースの)メッセージが必要な場合は、qspacecreateコマンドラインに-nオプションを入力して、メモリー領域のサイズを指定する必要があります。
IPCキーには、ほかのIPCリソースの要件と競合しない値を指定します。この値は32,768より大きく262,143未満にします。
キュー・スペースのサイズ、キューの数、および一度に登録できるメッセージの数は、アプリケーションのニーズによって決定されます。UDLエントリで指定されたページ数より大きいサイズを指定することはできません。また、これらのパラメータに関連して、キュー・スペース内の個々のqueue capacityパラメータを検討する必要があります。これらのパラメータを使用すると、(a)キューに登録できるメッセージの上限値を設定し、(b)キューに登録されたメッセージの数がしきい値に達したときに実行するコマンドの名前を指定できます。キュー・スペースに同時に登録できるメッセージの数を小さくすると、キューのしきい値に達しなくなります。
並列トランザクションの数を計算するには、以下の各項目を1つのトランザクションとしてカウントします。
クライアント・プログラムがtpenqueueを呼び出す前にトランザクションを開始する場合、キュー・スペースに同時にアクセスするクライアント数だけカウント数を増やします。最悪のケースは、すべてのクライアントがキュー・スペースに同時にアクセスすることです。
同時実行プロセスの数としては、このキュー・スペースを使用するグループのTMQUEUEサーバー、TMQFORWARDサーバー、またはTMS_QMサーバーごとに1、余裕として1をカウントします。
qspacecreateコマンドの使用時に、キュー・スペースを初期化するように設定できます。また、キュー・スペースを初めて開くときに、qopenコマンドで初期化するように設定することもできます。
使用するキューは、qmadminのqcreateコマンドで作成する必要があります。まず、qopenコマンドでキュー・スペースをオープンします。キュー・スペース名が指定されていない場合は、qopenで名前を入力するように求められます。APPQ_MIB(5)のT_APPQクラスを使用して、キューを作成することもできます。
> qcreate
Queue name: service1
Queue order (priority, time, fifo, lifo): fifo
Out-of-ordering enqueuing (top, msgid, [default=none]): none
Retries [default=0]: 2
Retry delay in seconds [default=0]: 30
High limit for queue capacity warning (b for bytes used, B for blocks used,
% for percent used, m for messages [default=100%]): 80%
Reset (low) limit for queue capacity warning [default=0%]: 0%
Queue capacity command:
No default queue capacity command
Queue 'service1' created
これらすべてのプロンプト(queue nameのプロンプト以外)では、入力を省略できます。queue nameが指定されていない場合、プログラムで警告メッセージが表示され、再度プロンプトが表示されます。これ以外のパラメータについてはプログラムでデフォルト値が用意されており、デフォルト値の使用を通知するメッセージが表示されます。
デフォルトの配信オプションやメモリーのしきい値のオプションを入力するようには求められません。デフォルトの配信オプションを使用すると、配信モードが指定されていないメッセージを永続(ディスク・ベースの)ストレージに配信するか、または非永続(メモリー・ベースの)ストレージに配信するかを指定できます。メモリーのしきい値オプションでは、非永続メモリーのしきい値に達したときに、コマンドを実行するための値を指定できます。これらのオプションを使用するには、qcreateコマンドラインで-dと-nをそれぞれ指定する必要があります。
メッセージは、このパラメータで指定された順序でキューに登録され、キューからの取出しに順序付け条件が設定されている場合を除き、キューの先頭から取り出されます。priority、expiration、timeがキューの順序付け条件として選択されている場合、メッセージはTPQCTL構造体の値に従ってキューに挿入されます。順序付け条件を組み合せて指定する場合は、最も重要な条件を最初に指定します。複数指定する場合は、カンマ(,)で区切ります。fifoまたはlifo (この2つは、相互に排他的)が指定されている場合は、この値を最後に指定します。パラメータが指定された順序によって、キューの順序付け条件が決定されます。たとえば、priority, fifoと指定されている場合、キューはメッセージの優先度に従って取り出され、同じ優先度のメッセージの場合は先入れ先出しで取り出されます。
管理者が順序を無視したキュー登録を有効にした場合、つまりプロンプトでtopまたはmsgidが選択されている場合、プログラマはキューの先頭、またはmsgidで識別されるメッセージの前にメッセージが入るように指定できます。その場合、tpenqueue呼出しのTPQCTL構造体の値を使用してください。このオプションは、よく検討してから使用します。一度このオプションを設定すると、それを変更するにはキューを破棄して、再度作成する必要があります。
待機メッセージ機能の通常の動作では、メッセージをキューから取り出すトランザクションがロールバックされると、メッセージがキューに戻されます。そのメッセージがキューの先頭に到達すると、再度キューから取り出されます。必要な再試行の回数、および次の再試行までの遅延時間を指定できます。キューから取り出されたメッセージが再試行のためにキューに戻されると、キューの順序付けは遅延時間(秒単位)だけ中断されます。この間、メッセージをキューから取り出すことはできません。
再試行回数のデフォルト値は0です。これは、再試行が一度も行われないことを示します。再試行回数の上限値に達すると、メッセージがキュー・スペースのエラー・キューに移されます。その場合、エラー・キューが指定され、作成されていることが前提です。エラー・キューが存在しない場合は、メッセージは破棄されます。
遅延時間には、秒単位が使用されます。メッセージ・キューがすぐにいっぱいになり、キューに戻されたメッセージがすぐに先頭に達する場合、遅延要因を作成してCPUサイクルを節約することができます。再試行に関しては、使用するアプリケーションでのこれまでの経験に基づいて決定します。特定のキューに関連付けられたサービスに大量の競合がある場合、一時的な問題が多数発生します。このような問題に対処するには、再試行回数に大きな値を指定します。(この数は再試行間隔と同様に厳密に主観的に決めることができます。)ロールバックされたトランザクションで通知される問題が解消されないものである場合、再試行回数を0にしてメッセージを直ちにエラー・キューに移動します。(これは、TMQFORWARDの-dオプションを指定したときの状況と非常に似ています。異なるのは、TMQFORWARDではキューのメッセージを自動的に削除するために長さが0ではない異常終了メッセージを受け取る必要があることだけです。)
qcreateコマンドには、キューの管理を部分的に自動化する3つのパラメータがあります。これらのパラメータは、上下限のしきい値を設定します。しきい値は、バイト数、ブロック数、メッセージ数、またはキューの容量に対する割合(パーセント)で表すことができます。これにより、しきい値の上限に達したときに実行されるコマンドを指定できます。実際には、コマンドはしきい値の上限に達したときに一度だけ実行され、しきい値の上限より先に下限に達しない限り、再度実行されることはありません。
High limit for queue capacity warning (b for bytes used, B for blocks used, % for percent used, m for messages [default=100%]): 80%
Reset (low) limit for queue capacity warning [default=0%]: 10%
Queue capacity command: /usr/app/bin/mailme myqueuespace service1
この例は、しきい値の上限としてディスク・ベースのキュー容量の80%を設定し、キューの80%が使用されたときにコマンドが実行されるように指定しています。このコマンドは、しきい値に達したときにメール・メッセージを送信するように作成されたスクリプトです。 myqueuespaceおよびservice1は、このコマンドに対する仮定的な引数です。キューがいっぱいになったことが一度通知されると、その状況に対応するための操作を行うことができます。警告メッセージを再度受け取るのは、キューのロードが容量の10%以下になり、もう一度80%に上がった場合だけです。永続的ではない(メモリー・ベースの)キューの容量を管理するために、qcreateコマンドの-nオプションを使用して、しきい値を設定したり、コマンドが実行されるように設定することもできます。
| 注意: | Windowsマシンを使用している場合、qmadmin()セッションでコマンドを設定する方法の詳細は、「Windows標準入出力」を参照してください。 |
2番目の例は、もう少し自動化されていて、TMQFORWARDサーバーの -eオプションを利用しています。
High limit for queue capacity warning (b for bytes used, B for blocks used, % for percent used, m for messages [default=100%]): 90%
Reset (low) limit for queue capacity warning [default=0%]: 0%
Queue capacity command: tmboot -i 1002
この例では、キューの予備のTMQFORWARDサーバーとしてSRVID=1002が設定されていること、そのCLOPTパラメータに -eオプションが指定されていることが前提となっています。また、サーバーが起動していないこと、または起動している場合は、キューが空であることが検出されたためにサーバーが自身をシャットダウンしたことも前提となっています。キューが容量の90%に達したとき、tmbootコマンドが実行されて予備のサーバーが起動します。-eオプションを使用すると、キューが空の場合にサーバーが自身を停止します。この例では、すでに起動しているサーバーに対して不要なtmbootコマンドを起動しないために、しきい値の下限として0%が設定されています。
この3つのオプションのデフォルト値は、100%、0%、およびコマンドなしです。
キューの作成と使用方法のパラメータ指定に関するこれまでの説明は、同名のサービスによって処理されるメッセージのキューの作成に基づいています。キューは、ピア・ツー・ピア通信などほかの目的で使用される場合もあります。キュー作成時のパラメータは、キューの用途が異なっても同じものが使用されます。メッセージがサービス・キューに登録される際に使用されるTPQCTL構造体には、応答キューおよび異常終了キューの名前を指定するためのフィールドがあります。TMQFORWARDは、リクエストされたサービスに対して行うtpacall(3c)の成功または失敗を検出し、それらのキューが管理者によって作成されている場合は、それぞれのキューに応答を登録します。応答キューまたは異常終了キューが存在しない場合、サービスからの成功または失敗のレスポンス・メッセージは削除され、発信元のクライアントは、キューに登録したリクエストの結果に関する情報を得ることができません。サービスから応答メッセージがない場合でも、応答キューが存在するときは、TMQFORWARDによって長さ0のメッセージがそのキューに登録されて、要求の発信元であるクライアントに結果が通知されます。
応答キューまたは異常終了キューを作成する場合は、これらのキューからのメッセージの取出しは、事前に登録した要求に関する情報を求めているクライアント・プロセスによって行われることに注意してください。このようなメッセージをキューから取り出す一般的な方法は、そのメッセージに関連付けられているmsgid (メッセージ識別子)またはcorrid (相関識別子)を使用することです。これは、キューの先頭からメッセージを取り出す方法と対照的です。そのため、キューの順序付け条件は、あまり意味を持ちません。その場合、fifoを設定しておけば十分です。retriesパラメータおよびretry delayパラメータは、応答キューの場合は意味がないので、デフォルト値を使用してください。queue capacityのしきい値とコマンドは、応答キューでも利用できます。これらを使用して管理者に警告を通知し、管理者が対応できるようにすると便利です。
エラー・キューは、システムのキューです。qspacecreateプロンプトの1つで、キュー・スペースのエラー・キューの名前を入力するように求められます。指定された名前のエラー・キューが実際に作成されている場合、そのエラー・キューに再試行回数の上限に達したサービス・キューのメッセージが移されます。エラー・キューのメッセージは、qmadminのコマンドを使用して手動で処理することも、APPQ_MIB MIBを使用して自動化された方法で処理することもできます。このようなエラー・キューの管理方法は、管理者が決定します。エラー・キューには、queue capacityパラメータを使用することができます。ただし、qnameを除くほかのすべてのqcreateのパラメータは使用できません。
| 注意: | エラー・キューとサービス異常終了キューには、同じキューを使用しないことをお薦めします。同じキューを使用すると、アプリケーションの管理が難しくなり、クライアントが管理者の領域にまでアクセスすることも起こり得ます。 |
通常、TMQUEUEおよびTMQFORWARDで暗号化メッセージ・バッファが処理される場合、復号化は行われません。ただし、『ATMIアプリケーションにおけるセキュリティの使用』の/Qとの互換性および相互運用性に関する項で説明したように、/Qコンポーネントでメッセージが登録されたバッファを復号化することが必要な場合があります。
/Qとの互換性および相互運用性に関する項で説明したように、トランザクションに関与しないtpdequeue()操作では、起動中のプロセスが有効な復号化キーを持っていない場合、キューの暗号化されたメッセージが破壊されます。そのため、アプリケーションのプログラマは、暗号化されたメッセージを取り出すためにプロセスでtpdequeue()を呼び出す場合は、事前にそのプロセスの復号化キーをオープンしておく必要があり、オープンしていない場合、メッセージは失われます。
復号化キーをオープンする方法については、『ATMIアプリケーションにおけるセキュリティの使用』のプラグインによる復号化キーの初期化に関する項および暗号化されたメッセージを受信するためのコードの記述に関する項を参照してください。
ここでは、効率的にキュー・スペースを操作できるように、キューの管理者が行うべき作業について説明します。
キュー・スペースのディスク・ストレージを増やす必要がある場合は、qmadmin(1)のqaddextコマンドを使用します。APPQ_MIB(5)のT_APPQSPACEクラスのTA_MAXPAGES属性を使用して、エクステントを追加することもできます。qmadminコマンドは、キュー・スペース名およびページ数を引数として取ります。ページは、QMCONFIG変数に指定されたデバイスに対して、UDLで定義されているエクステントから割り当てられます。感嘆符を使用すると、qmadmin外のコマンドを実行できるので、関連付けられたサーバー・グループを停止できます。例:
> !tmshutdown -g TMQUEUEGRP1
> qclose
> qaddext myqueue 100
キュー・スペースは、クローズしていなければなりません。オープンしているキュー・スペースにエクステントの追加を試みると、qmadminによってそのキューがクローズします。現在キュー・スペースにある永続的ではないメッセージは、qaddextコマンドが発行されて正常終了すると、すべて失われます。
キュー・スペースのバックアップを作成する場合は、UNIXコマンドのddを使用すると便利です。まず、関連付けられたサーバー・グループをシャットダウンします。次のようにコマンドを入力します。
tmshutdown -g TMQUEUEGRP1
dd if=<qspace_device_file> of=<output_device_filename>
そのほかのオプションについては、UNIXシステムのdd(1)リファレンス・ページを参照してください。
キュー・スペースをアーキテクチャが同じである別のマシンに移動する場合も、同じコマンドを使用できます。ただし、現在のデバイス名が移動先のマシンに存在しない場合は、qmadminのchdlコマンドで開始して、新しいデバイス名を指定する必要があります。
ddコマンドを持たないサーバー・プラットフォームでも、同じようなアーカイブ方法を使用できます。まず、バックアップを作成するキュー・スペース、または移動するキュー・スペースを含むグループをシャットダウンします。次に、アーカイブ・ツールを使用して、バックアップとして使用できるファイルなどの媒体、またはキュー・スペースを別のサーバーに移動する際に使用されるファイルなどの媒体に、キュー・スペースのデバイスを保存します。
異なるアーキテクチャ(主にバイトの並び順)を持つマシンにキュー・スペースを移動する場合、その手順は複雑になります。まず、キュー・スペースにあるすべてのキューからすべてのメッセージを取り出すアプリケーション・プログラムを作成して実行します。次に、それらのメッセージをマシンに依存しない形式で書き出します。最後に、メッセージを新しいキュー・スペースに登録します。
TMQFORWARDを使用してキューから取り出されて転送されるメッセージは、グループの境界を越えて処理されるので、グローバル・トランザクション内で実行されます。リソース・マネージに関連付けられていないサーバー、またはグローバル・トランザクション内で実行していないサーバーによってメッセージが実行される場合は、TMSNAME=TMS (NULL XAインタフェースの場合)であるサーバー・グループが必要です。
メッセージが実行のためにキューから取り出された際にTMQFORWARDで開始されたグローバル・トランザクションは、tpcommit()によって終了します。管理者は、構成ファイルにCMTRETパラメータを設定して、トランザクションのログへの記録時または完了時にトランザクションのコミットを設定できます。UBBCONFIG(5)のRESOURCESセクションのCMTRETの説明を参照してください。
トランザクション・タイムアウトを処理するには、キューの管理者と、メッセージをキューから取り出すクライアント・プログラムを開発するプログラマが協力することが必要です。tpdequeue(3c)が呼び出され、そのflags引数にTPQWAITが設定されている場合、TMQUEUEサーバーはメッセージがキューに到着するまで待機します。タイムアウトになるまでの時間(秒単位)は、次の条件によって決定されます。
TPQWAITが設定されている場合にメッセージがすぐに利用できないときは、TMQUEUEには他のサービス・リクエストを処理するためのアクション・リソースが必要になります。キュー・スペースが同時に処理できるアクション数を増やすこともできます。その場合、qspacecreateまたはqspacechangeコマンドに、-A actionsオプションを使用します。このオプションは、同時に処理できる追加のアクション数を指定します。処理の待機中にほかのアクションを実行できる場合、条件が満たされるまでブロッキング操作は中断されます。実行できるアクションがない場合は、tpdequeueの呼出しは失敗します。
TMQFORWARDサーバーがサービスにメッセージを転送したときにそのサービスが利用できなかった場合、キューに対する再試行回数の上限に達することがあります。メッセージは、エラー・キューが存在する場合はそこに移されます。このような状態を避けるには、管理者がTMQFORWARDサーバーを停止するか、または再試行回数の上限値を増やします。
メッセージはエラー・キューに移動されると、元のキューとは関連がなくなります。サービスが利用可能になったときに、管理者がメッセージをサービス・キューに戻してエラーを修復すると、キュー名がTPQCTL構造体のcorridに格納されて、キュー名がメッセージと関連付けられます。
「キューの容量の上限」で説明したqchange ...Queue capacity commandなど、qmadmin()セッション内で構成したコマンドを実行するために、WindowsのCreateProcess()関数ではDETACHED PROCESSとして子プロセスが生成されます。このようなプロセスには、標準入出力のための関連コンソールがありません。そのため、たとえば、標準DOS構文でqchange ... Queue capacity commandを設定して、組込みのDOSコマンド(dirまたはdateなど)を実行し、次に標準出力をファイルにパイプまたはリダイレクトすると、コマンドが正常終了してもファイルは空です。
この問題を解決する方法として、たとえば、qchange ... Queue capacity commandを実行するために、date /t > x.outコマンドでファイルのdate情報を取得します。この処理を対話的に行うには、次のような手順で実行します。
qmadmin
> qopenyourQspace> qchangeyourQname>go through all the setups... the threshold queue capacity warning,
and so on> "Queue capacity command: " cmd /c date /t > x.out
この処理をyourFile.cmdなどのコマンド・ファイルから行う場合は、date /t > x.outコマンドをyourFile.cmdに追加し、次のように実行します。
qmadmin
> qopenyourQspace> qchangeyourQname>go through all the setups... the threshold queue capacity warning,> "Queue capacity command: "
and so onyourFile.cmd
  
|