AS400のジャーナル・コミットメント制御とは？データリカバリー前に誤解しないための基本

AS400 / IBM i のデータ更新や障害対応では、ジャーナル、ジャーナルレシーバー、コミットメント制御という言葉が出てきます。これらは、更新履歴、復旧、整合性に関係する重要な仕組みですが、初心者がいきなり深く扱うには難しいテーマです。

この記事では、AS400保守担当者が「ジャーナルがあるから戻せるはず」と誤解しないために、最初に知っておきたい考え方を整理します。実際の復旧作業は環境差が大きいため、ここでは現場で確認する観点に絞ります。

ジャーナルとは
最初に確認すること
ジャーナルがあっても油断しない
データリカバリーで見ること
本番でやってはいけないこと
現場での調査例：伝票データがおかしいと言われた場合
ここまでの要点
COMMIT、ROLLBACK、DSPJRNを分けて考える
更新前データを残せるジャーナル設計にしておく
DSPJRNで作った更新前候補をそのまま戻さない
あわせて確認するAS400データ保護記事
ジャーナルと復旧は、研修で扱う時ほど前提確認が重要です
参考：IBM公式ドキュメント（DSPJRN）

ジャーナルとは

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

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

最初に確認すること

対象ファイルがジャーナル対象か
どのジャーナルに記録されているか
ジャーナルレシーバーが残っているか
対象時刻や対象伝票を特定できるか
復旧する場合の業務影響は何か
復旧後に件数や金額をどう確認するか

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

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

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

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

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

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

本番でやってはいけないこと

ジャーナル対象か確認せず「戻せる」と言う
対象時刻や対象伝票を特定せず復旧を始める
ひとつのファイルだけ戻して業務整合性を崩す
復旧後の件数・金額・帳票確認をしない
レシーバー削除や保存ルールを理解せず触る

現場での調査例：伝票データがおかしいと言われた場合

AS400保守の現場では、利用部門から伝票番号を指定されて「このデータがおかしい」と問い合わせを受けることがあります。私の場合は、いきなりソースを読み始めるのではなく、まず対象となる伝票番号と発生した事象を固定します。

指定された伝票を実際の画面で確認する
DBの現在値と画面表示を照合する
「おかしくなったと思われる時刻」の前後に調査範囲を絞る
事象をCodexへ伝え、関連するRPGやCLの更新処理を調べる
プログラムだけで判断できない場合は、ジャーナルの更新前後を比較する
ソースの処理と実際の更新履歴を人が突き合わせて原因を判断する

画面とDBを見た後、時系列でデータを追う

画面とDBの両方を見るのは、利用者が見ている状態と、実際に保存されている値を分けて確認するためです。現在値だけで理由が分からない場合は、伝票作成時からすべて追うのではなく、「おかしくなったと思われる時刻」の前後を中心に確認します。関係のない更新を減らせるため、原因となった処理を見つけやすくなります。

まず事象と関連プログラムをCodexで調べる

最近は、確認した事象をCodexへ伝え、関連プログラムの条件分岐や更新処理を調べてもらうことが多くなりました。更新漏れや想定外の分岐など、バグの候補がこの段階で見つかることも多く、人がソースを最初から追うより調査工数を抑えやすくなります。具体的な使い分けは、CodexをAS400保守で使う方法でも整理しています。

分からない場合はジャーナルの更新前後を比較する

プログラム調査だけで原因を特定できない場合は、該当時間帯のジャーナルを確認します。私は特定項目だけではなく、更新前と更新後のレコードを全体的に比較します。どの項目が、どの値からどの値へ変わったのかを確認したうえで、更新時刻、ジョブ、ユーザー、プログラム名を結び付けます。

Codexの回答だけで確定せず、ソースに書かれた処理とジャーナルに残った事実が一致するかを人が確認することが重要です。

機密情報の扱い：実際の伝票番号、顧客情報、個人情報、接続情報を外部AIへそのまま渡しません。社内ルールと契約条件を満たす環境で、必要な範囲だけをマスキングして扱います。

