きどたかのブログスマートフォン用の表示で見るきどたかのブログいつか誰かがこのブログからトラブルを解決しますように。性能z/OSではRMFを使って性能測定をするのが普通のようで、おそらくどこでもやっているだろう。どれだけ性能分析をカテゴライズ出来るかに興味がある。性能分析といっても色々あるからな・・・、ここではアプリケーションの立場からの分析を補助出来るか否かに焦点をあてている。全体の中で見れば、あまり役に立つ情報ではないだろう。自分が考えてる方法は2つある。1つはwlm_classification_fileで細かく指定する方法。1つはSMF120-9を使う方法。1つ目の方法を考えてみる。基本的にwlm_classification_fileは使った方がいい。それは少なくとも、データに応じた分析をする依然に、MDBレベルの分析はこれで出来るからだ。server,DISPLAY,WORK,CLINFOをした際に、Descriptionを出すためにはこのファイルが必要だ。MDBと言ってもClassificationは3つ存在する。BはInternalだから)今回はListenerPortの場合を考える。InboundClassificationというエレメント。ここでデフォルトトランザクションクラスをかける。次に、endpointエレメントがあり、ここでリスナーポート名とdefaultclassificationがかける。忘れちゃいけないのが、ここでdescriptionも書くことだ。データに応じたclassificationを行うには、classificationentryエレメントで、セレクターを書き、トランザクションクラスを割り当てることになる。(ここでもDescriptionは書いた方がいい)その際に注意が必要なのは、ejb-jar.xmlにもmessage-selectorが必要ということだろう。同一のリスナーポートでデータに応じてトランザクションクラスを分けたいわけだが、ejb-jar.xmlに手が入るってことは、1つのリスナーポートに対して、複数のMDBを設定することになる。クラスは同じなんだが、名前を変えて作らないといけない気がする。出来るよな?出来たとしても少し気持ち悪いよな。これをやるということは、CR部分の挙動が大幅に変わる。メッセージ・セレクターはMQからBROWSEするときに使うものなので、MQにアクセスする頻度がけっこう増えることになる。(コンシューマーの種類が増える)ただし、BROWSE部分は、エンクレーブに含まれない点はここに書いておこう。CRのコストは目をつぶってSR上のコストを見る分にはこれでも構わないだろう。WLMポリシーの方でも、トランザクションクラスに応じた定義をする必要もある。サービスクラスは増やさない。レポートクラスだけを増やす感じ。サービスクラスの種類は多くても20から30くらいじゃないといけない。ここまで書いてきた方法で、メッセージ・セレクターで分類出来るデータに応じてレポートクラスを分けることは可能ではないかと思う。若干気になる点もある。