おう、お前ら！今日もメインフレームのリングでデータとバチバチに殴り合ってるか？「IT格闘じいじ」だ！
27年メインフレーム（z/OS）の現場に立ってきた俺が、常々「もったいねぇな！」と思っている若手の動きがある。それが、数百万、数千万件もの膨大なデータが入った入力ファイルをそのままプログラム（COBOLやPL/I）に全部読み込ませて、プログラムの中のIF文で「あーでもない、こーでもない」とデータを間引いている姿だ。
そんな生ぬるいガードじゃ、CPU時間とI/O（入出力）の猛連打を食らって、システムが秒速でスタミナ切れ（リソース枯渇）を起こすぜ！甘い、ガードがガラ空きだ！
職人の戦い方は違う。ソート・プログラム（DFSORTやSyncsort）の「INCLUDE（インクルード）」と「OMIT（オミット）」という強力なカウンターパンチを使って、プログラムにデータを渡す前の「ソートフェーズ」で不要なデータを完全にシャットアウト（間引き）するんだ。
今回は、この爆速フィルタリングの技を伝授してやる。耳をかっぽじってよく聞きやがれ！
INCLUDEとOMIT：リングに上げるデータを選別する鉄拳
大量のデータが詰まったファイルを処理するとき、一番大切なのは「無駄なデータに1ミリも触れないこと」だ。ソートエンジンの段階でデータを絞り込めば、後続のプログラムの処理時間は劇的に短縮される。
ここで使うのが、INCLUDEカードとOMITカードだ。この2つは表裏一体のコンビネーション技だな。
- INCLUDE（データ取り込み）：「指定した条件に一致するデータだけをリングに上げる（抽出する）」という技だ。例えば、特定の店舗コードや当月分のデータだけを狙い撃ちで集めるときに使うぜ。
- OMIT（データ除外）：「指定した条件に一致するデータをリングから叩き出す（除外する）」という技だ。解約済みのフラグが立っているレコードや、エラーデータを一瞬でゴミ箱に叩き込むときに大活躍する。
わざわざCOBOLで長大なコードを書かなくても、JCLの制御カードにたった1行書だけで、OS直結の爆速ソートエンジンが数百万件のデータをノータイムで間引いてくれるんだから、使わない手はねぇよな！
実戦でそのまま使える！100%正常動作のJCL＆SYSINサンプル
口で言うだけなら誰でもできる。ここに現場のリングでそのまま100%正常動作する、動作検証済みのJCLとSYSIN（制御カード）のサンプルをぶち込んでおくぜ！
今回のコンビネーションは、「80バイトの固定長レコードから、10バイト目にある拠点コードが『TOKYO』であり、かつ30バイト目にある売上フラグが『0（無効）』以外のレコードだけをソートして抽出する」という実戦的なフォーマットだ！
//FILTERJB JOB (ACCOUNT),'SORT INCLUDE OMIT',CLASS=A,MSGCLASS=X
//* ===================================================================
//* IT格闘じいじ直伝：INCLUDE/OMITによる爆速フィルタリングJCL
//* ===================================================================
//SORTSTEP EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=YOUR.PROJECT.MASTER.DATA,DISP=SHR
//SORTOUT DD DSN=YOUR.PROJECT.FILTERED.DATA,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(10,10),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSIN DD *
INCLUDE COND=((10,5,CH,EQ,C'TOKYO'),AND,(30,1,CH,NE,C'0'))
SORT FIELDS=(1,9,CH,A)
/*【プロの解説：条件カードの軌道を見極めろ】
SYSINに書かれたこの2行のコンビネーションが、どうやってデータを仕留めているかステップ付きで具体例を解説するぜ。
① INCLUDE COND=((10,5,CH,EQ,C’TOKYO’),AND,(30,1,CH,NE,C’0′))
ここで強力な2連撃（複数条件）を叩き込んでいる！
- 10,5,CH,EQ,C’TOKYO’：入力データの10バイト目から5バイト分が、文字（CH）として「TOKYO」と等しい（EQ）かを見ている。
- AND：かつ（両方の条件を満たす必要があるぜ）。
- 30,1,CH,NE,C’0’：30バイト目の1バイトが、文字（CH）として「0」と等しくない（NE：Not Equal）かを見ている。
この網に引っかかったクリーンなデータだけが、次のソート処理のリングに上がる権利を得るんだ。条件を逆にしたい場合は、頭を OMIT COND=… に変えれば、その条件に一致するゴミデータを一瞬で場外乱闘へ叩き出せるぜ！
② SORT FIELDS=(1,9,CH,A)
INCLUDEによって完璧に絞り込まれた、無駄のないデータに対してのみソートを実行する。1バイト目から9バイト目のキー情報を基準に、文字（CH）の昇順（A）で並び替える。
最初からデータ量が激減しているから、ソート処理自体もノーダメージかつ爆速で終わるフォーメーションだ！
若手がハマる現場の罠！比較演算子の指定ミスと「S0C7」の恐怖
おい、ここからがセコンドとして一番伝えておきたい「現場の罠」だ。油断してると強烈なアベンドカウンターを食らってマットに沈むことになるぜ。
罠その①：比較演算子の型指定ミスによる「すり抜け」
INCLUDEやOMITの条件を書くとき、データの属性（型）を勘違いして指定する若手がめちゃくちゃ多い。
例えば、パック十進数（PACKED DECIMAL）が入っている領域に対して、間違えて文字型（CH）として比較条件 EQ,C’100′ なんて書いてしまうミスだ。
これをやると、ソートエンジンは内部のバイナリデータを全く違う文字として解釈しちまう。結果、抽出されるべきデータがすべて「すり抜けて除外」されるか、あるいは全く関係のないゴミデータがリングに上がってしまい、後続の処理が全滅するんだ。
罠その②：数値データの位置ズレによる「S0C7アベンド」
さらに凶悪なのが、数値型の領域を正しく指定したつもりでも、その領域にスペース（空白）や想定外の文字が混入していた場合だ。
数値比較（PD：パック十進数や、ZD：ゾーン十進数）の条件を通るとき、システムが「おい、ここ数値の形になってねぇぞ！」と検知した瞬間、恐怖の**「S0C7（データ例外アベンド）」**が炸裂する。夜間本番バッチのリングでこれを食らうと、深夜3時に叩き起こされるハメになるぜ！
🔥 致命的な罠その③：VB属性（可変長ファイル）における「+4バイトの死角」
固定長（FB）のファイルから、可変長（VB）のファイルに対戦相手が変わったとき、ノーガードの若手は100%ノックアウトされる。
可変長ファイル（RECFM=VB）には、レコードの先頭にシステムが自動で付与する**「RDW（レコード記述語）」という4バイトの隠された領域**が存在するんだ。
設計書に「10バイト目から拠点コード」と書いてあるからといって、固定長と同じ感覚で INCLUDE COND=(10,5,CH,…) と指定した瞬間、終わりだ！
データがどのようにズレるか、以下の「固定長」と「可変長」のデータイメージの対比を見れば一発で理解できるぜ！
📊 固定長（FB）vs 可変長（VB）データイメージ対比表
| レコード形式 | バイト位置の構造（データイメージ） | 正しいINCLUDE命令（開始位置） |
|---|---|---|
| 固定長（FB） | [1〜9: キー][10〜14: TOKYO][15〜80: データ…] | INCLUDE COND=(10,5,CH,EQ,C’TOKYO’) |
| 可変長（VB） | [1〜4: RDW][5〜13: キー][14〜18: TOKYO][19〜: データ…] | INCLUDE COND=(14,5,CH,EQ,C’TOKYO’) |
どうだ？可変長（VB）は先頭に RDW（4バイト） が強制介入してくるから、データの中身全体が後ろに4バイト分押し出されてるだろ！
それなのに固定長と同じ感覚で 10 バイト目を指定しちまったら、実際にはキー情報の後ろの4バイト（5〜13の中の10〜13バイト目）と、TOKYOの先頭1バイトをガッチャンコして判定することになっちまう。これじゃあデータ位置はグチャグチャ、数値が含まれていれば一発でS0C7アベンド行き確定だ！
【プロの防衛策（ガードの固め方）】
この罠を完全に無効化し、クリーンヒットを奪うための防衛策はこれだ！
データ定義（レイアウト）の属性（CH/PD/ZD）をトリプルチェックしろ：
ソート対象の領域が「文字」なのか「パック十進数」なのか「ゾーン十進数」なのか、コピペ元の設計書やCOBOLの登録集（COPY句）を穴があくほど見ろ。目分量で「多分数字だからZDだろ」なんて打つ奴は、職人のリングじゃ一瞬でKOされるぜ。
VB属性のときは、頭の中で必ず「+4」のステップを刻め：
処理するファイルが可変長（VB）だと分かった瞬間、ソートカードの開始位置指定は「設計書の位置 + 4バイト」に脳内デバッグしろ！設計書の10バイト目なら、ソートカードに書べきは 14 だ。この4バイトのガードを固めるだけで、位置ズレのパンチはすべて不発に終わるぜ！
安全のために文字比較（CH）でワンクッション挟む：
もし数値領域にゴミ（スペースなど）が混ざる可能性がある汚れたファイルを扱うなら、いきなりPDやZDで比較しちゃいけねぇ。まず INCLUDE や OMIT の前段で、その領域がスペース C’ ‘ でないことを文字比較（CH）で担保するか、16進数表記（X’40’など）を使ってゴミデータを確実に弾くガードを固めてから、本命の数値比較を繰り出すんだ！
まとめ：戦う前に勝負を決める、それが職人のデータフィルタリングだ
ソート処理の前にデータを極限まで絞り込むINCLUDEとOMITは、メインフレームという過酷なリングを生き抜くために必須の「高速化コンビネーション」だ。
プログラム側で重たいIF文を連打する前に、ソートエンジンの段階で不要なデータを1件残らず叩き出す。この「戦戦（前処理）」の段階での緻密なガードとカウンターの組み立てこそが、数千万件のバッチ処理を「秒」で終わらせる職人の流儀なんだぜ。
特に、可変長（VB）ファイルを扱うときの「RDW（4バイト）」の死角は、一度叩き込まないと何度も同じパンチを食らう鬼門だ。もし現場で位置ズレやS0C7アベンドに頭を抱えて消耗している若手がいたら、お前がこの対比イメージとJCLをコピペして手渡してやりな。
「甘いぜ、ガードがガラ空きだ」と、職人の圧倒的なスピードと精密なデータコントロールを見せつけてやろうじゃねえか。
リソースを制する者が、バッチ処理を制す。しっかりガードを固めて、次のシステムもバチバチに勝ちにいこうぜ！オっしゃあ！！！
関連記事:
コメント