WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

ワークロード種別ファイル

ワークロード種別文書は、z/OS ワークロード・マネージャーのインバウンド HTTP、IIOP、メッセージ・ドリブン Bean (MDB)、およびメディエーション作業を分類する共通 XML ファイルです。

使用上の注意

ワークロード種別文書を使用する場合は、タスク z/OS ワークロードの分類 を実行しなければなりません。 ワークロード種別文書の例については、 z/OS ワークロード種別文書の例 を参照してください。

必須エレメント

<?xml version="1.0" encoding="UTF-8">
アプリケーション・サーバーで処理するにはワークロード種別文書を ASCII で保管する必要があることを示します。 このステートメントは必須です。
<!DOCTYPE Classification SYSTEM "Classifications">
ワークロード種別文書を検証する WebSphere Application Server for z/OS で提供される DTD 文書の名前が付いた XML パーサーを指定します。ワークロード種別文書を書き込む場合、この DTD に記述されているルールに従う必要があります。このステートメントをワークロード種別文書に追加する必要があります。
Classification
<Classification schema_version="1.0">

ワークロード種別文書のルートを示します。 すべてのワークロード種別文書は、このエレメントで開始および終了する必要があります。schema_version 属性は必須です。 サポートされている schema_version は 1.0 のみです。種別エレメントは、1 つ以上の InboundClassification エレメントを含んでいます。 インバウンド・サービス統合作業の場合は、種別エレメントはまた 2 つの SibClassification エレメントまで含むことができます。

InboundClassification
<InboundClassification type="iiop | http | mdb" schema_version="1.0" default_transaction_class="value">

InboundClassification エレメントを使用する場合は、以下のルールを使用してください。

  • type 属性は必須です。その値は、iiop、http、または mdb でなければなりません。 それぞれのタイプの文書内で、InboundClassification エレメントの出現が 1 回だけ起こります。 1 つの文書内で 3 つの InboundClassification まで可能です。 タイプは、 種別文書内で特定の順番で指定する必要はありません。
  • schema_version 属性は必須です。値は 1.0 に設定する必要があります。
  • default_transaction_class 属性を指定する必要があります。 また、指定したタイプのワークフローのデフォルトのトランザクション・クラスを定義してください。ストリングの値は、有効な WLM トランザクション・クラス、ヌル・ストリング ("" など)、 または 8 個以下のブランク (" " など) を含んだストリングである必要があります。
  • InboundClassification エレメントをネストすることはできません。 それぞれの InboundClassification エレメントは、次の InboundClassification エレメントまたは SibClassification エレメントが開始する前に終了しなければなりません。
SibClassification
<SibClassification type="jmsra | destinationmediation" schema_version="1.0" default_transaction_class="value">

SibClassification エレメントの使用時には、以下のルールを使用してください。

  • type 属性は必須です。値には jmsra または destinationmediation を指定する必要があります。これらは、 それぞれのタイプの文書で最大で 1 つの SibClassification エレメントにすることができます。タイプは、 種別文書内で特定の順番で指定する必要はありません。
  • schema_version 属性は必須です。値は 1.0 に設定する必要があります。
  • default_transaction_class 属性を指定する必要があります。 また、指定したタイプのワークフローのデフォルトのトランザクション・クラスを定義してください。ストリングの値は、有効な WLM トランザクション・クラス、ヌル・ストリング ("" など)、 または 8 個以下のブランク (" " など) を含んだストリングである必要があります。
  • SibClassification エレメントはネストすることができません。それぞれの SibClassification エレメントは、次の InboundClassification エレメントまたは SibClassification エレメントが開始する前に終了する必要があります。
異なるタイプの作業の分類のルールおよび XML ステートメントはよく似ていますが、それぞれのタイプに対して、わずかに異なる構文があります。 それぞれのタイプの作業に対する構文についての詳細は、以下のセクションを参照してください。
InboundClassification
SibClassification

IIOP 種別

