AS400ジャーナル確認手順｜DSPJRNで更新前後と戻し判断を見る

2026.06.11

AS400 / IBM i の更新事故や本番トラブルでは、ジャーナルやコミットメント制御を理解しているかどうかで、調査と戻し判断の精度が変わります。普段は意識されにくい領域ですが、誤更新、途中失敗、夜間バッチの異常終了、SQL更新の確認では重要です。

確認する観点

確認見るもの判断
ジャーナル対象ファイル、ライブラリ、ジャーナル設定対象データの変更履歴を追えるか
更新範囲対象レコード、時刻、実行ジョブどこまで戻す必要があるか
コミット単位トランザクション、コミット、ロールバック途中失敗時に整合性が保たれるか
後続影響帳票、締め処理、外部連携データだけ戻してよいか
証跡ジョブログ、作業記録、承認あとで説明できるか

戻しは技術だけで判断しない

ジャーナルがあるから戻せる、という判断は危険です。すでに帳票が出ている、外部へ連携済み、別処理で集計済みの場合、データだけを戻すと業務上の不整合が残ることがあります。戻し前に、業務担当者、保守担当、承認者で影響範囲を確認します。

更新事故の初動

誤更新が疑われる時は、まず追加更新を止めるかどうかを判断し、対象時刻、実行ユーザー、ジョブ、対象ファイル、処理名を記録します。焦って再実行や手修正を重ねると、後から追えなくなります。

本番障害の初動は AS400本番障害の初動チェックリスト、本番反映と戻しは AS400本番反映・戻し手順チェックリスト、影響調査は AS400保守会社に相談する前のチェックリスト が近いテーマです。

Codexは記録整理に使う

ジャーナルや更新事故の相談でCodexを使う場合は、実データを渡さず、発生時刻、処理名、匿名化したファイル名、確認済み事項だけを渡します。AIには確認漏れの洗い出しを任せ、戻し実行と業務判断は人が行います。

データを修正する前の承認、対象件数、退避、修正後確認は、本番データ修正チェックリストで整理してください。

ジャーナルとは

ジャーナルは、ファイルなどの変更履歴を記録する仕組みです。更新前後の情報や操作履歴を残すことで、障害調査や復旧の手がかりになります。ただし、すべてのファイルが必ずジャーナル対象とは限りません。

用語意味注意点
ジャーナル変更履歴を記録するための仕組み対象ファイルが登録されているか確認する
ジャーナルレシーバー実際の履歴データを受けるオブジェクト世代、保存、削除、容量に注意する
コミットメント制御複数更新をまとめて確定・取り消しする考え方プログラムやジョブの設計と関係する
ロールバック確定前の更新を取り消す考え方何でも過去に戻せるわけではない

ジャーナルがあっても油断しない

ジャーナルがあるから必ず簡単に戻せる、とは限りません。対象ファイルがジャーナル対象外だった、レシーバーが残っていなかった、対象時刻が分からない、複数ファイルをまたいだ更新だった、ということがあります。

販売管理のような業務では、受注、出荷、在庫、売上、請求が連動しているため、ひとつのファイルだけ戻すと整合性が崩れることがあります。復旧判断では、販売管理システム保守ガイド も合わせて確認します。

データリカバリーで見ること

データリカバリーでは、バックアップ、ジャーナル、ジョブログ、業務影響をセットで見ます。バックアップから戻すのか、ジャーナルを使うのか、手作業で補正するのかは、対象データと影響範囲によって変わります。

復旧の考え方は、AS400データ復旧 と バックアップ確認チェックリスト も確認してください。

変更前オブジェクトを必ず残す

本番反映で一番怖いのは、戻したい時に変更前が残っていないことです。プログラムやCLを入れ替える前に、変更前オブジェクトを別ライブラリやSAVFへ保存し、いつ、誰が、何を保存したかを記録します。ソースだけでなく、実行オブジェクトも戻せる状態にしておくと安全です。

夜間バッチ前後の反映は特に注意する

