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

2026.05.24

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

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

AS400のWRKACTJOB画面でMSGW状態のジョブが表示されている例。PGM-TEST001Rがメッセージ待ちになっている
MSGWは、ジョブがメッセージ待ちになっている状態です。問い合わせへの応答待ちの場合は、焦って返信せず、メッセージ詳細、提示された選択肢、ジョブログ、途中更新と後続処理への影響を確認し、承認済み手順に従って判断します。

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

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

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

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

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

本番環境とテスト環境を間違える人は、単純に接続先のシステム名（画面の表示位置は環境で異なります）を見ていないことが多いと思います。AS400の画面は似て見えるので、思い込みで作業すると危険です。

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

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

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

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

接続先のシステム名（画面の表示位置は環境で異なります）を確認する、という対策はよく言われます。ただ、毎回きちんと見るかというと、実際には見落とします。急いでいる時ほど見ません。そこで運営者は、確認を意識でがんばるのではなく、セッション選択の取り違えを減らす工夫をしています。

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

つまり、複数マシンのセッションを同時に開いた状態を作らないということです。開いているウィンドウを同じマシンにそろえると、別マシンのセッションを誤って選ぶ機会を減らせます。ただし、最初に開いた接続先自体の誤りや、同じマシン内の本番・検証ライブラリの取り違えまでは防げません。実行直前の接続先・ライブラリ・ファイル・メンバーの照合は省略しません。

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

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

どちらを選ぶにしても、避けたいのは接続先や対象ライブラリを識別・照合しないまま、本番のデータ更新やコマンド実行に進むことです。手順が正しくても、実行先が違えば結果は事故になります。

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

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

CLRPFMは閲覧用コマンドではありません。対象はファイルだけでなくメンバーまで特定します。MBRを省略したまま目的のメンバーが選ばれると決めつけず、承認済み手順の対象と照合してください。

削除の前提を調べる際は、まずメンバー一覧を表示します。以下は架空名を使った確認例です。

DSPFD FILE(TESTLIB/TESTFILE) TYPE(*MBRLIST)

一覧から対象メンバー名と件数を記録し、バックアップの復元可否、同時利用、削除対象の承認を確認します。確認が揃わない段階ではCLRPFMを実行しません。IBM公式：DSPFD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実行前に残すメモ

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

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

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

CSVへの書き出しは、オブジェクトの属性や権限、関連ファイルまで含む復元用バックアップとは限りません。何をどの手順で戻せるかを検証環境で確認してから、作業可否を決めます。

スポンサーリンク