AS400 / IBM i の小改修では、テストが終わった後の本番反映と戻し手順が重要です。RPG/CLのオブジェクトを入れ替える、CLを差し替える、ファイル定義を変更する、夜間バッチに影響する修正を入れる場合は、反映前に「失敗した時にどう戻すか」を決めておく必要があります。
この記事では、AS400保守で本番反映前に確認すること、反映時に残す証跡、問題発生時の戻し方を整理します。サービス紹介だけでは見えにくい、現場で本当に必要になる作業です。
本番反映前に確認すること
| 確認項目 | 見ること | 残すもの |
|---|---|---|
| 対象オブジェクト | プログラム、CL、ファイル、メニュー | 変更前後のオブジェクト名とライブラリ |
| 反映時間 | 業務停止時間、夜間バッチ開始時刻 | 作業予定と承認者 |
| バックアップ | 変更前オブジェクト、ソース、SAVF | SAVOBJ、SAVLIB、SAVF名 |
| テスト結果 | 正常系、異常系、後続処理 | ジョブログ、画面、帳票、スプール |
| 戻し手順 | 問題時に何を戻すか | 復元コマンドと判断基準 |
変更前オブジェクトを必ず残す
本番反映で一番怖いのは、戻したい時に変更前が残っていないことです。プログラムやCLを入れ替える前に、変更前オブジェクトを別ライブラリやSAVFへ保存し、いつ、誰が、何を保存したかを記録します。ソースだけでなく、実行オブジェクトも戻せる状態にしておくと安全です。
夜間バッチ前後の反映は特に注意する
夜間バッチの前後に反映する場合は、JOBQ、SBSD、JOBSCDE、後続ジョブの開始時刻を確認します。請求締めや出荷確定に関わる処理では、途中で止まった時の再実行可否も先に決めておきます。反映直後にMSGW（メッセージ応答待ち）やCPF/RNXが出た場合、すぐジョブログを確認できる体制が必要です。
本番障害の初動は、AS400本番障害の初動チェックリストに整理しています。
反映後に見るエビデンス
反映後は、画面が動くかだけでなく、ジョブログ、スプール、更新ファイル、後続処理、外部連携を確認します。AS400では、画面上は正常に見えても、帳票やバッチ、CSV出力で後から問題が出ることがあります。
テストと証跡の残し方は、AS400小改修後のテスト・エビデンスチェックリストも参考になります。
戻し判断を先に決める
戻すかどうかの判断基準を反映後に考えると遅くなります。たとえば、特定のCPF/RNXが出たら戻す、締め処理が途中で止まったら業務担当者へ確認する、外部連携ファイルが作成されなければ旧オブジェクトへ戻す、という基準を先に決めます。
Codexで反映手順を整理する時
Codexは、本番反映手順、戻し手順、テスト観点、確認チェックリストの下書きを作る用途に使えます。ただし、会社名、ユーザー名、本番データ、取引先名は伏せ、実際のコマンド実行や本番判断は人間が行います。AIに作業を任せるのではなく、抜け漏れを減らす補助として使うのが安全です。
社内で安全に使うルールは、AS400 / IBM i 現場向け Codex実戦研修で整理できます。
ここまでの要点
AS400の本番反映では、対象オブジェクト、反映時間、バックアップ、テスト結果、戻し手順を先に確認します。変更前を残し、反映後のジョブログやスプールを確認し、問題時の戻し基準を決めておくことで、本番作業のリスクを下げられます。
ロールバック手順にジャーナル確認を入れる
AS400 / IBM i の本番反映で怖いのは、プログラムを戻すだけでは業務データが戻らないケースです。ジャーナルを設定しているファイルなら、障害発生後にDSPJRNで更新前・更新後の履歴を機械的に確認できます。COMMIT前ならROLLBACKで取り消せる可能性がありますが、COMMIT後はジャーナル、退避データ、バックアップ、承認記録を見て戻し案を作ります。
DSPJRNで更新前データを用意する考え方
DSPJRNをファイル出力すると、前半にIBM i側の制御情報、後半に実データが入ります。障害の時刻、ジョブ、ユーザー、更新区分、キー項目を手がかりにQRYやSQLで抽出すれば、更新前レコードの候補を作れます。これをそのまま本番へ戻すのではなく、業務担当者と対象件数、キー、更新時刻、後続処理を確認してからリランまたはデータ戻しを判断します。
| 確認するもの | 見る理由 |
|---|---|
| 障害発生時刻 | DSPJRNの抽出範囲を絞る |
| ジョブ名・ユーザー | 誤更新した処理や担当を特定する |
| 更新前・更新後イメージ | 戻すべき値と、戻してはいけない値を分ける |
| キー項目 | 対象レコードだけを抽出する |
| 後続ジョブ・外部連携 | EDIや締め処理へ影響が出ていないか確認する |
MSGW起点なら戻す前にジョブログを残す
障害起点がMSGWの場合、先にジョブログ、メッセージID、対象ファイル、直前の反映物、スプールを保存します。原因を残さずに戻すと、再実行後に同じ問題が出た時に追えなくなります。戻しは「旧オブジェクトへ戻す」「更新前データを戻す」「リランする」「外部連携を再送する」を分け、二重更新や二重送信を避けます。
戻した後に復旧完了とする条件
旧オブジェクトへ戻した、更新前データを戻した、リランした、という操作だけでは復旧完了とは言い切れません。戻し後は、業務データと後続処理が矛盾していないことを確認してから完了にします。
| 確認先 | 見ること | 完了にしない状態 |
|---|---|---|
| ジョブログ | 戻し処理、リラン、後続ジョブの完了 | 同じCPF/RNXやMSGWが残る |
| 業務データ | 対象件数、キー、更新前後の値 | 戻す対象外のレコードまで変わっている |
| 帳票・スプール | 請求書、出荷指示、エラーリスト | 画面は戻ったが帳票が旧状態のまま |
| 外部連携 | EDI、CSV、FTP、再送有無 | 相手先へ二重送信・未送信が残る |
| 業務承認 | 利用部門、運用担当、保守責任者 | 誰が復旧OKを出したか残らない |
あわせて確認するAS400本番作業記事
- AS400のジャーナル・コミットメント制御とは
- QAUDJRN・DSPJRNで更新履歴と原因を追う
- AS400本番データ修正の承認チェックリスト
- AS400本番反映Go/No-Goチェックリスト
- AS400外部連携データを再送する前のチェックリスト
- AS400 MSGWの見方
参考：IBM公式ドキュメント（DSPJRN）
本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。