AS400（IBM i）でRPGを保守するなら、コンパイルリストの読み方は避けて通れません。
コンパイルリストは、アプリをコンパイルした時のレポートです。エラーがあってもなくても出力させ、コンパイルが通ったか、どこに警告やエラーがあるかを確認します。
この記事では、25年以上AS400 / IBM iの販売管理システム保守に関わってきた現場目線で、初心者がまずどこを見ればよいかを整理します。
コンパイルリストとは
コンパイルリストは、RPGやCLなどをコンパイルした時に出力されるスプールです。ソース行、メッセージ、重大度、最終結果などを確認できます。
WRKJOBの記事でも書いた通り、コンパイルリストは「アプリをコンパイルした時のレポート」、ジョブログは「アプリを実行した時のレポート」です。
最初に見るのはコンパイルリストの一番下
RPGのコンパイルリストで最初に見る場所は、一番下です。
そこで、コンパイルされたのか、失敗したのかを確認します。次に見るのが重大度です。コンパイルリストは上から全部読むより、まず最後の結果を見て、そこからエラー番号で当たりを付ける方が現場では早いです。
| 見る順番 | 見る場所 | 確認すること |
|---|---|---|
| 1 | コンパイルリストの一番下 | コンパイルが成功したか失敗したか |
| 2 | メッセージ合計 | 通知、警告、エラー、重大エラーの件数 |
| 3 | 重大度 | どの程度の問題か |
| 4 | エラー番号 | RNF7031などで検索して該当箇所を探す |
| 5 | ソース | エラー箇所を修正してリコンパイルする |
重大度30と40の感覚
初心者が分かりにくいのは、重大度の数字の感覚です。
重大度40では、ファイル定義の不整合などを示す重大なエラーとして扱い、コンパイル結果と影響を確認します。重大度30は、フィールドの定義がおかしいなど、検索して修正すれば改善できることも多いです。
| 重大度 | 現場での見方 | 例 |
|---|---|---|
| 00 | 通知 | コンパイル時の情報メッセージ |
| 10 | 警告 | 注意は必要だが、すぐ失敗とは限らない |
| 20 | エラー | 修正対象として見る |
| 30 | 比較的よく見るエラー | フィールド定義、参照、記述ミスなど |
| 40 | 重大なエラー（原因確認と修正が必要） | ファイル定義、参照関係、コンパイル環境の問題など |
もちろん、重大度だけで全てを判断するわけではありません。重大度は、調査の入口です。
RNF7031のようなエラー番号は検索して当たりを付ける
RNF7031のようなエラー番号が出たら、私はまず 7031 でコンパイルリスト内を検索して当たりを付けます。
エラー番号を見つけたら、その周辺のメッセージ、ソース行、参照しているフィールドやファイルを確認します。いきなりソース全体を眺めるより、コンパイルリストでエラー箇所を特定してからソースを開く方が効率的です。
検索キー例:
7031
RNF7031
重大度 30
重大度 40コンパイルリストとソースの見比べ方
正直に言うと、コンパイルリストとソースを丁寧に横に並べて見比べる、ということはあまりしません。
現場では、コンパイルリストを見てエラー箇所を特定し、ソースを開いてそこを修正し、リコンパイルします。その繰り返しです。
- コンパイルリストの一番下を見る
- 重大度とエラー番号を見る
- エラー番号で検索して該当箇所へ移動する
- ソースを開いて修正する
- リコンパイルする
- 再度コンパイルリストの一番下を見る
エラー0件ならまずは安心。ただし動かして確認する
コンパイルエラーがなければ、まずは安心です。
ただし、コンパイルが通ったからといって、業務処理として正しく動くとは限りません。あとは動かしてみないと分かりません。単体テスト、ジョブログ確認、必要ならスプール確認まで行います。
特に販売管理システムでは、受注、出荷、在庫、売上、請求、外部I/Fなどがつながっています。コンパイルが通った後も、処理順やデータの流れを見て確認します。
本番作業ではコンパイルが通る状態で納品する
販売管理システムの保守で、コンパイルミスが本番に出ると怖いケースは何か。私の答えは、そもそもコンパイルミスが起こる状態で本番作業は行わない、です。
基本的に、コンパイルが通る状態で納品します。本番作業前に、テスト環境でコンパイル、単体テスト、必要な確認を済ませておくべきです。
本番対応の注意点は、AS400の本番対応で初心者がやってはいけないことにもまとめています。
若手には実戦で見方を説明する
コンパイルリストの読み方は、職人技みたいなところがあります。教科書のように一概に説明するより、実際にコンパイルリストを出力した時に、その場で見方を説明する方が伝わりやすいです。
最初に教えるなら、「一番下を見ろ」「重大度を見ろ」「エラー番号で検索しろ」「直したらリコンパイルしろ」です。
共有する時は、私はスクショ派です。どの行に、どのエラーが出ているかを見せた方が早いです。ただし、実データや顧客情報が写っていないかは必ず確認します。
コンパイルリストを確認した後、スプール、ジョブログ、ファイル定義、ライブラリを追加で見たい場合は、AS400コマンド逆引きから目的別に確認コマンドを探せます。
次に読む記事
コンパイルが通ったら単体テストへ進む
コンパイルリストでエラーが0件になっても、そこで作業完了ではありません。コンパイルは「作れるか」の確認で、単体テストは「仕様通りに動くか」の確認です。
RPGやCLを修正した後は、基本動作、最大桁・境界値、DB更新、帳票、外部I/F、ジョブログまで見ます。単体テストの観点は、AS400保守の単体テストで確認すべきことにまとめています。
ここまでの要点
AS400のコンパイルリストは、まず一番下を見て、コンパイルが成功したか失敗したかを確認します。
次に重大度を見ます。重大度30と40の感覚が分かってくると、どのくらい急いで直すべきか、どこを疑うべきかが見えやすくなります。
RNF7031のようなエラー番号は、コンパイルリスト内で検索して当たりを付けます。該当箇所を修正し、リコンパイルして、また一番下を見る。この繰り返しが基本です。
コンパイルが通ったらまずは安心。ただし、最後は動かして確認する。ここまで含めて、AS400保守の仕事です。
AS400保守・運用の全体像を見るなら
MSGW、WRKJOB、DSPJOBLOG、バッチ、本番対応までまとめて確認したい方は、AS400保守・運用完全ガイドも参考にしてください。
RPGソースを確認する画面例
コンパイルリストでエラー行を見つけた後は、該当するRPGソースを開いて前後の処理を確認します。エラー番号だけで判断せず、ファイル定義、パラメータ、項目定義、サブルーチン呼び出しまでつなげて見ることが大切です。
コンパイルリストは修正後の影響確認にも使う
コンパイルリストは、エラー行を見るだけでなく、警告、未使用項目、参照ファイル、変換エラー、CCSID、テスト観点を拾う材料にもなります。修正前の影響調査はDSPPGMREF確認、RPGの読み方はRPGソースの読み方、AIでレビューする場合はRPGソースをAIに読ませる時の注意点も確認してください。
コンパイルリストは単体テスト証跡にもなる
コンパイルリストはエラーを直すためだけでなく、修正後に何を確認したかを残す証跡にもなります。単体テストでは、コンパイル日時、ソースメンバー、重大度、生成オブジェクト、実行ジョブ、ジョブログを合わせて残すと、レビューやAIを使った調査がしやすくなります。テスト観点は RPG/CL修正後の単体テスト手順 へ進んでください。
次に確認するAS400保守の入口
コンパイルリストを読めるようになったら、エラー修正後の障害確認とコマンド確認までセットで覚えると現場対応が安定します。
コンパイルリストはエラー行だけでなく変更範囲を見る
RPGやCLのコンパイルでエラーが出た時、該当行だけを見ると修正が狭くなりすぎることがあります。実務では、直前に変更した範囲、参照しているファイル、コピー句、呼び出し先、警告メッセージまで合わせて確認すると、再修正を減らしやすくなります。
| 確認する場所 | 見る理由 | 関連する記事 |
|---|---|---|
| エラー行 | 文法ミス、桁、定義漏れを確認する | RPGの基本 |
| 直前の変更範囲 | 修正漏れや項目名の不一致を探す | RPG/CL影響調査 |
| 参照ファイル | フィールド定義、桁数、CCSIDの違いを見る | ライブラリとオブジェクト確認 |
| 警告メッセージ | コンパイルは通るが危ない箇所を拾う | CPFエラー一覧 |
| レビュー観点 | 若手や引き継ぎ担当へ確認順を渡す | 研修内容・料金を見る |
Codexにコンパイルリストを読ませる場合も、エラー行だけを貼るより、変更した目的、対象プログラム、関連ファイル、発生したメッセージを一緒に整理した方が確認観点を出しやすくなります。ただし、顧客名、接続情報、本番データ、ソース全文などの機密情報は入れない運用にしてください。
