AS400 / IBM i の更新事故や本番トラブルでは、ジャーナルやコミットメント制御を理解しているかどうかで、調査と戻し判断の精度が変わります。普段は意識されにくい領域ですが、誤更新、途中失敗、夜間バッチの異常終了、SQL更新の確認では重要です。
確認する観点
| 確認 | 見るもの | 判断 |
|---|---|---|
| ジャーナル対象 | ファイル、ライブラリ、ジャーナル設定 | 対象データの変更履歴を追えるか |
| 更新範囲 | 対象レコード、時刻、実行ジョブ | どこまで戻す必要があるか |
| コミット単位 | トランザクション、コミット、ロールバック | 途中失敗時に整合性が保たれるか |
| 後続影響 | 帳票、締め処理、外部連携 | データだけ戻してよいか |
| 証跡 | ジョブログ、作業記録、承認 | あとで説明できるか |
戻しは技術だけで判断しない
ジャーナルがあるから戻せる、という判断は危険です。すでに帳票が出ている、外部へ連携済み、別処理で集計済みの場合、データだけを戻すと業務上の不整合が残ることがあります。戻し前に、業務担当者、保守担当、承認者で影響範囲を確認します。
更新事故の初動
誤更新が疑われる時は、まず追加更新を止めるかどうかを判断し、対象時刻、実行ユーザー、ジョブ、対象ファイル、処理名を記録します。焦って再実行や手修正を重ねると、後から追えなくなります。
本番障害の初動は AS400本番障害の初動チェックリスト、本番反映と戻しは AS400本番反映・戻し手順チェックリスト、影響調査は AS400 RPG/CL影響調査チェックリスト が近いテーマです。
Codexは記録整理に使う
ジャーナルや更新事故の相談でCodexを使う場合は、実データを渡さず、発生時刻、処理名、匿名化したファイル名、確認済み事項だけを渡します。AIには確認漏れの洗い出しを任せ、戻し実行と業務判断は人が行います。
関連: AS400本番データ修正の承認チェックリスト｜SQL更新・手修正で事故を防ぐもあわせて確認してください。
関連するAS400確認ルート
ジャーナルとコミットメント制御は、更新事故や復旧判断の土台です。コマンド確認だけでなく、どの業務を戻すのか、どこまで整合性を見るのかを合わせて確認します。
COMMIT後の更新は、ROLLBACKだけでは戻せない
AS400 / IBM i のコミットメント制御では、STRCMTCTLで制御を開始し、COMMITで確定、ROLLBACKで未確定の変更を取り消します。
ここで誤解しやすいのは、ROLLBACKは「COMMIT前の更新を取り消す」ための仕組みであり、COMMIT済みの更新を何でも自動で元に戻す機能ではない、という点です。
COMMIT後に戻す必要が出た場合は、ジャーナル、バックアップ、作業前退避データを使って、補正更新や復元手順を作る判断になります。
本番作業前には、次の点を確認します。
- コミットメント制御を使っている処理か
- COMMITのタイミングはどこか
- ROLLBACKできる範囲はどこまでか
- 対象ファイルがジャーナル管理されているか
- 更新前データを作業前に退避しているか
「ロールバックできるはず」と思い込まず、COMMIT前ならROLLBACK、COMMIT後ならジャーナルや退避データを使って戻し案を作る、という切り分けが必要です。
COMMIT後に戻す必要が出た場合
COMMIT後の更新は、ROLLBACKだけでは取り消せません。そのため、障害発生後に「どのレコードが更新されたか」「更新前の値は何だったか」を確認する必要が出ます。対象ファイルがジャーナル管理されていれば、DSPJRNで更新履歴を確認できる場合があります。
実際の調査では、ジョブ、ユーザー、更新時刻、対象ファイル、更新前後の値を順に見ます。DSPJRNの確認観点はAS400監査ジャーナル・DSPJRNの確認方法にまとめています。COMMIT後の復旧は、ジャーナルだけで決めず、バックアップ、退避データ、業務承認、再実行可否とあわせて判断します。
DSPJRNで更新前後を確認して、戻し判断に使う
ジャーナルを設定している現場では、障害発生時に「どのレコードが、いつ、どのジョブで、どう変わったか」を機械的に追えるのが大きな強みです。COMMIT前ならROLLBACKで戻せる可能性がありますが、COMMIT後はジャーナルやバックアップを見ながら、業務上どこまで戻すかを判断します。
現場でよく使う流れは、障害発生後にDSPJRNで対象ファイルの更新前後を確認し、更新前レコードを抽出して、リラン前の状態を再現できるか検討する方法です。ジャーナルは「戻すボタン」ではなく、戻し判断の証跡と材料として使う、と考えると事故対応で迷いにくくなります。
- 障害発生時刻、対象ジョブ、対象ユーザーを絞る
- DSPJRNで対象ファイルの更新前後を確認する
- COMMIT前かCOMMIT後かを確認する
- 更新前レコードを抽出し、戻し・補正更新・リランのどれが安全か判断する
- 業務担当者に、後続処理や外部連携への影響を確認してから実行する
特にEDI、請求締め、在庫引当、出荷確定のように相手先や後続処理が絡む業務では、技術的に戻せることと、業務として戻してよいことは別です。DSPJRNの結果は、業務担当者と会話するための証拠として残しておくのが安全です。
DSPJRN出力から更新前レコードを作る考え方
ジャーナルを設定していると、障害発生時にファイルの更新前・更新後の履歴を機械的に追える場合があります。現場では、障害発生後にDSPJRNで更新前後を確認し、更新前のレコードを抽出して、処理実行前に近い状態へ戻してからリランする、という考え方を取ることがあります。
DSPJRNをファイル出力すると、前半にIBM i側の制御用フィールドが入り、後半に実データが入る形になります。つまり、出力ファイルをQRYやSQLで見て、制御用フィールドと実データ側のキー項目を条件に抽出できれば、更新前レコードを作るための材料になります。
| 確認するもの | 見る理由 | 関連ページ |
|---|---|---|
| 更新前・更新後の区別 | どのエントリーが戻し対象かを間違えないため | AS400データ復旧手順 |
| 制御用フィールド | 日時、ユーザー、ジョブ、エントリー種別などで絞り込むため | 本番障害の初動対応 |
| 実データ側のキー | 対象伝票、対象商品、対象得意先などを特定するため | DSPFFD・DSPPFMの確認 |
| リラン可否 | 戻した後に同じ処理を再実行してよいか判断するため | 本番データ修正前チェック |
注意点として、ジャーナルがあるから必ず安全に戻せるわけではありません。対象期間、対象ファイル、コミットメント制御、後続処理、外部連携、締め処理の状態を確認してから、戻すのか、再作成するのか、リランするのかを判断します。
APYJRNCHG・RMVJRNCHGを使う前に確認すること
ジャーナル関連の復旧では、APYJRNCHGやRMVJRNCHGのようなコマンド名が出てくることがあります。ただし、これらは「とりあえず実行して戻す」ためのコマンドではありません。対象ファイル、ジャーナルイメージ、レシーバー、ロック状態、コミット単位、後続処理への影響を確認してから検討します。
| 確認すること | 見る理由 |
|---|---|
| 対象ファイルがジャーナル対象か | 履歴がなければ復旧材料にできない |
| 更新前イメージが残っているか | 更新後だけでは戻し材料が不足することがある |
| 対象時刻・順序番号を絞れているか | 範囲を誤ると正しい更新まで巻き戻す可能性がある |
| 複数ファイル更新か | 1ファイルだけ戻すと業務整合性が崩れることがある |
| 帳票・EDI・締め・会計連携が済んでいるか | データを戻しても外部や後続処理が戻らないことがある |
現場では、コマンドの可否よりも「どの更新を、どこまで戻すのか」を説明できることが重要です。DSPJRNで更新前後を確認し、戻し対象を絞ったうえで、業務担当者と承認者に影響範囲を説明してから進めます。
DSPJRNで更新前レコードを復元材料にする
ジャーナルを設定しているファイルでは、障害発生時に更新前と更新後の履歴を機械的に追える場合があります。現場では、単に「誰が更新したか」を見るだけでなく、更新前レコードを復旧材料として取り出せるかまで確認します。
- 障害発生時刻、対象ファイル、対象キー、実行ジョブを記録する
- DSPJRNで対象範囲を絞り、更新前後のエントリーを確認する
- DSPJRNをファイル出力し、制御情報と実データ部分を分けて見る
- QRYなどでキー項目を条件に抽出し、更新前レコードを復元材料として作る
- 戻し後にリランしてよいか、EDI、締め、帳票、会計連携への影響を確認する
DSPJRNのファイル出力は、前半にIBM i側の制御情報、後半に実データが入る形で扱うことがあります。そのため、制御情報だけを見て判断せず、実データ側のキー項目と業務上の対象伝票を合わせて確認します。更新前データを作れても、すでに請求、出荷、EDI送信、会計連携が進んでいる場合は、データだけ戻すと別の不整合を作るため、戻しとリランは別判断にします。
この手順は環境差が大きいため、コマンド例をそのまま実行するより、まず自社のジャーナル設定、対象ファイル、保管期間、出力形式、承認ルールを確認してください。大切なのは「ジャーナルがあるから安心」ではなく、「障害時に更新前後を説明でき、必要なら復旧材料を作れる状態にしておく」ことです。
参考：IBM公式ドキュメント（DSPJRN）
本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。