きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

WASzにおけるWLMの使われ方のイメージ

WebSphere Application Server z/OS WLM

これは自分の中のイメージであって、正しいというわけではありません。
アメリカに来る前から抱いているイメージです。
きっとほとんどの人がちんぷんかんぷんな内容になるでしょう。


WASzは2つのWLMサービスを使用していると思う。
1つはQueuing Manager Service.
もう1つはEnclave Service.
と言ってもこの2つはセットみたいなものだ。
しかしWASの資料を見てもQueueing Manager Serviceのことは見たことがない。


詳しくはこれを読め。
z/OS V1R12.0 MVS Programming Workload Management Services


Queuing Manager Modelというのがあり、これを理解するのが肝だ。
タイムフレームを考えるならSMF Type120-9にも関係している。
また、WASにおける動的アプリケーション環境とはすなわちこれだと言うものだ。


WASのCRがQueuing Manager,
WASのSRがServer Managerと呼ばれることになる。


SRはCRが直接起動するのではなく、WLMが起動している。
自分の記憶が確かなら、SRはサービスクラス毎に異なるアドレス・スペースになる。
そしてWLMはサービスクラス毎にWork Requestを管理するキューを持っているはずだ。


CRはおそらく起動時にSERVERクラス・プロファイルを見て、
IWM4AEDFマクロで動的アプリケーション環境を定義しとるはず。(ここでは64bitでも使えるマクロを書いてる)
このマクロの説明を見ると気付くと思うが、WASの設定に関連を持つパラメータが存在する。
たとえばDISTRIBUTE_WORKだ。
FIRST_AVAILABLEとROUND_ROBINが選べる。
これはserver_work_distribution_algorithmカスタム・プロパティに対応している。


また、SELETC_POLICYというパラメータもある。
ここを読むと、必ずサービスクラス毎のキューというわけではなく、
サーバー・アドレス・スペース毎のキューというのも選べるのだ。
これはfixpack19から追加されたdynapplenv_wlm_select_policyカスタム・プロパティに対応してる。
fixpack19が出たのは2011年9月だから、WASzはまだまだz/OSの機能を駆使しようとしているのがうかがえる。


CRはMDBやHTTPリクエストを受けるとエンクレーブを作る。
IWM4ECREマクロでね。
ただし、WASの設定で、wlm_classification_fileを設定することもあるだろう。
そうなると、マクロを発行する前に、このXMLファイルを見ないといけない。
たとえば、リスナーポートごとにトランザクションクラスを分けたり、
メッセージ・セレクターでトランザクション・クラスを分けたりしたらということだ。
で、前から疑問に思ってるのは、IWM4ECREマクロが発行されるまでは、
CRのMQブラウズのコストはSTCにカウントされるんじゃないかという点だ。
通常リスナーポート（キュー）ごとに、CRで1スレッド使われるんだけど、セレクターを使ったらどうなるかも興味深い。
wlm_classification_fileのセレクターは、直接MQのブラウズに渡ってないと思うのだよ。
出来ればこういう疑問をアメリカのエンジニアに聞きたい。個人的な疑問で申し訳ないが。
しかし、戻りのメッセージをMQにputするときはエンクレーブがあるからカウントされてもいいよね、みたいな。
IWM4ECREマクロを発行するとき、CLSFYを指定できるので、ここでサービスクラスは決定しちゃう。


CRはIWM4QINマクロで、WLMキューにリクエストをぶちこむ。
IWM4ECREマクロの必須のアウトプットパラメーターETOKENなどがあるので、どのキューにぶちこむとかは書かない。
ただ、SERVER_TOKENだとかREGION_TOKENがあるので、そのあたりはよく分からない。
おそらくは同一セッションならどうのこうのに使えるもんだろう。
MQ使ってる場合は、ここでたぶんユーザーデータの領域にメッセージ・トークンを詰め込んでいるはず。


SRはIWM4SSLマクロで、WLMキューからリクエストをセレクトするだろう。
インターバルがあるのかよく分からない。このマクロでは、キューが空だとサスペンドすると書いてある。
ただ、このWLMキューからSRまでの時間が早いことは、120-9で見たことがあるので気にすることもなかろう。


SRはIWM4STBGマクロで、処理を開始する。
開始って、なんだろうね。
control_region_mdb_queue_timeout_percentで見てる時間は、
〜IWM4SSLもしくはIWM4STBGまでのはず。厳密にどちらかを書いてる資料はまだ見たことない。
たぶんIWM4STBGマクロまでだと思う。
というのも、SELECTで時間に関する情報を更新してるとは思えないからだ。


SRはIWM4STENマクロで、処理を終了する。


んで、ここでまた疑問なんだが、Queuing Manager Modelでは、
Server Managerはこの後、独自のインタフェースで、Queuing Managerに終了を伝えると書いてある。
SRはCRにどうやって伝えてるのだろう？
また、Javaの感覚としては、CRはそれを待つスレッドを持っているんじゃないかと思う。
あとは、タイムアウトを検知するスレッドもいると思う。ひょっとしたら、同一スレッドかも。
となると、CRはWLMにリクエストをぶちこむときに、スレッドに関する情報も渡してるのか？？


最後にCRがIWM4EDELで、エンクレーブを削除する。


ざっくりではあるが、現状のWASzの認識の一部を書いてみた。