属性タイプ="iiop" を持つ InboundClassification エレメントは、IIOP 種別に適用可能な文書のセクションを定義します。 このエレメントの例は、以下のとおりです。

<InboundClassification 	type="iiop" schema_version="1.0" 
                         default_transaction_class="value1">
以下の Java 2 Platform, Enterprise Edition (J2EE) アプリケーション成果物に基づいて、IIOP 作業をクラス分けすることができます。
  • アプリケーション名

    Enterprise Bean を含むアプリケーションの名前。 これはアプリケーションの表示名であり、すべての成果物を含む .ear ファイルの名前ではない可能性があります。

  • モジュール名

    1 つ以上の エンタープライズ Bean を含む EJB .jar ファイルの名前。 .ear ファイル内には、複数の EJB .jar ファイルがある場合があります。

  • コンポーネント名

    モジュール (または EJB .jar ファイル) 内に含まれている EJB の名前。 1 つ以上の エンタープライズ Bean が .jar ファイル内に含まれている場合があります。

  • メソッド名

    EJB 上のリモート・メソッドの名前。

iiop_classification_info エレメントを使用して、これらのどのレベルにおいても、さまざまなアプリケーション内で IIOP 作業をクラス分けします。

iiop_classification_info
<iiop_classification_info 	transaction_class="value1"
                          [application_name="value2"]
                          [module_name="value3"]
                          [component_name="value4"]
                          [method_name="value5"]
                          [description="value6"] >
iiop_classification_info エレメントを使用して、TCLASS 値をインバウンド要求に割り当てるアプリケーション、モジュール、コンポーネント、およびメソッド名に基づいたフィルターを構築することができます。 iiop_classification_info エレメントを使用する場合は、以下のルールを使用してください。
  • transaction_class 属性が指定されなければなりません。 ストリングの値は、有効な WLM トランザクション・クラス、ヌル・ストリング ("" など)、 または 8 個以下のブランク (" " など) を含んだストリングである必要があります。 ヌルまたは空白ストリングを指定することによって、デフォルトの TCLASS 設定、あるいは高水準フィルターによって割り当てられた TCLASS 設定をオーバーライドすることができます。 ヌルまたは空白ストリングを指定するということは、要求に対する TCLASS 値を持たないということです。
  • 必要な場合は、属性 application_name、module_name、component_name、および method_name を使用することができます。 これらの属性は、トランザクション・クラスを割り当てるか、 あるいはネストされた iiop_classification_info エレメントがトランザクション・クラスを 割り当てられるようにする、セレクターまたはフィルターとして機能します。 これらの属性の値を以下の方法で指定することができます。
    • アプリケーション、モジュール、コンポーネント、またはメソッドの正確な名前。
    • ワイルドカードの値。 ストリングの最後の文字としてアスタリスク (*) を配置すると、アスタリスクの前のストリングから始まるどのストリングも一致と見なすことを指示できます。 例えば、ストリング MAR* は、MARCH および MARS の両方と一致します。

    これらの属性の任意の組み合わせを使用して、フィルターをクラス分けします。 ただし、必要な細分度のみを使用します。例えば、アプリケーション・サーバー上にアプリケーションが 1 つしかない場合、application_name 属性を指定するためのクラス分けルールは必要ありません。

  • iiop_classification_info エレメントは、階層的な方法でネストすることができます。 エレメントをネストすることで、属性値に基づいたクラス分けフィルターを作成することができます。 以下のフィルターは、MyAPP1 アプリケーション内の EJB1 および EJB2 Enterprise Bean 上で要求をクラス分けします。
    <iiop_classification_info transaction_class="FAST"
                              application_name="MyAPP1"
                              component_name="EJB1" />
    <iiop_classification_info transaction_class="SLOW"
                              application_name="MyAPP1"
                              component_name="EJB2" />
    以下のフィルターもまた MyAPP1 アプリケーション内の EJB1 および EJB2 上の要求をクラス分けしますが、アプリケーション内の他のどの EJB 上でも要求もクラス分けします。
    <iiop_classification_info transaction_class="MEDIUM"
                              application_name="MyAPP1">
         <iiop_classification_info transaction_class="FAST"
                                   component_name="EJB1" />
         <iiop_classification_info transaction_class="SLOW"
                                   component_name="EJB2" />
    </iiop_classification_info>
  • 親のエレメントの属性値と競合する属性値を指定した場合は、下位レベル・フィルターが否定されます。 親のエレメントの属性値と競合する子の値の例は、以下のとおりです。
    <iiop_classification_info transaction_class="FAST"
                              application_name="MyAPP1">
         <iiop_classification_info transaction_class="SLOW"
                                   application_name="MyAPP2" />
    </iiop_classification_info>
    この例では、MyAPP2 内の EJB 要求は決してトランザクション・クラス「SLOW」に割り当てられません。高水準フィルターが application_name="MyAPP1" に対する IIOP 要求のみを下位レベル・フィルターへパススルーすることを許可するからです。
  • 要求の属性と一致した特定レベルにある最初のフィルターが使用されます。最良のあるいは最も限定されたフィルターではありません。 従って、フィルターを指定する順序は重要です。
    <iiop_classification_info transaction_class="FAST"
                              application_name="MyAPP" />
         <iiop_classification_info transaction_class="SLOW"
                                   component_name="*" />
         <iiop_classification_info transaction_class="MEDIUM"
                                   component_name="MySSB" />
    </iiop_classification_info>
    
    前の例で、MyAPP アプリケーション内で Enterprise Bean によって処理されたすべての IIOP 要求は、SLOW の TCLASS 値に割り当てられます。 これは、MySSB エンタープライズに対するすべての要求にも当てはまります。 MySSB がトランザクション・クラスを割り当てられた場合でも、フィルターは適用されません。最初のフィルターが適用され、SLOW の TCLASS 値が割り当てられたからです。 同じレベルのフィルターの残存リストは、無視されます。
  • 説明フィールドはオプションです。 しかし、すべての iiop_classification_info エレメントに説明を使用しなければなりません。 説明ストリングは、オペレーター・コマンド・サポートのパーツとして印刷され、使用されているクラス分けルールを識別することができます。 説明は MVS コンソールに表示されるので、妥当な長さにしてください。

