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・FTP・監査ログを見る も確認してください。
関連: AS400現場でAIを使う時の禁止事項チェックリスト｜本番データ・顧客情報を入れないもあわせて確認してください。
関連: AS400本番反映Go/No-Goチェックリスト｜リリース直前に止める判断を入れるもあわせて確認してください。
関連: AS400請求金額不一致の調べ方｜請求締め・売上・消費税・再計算で見ることもあわせて確認してください。
関連するAS400確認ルート
本番データ修正は、SQLやDFUの技術だけで決めてはいけません。修正前後の証跡、承認、戻し方、後続処理への影響まで確認してから実行します。
ジャーナルがある場合はDSPJRN確認も候補に入れる
本番データ修正では、作業前に更新前データを残すのが基本です。あわせて対象ファイルがジャーナル管理されている場合は、DSPJRNで更新履歴を確認できるかも見ておくと、障害後の説明がしやすくなります。
特に、いつ、誰が、どのジョブで、どのキーのレコードを更新したのかを確認したい場合は、AS400監査ジャーナル・DSPJRNの確認方法を参照してください。COMMIT/ROLLBACKを使う処理であれば、AS400コミットメント制御の確認ポイントもあわせて確認します。
本番データ修正前に、更新前データを必ず残す
本番データ修正で一番怖いのは、修正後に「どの値を、どの条件で、何件変えたのか」を説明できなくなることです。UPDATE、DFU、RPG/CLのどれで直す場合でも、作業前に更新前データを退避し、件数とキー項目を確認してから実行します。
対象ファイルがジャーナル管理されている場合は、DSPJRNで更新前後の履歴を追えるかも確認します。ジャーナルがあるから安全、ではなく、更新前イメージが残る設定か、レシーバーが保管されているか、対象期間を追えるかまで見ておく必要があります。
- 修正対象のSELECT条件と件数を作業前に保存する
- 更新前レコードを一時ファイルやCSVへ退避する
- 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リリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。