jdmpviewの誤算
金曜日は雪で会社に行かず、
家から繋いでダンプを取得。
WASのMust Gatherであるハング時のOMVS+RRS+CR+SRな内容を取得。
それをjextract。
一方でjdmpviewは厄介。
これが誤算だ。
info procでは3つ(1CR+2SR)のRuntimeを認識しているようだ。
SR,CR,SRの順番だった。
CRを見たいのに運が悪かった。
コマンドによって複数アドレス空間を処理できるものもあるようだが、ほんの一部という理解。
x/jやinfo classの際には、アドレス空間を切り替えできていないために望んでない結果になる。
本当に面倒臭いことに気付いたなぁ。
家では6.0.1で実験してるから、会社で実験が足らなかったと言える。
複数アドレス空間をダンプするシナリオはわりとあるんだけど、それに備えていなかった。
解析用のためだけに6.0.1を用意するか。
もしくはDTFJアプリを書いておくか。
z/OS上でのjdmpviewの実験では、スペースが足らなくて失敗している。
デフォルトでは/tmpに一時ファイルを作るようだ。
これは-J-Djava.io.tmpdir=で回避可能だが、それでもスペース不足で失敗。
dfで空きスペースを探る。。。
空きが見つかった。
ふむ、z/OS上のJava6でもcontextコマンドは利用できないと分かった。
6.0.1を用意するか?
DTFJアプリを書くか?
どうしようかな。