HTTP クラス分け

属性 type="http" を持つ InboundClassification エレメントは、HTTP 種別に適用可能な文書のセクションを定義します。 このエレメントの例は、以下のとおりです。

<InboundClassification  	type="http"
                        schema_version="1.0"
                        default_transaction_class="value1">
HTTP 処理は以下の J2EE 成果物に基づいてクラス分けすることができます。
  • 仮想ホスト名

    インバウンド要求が送信されている HTTP ヘッダーのホスト名を指定します。

  • ポート番号

    HTTP キャッチャーが listen しているポートを指定します。

  • URI (Uniform Resource Identifier)

    Web アプリケーションを識別するストリング。

http_classification_info エレメントを使用して、これらのどのレベルにおいても、さまざまなアプリケーション内で HTTP 処理をクラス分けすることができます。
<http_classification_info transaction_class="value1"
                          [host="value2"]
                          [port="value3"]
                          [uri="value4"]
                          [description="value5"] >
http_classification_info エレメントを使用して、ホスト、ポート、および URI に基づいてフィルターを構築し、インバウンド要求に TCLASS 値を割り当てることができます。 http_classification_info エレメントを使用する場合は、以下のルールを使用してください。
  • transaction_class 属性が指定されなければなりません。 ストリングの値は、有効な WLM トランザクション・クラス、ヌル・ストリング ("" など)、 または 8 個以下のブランク (" " など) を含んだストリングである必要があります。 ヌルまたは空白ストリングを指定することによって、デフォルトの TCLASS 設定、あるいは高水準フィルターによって割り当てられた TCLASS 設定をオーバーライドすることができます。 ヌルまたは空白ストリングを指定するということは、要求に対する TCLASS 値を持たないということです。
  • 必要な場合は、属性 ホスト、ポート、および URI を使用することができます。 これらの属性は、トランザクション・クラスを割り当てるかまたはトランザクション・クラスを割り当てるためにネストされた http_classification_info エレメントを許可するセレクターまたはフィルターとして振舞います。 これらの属性の値を以下の方法で指定することができます。
    • ホスト、ポート、または URI の正確な名前。
    • ワイルドカードの値。 ストリングと一致するアスタリスク (*) を使用することができます。 ストリング MAY* は、MAY で始まるすべてのストリングと一致します。
    • 任意の値。すべての値に対する一致を指定するには、アスタリスク (*) 記号を使用します。
    これら属性のいずれかまたはすべてを使用して、フィルターをクラス分けします。 要求される細分度を使用するだけです。 例えば、アプリケーション・サーバー上にアプリケーションが 1 つしかない場合、URI 属性を指定するためのクラス分けルールは必要ありません。
  • http_classification_info エレメントを、階層的方法でネストすることができます。 属性名に基づいたフィルターを構成することが可能です。 以下の 2 つのフィルターを考えてみましょう。
    <http_classification_info transaction_class="FAST"
                              host="MyVHost1.com"
                              uri="/MyWebApp1/*" />
    <http_classification_info transaction_class="SLOW"
                              host="MyVHost2.com"
                              uri="/MyWebApp2/*" />
    <http_classification_info transaction_class="MEDIUM"
                              host="MyVHost1.com">
         <http_classification_info transaction_class="FAST"
                                   uri="/MyWebApp1/*" />
         <http_classification_info transaction_class="SLOW"
                                   uri="/MyWebApp2/*" />
    </http_classification_info>
    両方のフィルターとも、仮想ホスト MyVHost1.com に対して Web アプリケーションをホストしているアプリケーション・サーバー内で、コンテキスト・ルート /MyWebApp1 and /MyWebApp2 によって識別されている Web アプリケーションへの要求をクラス分けします。 しかし、2 番目のフィルターはまた、アプリケーション・サーバー内の他のどのコンテキスト・ルート上の要求もクラス分けします。
  • 親のエレメント属性値と異なる属性名を指定することによって、実際上、下位レベルのフィルターが否定されます。 以下に例を示します。
    <http_classification_info transaction_class="FAST"
                              uri="/MyWebApp1/*">
         <http_classification_info transaction_class="SLOW"
                                   uri="/MyWebApp2">
         </http_classification_info>
    </http_classification_info>
    この例は、トランザクション・クラス SLOW に割り当てられている /MyWebApp2 のコンテキスト・ルートを用いて Web アプリケーション内で結果を生じることはありません。 上位フィルターは、/MyWebApp1/* のコンテキスト・ルートを使用した HTTP 要求のみを下位レベル・フィルターへパスすることを許可します。
  • 特定レベルにある最初のフィルターが使用されます。最良のあるいは最も限定されたフィルターではありません。 そのため、それぞれのレベルにあるフィルターの順序は重要です。 以下に例を示します。
    <http_classification_info transaction_class="FAST"
                              host="MyVHost.com" />
         <http_classification_info transaction_class="SLOW"
                                   uri="*" />
         <http_classification_info transaction_class="MEDIUM"
                                   uri="/MyWebAppX/*" />
    </http_classification_info>
    この例では、仮想ホスト "MyVHost.com" によるアプリケーション・サーバーによって処理された HTTP 要求は、SLOW の TCLASS 値に割り当てられます。 コンテキスト・ルート /MyWebAppX を使用した Web アプリケーションへの要求でも、フィルターが適用されていないので、SLOW の TCLASS 値に割り当てられます。 最初の一致したフィルターが TCLASS 割り当てに使用され、同じレベルにある残りのフィルターは無視されます。
  • 説明フィールドはオプションですが、すべての http_classification_info エレメント上で使用すべきです。 MVS コンソールでトランザクション・クラスをモニターする場合、説明が表示されます。

MDB クラス分け

属性 type="mdb" を持つ InboundClassification エレメントは、リスナー・ポートでデプロイされた EJB 2.0 メッセージ・ドリブン Bean (MDB) の処理に適用する文書のセクションを定義します。 このエレメントの例は、以下のとおりです。
<InboundClassification  type="mdb"
                        schema_version="1.0"
                        default_transaction_class="qrs">
それぞれの InboundClassification エレメントは、定義された messagelistenerport タイプを持つ 1 つ以上のエンドポイント・エレメントを含むことができます。 トランザクション・クラスをメッセージ・ドリブン Bean と関連させたいサーバー内で定義された各リスナー・ポートに対して、1 つのエンドポイント・エレメントを定義します。 以下にエンドポイント・エレメントの例を示します。
<endpoint  type="messagelistenerport"
           name="IPVListenerPort" 
           defaultclassification="MDBX"
           description="ABC">
エンドポイント・エレメントを定義する場合は、以下のルールを使用してください。
  • タイプ属性は常時、messagelistenerport と等しくなければなりません。
  • 名前属性は、エンドポイント・エレメントのリスナーと対応します。 名前属性の値は、サーバーの管理コンソール内で指定されているリスナー・ポートの名前でなければなりません。
  • defaultclassification エレメントは、メッセージ・ドリブン Bean と関連したデフォルト・トランザクション・クラスです。 この属性の値は、デフォルトのトランザクション・クラス分け値をオーバーライドします。
  • 説明フィールドはオプションですが、すべてのエンドポイント・エレメント上で使用すべきです。 MVS コンソールでトランザクション・クラスをモニターする場合、説明が表示されます。
それぞれのエンドポイント・エレメントは、ゼロまたは 1 つ以上の classificationentry エレメントを持つことができます。 種別入力エレメントの例は、以下のとおりです。
<classificationentry  
selector="Location=&apos;East&apos;"
                      classification="MDB2"
                      description="XYZ" />
classificationentry エレメントの selector 属性を使用して、トランザクション・クラスを、デプロイメント記述子内にセレクター文節を持つメッセージ・ドリブン Bean へ割り当てます。 classificationentry エレメントを定義する場合は、以下のルールを使用してください。
  • selector 属性の値は、正確に MDB デプロイメント記述子内のセレクター文節と一致しなければなりません。
  • selector 属性の値は、XML 文書の正しい構文で指定する必要があります。 < および > 記号を、それぞれエンティティー参照 &lt; および &gt; に置換する必要があります。 同様に、アポストロフィまたは引用符を使用する場合、&apos; および &quot; エンティティー参照を使用します。

JMS RA 種別

属性 type="jmsra" を持つ SibClassification エレメントは、デフォルトのメッセージング・プロバイダーの JCA リソース・アダプター (RA) で使用する JCA 1.5 準拠リソースに対してデプロイされたメッセージ・ドリブン Bean (MDB) の処理に適用する文書のセクションを定義します。 このエレメントの例は、以下のとおりです。
<SibClassification  type="jmsra"
                        schema_version="1.0"
                        default_transaction_class="a">
それぞれの SibClassification エレメントには、1 つ以上の sib_classification_info エレメントを含めることができます。種別入力エレメントの例は、以下のとおりです。
<sib_classification_info  selector="&apos;East&apos;"
                      transaction_class="sibb"
                      selector="user.Location=&apos;East&apos;"
                      bus="bigrred"
                      destination="abusqueue"
                      description="Some words" />
selector
sib_classification_info エレメントの selector 属性を使用して、デプロイメント記述子にセレクター文節があるメッセージ駆動型 Bean にトランザクション・クラスを割り当てます。sib_classification_info エレメントを定義する場合、以下のルールを使用してください。
  • selector 属性の値は、メッセージ・プロパティーの値に従ってメッセージを選択する SQL 式です。 構文は、JMS 1.1 仕様のメッセージ・セレクターの構文ですが、(JMS メッセージだけではなく) SIMessage メッセージ上で作動可能です。構文では、 システム・プロパティー (JMS ヘッダー、JMSX プロパティー、および JMS_IBM_properties など) およびユーザー・プロパティー (先頭に ".user" を付ける必要があり、例えば、ユーザー・プロパティー "Location" の場合、 セレクターは、先の例で示したように "user.Location" を指定します) を選択することができます。詳しくは、メッセージ・プロパティーでの作業 を参照してください。
  • selector 属性の値は、XML 文書の正しい構文で指定する必要があります。 < および > 記号を、それぞれエンティティー参照 &lt; および &gt; に置換する必要があります。 同様に、アポストロフィまたは引用符を使用する場合、&apos; および &quot; エンティティー参照を使用します。
bus
ターゲット宛先が割り当てられているサービス統合バスの名前です。 種別は、このプロパティーにより命名されたバスに適用されます。 このプロパティーを指定しない場合、いずれかのバスに適用されます。種別が適用される宛先は、 使用する宛先プロパティーによって決まります。
destination
メッセージが配信されたターゲット・バス宛先の名前です。これは、キューまたはトピック・スペースの名前です。 種別は、このプロパティーで名前が指定された宛先に適用されます。 このプロパティーを指定しない場合、いずれかの宛先に適用されます。種別が適用されるサービス統合バスは、 使用するバス・プロパティーによって決まります。
discriminator
プロパティーは、宛先プロパティーによりトピック・スペースに名前が付けられる場合にかぎり適用されます。 この判別プログラムの値は、XPath 式となり、トピック・スペース内の 1 つ以上のトピックを選択します。
description
「description」フィールドはオプションですが、すべての sib_classification_info エレメントで使用する必要があります。 MVS コンソールでトランザクション・クラスをモニターする場合、説明が表示されます。

それぞれの sib_classification_info エレメントには、必要に応じてこれらのプロパティーを 1 つ以上含めて、メッセージの作業を分類することができます。 sib_classification_info エレメントには、 それぞれのプロパティーの複数のインスタンスを含めることはできません。

メッセージが複数の sib_classification_info エレメントに一致する場合、最初に表示されたエレメントが使用されます。 例えば、以下の指定があるとします。
<sib_classification_info bus="MyBus" transaction_class="a" />
<sib_classification_info destination="MyDest" transaction_class="b" />
サービス統合バス MyBus から宛先 MyDest に到着したメッセージは、種別 "a" に割り当てられます。その他のバスから MyDest に到着したメッセージは、種別 "b" に割り当てられます。

囲んでいる SibClassification エレメント内のいずれの sib_classification_info エレメントにもメッセージが一致しない場合、そのメッセージには、SibClassification エレメントのデフォルトの種別が割り当てられます。

メッセージが、すべての SibClassification エレメントでいずれの sib_classification_info エレメントにも一致しない場合、または SibClassification エレメントが定義されていない場合、すべての作業は、値が "SIBUS" と指定された組み込みのデフォルト種別を受信します。 z/OS ワークロードの分類 で説明されているように、TCLASS 値 "SIBUS" を使用することが必要な z/OS ワークロード・マネージャー・アクションを実行しなければなりません。

メディエーション種別

属性タイプが「destinationmediation」である SibClassification エレメントは、サービス統合バスの宛先に割り当てられたメディエーションの作業に適用する文書のセクションを定義します。このエレメントの例は、以下のとおりです。
    <SibClassification type="destinationmediation"
                        schema_version="1.0"
                        default_transaction_class="b">
それぞれの SibClassification エレメントには、1 つ以上の sib_classification_info エレメントを含めることができます。種別入力エレメントの例は、以下のとおりです。
<sib_classification_info
                      transaction_class="e"
                      selector="user.Location=&apos;East&apos;"
                      destination="themoon"
                      discriminator="sides/dark" 
                      description="n" />
selector
sib_classification_info エレメントの selector 属性を使用して、デプロイメント記述子にセレクター文節があるメディエーションにトランザクション・クラスを割り当てます。sib_classification_info エレメントを定義する場合、以下のルールを使用してください。
  • selector 属性の値は、メッセージ・プロパティーの値に従ってメッセージを選択する SQL 式です。 構文は、JMS 1.1 仕様のメッセージ・セレクターの構文ですが、(JMS メッセージだけではなく) SIMessage メッセージ上で作動可能です。構文では、 システム・プロパティー (JMS ヘッダー、JMSX プロパティー、および JMS_IBM_properties など) およびユーザー・プロパティー (先頭に ".user" を付ける必要があり、例えば、ユーザー・プロパティー "Location" の場合、 セレクターは、先の例で示したように "user.Location" を指定します) を選択することができます。

    詳しくは、メッセージ・プロパティーでの作業 を参照してください。

  • selector 属性の値は、XML 文書の正しい構文で指定する必要があります。 < および > 記号を、それぞれエンティティー参照 &lt; および &gt; に置換する必要があります。 同様に、アポストロフィまたは引用符を使用する場合、&apos; および &quot; エンティティー参照を使用します。
bus
ターゲット宛先が割り当てられているサービス統合バスの名前です。 種別は、このプロパティーにより命名されたバスに適用されます。 このプロパティーを指定しない場合、いずれかのバスに適用されます。種別が適用される宛先は、 使用する宛先プロパティーによって決まります。
destination
メッセージが配信されたターゲット・バス宛先の名前です。これは、キューまたはトピック・スペースの名前です。 種別は、このプロパティーで名前が指定された宛先に適用されます。 このプロパティーを指定しない場合、いずれかの宛先に適用されます。種別が適用されるサービス統合バスは、 使用するバス・プロパティーによって決まります。
discriminator
プロパティーは、宛先プロパティーによりトピック・スペースに名前が付けられる場合にかぎり適用されます。 この判別プログラムの値は、XPath 式となり、トピック・スペース内の 1 つ以上のトピックを選択します。
description
「description」フィールドはオプションですが、すべての sib_classification_info エレメントで使用する必要があります。 MVS コンソールでトランザクション・クラスをモニターする場合、説明が表示されます。

それぞれの sib_classification_info エレメントには、必要に応じてこれらのプロパティーを 1 つ以上含めて、メッセージの作業を分類することができます。 sib_classification_info エレメントには、 それぞれのプロパティーの複数のインスタンスを含めることはできません。

メッセージが複数の sib_classification_info エレメントに一致する場合、最初に表示されたエレメントが使用されます。 例えば、以下の指定があるとします。
<sib_classification_info transaction_class="e" destination="themoon" description="n" />
<sib_classification_info transaction_class="f" description="n" />
仲介された宛先 themoon に到着したメッセージは、種別 "e" に割り当てられます。その他の仲介された宛先に到着したメッセージは、種別 "f" に割り当てられます。

囲んでいる SibClassification エレメント内のいずれの sib_classification_info エレメントにもメッセージが一致しない場合、そのメッセージには、SibClassification エレメントのデフォルトの種別が割り当てられます。

メッセージが、すべての SibClassification エレメントでいずれの sib_classification_info エレメントにも一致しない場合、または SibClassification エレメントが定義されていない 場合、すべての作業は、値が "SIBUS" と指定された組み込みのデフォルト種別を受信します。z/OS ワークロードの分類 で説明されているように、TCLASS 値 "SIBUS" を使用することが必要な z/OS ワークロード・マネージャー・アクションを実行しなければなりません。




関連概念
z/OS 用のワークロード管理 (WLM)
関連タスク
z/OS ワークロードの分類
関連資料
z/OS ワークロード種別文書の例
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/rrun_wlm_tclass_dtd.html