ダンプリスト解析入門①：ダンプの種類と解析に必要な準備

アセンブラー・プログラミングをする上で避けて通れないのが、ダンプリストの解析です。MVS（および互換OS）には、プログラムが実行中に異常終了すると、その原因を判別するための診断資料として、プログラムに関連する仮想記憶域をダンプして出力する機能があります。出力されたダンプリストを解析することで、異常終了や誤動作の原因を知るための大きな手がかりとなります。
ユーザー自らアセンブラー・プログラミングをしない場合でも、メーカーやISVなどのプログラム製品をまったく利用しない運用はほとんどないでしょう。これらの製品でも、プログラムの異常終了などの際にはダンプリストが出力されることになります。直接ダンプリストを解析することがなくても、ダンプの取扱い方やリストに出力される内容の概要だけでも知っておくことは、システムを運用する上でも役立つ知識です。

ダンプの種類

• ABENDダンプ

プログラムが異常終了した際に書き出されるダンプです。アプリケーション・プログラムに対するダンプとは多くの場合、このABENDダンプのことです。

• SNAPダンプ

ABENDダンプは異常終了した際にOSによって自動的に採取される、いわゆる受け身のダンプですが、SNAPダンプはこの逆で、アプリケーション・プログラムが自分でOSのダンプ・サービスを呼び出して書き出すダンプです。プログラムが異常終了するわけではないが上手く動かない、といったような場合にデバッグの目的で使われます。

• SVCダンプ、トランザクション・ダンプ

OS自身のプログラム・モジュール内でエラーが検知された場合などに書き出されるダンプです。アプリケーションと異なり、OSやDB/DCなどのサーバー・プログラムなどではエラーが発生したからといってABENDするわけにはいきません。必要なリカバリー処理を行って、プログラムの実行を継続するのが普通です。ただし、発生したエラーの原因は究明する必要がありますから、その診断用資料として出力されるのがSVCダンプで、SYS1.DUMPnnと呼ばれるシステム・ダンプデータセットにダンプデータが書き出されます。z/OSでは、DUMPDSコマンドによって標準のSYS1.DUMPnn以外のダンプデータセットを割り振ることもできます。
トランザクション・ダンプは、MVSだけの独自の機能で、アプリケーション・プログラム用のSVCダンプと考えればいいでしょう。SVCダンプ同様にアドレス空間全体をダンプしますが、システム・ダンプデータセットではなく、JCLに定義された出力データセットもしくはプログラムが指定した名前で生成されたダンプデータセットに出力され、SVCダンプとは分けて管理することができます。

• SAダンプ

Stand Aloneダンプの略で、システムWAITやシステム・ループといったシステム・ダウン状態が発生した場合に採取されるダンプです。このような状態ではOS自身も動作不能になっていますから、OSの機能によるダンプの採取ができません。SADUMPと呼ばれるダンプを採取するための専用のプログラムでシステムを再IPLします。IPLされたSADUMPプログラムによって、ダンプ処理が開始されます。

細かな点で異なるものの、上記いずれのダンプもフォーマットされたリストの形式は基本的に同じです。このシリーズでは、ABENDダンプを使った解析方法を解説しますが、その方法はSVCダンプなどにも応用できます。

ABENDダンプの出力

ABENDダンプは、実行するプログラムのジョブ・ステップJCLに次に示すDD名でDDステートメントを定義しておけば、異常終了が発生するとMVSによって自動的に出力されます。

• SYSUDUMP

主にアプリケーション・プログラム用に出力されるダンプです。ダンプ範囲もアプリケーション関連領域に限定され、デバッグに必要な最低限の内容がダンプされることが多いです。書き出されるダンプは、リスト形式にフォーマットされ人間が目で見てわかるようになっています。

• SYSABEND

主にアプリケーション・プログラム用に出力されるダンプですが、ダンプ範囲はSYSUDUMPより広くなり、さまざまなOS関連領域なども追加でダンプされます。ユーティリティーやISV製品などのデバッグなどでも利用されます。こちらも、リスト形式にフォーマットされ人間が目で見てわかるようになっています。

• SYSMDUMP（SYSNDUMP：VOS3の場合）

空間のプライベート領域（リージョン域）のみならず、システム共通領域、さらにはOSのニュークリアスやSQAまでも含めた空間全域が採取されます。前述のSYSUDUMPやSYSABENDと異なりダンプデータはバイナリー形式のまま書き出されます。解析には編集用のユーティリティー（MVSではIPCS、MSPではPIC、VOS3ではJSLDMPR）によってリスト形式にフォーマットする必要があります。

