実行環境

41. 真のエラー原因を追究する方法

プログラムを実行で期待通りに動作しなかったりエラーが発生した場合に真のエラーを
追求できないでいる開発者や特約店SEが多くなった。
そのため「エラーが発生しました」という報告だけで

という基本的な報告すらない場合が最近は多くなっている。
ここでは真のエラー原因を追究するための具体的な方法について解説する。

【1】エラーの原因を大局的に考慮する

エラーとなる要因はプログラムばかりに原因があるのではない。
何かエラーが発生するとすべてプログラムが悪いものと判断するのは早計と言える。
プログラムが実行するための構成要素は

  1. プログラム
  2. データ ...... 想定外のデータが見つかった等
  3. 操作 ...... 特殊な対応外の操作が行われた場合
  4. 環境 (Windows/OS400) ...... 環境に損傷がある場合や対象外の環境であった場合

の 4つの要因がある。いくら徹底的にプログラムを事前に検証していたとしても
これらすべてのありとあわゆる要件について検証することはソフトウェアの性格上
不可能である
エラーが発生したときはこれらについてもすべて調査して
原因の解明に努める必要がある。エラーを繰り返し再現することができれば
原因の追究は比較的やさしくなるが最も困難であるのは、再現性に乏しい場合である。
エラーを発見した操作員は上記の 2 〜 4 について開発者に報告する必要がある。

【2】真のエラー・メッセージを調査する。

iSeries400の場合、エラーが検出されるとかなり詳しくエラー内容を知ることができるように
なっているが残念ながら操作員や開発者(SE)においてもエラーの調査の方法を知らない
人が大半を占めている。
ここではエラー・メッセージの調査のための基本的な操作を紹介する。

1. 操作員メッセージ(QSYSOPR) と JOBLOG を調査する。

DSPMSG QSYSOPRによって操作員メッセージにエラーが報告されていないか
調べる。
WRKOUTQ QEZJOBLOG および WRKOUTQ QEZDEBUG
JOBLOG やダンプがあれば調査する。
適用業務によっては QPRINT にエラーが報告されている場合がある。

2. WRKACTJOB による調査

WRKACTJOBによって異常が発生していないか調査する。
状況が「MSGW」になっているようであれば「7=メッセージの表示」によって
エラー・メッセージを表示して対応する。
問題のJOBに関しては「5=処理」に続いて「10=ジョブ・ログの表示」や
「4=スプール・ファイルの処理」によってエラーが報告されていないか調査する。
特に重要であるのは「10=ジョブ・ログの表示」で実行コマンドにカーソルをセットして
「F10=詳細メッセージの表示」を行うことである。

3.ロー・レベル・メッセージを調査する。

今日、大半の操作員は QCMD を使用しないためにロー・レベル・メッセージ
(詳細メッセージ)を調べることが少なくなってしまっている。
CALL QCMD を行ってから CALL MYLIB/MYPGM のように実行して
エラーが発生したら「CALL MYLIB/MYPGM」の行にカーソルをセットして
「F10=詳細なメッセージの組み込み」を実行する。
F10キーを押すことによって詳細なロー・レベル・メッセージを表示することができる。
このロー・レベル・メッセージを表示させることが真のエラー原因を知ることに繋がる
非常に重要な操作であることを覚えていて欲しい。

【3】エラーの修正

エラーの内容が把握できたとしても慌てて修正してはならない。

1. エラーが発生する要件を絞り込む

【1】で説明したようにプログラムが実行される要件は4種類ある。
複数の操作やデータが混在しているときにはどのような操作やデータのときだけに
エラーが発生するのかを要因を絞り込む必要がある。
例えばある操作Aを行ってから操作Bを行ったときにエラーが発生するものとすれば
これだけでは操作Aに原因があるのか、または操作Bに原因があるのかはわからない。
しかし操作Cを行ってから操作Bを行えばエラーは発生しないのであれば
原因は操作Aにあるのではないかと推測できる。
このようにして要因をできるだけ少なくしてエラーが発生する条件を絞り込んでいく
作業をまず行うことが必要である。

2. エラーを繰り返し再現できるようにする。

上記の1によって限られた特定の要件において必ずエラーが再現できるように
要件を絞りこんで実行できるようにしておく。

3. エラーを修正する。

プログラムで必要な対応を追加してエラーの補正対策を行う。
この場合でも一時的に値を変更して結果をシミレートしてから修正を行うほうがよい。

4. 再現パターンでエラーの解消を検証する。

2.の繰り返し再現の方法でエラーが解消されたことを確認する。

5. 一般的な処理全体を確認する。

4.で解決したわけではない。しばしばエラー対策によって別の新たなエラーが
誘発される場合がある。そこで基本的な操作やデータにおいても問題なく動作するかを
一般的なパターンで検証する必要がある。
これは別の環境でも正しく動作する改訂であったのかを注意深く検証する
必要がある。
ここまで十分な検証を終えてから初めて修正が正しかったものと判定することが
できる。

【 まとめ 】

要は論理的な問題点の抽出を明確に行ってから適切な対応を行うことが肝要である。
原因は不明であるがある箇所さえ修正したら問題が解消したというのであれば
またぞろ別の場所で問題が再発する可能性がある。
合理的な問題点の抽出と解決を念頭におかれたい。