AS400本番作業チェック|CLRPFM前に見る環境・バックアップ・戻し手順

AS400 / IBM iの本番作業で怖いのは、コマンドを知らないことよりも、環境や対象を取り違えたまま更新・削除を実行することです。

特にCLRPFMやデータ更新では、ライブラリリスト、対象ファイル、バックアップ、戻し手順、作業者の役割を先に確認します。この記事では、初心者が実行キーを押す前に見る順番を、現場向けチェックリストとして整理します。

本番作業前に私が確認する順番

本番対応では、確認項目をたくさん並べるだけでは不十分です。現場では、どの順番で確認するかも大事です。私なら、まず対象環境と作業対象を確認し、次に作業者と役割、バックアップと戻し方、実行後の確認方法を順に固めます。

順番確認するもの現場で見る理由
1環境と対象接続先、本番・検証の別、ライブラリ、ファイル、メンバーを最初に固定します。ここを間違えると、正しいコマンドでも事故になります。
2作業者と承認実行者、確認者、承認者、作業を止める条件を明確にし、確認漏れや二重作業を防ぎます。
3バックアップと戻し方更新前の状態、復元可能性、途中更新や後続処理への影響を確認し、戻す場合の手順を決めます。
4実行後の確認対象件数、ジョブログ、業務結果、後続バッチや外部連携の確認方法を先に決めます。

初心者は、いきなりコマンドやSQLに目が行きがちです。しかし本番作業では、先に「誰が実行するのか」「戻せるのか」「どこに対して実行するのか」を固めます。ここが曖昧なまま作業すると、手順は合っていても結果が危なくなります。

本番環境とテスト環境を間違える人が見落とすところ

本番環境とテスト環境を間違える人は、単純に画面右上のマシン名を見ていないことが多いと思います。AS400の画面は似て見えるので、思い込みで作業すると危険です。

「本番のつもりでテスト機を見ていた」「テストのつもりで本番機を触っていた」という取り違えは、作業者本人が気づきにくいです。だからこそ、コマンド実行前に画面右上のマシン名、ライブラリリスト、対象ライブラリを声に出して確認するくらいでちょうどよいです。

DSPJOB
DSPLIBL
WRKOBJ OBJ(TESTLIB/TEST001R) OBJTYPE(*PGM)

特に CLRPFM のようなデータを消すコマンドでは、最低限ライブラリ名を必ず確認します。ファイル名だけを見て安心してはいけません。同じ名前のファイルが複数ライブラリにあるのがAS400の現場です。

接続先マシンの取り違えを、運営者はこうやって防いでいる

画面右上のマシン名を確認する、という対策はよく言われます。ただ、毎回きちんと見るかというと、実際には見落とします。急いでいる時ほど見ません。そこで運営者は、確認を意識でがんばるのではなく、取り違えようがない状態を先に作るやり方をしています。

  • タスクバーに立ち上げておく5250セッションは、すべて同じマシンのものだけにする
  • そのマシンでの作業が終わったら、いったん全ウィンドウを閉じる
  • 閉じてから、次のマシンのセッションを開く

つまり、複数マシンのセッションを同時に開いた状態を作らないということです。開いているウィンドウが全部同じマシンなら、どれをクリックしても行き先は一つなので、そもそも取り違えが起きません。マシン名を読み間違えたかどうかを気にする必要もなくなります。

別のやり方として、画面の文字色をマシンごとに変えて識別する人もいます。本番は赤、テストは青、といった分け方です。運営者はこの方法は使っていません。黒背景に緑文字が一番見やすいと感じていて、全画面をその設定で統一しているためです。見やすさを取るか、色による識別を取るかは分かれるところで、色を変える運用にするなら全マシン分の配色を決めて固定しておく必要があります。

やり方向いている場合注意点
セッションを1マシンに限定する画面の見やすさを統一したい。表示設定を変えたくないマシンを切り替えるたびに全ウィンドウを閉じる手間がかかる
マシンごとに文字色・背景色を変える複数マシンを同時に開いて作業する必要がある配色を全マシン分決めて固定しないと、かえって混乱する

