「IDCAMSがデータセットの掃除屋なら、IEBCOPYはライブラリの守護神だ。JCLを書くなら、IEBCOPYと格闘できないと、現場では半人前扱いだぜ。」
27年間、ITエンジニアとして現場のJCL、そして区分データセット（PDS/PDSE）のバグや容量不足（ABEND）と格闘し続けてきた老兵が、今日は「IEBCOPY」の真髄を叩き込んでやる。
IEBCOPYは、z/OS（メインフレーム）の区分データセットを操作する、最も強力で信頼されているIBMユーティリティだぜ。これさえマスターすれば、プログラムのデプロイ、ライブラリのマージ、バックアップ、そして現場で最も感謝される「PDSの圧縮（コンプレス）」まで、自在に操れるようになる。
この記事では、
- IEBCOPYの役割
- JCLの基本構成
- 全パラメータの表形式解説
- 現場で混乱しやすい注意事項
さあ、このリファレンスを脳内キャッシュにインポートして、今日の現場のStatusを正常稼働に戻そうぜ！
IEBCOPYとは？：ライブラリの Status 正常化を担う守護神
ライブラリが悲鳴を上げている（B37/E37 ABEND）時は、迷わずこの守護神をロードしろ。IEBCOPYが、PDSの内部Statusを最速で正常化（Green）に戻してくれるぜ。
IEBCOPYは、IBMメインフレーム（z/OS）において、区分データセット（PDS: Partitioned Data Set、またはPDSE）を操作するための標準的なユーティリティだぜ。
※職人の鉄則：POとPDSの混乱をデバッグしろ
JCLでPDSを定義する時、DSORG=PO というパラメータを叩き込むぜ。このPOは「Partitioned Organization（区分組織）」の略だ。現場で「PO」と言えば、それは区分データセット（PDS）のことを指していると思ってOKだぜ。ここがごっちゃになってる若手は、リングに上がる前の基本ルールで減点されてるようなもんだぜ。
基本的なJCL構成：IT職人の命令フォーマット
JCLはシステムへの命令書だ。SYSPRINTでログを確認し、SYSINで具体的な動作を叩き込む。この基本形（フォーマット）を脳内にデプロイすれば、どんなユーティリティも怖くないぜ。
IEBCOPYを起動させるための、最もシンプルで100%正常動作する基本JCLだ。SYSIN（命令パケット）へ命令クエリを叩き込むスタイルだぜ。
//IEBCOPY JOB (ACCOUNT),'IEBCOPY JOB',CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//DDIN DD DSN=YOUR.SOURCE.LIBRARY,DISP=SHR
//DDOUT DD DSN=YOUR.TARGET.LIBRARY,DISP=SHR
//SYSIN DD *
COPY INDD=DDIN,OUTDD=DDOUT
/*
//鉄壁のコード解説
- //STEP01 EXEC PGM=IEBCOPY : IBM純正のライブラリ制御ユーティリティ「IEBCOPY」をロードして実行する、すべての始まりとなる命令ステップだぜ。
- //SYSIN DD * と COPY INDD=… : システムに入力ストリーム（制御カード）を流し込む。内部コマンドの COPY によって、DDIN で定義した入力元から、DDOUT の出力先へメンバーを爆速パケット転送しろという具体的なコンビネーション命令だぜ。
全パラメータの詳細説明：職人の命令セット
一つひとつのパラメータには意味がある。コピーか、置換か、名前変更か。状況に応じた「命令セット」を使い分け、データセットを自在にコントロールしろ。
| パラメータ・コマンド | 詳細説明 | 職人の鉄則・意味 |
|---|---|---|
| COPY | 区分データセットのメンバーをコピー・処理する基本命令だ。 | 最重要。後述のSELECTやEXCLUDEと併用可能だぜ。 |
| INDD=ddname | 入力元の区分データセット（PDS/PDSE）のDD名を指定する。 | 必須項目。複数のDD名を指定して一括マージも可能だぜ。 |
| OUTDD=ddname | 出力先の区分データセット（PDS/PDSE）のDD名を指定する。 | 必須項目。INDDと同じDD名なら「圧縮（コンプレス）」になるぜ。 |
| REPLACE=YES (R=Y) | 出力先ライブラリに同名のメンバーがあった場合、上書き（置換）する。 | 本番デプロイ時は、これを指定して古いデータをKOするんだ。 |
| REPLACE=NO (R=N) | 出力先ライブラリに同名のメンバーがあった場合、上書きしない。 | デフォルトはこのStatus。上書きエラーを未然に防ぐぜ。 |
| SELECT MEMBER= | 指定した特定のメンバーだけを選択してコピーする。 | 例：(MEM1, MEM2)。必要なパケットだけ選んで転送しろ！ |
| SELECT MEMBER=((O,N,R)) | メンバー名「O（古）」を「N（新）」に変更（RENAME）して置換コピー。 | 最後のRはReplaceだ。名前を変えつつ、既存なら上書きの特権。 |
| EXCLUDE MEMBER= | 指定したメンバー以外（除外）をすべてコピーする。 | 不要なゴミパケットを弾いてライブラリを移行する時に使うぜ。 |
【現場の罠】オンライン稼働中の排他制御無視とE37容量不足の恐怖
ここで若手が100%ハマる、現場の最凶アベンドの罠について警告しておく。
それが、「PDSライブラリのガベージ（不要領域の断片化）による E37 / B37 ABEND（容量不足）」、そして圧縮処理時に DISP パラメータのガードを崩して引き起こす「データセット完全破壊（システムダウン）」の罠だ。
PDSというのは、メンバーを更新・削除するたびに、古い領域が「使用不可能なゴミ（ガベージ）」として中に残り続けるシビアな構造データセットだ。見た目のファイル容量に余裕があっても、内部のインデックスや空きブロックが枯渇すると、突如として E37 ABEND のストレートを喰らってシステムが急停止する。
これを解決するのが「PDSの圧縮（コンプレス）」だが、ここにド素人の罠がある。
「よし、容量不足だから圧縮コマンドのJCLを流そう！」と、ノーガードで DISP=SHR を指定してバッチを叩く奴がいる。甘いぜ、ガードがガラ空きだ！
もし、そのPDSがCICSやIMS、オンラインシステム、あるいは他のユーザーによって参照（SHR）されている最中にIEBCOPYで圧縮を仕掛けたらどうなるか。処理中のデータストリームが完全に衝突し、最悪の場合、ライブラリ内のすべての全メンバーのディレクトリ領域が汚染されて完全アベンド（データ全損）を叩き出すぜ。
プロの防衛策（カウンターパンチ）
DISP=OLDによる鉄壁の排他制御： PDSを圧縮（コンプレス）する際は、必ず DISP=OLD を指定し、データセットを自分のJOBだけで完全にロック（排他制御）しろ。システムが「他の奴は誰も触らせねえ！」とガードを固めた状態を確認してから、IEBCOPYの鉄拳（圧縮）を叩き込むのがプロの流儀だぜ。
実戦JCLサンプル：現場でコピペして戦う職人の鉄則
理論も大事だが、現場では「動くコード」が正義だぜ。俺が27年使い倒した、E37 ABENDを防ぐ「PDS圧縮」や、安全なデプロイのための「メンバー変更コピー」のJCLパケットを用意した。そのままデプロイして、 Status：Green を勝ち取れ！
実戦例1：名前を変更して本番デプロイ（置換あり）
開発ライブラリ（TEST.SOURCE）から本番ライブラリ（PROD.SOURCE）へ、名前を変えて上書きコピーするぜ。
//DEPLOY JOB (ACCOUNT),'PGM DEPLOY',CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//DDIN DD DSN=TEST.SOURCE,DISP=SHR
//DDOUT DD DSN=PROD.SOURCE,DISP=OLD
//SYSIN DD *
COPY INDD=DDIN,OUTDD=DDOUT,R=Y
SELECT MEMBER=((OLDPGM1,NEWPGM1,R),PGM002)
/*- COPY INDD=DDIN,OUTDD=DDOUT,R=Y : 同名メンバーがあった場合は古いシステムを上書き（R=Y）してノックアウトしろという実行命令カードだ。
- SELECT MEMBER=((OLDPGM1,NEWPGM1,R),PGM002) : 入力元の「OLDPGM1」を、出力先では「NEWPGM1」という名前にリネームしてデプロイし、同時に「PGM002」はそのままの名前で本番環境へパケット転送する職人技だぜ。
実戦例2：PDSの圧縮（コンプレス）（最重要ミッション）
PDSの断片化されたガベージを掃除して、E37 ABENDを最速解決・予防する、27年選手の真骨頂だ。
//COMPRESS JOB (ACCOUNT),'PDS COMPRESS',CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//DDCOMPDD DD DSN=YOUR.LIBRARY.PDS,DISP=OLD
//SYSIN DD *
COPY INDD=DDCOMPDD,OUTDD=DDCOMPDD
/*- //DDCOMPDD DD DSN=…,DISP=OLD : 前述した通り、DISP=OLD でシステムに強力なロックを掛け、他のトランザクションを一切寄せ付けない防御陣形を敷いているぜ。
- COPY INDD=DDCOMPDD,OUTDD=DDCOMPDD : 「入力元（INDD）と出力先（OUTDD）に全く同じDD名を指定する」、これこそがIEBCOPYにおけるPDS圧縮（コンプレス）の黄金コマンドだぜ！これによって内部データが綺麗に再配置され、E37エラーが消滅する。
実戦例3：バックアップ（アンロード）
ライブラリが壊れる前に、PDS全体を1本の順次ファイル（PS）に退避（アンロード）させておく、損切りの美学に基づいた防衛策だ。
//UNLOAD JOB (ACCOUNT),'PDS UNLOAD',CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//DDPDSIN DD DSN=YOUR.PDS.LIBRARY,DISP=SHR
//DDPSBACK DD DSN=YOUR.BACKUP.PS,DISP=(NEW,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(10,5)),DCB=(RECFM=U,BLKSIZE=27998)
//SYSIN DD *
COPY INDD=DDPDSIN,OUTDD=DDPSBACK
/*- DCB=(RECFM=U,BLKSIZE=27998) : 区分データセットをアンロード（PS化）する時は、レコード形式を RECFM=U（不定長）にし、ブロックサイズをトラック容量に最適化（27998など）するのがメインフレームの掟だ。
- COPY INDD=DDPDSIN,OUTDD=DDPSBACK : これにより、PDSの全メンバー構造が、1本のバックアップ用順次データストリームへと安全にパッキングされるぜ。
まとめ：IEBCOPYという守護神を脳内にデプロイしろ
どうだ、IEBCOPYの使い勝手がシビアにわかったか？
こいつを自在に扱えれば、ライブラリ管理や容量限界の局面で慌ててバグ（アベンド）を出すことはねえ。現場でエラーが出ても、焦らずSYSINの命令クエリをデバッグし、DISP=OLD のガードを固めてから圧縮をぶち込め。
27年、この頑丈なJCLが俺の背中を守り、数々のシステム障害から現場を救ってくれた。次は、お前の番だぜ。
投資も、ブログも、メインフレームも、シビアにルールを読み切った職人だけが最後にリングの真ん中で立ってるんだ。さあ、学んだコードを今すぐ現場のシステムにデプロイして、 Status：Green を勝ち取るぞ！オス！！！
関連記事:
コメント