本番障害の初動対応も確認 作業者、環境、影響範囲、ジョブログ、MSGW、データリカバリーをどの順番で見るかは、AS400本番障害の初動対応チェックリスト にまとめています。焦って作業する前の確認用に使えます。
実例でジョブログを読みたい場合 CPF・RNX・MSGWが出た時の読み方は、AS400ジョブログ実例集 にまとめています。最後のエラーだけで判断しない練習になります。
RNX番号から確認したい場合 RPG実行時エラーの見方は、AS400 RNXエラー一覧 にまとめています。配列、10進数データ、RNX8888などを調べる入口になります。
CPF番号から確認したい場合 CPF0000、CPF4101、CPF4131、CPF9801など、よく見るCPFの確認ポイントは AS400 CPFエラー一覧 にまとめています。
CPF・RNX・MCH・MSGWの見分け方 ジョブログやコンパイルリストで出るメッセージIDを整理したい場合は、AS400メッセージID・エラーコード一覧 も確認してください。原因メッセージと結果のエラーを分けて見る時の入口になります。
AS400（IBM i）で作業していると、CPFxxxx という形式のエラーコードをよく見ます。CPFエラーは、IBM iのシステムメッセージの一種で、コマンド実行、ファイル操作、ジョブ実行、権限不足など、さまざまな場面で表示されます。
エラーコードだけを見ると難しく感じますが、確認する順番を決めておけば落ち着いて調査できます。
CPFエラーとは
CPFは、IBM iが返すメッセージIDの接頭辞です。たとえば、存在しないオブジェクトを参照した、ファイルがロックされている、権限が足りない、コマンドの指定が誤っている、といった場合にCPFメッセージが出ます。
まず確認すること
- エラーが出た画面またはコマンドを確認する
- CPF番号を控える
- 直前に実行した操作を確認する
- ジョブログで前後のメッセージを見る
- 対象オブジェクト、ライブラリ、権限、ロック状態を確認する
ジョブログの確認
エラー調査では、画面に表示された1行だけで判断しないことが重要です。ジョブログには、エラーの前後に原因のヒントが出ていることがあります。コマンド実行中のエラーであれば、DSPJOBLOG やジョブのスプールから詳細を確認します。
よくある原因
| 原因 | 確認ポイント |
|---|---|
| オブジェクトが存在しない | ライブラリ名、オブジェクト名、ライブラリリストを確認 |
| 権限不足 | 対象オブジェクトの権限、実行ユーザーの権限を確認 |
| ファイルロック | 誰がファイルやレコードを使用しているか確認 |
| パラメータ誤り | コマンドやCALL時の指定値、桁数、型を確認 |
| コンパイルエラー | コンパイルリスト、参照ファイル、コピー句を確認 |
調査で使うコマンド例
DSPJOBLOG: 現在ジョブのジョブログを表示WRKJOB: ジョブを確認WRKOBJ: オブジェクト存在確認DSPOBJD: オブジェクト詳細確認DSPMSGD CPFxxxx: メッセージ説明の確認WRKOBJLCK: オブジェクトロック確認
対処の考え方
CPFエラーは、コードそのものを覚えるよりも、エラーの種類を切り分けることが大切です。存在しないのか、権限がないのか、ロックされているのか、指定値が違うのかを順番に確認します。
RPGプログラムでエラーが発生している場合は、どのファイル操作で落ちているかを見ます。CHAIN、READ、UPDATE、WRITE の周辺、外部プログラム CALL の戻りコード、ジョブログのメッセージを合わせて確認します。
AS400の操作に慣れていない場合は、基本コマンドを先に押さえると調査が楽になります。
まとめ
CPFエラーは、AS400が原因を知らせてくれる重要なメッセージです。エラー番号、ジョブログ、対象オブジェクト、権限、ロック状態を順に確認すれば、多くの問題は切り分けられます。焦って修正するより、まず事実を集めることが安全な保守につながります。
25年以上AS400に関わって感じること
私は2000年に新卒でIT業界に入り、流通業界の販売管理システムでAS400（IBM i）の開発・保守・追加要望対応を続けてきました。入社当時から「AS400は近いうちになくなる」と言われていましたが、今も現場では現役です。C言語研修では苦労しましたが、RPGに触れたときは「これならやっていける」と感じました。この記事も、そうした現場経験をもとに初心者向けに整理しています。
この記事の現場視点
CPFエラーは慣れないうちは怖く見えますが、落ち着いてジョブログを追うと原因に近づけます。本番前後の忙しい時期ほど、最後のメッセージだけで判断しないことが大切です。
CPFエラー調査で先に見るべき情報
CPFエラーはメッセージIDだけを見ても原因が決めきれないことがあります。実務では、発生時刻、ジョブ名、ユーザー、対象ファイル、直前に実行されたコマンドやプログラムを合わせて見ることで、原因を絞り込みやすくなります。
- ジョブログで最初に出たメッセージを確認する
- 後続エラーだけで判断しない
- 対象オブジェクトの存在、権限、ロック状態を見る
- 再現条件をメモしてから修正する
よくある質問
CPFエラーは毎回プログラム修正が必要ですか？
必ずしもそうではありません。権限不足、ファイル未作成、ライブラリリストの違い、データ状態など、運用や環境設定で解決するケースもあります。修正前にジョブログと対象オブジェクトを確認することが大切です。
このサイトの運営方針は、このサイトについて にまとめています。
CPFエラー対応と本番作業の注意点
CPFエラーの原因を調べるときも、本番環境での作業では更新先ライブラリーや作業手順の確認が欠かせません。実作業前のチェックポイントは、AS400の本番対応で初心者がやってはいけないことでも解説しています。
CPFエラーを見た時に最初に確認すること
CPFエラーを見た時、私はまずメッセージIDを確認します。ただし、メッセージIDだけを見て判断するわけではありません。そのメッセージIDを手がかりに、ジョブログ全体を検索して、実際に何が起きているのかを追います。
初心者は、画面に出ている1つのメッセージだけを見て「このエラーが原因だ」と考えがちです。しかしAS400 / IBM i の障害では、表示されているCPFメッセージが結果であって、原因はその少し前に出ていることがあります。
DSPJOBLOG F CPF F CPF4101 F CPF5035
ジョブログを見る時は、該当メッセージの前後も確認します。直前にどのプログラムが動いたのか、どのファイルを開こうとしたのか、どのCLから呼ばれているのか。そこまで見ないと、原因ではなく表面だけを追うことになります。
初心者には「プログラムがこけた」と説明する
CPFエラーについて、初心者が大きな勘違いをしているというより、そもそもそれが何なのか分かっていないことが多いです。だから私は、最初は難しく説明しすぎず「プログラムがこけた」「処理が障害になって止まった」と説明します。
そこから、CPFメッセージはAS400が出している異常や注意のメッセージであり、ジョブログに原因を追うための情報が残っている、と教える方が伝わりやすいです。
現場でよく見るCPFエラーの例
現場でよく見るCPF系のエラーとしては、ファイルオープンエラーや10進数エラーがあります。どちらも珍しいものではありませんが、原因の見方を間違えると調査に時間がかかります。
| 種類 | 現場で見ている原因 | 確認すること |
|---|---|---|
| ファイルオープンエラー | コンパイル環境を間違えている、対象ファイルが想定と違う、ライブラリー指定が違う | ライブラリーリスト、対象ファイル、コンパイル環境、実行環境 |
| 10進数エラー | 単純なテスト不足、想定外データ、数値項目に不正な値が入っている | 入力データ、直前処理、RPGの該当行、テストケース |
| オブジェクトなし | ライブラリー違い、配置漏れ、ジョブ環境違い | WRKOBJ、DSPLIBL、対象ライブラリー |
| 権限不足 | 実行ユーザーの権限不足、運用ユーザー違い | 実行ユーザー、オブジェクト権限、ジョブ記述 |
ファイルオープンエラーは、単に「ファイルが開けない」で終わらせません。コンパイルした環境と実行している環境が合っているか、見ているライブラリーが正しいかを確認します。10進数エラーは、かなり厳しめに言えばテスト不足で出ることも多いです。異常系や境界値を見ていないと、本番データで初めて落ちます。
CPFエラーで後続処理を止めるか判断する表
CPFエラーは、エラーIDだけで「止める」「続ける」を決めません。販売管理では、受注、出荷、在庫、売上、請求がつながっているため、後続処理がどのデータを使うかまで見て判断します。
| 見るところ | 確認内容 | 判断の目安 |
|---|---|---|
| メッセージID | CPF、RNX、MCHなどの種類 | まず何系の障害かを切り分ける |
| ジョブログ全体 | 直前のCALL、ファイル操作、権限、MSGW | 最後の1行だけで判断しない |
| 全体CL | 後続処理、MONMSG、ジョブ投入順 | 止めるべきか、リトライ可能かを見る |
| 業務影響 | 受注、出荷、在庫、売上、請求への影響 | 商品が客に届く処理を優先して見る |
後続処理を止めるかは全体CLを見て判断する
CPFエラーを見たからといって、私はすぐに後続処理を止める判断はしません。まず全体CLを調査して、後続処理が何をしているのかを確認します。
前処理が失敗しているのに後続処理を流すと危ない場合もあります。一方で、警告や想定内のメッセージとして処理設計されている場合もあります。だから、メッセージ単体ではなく、CL全体の流れ、MONMSGの扱い、次に呼ばれるプログラム、更新対象ファイルを見て判断します。
CALL PGM(TESTLIB/TEST001R) MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR)) CALL PGM(TESTLIB/TEST002R) CALL PGM(TESTLIB/TEST003R)
本当に危ないのは、「CPFが出たから止める」「CPFが出たけど動いているから続ける」と短絡的に判断することです。販売管理のような基幹システムでは、受注、出荷、在庫、売上、請求のどこに影響するかを見てから判断しないと、二次災害につながります。
CPFエラーはメッセージIDだけで終わらせない
CPFエラーを見たとき、私はまずメッセージIDを確認し、ジョブログ全体を検索して何が起きているのかを見ます。最後に出ているエラーだけを見ると、原因ではなく結果だけを拾ってしまうことがあります。
販売管理システムでは、ファイルオープンエラーや10進数データエラーのような障害が出ることがあります。ファイルオープン系はコンパイル環境やライブラリ指定の誤り、10進数エラーは単体テスト不足が原因になることもあります。
| 見え方 | 現場で疑うこと | 次に見る場所 |
|---|---|---|
| ファイルが開けない | ライブラリ違い、権限不足、オブジェクト違い | DSPLIBL、WRKOBJ、ジョブログ |
| 10進数データエラー | 入力値、桁数、テスト不足 | 該当ファイル、RPGソース、テストデータ |
| 後続処理で異常 | 前段の処理が正常に終わっていない | 全体CL、ジョブの流れ、関連ジョブログ |
すぐに「止める」「無視する」と決めるのではなく、全体CLや後続処理を確認して判断することが大切です。
AS400保守・運用の全体像を見るなら
MSGW、WRKJOB、DSPJOBLOG、バッチ、本番対応までまとめて確認したい方は、AS400保守・運用完全ガイドも参考にしてください。