夜間バッチの前後に反映する場合は、JOBQ、SBSD、JOBSCDE、後続ジョブの開始時刻を確認します。請求締めや出荷確定に関わる処理では、途中で止まった時の再実行可否も先に決めておきます。反映直後にMSGW（メッセージ応答待ち）やCPF/RNXが出た場合、すぐジョブログを確認できる体制が必要です。

本番障害の初動は、AS400本番障害の初動チェックリストに整理しています。

反映後に見るエビデンス

反映後は、画面が動くかだけでなく、ジョブログ、スプール、更新ファイル、後続処理、外部連携を確認します。AS400では、画面上は正常に見えても、帳票やバッチ、CSV出力で後から問題が出ることがあります。

テストと証跡の残し方は、AS400業務ヒアリングシートも参考になります。

戻し判断を先に決める

戻すかどうかの判断基準を反映後に考えると遅くなります。たとえば、特定のCPF/RNXが出たら戻す、締め処理が途中で止まったら業務担当者へ確認する、外部連携ファイルが作成されなければ旧オブジェクトへ戻す、という基準を先に決めます。

ロールバック手順にジャーナル確認を入れる

AS400 / IBM i の本番反映で怖いのは、プログラムを戻すだけでは業務データが戻らないケースです。対象期間にジャーナル処理され、必要なレシーバーが残っていれば、DSPJRNで記録された変更を調べられます。ただし、更新前イメージの取得設定やコミットメント制御の利用状況によって、残る情報は異なります。ジャーナルがあるだけで更新前の値を取得できるとは限りません。COMMIT前ならROLLBACKで取り消せる可能性がありますが、COMMIT後はジャーナル、退避データ、バックアップ、承認記録を見て戻し案を作ります。

ジャーナルと更新履歴とあわせて確認したい手順

ジャーナルとコミットメント制御は、更新事故や復旧判断の土台です。コマンド確認だけでなく、どの業務を戻すのか、どこまで整合性を見るのかを合わせて確認します。

COMMIT後の更新は、ROLLBACKだけでは戻せない

AS400 / IBM i のコミットメント制御では、STRCMTCTLで制御を開始し、COMMITで確定、ROLLBACKで未確定の変更を取り消します。

ここで誤解しやすいのは、ROLLBACKは「COMMIT前の更新を取り消す」ための仕組みであり、COMMIT済みの更新を何でも自動で元に戻す機能ではない、という点です。

COMMIT後に戻す必要が出た場合は、ジャーナル、バックアップ、作業前退避データを使って、補正更新や復元手順を作る判断になります。

本番作業前には、次の点を確認します。

  • コミットメント制御を使っている処理か
  • COMMITのタイミングはどこか
  • ROLLBACKできる範囲はどこまでか
  • 対象ファイルがジャーナル管理されているか
  • 更新前データを作業前に退避しているか

「ロールバックできるはず」と思い込まず、COMMIT前ならROLLBACK、COMMIT後ならジャーナルや退避データを使って戻し案を作る、という切り分けが必要です。

COMMIT後に戻す必要が出た場合

COMMIT後の更新は、ROLLBACKだけでは取り消せません。そのため、障害発生後に「どのレコードが更新されたか」「更新前の値は何だったか」を確認する必要が出ます。対象ファイルがジャーナル管理されていれば、DSPJRNで更新履歴を確認できる場合があります。

実際の調査では、対象期間のレシーバー、ジョブ、ユーザー、更新時刻、対象ファイルを確認し、取得・保持されているイメージだけを根拠にします。QAUDJRNの監査記録と、業務ファイルの更新内容を記録するジャーナルは区別します。COMMIT後の復旧は、退避データ、業務承認、途中更新と再実行の影響まで合わせて判断します。

DSPJRNで更新前後を確認して、戻し判断に使う

ジャーナルを設定している現場では、障害発生時に「どのレコードが、いつ、どのジョブで、どう変わったか」を機械的に追えるのが大きな強みです。COMMIT前ならROLLBACKで戻せる可能性がありますが、COMMIT後はジャーナルやバックアップを見ながら、業務上どこまで戻すかを判断します。

