AS400 / IBM i の保守では、どうしても本番データを手修正しなければならない場面があります。ただし、SQL更新やDFU的な手修正は、便利であるほど事故につながります。1件だけの修正でも、承認、対象件数、バックアップ、戻し手順、証跡を残すことが重要です。
本番データ修正前の確認
| 確認 | 見るもの | 判断 |
|---|---|---|
| 修正理由 | 依頼内容、業務影響、原因 | 本当に本番修正が必要か |
| 対象範囲 | ライブラリ、ファイル、キー、件数 | WHERE条件が正しいか |
| 承認 | 利用部門、保守責任者、作業者 | 口頭だけで進めていないか |
| 戻し | 修正前値、バックアップ、ジャーナル | 失敗時に戻せるか |
| 証跡 | 実行SQL、時刻、結果件数 | あとで説明できるか |
UPDATE文はSELECTで先に確認する
SQLで更新する場合は、UPDATEを実行する前に同じWHERE条件でSELECTし、対象件数と内容を確認します。件数が想定と違う場合は、その時点で止めます。本番では「たぶんこの条件」で進めないことが大事です。
修正後の確認も手順に入れる
データ修正は実行して終わりではありません。修正後の画面確認、帳票確認、後続バッチ、外部連携、問い合わせ元への報告まで含めて完了です。修正内容によっては、ジャーナルや監査ログも確認します。
SQL調査の注意点は AS400 Query・SQLでデータ確認する時の注意点、更新事故と戻し判断は AS400ジャーナル・コミットメント制御の確認手順、本番反映全体は AS400本番反映・戻し手順チェックリスト を参照してください。
Codexには実データを渡さない
Codexに相談する場合は、実データ、顧客名、個人情報、取引先名を入れず、匿名化した条件と確認観点だけを渡します。AIは承認チェックリストや作業記録の整形には使えますが、本番更新の判断者ではありません。
関連: AS400のセキュリティ・運用改善・外部依頼を整理する場合は、AS400権限・監査チェックリスト｜ユーザープロファイル・オブジェクト権限・退職者IDを確認する も確認してください。
関連: AS400のRPGソースをAIに読ませる時の注意点｜本番データ・機密情報を守る考え方もあわせて確認してください。
関連: AS400本番作業チェック｜CLRPFM前に見る環境・バックアップ・戻し手順もあわせて確認してください。
関連: AS400販売管理システム保守ガイド｜受注・出荷・在庫・売上・請求で見るポイントもあわせて確認してください。
実行前の声出し
- 本番環境であることを確認したか
- 対象件数は想定通りか
- 更新前データを保存したか
- 戻しSQLを用意したか
- 締め、EDI、請求、在庫への影響を確認したか
若手や外部担当者の本番事故防止は、AS400保守会社に相談する前のチェックリスト｜障害・小改修・データ抽出・リプレースで整理することも確認してください。
本番SQL更新を3段階で管理する
本番SQL更新は、SQL文をレビューするだけでは不十分です。事前確認、実行、実行後確認を別の段階として扱い、それぞれに実行者と確認者を置きます。
| 段階 | 確認すること | 止める条件 |
|---|---|---|
| 1. 事前確認 | 同じWHERE条件のSELECT結果、対象キー、件数、環境、ライブラリ、バックアップ | 0件、想定外件数、対象不明、戻し材料なし |
| 2. 実行 | 実行者、承認者、開始時刻、更新範囲、コミット方針、オンライン処理やバッチとの競合 | 別処理が対象データを更新中、ロックや影響範囲が不明 |
| 3. 実行後確認 | 更新件数、代表キー、ジョブログ、後続バッチ、帳票、EDIや会計連携 | 件数不一致、後続エラー、戻し判断が必要 |
SELECTで件数が合っていても、更新中に別処理が動けば結果は変わります。締め処理、受注・出荷更新、在庫引当、EDI連携が動く時間帯を避け、実行可能な時間帯を業務担当者と決めます。
承認記録に残す項目
- 変更理由と申請番号
- 本番環境、対象ライブラリ、ファイル、キー項目
- 事前SELECTの件数と確認者
- 更新前データの保存場所と戻し方法
- 実行予定時刻、実行者、承認者、立会者
- 更新後に確認する件数、画面、帳票、後続処理
- 中止条件と、異常時の連絡先
生成AIへ確認を依頼する場合も、本番の接続情報、パスワード、顧客名、個人情報、実データは渡しません。匿名化した項目名、想定件数、処理の前後関係だけでレビューできる形にします。
本番データ修正とあわせて確認したい手順
本番データ修正は、SQLやDFUの技術だけで決めてはいけません。修正前後の証跡、承認、戻し方、後続処理への影響まで確認してから実行します。
ジャーナルがある場合はDSPJRN確認も候補に入れる
本番データ修正では、作業前に更新前データを残すのが基本です。あわせて対象ファイルがジャーナル管理されている場合は、DSPJRNで更新履歴を確認できるかも見ておくと、障害後の説明がしやすくなります。
レコード更新履歴を調べる場合は、対象ファイルのデータ・ジャーナルと保存済みレシーバーを確認します。QAUDJRNは監査用であり、業務レコードの更新前後データを代わりに保存するものではありません。データ・ジャーナルとコミットメント制御の確認手順で、必要な記録と復旧条件を照合してください。
本番データ修正前に、更新前データを必ず残す
本番データ修正で一番怖いのは、修正後に「どの値を、どの条件で、何件変えたのか」を説明できなくなることです。UPDATE、DFU、RPG/CLのどれで直す場合でも、作業前に更新前データを退避し、件数とキー項目を確認してから実行します。
対象ファイルがジャーナル管理されている場合は、DSPJRNで更新前後の履歴を追えるかも確認します。ジャーナルがあるから安全、ではなく、更新前イメージが残る設定か、レシーバーが保管されているか、対象期間を追えるかまで見ておく必要があります。
- 修正対象のSELECT条件と件数を作業前に保存する
- 更新前レコードを承認された形式で退避する。CSVは型・NULL・桁・文字コードが保たれ、復元できるかを事前検証する
- DSPJRNで更新前後を追えるか確認する
- COMMIT/ROLLBACKを使う場合は、COMMIT前の検証手順を決める
- COMMIT後に戻す場合の補正更新、バックアップ復旧、リラン判断を事前に決める
技術的に直せることと、業務として直してよいことは別です。特に請求締め、在庫、EDI、出荷確定に関わる修正では、修正前データと承認記録を残すことで、後から説明できる状態を作っておくことが大切です。
修正を実行しない判断
本番データ修正は、SQLやDFUで直せるかどうかだけで判断しません。次の状態では、作業を止めて依頼内容、承認、戻し方を確認します。
| 止める状態 | 確認すること | 再開条件 |
|---|---|---|
| 承認がない | 依頼者、業務責任者、保守責任者 | 誰が修正を承認したか残る |
| 対象件数が合わない | SELECT条件、キー項目、除外条件 | 修正前件数と更新予定件数が一致する |
| 更新前データがない | 退避ファイル、CSV、DSPJRN、バックアップ | 戻しに使える証跡がある |
| 後続処理が不明 | 締め、在庫、EDI、外部連携、帳票 | 修正後に確認する処理が決まっている |
障害起点がMSGWなら、戻す前にジョブログを残す
本番反映やデータ修正の記事を読んでいる時点では、すでに「どう戻すか」に意識が向きがちです。ただし、障害の入口がMSGW（メッセージ応答待ち）や夜間バッチ停止だった場合は、戻し作業の前にジョブログ、QSYSOPRのメッセージ、返答内容、後続処理の有無を残しておきます。原因が曖昧なまま戻すと、リラン時に同じ場所で止まることがあります。
- MSGWの2次テキストと返答候補を確認する
- DSPJOBLOGで最初の原因メッセージと最後の停止メッセージを分ける
- 返答後に後続処理が流れたかを確認する
- 更新済みデータがある場合は、DSPJRNや更新前データを確認する
- リラン、補正更新、戻し作業のどれが安全かを決める
入口の確認はMSGWの確認手順、返答判断はMSGW返答判断表、ジョブログの読み順はDSPJOBLOGで原因を追う順番を参照してください。
本番データ修正を相談する前に残す情報
AS400 / IBM iの本番データ修正は、UPDATE文を急いで実行するよりも、修正前の状態、承認、戻し方、業務影響を先にそろえることが重要です。外部へ相談する場合も、対象データと判断材料が整理されているほど、調査のやり直しや不要な停止を減らせます。
| 残す情報 | 確認する理由 |
|---|---|
| 更新前データ | SELECT結果、件数、キー項目、更新対象の抽出条件を残し、戻し判断ができる状態にします。 |
| 承認者と依頼元 | 誰の判断で、どの業務目的で修正するのかを明確にし、口頭依頼だけで進めないようにします。 |
| 戻し手順 | 更新後に問題が出た場合、どの値へ戻すか、再実行やリランが必要かを先に決めます。 |
| 影響範囲 | 帳票、連携、締め処理、夜間ジョブ、関連ファイルへの影響を確認してから作業します。 |
抽出条件の整理はAS400データ抽出ガイド、影響範囲の確認はRPG/CL影響調査チェックリストも合わせて確認してください。緊急対応が絡む場合はAS400保守の初動対応フロー、外部へ依頼する場合はAS400保守会社の選び方で相談材料を整えます。
本番データ修正の承認、更新前データ、戻し手順、影響範囲を整理したうえで第三者確認が必要な場合は、お問い合わせから状況を共有できます。実データや個人情報は送らず、マスキングした条件と事象概要から相談してください。
DFUを覚えるより、SQLに寄せたほうがいい
本番データを直す手段として、AS400にはDFU（STRDFU、UPDDTA）があります。運営者の考えは、DFUでデータ更新をせず、SQLで更新したほうがよいというものです。
理由は安全性の話ではなく、覚えることは少ないほうがいいという一点です。DFUはIBM i特有のツールで、覚えてもそこでしか使えません。SQLなら汎用性があります。
SQLの汎用性が効く範囲
SQLを覚えると、IBM iの中だけでも使い回しが効きます。
- ACSのSQLスクリプト実行
- Queryの代わりとしての抽出
- RPGの組み込みSQL
- ODBC / JDBC経由で外部ツールから接続する時
さらにIBM iを離れても、基本的な構文は他のデータベースで通用します。若手が学習に使える時間は限られています。その時間をIBM i専用のツール操作に使うか、どこへ行っても残る知識に使うかという配分の問題です。
| 観点 | DFU | SQL |
|---|---|---|
| 使える場所 | IBM iの画面操作のみ | ACS、Query代替、組み込みSQL、ODBC/JDBC、他DBでも通用 |
| 覚え直しの必要 | IBM iを離れると残らない | 基本構文は持ち出せる |
| 対象件数の事前確認 | 画面で1件ずつ見る | 同じ条件を SELECT に置き換えて件数を先に数えられる |
| 実行内容の記録 | 操作の記録は残りにくい | 実行した文がそのまま証跡になる |
ただしSQLのほうが事故は大きくなる
SQLに寄せることを、そのまま「SQLのほうが安全」と読み替えないでください。DFUは画面で1件ずつ触る分、間違えても被害が1件で止まることがあります。SQLは条件を間違えれば一度に全件を書き換えられます。WHERE を付け忘れた UPDATE の被害は、DFUの操作ミスとは桁が違います。
だからこそ、この記事の前半にある手順が要ります。更新する条件をそのまま SELECT に置き換えて件数を確認し、想定した件数と一致してから UPDATE に進みます。汎用性を取るということは、威力の大きい道具を持つということでもあります。
DFUそのものの仕様はUpdate Data with Temp Program (UPDDTA) – IBM Documentationで確認できます。使わない判断をするにしても、現場に残っている以上、何をする道具かは知っておく必要があります。
参考：IBM公式ドキュメント（DSPJRN）
本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。