SYSUDUMP、SYSABENDおよびSYSMDUMPにおけるダンプ範囲は、システムで固定されているわけではなく、SYS1.PARMLIBのダンプ出力範囲設定パラメーターによってユーザー毎にカスタマイズされます。前述の出力範囲の違いはあくまでも一例で、実際のダンプ範囲はユーザーによって異なります。ただしダンプされるデータ量は、SYSUDUMPが一番少なく、次にSYSABEND、SYSMDUMPが一番多い、となるよう設定されることがほとんどです。実際の出力範囲は、SYSUDUMPならSYS1.PARMLIBのIEADMP00（KAADMP00、JAADMP00）、SYSABENDならIEAABD00（KAAABD00、JAAABD00）、SYSMDUMPならIEADMR00（KAADMR00）によってセンター・デフォルトが定義されます。また、CHNGDUMPコマンドによって一時的に変更することもできます。VOS3の場合は、SYSUDUMPなどのダンプ出力先を定義したDDステートメントにDUMPパラメーターを指定することで、ダンプ範囲をジョブ・ステップ単位で変更することができる。

SDATA=(CB,ERR,LSQA,SUM,TRT),PDATA=(PSW,REGS,JPA,SA,SPLS,SUBTASKS)

一般的なバッチ・アプリケーション・プログラムでは、メーカーのデフォルト設定でも十分な場合が多いですが、SYSUDUMPもしくはSYSABENDで上記で示す範囲がダンプされるといいでしょう。
※足りなければ役に立たないし、多すぎれば不要な範囲のメモリー領域が大量にダンプされてしまう。

• 徴候（SYMPTOM） DUMP

MVSの場合、ジョブ・ステップで実行中のプログラムがABENDすると、ジョブログに徴候ダンプ（SYMPTOM DUMP）が出力されます。徴候ダンプには、ABENDコードと理由コード、ABEND時のPSWとPSWが示すアドレスの前後6バイト分の領域内容、汎用レジスターの内容が含まれます。（MSPではSYSUDUMPなどのDDステートメントが未定義の場合のみ出力される※ここは記憶なのでもしかしたら違っているかも…）
デバッグに慣れてくると、単純な理由ならこの徴候ダンプだけでもABENDの原因がわかることも多いです。

ダンプリストの解析に必要なもの

• PRINT GEN指定のアセンブル・リスト

ダンプリストの解析をするためには、ロードモジュールと同じレベルのアセンブル・リストを準備します。つまり、動かしたロードモジュール（オブジェクト）をアセンブルした際のリストです。レベルが合わずリストとロードモジュールの内容が違っていたり、ずれていたりするとデバッグの邪魔になるだけです。また、ソース・プログラムではなくアセンブル・リストです。ソース・プログラムでは、命令コードもロケーション・カウンター（モジュール内相対オフセット・アドレス）もわかりません。また、アセンブルする際には、PRINT GEN命令で使用しているマクロ内の命令がすべて展開されるようにします。PRINT NOGEN状態ではマクロ内の命令は展開されないので、マクロ命令のパラメーターの記述ミスなどで期待しない命令列が展開されたような場合、エラーの原因を見つけるのが難しくなります。

ダンプリストを見ながら、アセンブル・リストを照らし合わせ、必要に応じてCPU命令の解説書（z/Architecture解説書：Principles of Operation）や システム便覧（z/Architecture Reference Summary）を始めとするマニュアル類なども参照して、エラーの原因を調べていきます。
SYSUDUMPやSYSABENDの場合、ダンプはISPFやSDSFなどのデータセットやSYSOUTのブラウズ機能で表示してもいいのですが、80桁×24行のディスプレイ画面では、常に左右にスクロールしなければならず、見にくいだけで効率が上がりません。SYMPTOM DUMPやPSW、レジスターで示される領域の内容などから簡単に原因がわからず、あたりもつかないような場合は、ダンプをじっくり追いかける、ということになりますが、その場合、80桁のディスプレイしか利用できないのであれば、端末エミュレーターのファイル転送機能やFTPなどで、PC側にテキストファイルとしてダンプを送り、PC側のエディターやファイルブラウザーなどを使う方が効率がいいでしょう。