AS400 / IBM i のRPGで RNX8888 が出たとき、メッセージ名だけを見て原因を決めつけると迷いやすいです。
特に「再帰的なエラー」「エラー処理中のさらに別のエラー」「同じ処理を何度も呼び出している状態」が絡むと、ジョブログの最後に見えているRNX8888だけを追っても、本当の原因にたどり着けないことがあります。
この記事では、RNX8888が出たときに初心者がどこから確認すればよいかを、25年以上AS400 / IBM i の保守に関わってきた現場目線で整理します。
この記事の結論
RNX8888は、最後に見えているメッセージだけで判断しない方が安全です。ジョブログを前に戻り、最初に発生した異常、呼び出し元、例外処理、同じプログラムの再呼び出し、ログ出力処理を順番に確認します。
RNX8888とは
RNXで始まるメッセージは、RPGの実行時に関係するメッセージです。RNX8888は、RPGプログラムで処理できない異常が発生したときや、エラー処理の途中でさらに別の異常が起きたときに見かけることがあります。
ここで大事なのは、RNX8888そのものが「最初の原因」とは限らないことです。ファイルオープン失敗、数値変換エラー、配列の範囲外参照、権限不足、ロック、CALL先の異常など、前段に別のメッセージが出ていることがあります。
現場では、RNX8888を見たらまず「このメッセージの前に何が出ているか」を確認します。最後のメッセージだけを追うより、最初に崩れた場所を探す方が早いです。
「再帰的エラー」として見るべきパターン
RNX8888の記事で書いておきたいのは、再帰的なエラーの見方です。ここでいう再帰的とは、単純に「プログラムが自分自身をCALLしている」という意味だけではありません。
たとえば、次のような状態です。
- プログラムAがエラーになり、エラー処理で共通ログ出力プログラムBを呼ぶ
- ログ出力プログラムBの中で、さらにファイルエラーが起きる
- *PSSRやMONITORの中で、また同じようなエラー処理を呼ぶ
- CALL関係が循環して、同じ処理に戻ってしまう
- 結果として、最初の原因より後ろにRNX8888が見える
この場合、RNX8888だけを見ても原因は見えません。エラー処理の中で、さらにエラーが発生している可能性を疑います。
よくある流れのイメージ TEST001R でファイル更新エラー ↓ *PSSR または MONITOR の例外処理へ入る ↓ ログ出力用の共通処理をCALL ↓ ログファイルがロック、または権限不足 ↓ エラー処理中にさらにエラー ↓ ジョブログ後半に RNX8888 が出る
現場でよく見る発生パターン
RNX8888が絡む調査で、私がまず疑うのは次のようなパターンです。
| 発生パターン | 確認すること |
|---|---|
| 例外処理中の二次エラー | *PSSR、MONITOR、ON-ERRORの中でさらにI/OやCALLをしていないか |
| ログ出力処理の失敗 | ログファイルのロック、権限不足、ライブラリー違いがないか |
| CALL関係の循環 | 同じプログラムや共通処理を何度も呼んでいないか |
| 想定外データ | 数値変換、桁あふれ、日付変換、配列指標エラーがないか |
| ファイル関連エラー | ファイル未作成、メンバーなし、ロック、オープン失敗がないか |
| 環境違い | TESTLIBのつもりが別ライブラリーを見ていないか |
特に本番障害時は、ログ出力やエラー通知処理が意外と原因になることがあります。普段は正常に動いているため見落としやすいですが、障害時だけ通る処理こそ確認が必要です。
ジョブログで確認する順番
RNX8888を調べるときは、ソースを見る前にジョブログの流れを押さえる方が安全です。私は次の順番で確認します。
- RNX8888の行を見つける
- その直前のメッセージを前に戻って確認する
- 最初に異常が出たメッセージIDを探す
- プログラム名、ステートメント番号、ファイル名を確認する
- 同じ時刻に出ているCPFメッセージを見る
- CALLスタックや呼び出し元を確認する
- *PSSR、MONITOR、ON-ERRORなどの例外処理を確認する
- ログ出力や通知処理の中で別のエラーが起きていないか見る
初心者のうちは、RNX8888の行だけを見てしまいがちです。しかし、現場では「RNX8888より前に出ているメッセージ」の方が大事なことが多いです。
調査時に見るコマンド例
実際の調査では、ジョブログ、対象オブジェクト、ライブラリーリストを確認します。ここでは例として、ライブラリー名はTESTLIB、プログラム名はTEST001Rにしています。
DSPJOBLOG WRKJOB DSPPGM PGM(TESTLIB/TEST001R) WRKOBJ OBJ(TESTLIB/TEST001R) OBJTYPE(*PGM) WRKOBJ OBJ(TESTLIB/*ALL) DSPLIBL
重要なのは、コマンドを打つこと自体ではありません。どのジョブで起きたのか、どのライブラリーを見ているのか、どのプログラムが実行されたのかを確認することです。
ソースで確認するポイント
ジョブログで最初の異常箇所を絞ったら、次にRPGやCLのソースを確認します。RNX8888が絡む場合、通常処理だけでなく例外処理も必ず見ます。
| 見る場所 | 確認する理由 |
|---|---|
| 対象ステートメント付近 | 最初に異常が出た処理を確認する |
| *PSSR | エラー処理中にさらにエラーが起きていないか見る |
| MONITOR / ON-ERROR | 例外を握りつぶしていないか、別処理を呼んでいないか見る |
| CALL命令 | 共通処理や同じ処理を繰り返し呼んでいないか見る |
| ログ出力処理 | ログファイル更新で二次エラーになっていないか見る |
| ファイル定義 | 参照しているファイル、使用区分、更新有無を確認する |
再帰的なエラーを疑う場合は、CALL先をたどることが大事です。同じプログラムや同じ共通処理に戻っていないか、例外処理からさらに例外処理を呼んでいないかを確認します。
初心者がやりがちなミス
RNX8888の調査で初心者がやりがちなミスは、最後に見えたメッセージだけを追うことです。
- RNX8888の行だけ見て、前のメッセージを確認しない
- ジョブログを途中から読み、最初の異常を見落とす
- エラー処理の中のI/OやCALLを確認しない
- ログ出力処理を疑わない
- ライブラリー違いを確認しない
- 本番環境でいきなり修正しようとする
RNX8888は、見えているメッセージだけで焦ると危険です。原因が曖昧なまま暫定対応を広げると、二次災害につながります。
本番対応での注意点
本番障害時は、周りから急かされることがあります。それでも、ジョブログ、対象ライブラリー、対象ファイル、実行ユーザー、処理時刻は必ず確認します。
SQLやコマンドでデータを確認する場合も、参照先のライブラリーを間違えると判断を誤ります。更新系の作業に入る前に、ライブラリーリストと対象ファイルを声に出して確認するくらい慎重でよいです。
本番対応では、まず止血、次に原因確認、最後に恒久対応です。RNX8888が出たからといって、すぐにプログラム修正やデータ更新に入るのではなく、最初に崩れた場所を確認してから動きます。
確認チェックリスト
- RNX8888より前のメッセージを確認したか
- 最初に異常が出たプログラムを特定したか
- ステートメント番号やファイル名を確認したか
- 対象ライブラリーと対象ファイルを確認したか
- *PSSRやMONITORの中で別のエラーが起きていないか
- ログ出力や通知処理が二次エラーになっていないか
- CALL関係が循環していないか
- 同じプログラムや共通処理を繰り返し呼んでいないか
- 本番で触る前に、作業手順を整理したか
- 修正前に、再現条件と影響範囲を確認したか
まとめ
RNX8888が出たときは、メッセージ名だけで判断せず、ジョブログを前後にたどって最初の原因を探します。特に、エラー処理の中でさらにエラーが起きている場合や、CALL関係が循環している場合は、最後に見えているメッセージだけでは原因が見えません。
確認する順番は、ジョブログ、最初のメッセージ、対象プログラム、ステートメント番号、例外処理、CALL先、ログ出力処理、ライブラリーです。焦って修正するより、まず状況を整理することが大事です。
ジョブログの見方は、AS400のジョブログ確認手順にもまとめています。CPFメッセージの切り分けは、AS400のCPFエラー対応手順もあわせて確認してください。本番対応の考え方は、AS400の本番対応で初心者がやってはいけないことに整理しています。
IBM公式のメッセージ情報を確認したい場合は、IBM i documentation から対象バージョンのRPGメッセージを確認してください。
RNX8888で現場が混乱しやすい理由
RNX8888は、メッセージだけを見ると「再帰的なエラー」という印象が強く、初心者ほどプログラム単体のバグだと決めつけがちです。ただ現場では、呼び出し順、エラーハンドリング、MONMSG、再呼び出し、想定外データが絡んでいることがあります。つまり、ソース1本だけを見ても原因に届かないことがあります。
確認する順番
- ジョブログで最初に出た原因メッセージを探す
- RNX8888の直前にCALLされているプログラムを確認する
- CL側のMONMSGでエラーを握りつぶしていないか見る
- 同じプログラムを再度CALLする構造になっていないか見る
- 入力データ、制御ファイル、処理対象区分が想定外になっていないか確認する
現場で大事なのは、「RNX8888が出た場所」だけでなく「RNX8888に至るまでの流れ」を見ることです。結果のエラーに飛びつくより、最初の異常、直前のCALL、例外処理の扱いを順番に確認した方が早く原因に近づけます。
初心者に伝えたいのは、再帰や例外が絡むエラーほど一人で抱え込まないことです。ジョブログの該当箇所、CALL関係、想定していた入力条件を整理してからレビューしてもらうと、無駄な手戻りが減ります。
