AS400 / IBM i の保守では、どうしても本番データを手修正しなければならない場面があります。ただし、SQL更新やDFU的な手修正は、便利であるほど事故につながります。1件だけの修正でも、承認、対象件数、バックアップ、戻し手順、証跡を残すことが重要です。
本番データ修正前の確認
| 確認 | 見るもの | 判断 |
|---|---|---|
| 修正理由 | 依頼内容、業務影響、原因 | 本当に本番修正が必要か |
| 対象範囲 | ライブラリ、ファイル、キー、件数 | WHERE条件が正しいか |
| 承認 | 利用部門、保守責任者、作業者 | 口頭だけで進めていないか |
| 戻し | 修正前値、バックアップ、ジャーナル | 失敗時に戻せるか |
| 証跡 | 実行SQL、時刻、結果件数 | あとで説明できるか |
UPDATE文はSELECTで先に確認する
SQLで更新する場合は、UPDATEを実行する前に同じWHERE条件でSELECTし、対象キー・件数・内容を確認します。件数が想定と違う場合は、その時点で止めます。件数の一致だけでは実行条件を満たしません。確認後に別処理が対象を変更する可能性、トランザクションとロック、承認、更新前退避、実行後検証を含めて手順を決めます。
修正後の確認も手順に入れる
データ修正は実行して終わりではありません。修正後の画面確認、帳票確認、後続バッチ、外部連携、問い合わせ元への報告まで含めて完了です。修正内容によっては、ジャーナルや監査ログも確認します。
SQL調査の注意点は Query・SQLでデータ確認する時の注意点、更新履歴と戻し判断は ジャーナル・コミットメント制御の確認手順、実行前の環境・承認確認は 本番作業チェック を参照してください。
Codexには実データを渡さない
Codexに相談する場合は、社内規程・契約で利用を許可されたサービスと情報の範囲を先に確認します。匿名化だけで入力可能とは判断せず、実データ、顧客名、個人情報、接続情報を除き、許可された架空の条件と確認観点を使います。AIは承認チェックリストや作業記録の整形には使えますが、本番更新の判断者ではありません。AIへ入力する情報の安全確認も参照してください。
実行前の声出し
- 本番環境であることを確認したか
- 対象件数は想定通りか
- 更新前データを保存したか
- 戻しSQLを用意したか
- 締め、EDI、請求、在庫への影響を確認したか
若手や外部担当者の本番事故防止は、AS400保守会社に相談する前のチェックリスト｜障害・小改修・データ抽出・リプレースで整理することも確認してください。
本番SQL更新を3段階で管理する
本番SQL更新は、SQL文をレビューするだけでは不十分です。事前確認、実行、実行後確認を別の段階として扱い、それぞれに実行者と確認者を置きます。
| 段階 | 確認すること | 止める条件 |
|---|---|---|
| 1. 事前確認 | 同じWHERE条件のSELECT結果、対象キー、件数、環境、ライブラリ、バックアップ | 0件、想定外件数、対象不明、戻し材料なし |
| 2. 実行 | 実行者、承認者、開始時刻、更新範囲、コミット方針、オンライン処理やバッチとの競合 | 別処理が対象データを更新中、ロックや影響範囲が不明 |
| 3. 実行後確認 | 更新件数、代表キー、ジョブログ、後続バッチ、帳票、EDIや会計連携 | 件数不一致、後続エラー、戻し判断が必要 |
SELECTで件数が合っていても、更新中に別処理が動けば結果は変わります。締め処理、受注・出荷更新、在庫引当、EDI連携が動く時間帯を避け、実行可能な時間帯を業務担当者と決めます。
承認記録に残す項目
- 変更理由と申請番号
- 本番環境、対象ライブラリ、ファイル、キー項目
- 事前SELECTの件数と確認者
- 更新前データの保存場所と戻し方法
- 実行予定時刻、実行者、承認者、立会者
- 更新後に確認する件数、画面、帳票、後続処理
- 中止条件と、異常時の連絡先
承認記録やSQLには機密情報が含まれるため、組織が承認した保管場所と閲覧権限で管理します。AIで整形する場合も、前述の利用許可条件を満たす情報だけを使います。
ジャーナルがある場合はDSPJRN確認も候補に入れる
本番データ修正では、作業前に更新前データを残すのが基本です。あわせて対象ファイルがジャーナル管理されている場合は、DSPJRNで更新履歴を確認できるかも見ておくと、障害後の説明がしやすくなります。
レコード更新履歴を調べる場合は、対象ファイルのデータ・ジャーナルと保存済みレシーバーを確認します。QAUDJRNは監査用であり、業務レコードの更新前後データを代わりに保存するものではありません。データ・ジャーナルとコミットメント制御の確認手順で、必要な記録と復旧条件を照合してください。
修正を実行しない判断
本番データ修正は、SQLやDFUで直せるかどうかだけで判断しません。次の状態では、作業を止めて依頼内容、承認、戻し方を確認します。
| 止める状態 | 確認すること | 再開条件 |
|---|---|---|
| 承認がない | 依頼者、業務責任者、保守責任者 | 誰が修正を承認したか残る |
| 対象件数が合わない | SELECT条件、キー項目、除外条件 | 修正前件数と更新予定件数が一致する |
| 更新前データがない | 退避ファイル、CSV、DSPJRN、バックアップ | 戻しに使える証跡がある |
| 後続処理が不明 | 締め、在庫、EDI、外部連携、帳票 | 修正後に確認する処理が決まっている |
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で対象キー・件数・内容を確かめたうえで、並行更新への対処、コミット方針、退避、承認、実行後の照合がそろった場合にだけ更新します。SELECTした時と更新する時の状態が同じとは限らず、件数一致だけを実行許可にはしません。
DFUそのものの仕様はUpdate Data with Temp Program (UPDDTA) – IBM Documentationで確認できます。使わない判断をするにしても、現場に残っている以上、何をする道具かは知っておく必要があります。
参考：IBM公式ドキュメント（DSPJRN）
本記事で扱った DSPJRN の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。
