AS400 / IBM i の更新事故や本番トラブルでは、ジャーナルやコミットメント制御を理解しているかどうかで、調査と戻し判断の精度が変わります。普段は意識されにくい領域ですが、誤更新、途中失敗、夜間バッチの異常終了、SQL更新の確認では重要です。
ジャーナルとは
ジャーナルは、ファイルなどの変更履歴を記録する仕組みです。更新前後の情報や操作履歴を残すことで、障害調査や復旧の手がかりになります。ただし、すべてのファイルが必ずジャーナル対象とは限りません。
| 用語 | 意味 | 注意点 |
|---|---|---|
| ジャーナル | 変更履歴を記録するための仕組み | 対象ファイルが登録されているか確認する |
| ジャーナルレシーバー | 実際の履歴データを受けるオブジェクト | 世代、保存、削除、容量に注意する |
| コミットメント制御 | 複数更新をまとめて確定・取り消しする考え方 | プログラムやジョブの設計と関係する |
| ロールバック | 確定前の更新を取り消す考え方 | 何でも過去に戻せるわけではない |
確認する観点
| 確認 | 見るもの | 判断 |
|---|---|---|
| ジャーナル対象 | ファイル、ライブラリ、ジャーナル設定 | 対象データの変更履歴を追えるか |
| 更新範囲 | 対象レコード、時刻、実行ジョブ | どこまで戻す必要があるか |
| コミット単位 | トランザクション、コミット、ロールバック | 途中失敗時に整合性が保たれるか |
| 後続影響 | 帳票、締め処理、外部連携 | データだけ戻してよいか |
| 証跡 | ジョブログ、作業記録、承認 | あとで説明できるか |
更新事故の初動
誤更新が疑われる時は、まず追加更新を止めるかどうかを判断し、対象時刻、実行ユーザー、ジョブ、対象ファイル、処理名を記録します。焦って再実行や手修正を重ねると、後から追えなくなります。
本番障害の初動は AS400本番障害の初動チェックリスト、本番前の環境・承認確認は 本番作業チェックリスト、影響調査は RPG/CL影響調査チェックリスト が近いテーマです。
COMMIT後の更新は、ROLLBACKだけでは戻せない
AS400 / IBM iでは、STRCMTCTLを明示してコミットメント制御を開始する場合と、SQLの設定により暗黙に開始される場合があります。対象の接続・ジョブがコミットメント制御を利用しているかを先に確認します。COMMITで確定し、ROLLBACKはその作業単位の未確定変更を取り消します。
ここで誤解しやすいのは、ROLLBACKは「COMMIT前の更新を取り消す」ための仕組みであり、COMMIT済みの更新を何でも自動で元に戻す機能ではない、という点です。
COMMIT後に戻す必要が出た場合は、ジャーナル、バックアップ、作業前退避データを使って、補正更新や復元手順を作る判断になります。
本番作業前には、次の点を確認します。
- コミットメント制御を使っている処理か
- COMMITのタイミングはどこか
- ROLLBACKできる範囲はどこまでか
- 対象ファイルがジャーナル管理されているか
- 更新前データを作業前に退避しているか
「ロールバックできるはず」と思い込まず、COMMIT前ならROLLBACK、COMMIT後ならジャーナルや退避データを使って戻し案を作る、という切り分けが必要です。
COMMIT後に戻す必要が出た場合
COMMIT後の更新は、ROLLBACKだけでは取り消せません。そのため、障害発生後に「どのレコードが更新されたか」「更新前の値は何だったか」を確認する必要が出ます。対象ファイルがジャーナル管理されていれば、DSPJRNで更新履歴を確認できる場合があります。
実際の調査では、対象期間のレシーバー、ジョブ、ユーザー、更新時刻、対象ファイルを確認し、取得・保持されているイメージだけを根拠にします。QAUDJRNの監査記録と、業務ファイルの更新内容を記録するジャーナルは区別します。COMMIT後の復旧は、退避データ、業務承認、途中更新と再実行の影響まで合わせて判断します。
DSPJRN出力から更新前レコードを作る考え方
ジャーナルを設定していると、障害発生時にファイルの更新前・更新後の履歴を機械的に追える場合があります。現場では、障害発生後にDSPJRNで更新前後を確認し、更新前のレコードを抽出して、処理実行前に近い状態へ戻してからリランする、という考え方を取ることがあります。
DSPJRNの出力にはエントリーの管理情報と、種類に応じたエントリー固有データが含まれます。レコード内容を解釈するには、出力形式、エントリー種別、当時のレコード様式、データ型、CCSID、イメージの最小化設定などを確認します。データ部分をそのまま業務ファイルの行として扱ったり、最新の定義だけで読み替えたりしないでください。更新前イメージが取得・保持されているかを確認したうえで、検証環境で復旧材料として利用できるか確かめます。IBM公式：更新前イメージを使用する理由も参照してください。
| 確認するもの | 見る理由 | 関連ページ |
|---|---|---|
| 更新前・更新後の区別 | どのエントリーが戻し対象かを間違えないため | AS400データ復旧手順 |
| 制御用フィールド | 日時、ユーザー、ジョブ、エントリー種別などで絞り込むため | 本番障害の初動対応 |
| 実データ側のキー | 対象伝票、対象商品、対象得意先などを特定するため | DSPFFD・DSPPFMの確認 |
| リラン可否 | 戻した後に同じ処理を再実行してよいか判断するため | 本番データ修正前チェック |
注意点として、ジャーナルがあるから必ず安全に戻せるわけではありません。対象期間、対象ファイル、コミットメント制御、後続処理、外部連携、締め処理の状態を確認してから、戻すのか、再作成するのか、リランするのかを判断します。
APYJRNCHG・RMVJRNCHGを使う前に確認すること
ジャーナル関連の復旧では、APYJRNCHGやRMVJRNCHGのようなコマンド名が出てくることがあります。ただし、これらは「とりあえず実行して戻す」ためのコマンドではありません。対象ファイル、ジャーナルイメージ、レシーバー、ロック状態、コミット単位、後続処理への影響を確認してから検討します。
| 確認すること | 見る理由 |
|---|---|
| 対象ファイルがジャーナル対象か | 履歴がなければ復旧材料にできない |
| 更新前イメージが残っているか | 更新後だけでは戻し材料が不足することがある |
| 対象時刻・順序番号を絞れているか | 範囲を誤ると正しい更新まで巻き戻す可能性がある |
| 複数ファイル更新か | 1ファイルだけ戻すと業務整合性が崩れることがある |
| 帳票・EDI・締め・会計連携が済んでいるか | データを戻しても外部や後続処理が戻らないことがある |
現場では、コマンドの可否よりも「どの更新を、どこまで戻すのか」を説明できることが重要です。DSPJRNで更新前後を確認し、戻し対象を絞ったうえで、業務担当者と承認者に影響範囲を説明してから進めます。
参考：IBM公式ドキュメント（DSPJRN）
本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。
SQLがコミットメント制御を開始する条件はIBM公式：Transaction recovery through commitment controlで確認できます。制御対象外の更新や、すでに確定した更新をROLLBACKで戻せるとは考えないでください。