現場でよく使う流れは、障害発生後にDSPJRNで対象ファイルの更新前後を確認し、更新前レコードを抽出して、リラン前の状態を再現できるか検討する方法です。ジャーナルは「戻すボタン」ではなく、戻し判断の証跡と材料として使う、と考えると事故対応で迷いにくくなります。

  • 障害発生時刻、対象ジョブ、対象ユーザーを絞る
  • 対象期間のレシーバーと記録されたイメージを確認する。更新前値の比較は更新前イメージが残る場合に限る
  • COMMIT前かCOMMIT後かを確認する
  • 利用可能な更新前イメージや退避データを検証環境で解釈し、戻し・補正更新・再実行の可否を業務担当と判断する
  • 業務担当者に、後続処理や外部連携への影響を確認してから実行する

特にEDI、請求締め、在庫引当、出荷確定のように相手先や後続処理が絡む業務では、技術的に戻せることと、業務として戻してよいことは別です。DSPJRNの結果は、業務担当者と会話するための証拠として残しておくのが安全です。

DSPJRN出力から更新前レコードを作る考え方

ジャーナルを設定していると、障害発生時にファイルの更新前・更新後の履歴を機械的に追える場合があります。現場では、障害発生後にDSPJRNで更新前後を確認し、更新前のレコードを抽出して、処理実行前に近い状態へ戻してからリランする、という考え方を取ることがあります。

DSPJRNの出力にはエントリーの管理情報と、種類に応じたエントリー固有データが含まれます。レコード内容を解釈するには、出力形式、エントリー種別、当時のレコード様式、データ型、CCSID、イメージの最小化設定などを確認します。データ部分をそのまま業務ファイルの行として扱ったり、最新の定義だけで読み替えたりしないでください。更新前イメージが取得・保持されているかを確認したうえで、検証環境で復旧材料として利用できるか確かめます。IBM公式：更新前イメージを使用する理由も参照してください。

確認するもの見る理由関連ページ
更新前・更新後の区別どのエントリーが戻し対象かを間違えないためAS400データ復旧手順
制御用フィールド日時、ユーザー、ジョブ、エントリー種別などで絞り込むため本番障害の初動対応
実データ側のキー対象伝票、対象商品、対象得意先などを特定するためDSPFFD・DSPPFMの確認
リラン可否戻した後に同じ処理を再実行してよいか判断するため本番データ修正前チェック

注意点として、ジャーナルがあるから必ず安全に戻せるわけではありません。対象期間、対象ファイル、コミットメント制御、後続処理、外部連携、締め処理の状態を確認してから、戻すのか、再作成するのか、リランするのかを判断します。

APYJRNCHG・RMVJRNCHGを使う前に確認すること

ジャーナル関連の復旧では、APYJRNCHGやRMVJRNCHGのようなコマンド名が出てくることがあります。ただし、これらは「とりあえず実行して戻す」ためのコマンドではありません。対象ファイル、ジャーナルイメージ、レシーバー、ロック状態、コミット単位、後続処理への影響を確認してから検討します。

確認すること見る理由
対象ファイルがジャーナル対象か履歴がなければ復旧材料にできない
更新前イメージが残っているか更新後だけでは戻し材料が不足することがある
対象時刻・順序番号を絞れているか範囲を誤ると正しい更新まで巻き戻す可能性がある
複数ファイル更新か1ファイルだけ戻すと業務整合性が崩れることがある
帳票・EDI・締め・会計連携が済んでいるかデータを戻しても外部や後続処理が戻らないことがある

現場では、コマンドの可否よりも「どの更新を、どこまで戻すのか」を説明できることが重要です。DSPJRNで更新前後を確認し、戻し対象を絞ったうえで、業務担当者と承認者に影響範囲を説明してから進めます。

参考：IBM公式ドキュメント（DSPJRN）

本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。

スポンサーリンク