アセンブラー・プログラミングをする上で避けて通れないのが、ダンプ・リストの解析です。z/OS（MVS）には、プログラムが実行中に異常終了するとその原因を判別するための診断資料として、プログラムに関連する仮想記憶域をダンプして出力する機能があります。出力されたダンプ・リストを解析することで、異常終了や誤動作の原因を知るための大きな手がかりとなります。
ユーザー自らアセンブラー・プログラミングをしない場合でも、メーカーやISVなどのプログラム製品をまったく利用しない運用はほとんどないでしょう。これらの製品でもプログラムの異常終了などの際には、ダンプ・リストが出力されます。直接ダンプ・リストを解析することがなくても、ダンプの取扱い方やリストに出力される内容の概要だけでも知っておくことは、システムを運用する上でも役立つ知識です。
ダンプの種類
プログラムが異常終了した際に書き出されるダンプです。アプリケーション・プログラムに対するダンプとは多くの場合、このABENDダンプのことです。
ABENDダンプは異常終了した際にOSによって自動的に採取される、いわゆる受け身のダンプですが、SNAPダンプはこの逆で、アプリケーション・プログラムが自分でOSのダンプ・サービスを呼び出して書き出すダンプです。プログラムが異常終了するわけではないが上手く動かない、といったような場合にデバッグの目的で使われます。
OS自身のプログラム・モジュール内でエラーが検知された場合などに書き出されるダンプです。アプリケーションと異なり、OSやDB/DCなどのサーバー・プログラムなどではエラーが発生したからといってABENDするわけにはいきません。必要なリカバリー処理を行って、プログラムの実行を継続するのが普通です。ただし、発生したエラーの原因は究明する必要がありますから、その診断用資料として出力されるのがSVCダンプで、SYS1.DUMPnnと呼ばれるシステム・ダンプデータセットにダンプデータが書き出されます。z/OSでは、DUMPDSコマンドによって標準のSYS1.DUMPnn以外のダンプデータセットを割り振ることもできます。
トランザクション・ダンプは、MVSだけの独自の機能で、アプリケーション・プログラム用のSVCダンプと考えればいいでしょう。SVCダンプ同様にアドレス空間全体をダンプしますが、システム・ダンプデータセットではなく、JCLに定義された出力データセットもしくはプログラムが指定した名前で生成されたダンプデータセットに出力され、SVCダンプとは分けて管理することができます。
Stand Aloneダンプの略で、システムWAITやシステム・ループといったシステム・ダウン状態が発生した場合に採取されるダンプです。このような状態ではOS自身も動作不能になっていますから、OSの機能によるダンプの採取ができません。SADUMPと呼ばれるダンプを採取するための専用のプログラムでシステムを再IPLします。IPLされたSADUMPプログラムによって、ダンプ処理が開始されます。
細かな点で異なるものの、上記いずれのダンプもフォーマットされたリストの形式は基本的に同じです。このシリーズでは、ABENDダンプを使った解析方法を解説しますが、その方法はSVCダンプなどにも応用できます。
ABENDダンプの出力
ABENDダンプは、実行するプログラムのジョブ・ステップJCLに次に示すDD名でDDステートメントを定義しておけば、異常終了が発生するとMVSによって自動的に出力されます。
主にアプリケーション・プログラム用に出力されるダンプです。ダンプ範囲もアプリケーション関連領域に限定され、デバッグに必要な最低限の内容がダンプされることが多いです。書き出されるダンプは、リスト形式にフォーマットされ人間が目で見てわかるようになっています。
主にアプリケーション・プログラム用に出力されるダンプですが、ダンプ範囲はSYSUDUMPより広くなり、さまざまなOS関連領域なども追加でダンプされます。ユーティリティーやISV製品などのデバッグなどでも利用されます。こちらも、リスト形式にフォーマットされ人間が目で見てわかるようになっています。
空間のプライベート領域（リージョン域）のみならず、システム共通領域さらにはOSのニュークリアスやSQAまでも含めた空間全域が採取されます。前述のSYSUDUMPやSYSABENDと異なりダンプ・データはバイナリー形式のまま書き出されます。解析には編集用のIPCSユーティリティーによってリスト形式にフォーマットする必要があります。
SYSUDUMP、SYSABENDおよびSYSMDUMPにおけるダンプ範囲は、システムで固定されているわけではなくSYS1.PARMLIBのダンプ出力範囲設定パラメーターによってユーザー毎にカスタマイズされます。前述の出力範囲の違いはあくまでも一例で、実際のダンプ範囲はユーザーによって異なります。ただし、ダンプされるデータ量はSYSUDUMPが一番少なく、次にSYSABEND、その次にSYSMDUMPとなるよう設定されることがほとんどです。実際の出力範囲は、SYSUDUMPならSYS1.PARMLIBのIEADMP00、SYSABENDならIEAABD00、SYSMDUMPならIEADMR00によってセンター・デフォルトが定義されます。また、CHNGDUMPコマンドによって一時的に変更することもできます。
MVSでは、ジョブ・ステップで実行中のプログラムがABENDするとジョブログに徴候ダンプ（SYMPTOM DUMP）が出力されます。徴候ダンプにはABENDコードと理由コード、ABEND時のPSWとPSWが示すアドレスの前後6バイト分の領域内容、汎用レジスターの内容が含まれます。デバッグに慣れてくると、単純な理由ならこの徴候ダンプだけでも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側のエディターやファイルブラウザーなどを使う方が効率がいいでしょう。