ここまでの要点

ジャーナルとコミットメント制御は、AS400 / IBM i のデータ保護や整合性に関係する重要な仕組みです。ただし、初心者が「ジャーナルがあるから何でも戻せる」と考えるのは危険です。

本番で復旧判断をする時は、対象ファイル、ジャーナル、レシーバー、バックアップ、ジョブログ、業務影響を確認し、必要に応じて保守会社や責任者へ相談してください。

COMMIT、ROLLBACK、DSPJRNを分けて考える

ジャーナルとコミットメント制御は混同されやすいですが、役割は違います。ジャーナルはファイル更新の履歴を残す仕組みです。コミットメント制御は、処理の区切りまで更新を確定させるか、取り消すかを制御する仕組みです。DSPJRNは、ジャーナルに残った履歴を確認する時に使います。

用語	現場での意味
STRCMTCTL	コミットメント制御を開始する
COMMIT	未確定の更新を確定する
ROLLBACK	未確定の更新を取り消す
DSPJRN	ジャーナルに残った更新履歴を確認する
更新前イメージ	戻しや調査で使う更新前の値

初心者が特に注意したいのは、「ROLLBACKできるから安心」と決めつけないことです。COMMIT済みの更新は、ROLLBACKだけでは元に戻せません。戻すには、更新前データ、バックアップ、ジャーナルの前イメージ、または作業前に退避したデータを使って復旧案を作る必要があります。

更新前データを残せるジャーナル設計にしておく

ジャーナルは「設定してあるか」だけでなく、「あとで何を確認したいか」まで決めておくと実務で使いやすくなります。障害発生時に更新前・更新後の履歴を追いたい場合は、対象ファイル、更新前イメージ、ジャーナルレシーバーの保管期間、DSPJRNで見る時の時刻・ジョブ・ユーザー・キー項目を事前に整理します。

どの物理ファイルをジャーナル対象にするかを決める
更新前イメージを残す必要があるかを確認する
レシーバーの保管期間と容量を決める
DSPJRNで抽出する時刻、ジョブ、ユーザー、キー項目を整理する
復旧やリランは業務承認を取ってから実施する

DSPJRNで作った更新前候補をそのまま戻さない

DSPJRNをファイル出力し、制御情報と実データのキー項目で抽出すると、更新前レコードの候補を作れます。ただし、その候補をそのまま本番へ戻す前に、対象件数、時刻、後続処理、業務承認を確認します。

確認	見ること	止める状態
対象件数	抽出件数、キー項目、重複	想定件数と合わない
時刻	障害発生時刻、更新時刻、COMMIT時刻	別処理の更新が混ざる
後続処理	締め、在庫、請求、外部連携	戻すと後続データと矛盾する
承認	業務担当、保守責任者、戻し方法	誰が復旧OKを出したか残らない

あわせて確認するAS400データ保護記事

ジャーナルと復旧は、研修で扱う時ほど前提確認が重要です

ジャーナルやコミットメント制御は、知識としては説明できても、本番復旧で使う時には判断を間違えやすい領域です。特に「ジャーナルがあるから戻せる」と決めつけるのは危険です。対象ファイル、ジャーナル設定、更新前後イメージ、コミット境界、業務上戻してよい範囲を分けて確認します。

確認項目	見る内容	注意点
ジャーナル設定	対象ファイルがジャーナル対象か、更新前イメージがあるか	設定がなければDSPJRNだけでは戻せない
更新範囲	対象日時、対象キー、対象ジョブ、対象ユーザー	範囲を広く取りすぎると正常更新まで巻き戻す
COMMIT / ROLLBACK	コミット境界、未コミット状態、トランザクション単位	1レコードだけ見て判断しない
復旧手順	抽出、確認、承認、復旧、検証の順番	本番更新前に承認とバックアップを確認する
教育化	事例、禁止事項、相談基準を残す	操作だけでなく判断基準を残す