どちらを選ぶにしても、避けたいのは複数マシンのセッションを開いたまま、本番のデータ更新やコマンド実行に進むことです。手順が正しくても、実行先が違えば結果は事故になります。

本番作業で焦りが生じたときのリスク

本番対応で焦りが生じると、意図しない操作や確認漏れが起きやすくなります。早く復旧させたい場面ほど、一度手を止めて環境、対象、手順を確認することが重要です。

本番対応を始める前に必ず守りたいのが、環境確認です。どのマシンに入っているのか、どのライブラリを見ているのか、どのファイルを触るのか。ここが確認できるまで、更新系作業には進みません。

一番危ないのは、環境を取り違えることです。

テスト環境で作業しているつもりが本番環境だった。本番のつもりで確認していたら、実は検証環境だった。こういう取り違えは、慣れていない人ほど起こしやすいです。

AS400の現場では、ライブラリ名やジョブ環境、サインオン先、ライブラリリストの状態によって、見えているデータや更新先が変わります。画面の見た目が似ていると、本人は正しい環境で作業しているつもりでも、実際には別環境を触っていることがあります。

WRKLIB LIB(TESTLIB)
WRKOBJ OBJ(TESTLIB/*ALL)
DSPLIBL

本番作業の事故は、知識不足より確認の抜けで起きます。抜けを防ぐのは個人の注意力ではなく、順番を決めて全員が同じ手順を踏むことです。その型を作る作業を扱うのがCodex実戦研修(法人向け・半日ハンズオン)です。

上のような確認コマンドは、ただ打てばよいわけではありません。今どのライブラリを見ているのか、これからどのライブラリを更新するのかを確認するために使います。

CLRPFMのようなコマンドは特に慎重に扱う

CLRPFM は物理ファイルメンバーのレコードをクリアするコマンドです。便利な場面もありますが、本番環境で対象を間違えると大きな事故につながります。

CLRPFM FILE(TESTLIB/TESTFILE)

このようなコマンドを使う前には、少なくとも次の確認が必要です。

確認項目見る理由
サインオンしている環境本番・検証・開発を取り違えていないか確認する
ライブラリリスト意図しないライブラリが優先されていないか確認する
対象ライブラリ更新先・削除先が本当に正しいか確認する
対象ファイル同名ファイルや似た名前のファイルを取り違えていないか確認する
バックアップ戻せる状態を作ってから作業しているか確認する

初心者ほど「コマンドを覚えたら作業できる」と考えがちですが、本番対応ではコマンドそのものより、実行前の確認の方が大事です。

データリカバリーで最初に確認すること

データリカバリー作業で最初に見るべきものは、やはり環境です。

ライブラリリストを点検し、SQLでリカバリーする場合も、更新先のライブラリを必ず確認します。SQLは便利ですが、対象指定を誤ると一瞬で本番データを書き換えてしまいます。

DSPLIBL
SELECT * FROM TESTLIB.TESTFILE FETCH FIRST 10 ROWS ONLY

リカバリー時は、次の順番で考えると落ち着いて確認しやすくなります。

  1. どの環境で作業しているか確認する
  2. どのライブラリを更新するか確認する
  3. 更新前のデータを退避する
  4. 更新対象件数を確認する
  5. 作業手順をメンバーとレビューする
  6. 実行後に結果件数と業務影響を確認する

特に本番障害中は「すぐ直してほしい」という空気になります。ですが、急いでいるときほど、更新先の確認を省略してはいけません。

急いでいるときに抜けやすい確認

急いでいると、確認を飛ばす、手順を書かない、確認者に見せない、ログを残さないといった抜けが生じやすくなります。

本番対応では、一度落ち着いて作業手順を作成し、メンバーとレビューする方が結果的に早いことが多いです。障害対応中に手順書を書く時間が惜しいと感じるかもしれませんが、手順がないまま作業して二次災害を起こす方が、はるかに時間を失います。

本番障害時に求められる進行判断

本番障害時は、PMの判断によって現場の疲弊度が大きく変わります。

適切な進行では、まず障害状況を確認します。いきなり完全解決を狙うのではなく、暫定対応で業務影響を抑え、状況を整理してから恒久対応へ進みます。

一方、原因や影響を確認しないまま場当たり的な操作を行うと、後から二次障害につながる可能性があります。目の前の事象だけでなく、後続処理まで確認することが重要です。

場面良い進め方危ない進め方
障害発生直後状況・影響範囲・優先度を整理する原因が曖昧なまま作業を急がせる
暫定対応止血を優先し、後で本格対応するその場しのぎで複雑な修正を入れる
作業指示手順と確認者を決める確認者を決めず担当者だけに任せる
対応後原因と再発防止を整理する原因と再発防止を記録しない

若手に守ってほしい3つのこと

若手や初心者に伝えたいことは、次の3つです。

単体テストを怠らない

単体テストは地味ですが、ここを軽く見ると後工程で必ず苦しくなります。自分が作ったものが本当に想定通りに動くのか、異常系でどうなるのか、データが0件のときにどうなるのか。最低限の確認を自分でやる習慣が大事です。

納品先は上司ではなくエンドユーザーだと考える

上司に言われた通りに作るだけでは足りません。実際に使うのはエンドユーザーです。画面、帳票、バッチ、エラー時の運用まで含めて、使う人が困らないかを考える必要があります。

運用を意識した作りにする

言われたものを言われた通りに作るだけでは、保守しづらいシステムになりがちです。障害時に調査しやすいか、ログは追えるか、再実行できるか、リカバリーしやすいか。AS400の業務システムでは、運用を意識した作りがとても重要です。

大変な現場から得られるものもある

本番稼働前後は本当に大変なことがあります。トラブルが起きれば、待ったなしでデータを直さなければいけない場面もあります。失敗すれば多くの店舗や業務に影響するかもしれない。その責任の重さで精神的に疲れることもあります。

ただ、若い頃にそういう現場を経験すること自体は、悪いことばかりではありません。もちろん無茶な働き方を肯定するつもりはありませんが、厳しい局面を経験すると、次の現場で落ち着いて動けるようになります。経験値として残るものはあります。

大事なのは、ただ耐えることではありません。何が危なかったのか、どの判断が良かったのか、どこで二次災害を防げたのかを振り返り、次につなげることです。

本番対応前のチェックリスト

作業の依頼と承認を紙に残す形にしておくと、誰が何を承認したのかを後から追えます。AS400の変更依頼書テンプレートに、記載する項目をまとめています。

本番対応の前には、最低限このチェックリストを確認しておきたいです。

  • 本番・検証・開発のどの環境で作業しているか確認したか
  • ライブラリリストを確認したか
  • 更新先ライブラリを明示しているか
  • 対象ファイル・対象メンバーを確認したか
  • 更新前データを退避したか
  • 更新対象件数を事前に確認したか
  • 作業手順を文章にしたか
  • メンバーまたは責任者とレビューしたか
  • 実行後の確認方法を決めているか
  • 戻し手順を用意しているか

本番対応に不安を感じる方へ

本番対応に不安を感じるのは自然なことです。業務データを扱う以上、適度な緊張感を持って確認することが大切です。

焦りを感じたときは、いったん手を止めます。

まず状況を整理し、確認できたことから進めます。

本番対応で大事なのは、特別な度胸ではありません。環境を確認すること、手順を作ること、レビューすること、戻せる状態を作ること。この基本を守るだけで、防げる事故はかなりあります。

AS400 / IBM i の現場は、今でも止められない業務を支えています。だからこそ、初心者のうちから「作る力」だけでなく「安全に運用する力」を意識しておくと、現場で信頼されるエンジニアに近づけると思います。

AS400の基礎から順番に学びたい方は、AS400学習ロードマップもあわせて確認してみてください。

本番トラブルでデータリカバリーが必要になったら

本番対応中にデータ修正や戻し作業が必要になった場合は、環境確認だけでなく、影響範囲、リハーサル、ライブラリ名の確認も重要です。具体的な考え方は、AS400データ復旧にまとめています。

AS400のWRKACTJOB画面でMSGW状態のジョブが表示されている例。PGM-TEST001Rがメッセージ待ちになっている
MSGWは、ジョブがメッセージ応答待ちになっている状態です。焦ってDを返すのではなく、ジョブログと後続処理への影響を確認してから、C、I、Rなどの応答を判断します。

本番対応では、実行前データと戻し方を先に決める

本番環境で更新・削除系の作業をするときは、コマンドを実行できることより、戻し方を説明できることが重要です。CLRPFM、UPDATE、DFU、CPYF、リラン、締め処理の再実行では、対象ライブラリ、対象ファイル、件数、承認、バックアップ、ジャーナル、再実行可否を先に確認します。

本番作業の確認順は研修でそろえておく

本番作業は、コマンドを知っているだけでは事故を防ぎきれません。対象ライブラリ、対象ファイル、バックアップ、戻し手順、作業者と確認者の分担を、毎回同じ順番で確認できる状態にしておくことが大切です。

若手や後任者へ引き継ぐ場合は、実際の画面やジョブログを見ながら「どこで止まって確認するか」を一緒に決める方が定着しやすくなります。法人向けの研修として整えたい場合は、AS400 / IBM i 現場向けCodex研修を確認し、対象業務と研修希望内容を研修問い合わせフォームから送ってください。

  • 作業前に対象ライブラリ、対象ファイル、対象メンバーを確認する
  • 更新前データをSELECT、CPYF、CSV、またはDSPJRNで残す
  • 対象件数、承認者、戻し手順、リラン条件を作業前に決める
  • EDI、請求締め、出荷確定、夜間バッチへの影響を確認する
  • 戻せる証拠がない、対象件数が想定と違う、MSGWが残っている場合は止まる

CLRPFM実行前チェック

確認見る理由
ライブラリ名本番、検証、退避ライブラリの取り違えを防ぐ
ファイル名同名ファイルや似た名前のファイルを誤って消さない
メンバー名特定メンバーだけを対象にするのか、全体なのかを確認する
バックアップ直前に戻せる状態かを確認する
業務影響在庫、請求、出荷、EDI、会計連携への影響を見る
承認者作業者だけで判断しない

本番で危ないパターン

  • テスト用のつもりで本番ライブラリを指定している
  • 一時ファイルだと思ったら後続処理で使っている
  • 締め処理後のデータを消してしまう
  • EDI送信済みデータと未送信データの区別がついていない
  • バックアップはあるが、戻す手順を誰も確認していない

AS400の怖さは、コマンド自体が難しいことではなく、業務データとの距離が近いことです。CLRPFMを打つ前には、技術確認と同じくらい業務確認が必要です。

実行前に残すメモ

対象ライブラリ:
対象ファイル:
対象メンバー:
消す理由:
業務影響:
バックアップ取得時刻:
復旧手順:
承認者:
実行者:
実行予定時刻:

障害対応で焦っているときほど、メモを残す価値があります。後から「なぜ消したのか」「どこまで確認したのか」を説明できる状態にしておくと、現場の信頼を守れます。

本番作業全体の考え方は、AS400本番作業チェックとAS400データ復旧も合わせて確認してください。

本番作業で迷った時に次に確認すること

本番対応は「早く直す」より「間違った場所を触らない」を優先します。状況に応じて、次の記事で確認対象を絞ってください。

  • CLRPFM本番実行前チェックで、削除・初期化前の確認を整理する
  • AS400ジャーナル確認手順|DSPJRNで更新前後と戻し判断を見るで、承認・件数・戻し方をそろえる
  • DSPJRN確認で、更新前後の履歴と戻し材料を見る
  • AS400ジャーナル確認手順|DSPJRNで更新前後と戻し判断を見るで、ロールバック判断を確認する
  • AS400データ復旧|本番障害で戻す・リランする前に確認することで、影響範囲とジョブログを整理する

若手や外部エンジニアに任せる場合も、「何を実行してよいか」だけでなく「どこで止まるべきか」を共有します。作業前の確認、第三者レビュー、実行後の証跡、戻し方までそろっていない場合は、無理に本番操作へ進まない方が安全です。