PROCSEQの呪縛を解け：物理の鎖を断ち切り、論理の翼を与えるパス再定義の極意
テックリードの私だ。今日のコードレビュー、あるいはアーキテクチャ設計レビューを始める。
お前らが持ち寄った「階層型DBMS（IMS DBなど）の新規スキーマ定義」を見たが……おいおい、相変わらず物理構造（HIDAM/HDAM）に引きずられた硬直した設計をしているな。
「親セグメントの下に子、子孫へはポインタで一路邁進」――そんな教科書通りのツリー構造だけで、複雑怪奇な業務要件のクエリをすべてさばけると思っているのか？
現実のビジネスは非情だ。物理的な親子関係とは全く異なる軸、例えば「顧客ID順ではなく、契約日順かつ地域コード順で走査したい」という要求が平然と飛んでくる。
ここで安易に物理データベースをもう一つ複製したり、冗長なポインタチェーンを張ったりした開発者は、私のレビューで即座にレッドカードを食らうことになると知れ。
今回は、階層型DBMSの隠された牙であり、真の表現力を引き出す「PROCSEQ（Processing Sequence）パラメータ」について徹底的に叩き込む。物理の呪縛を断ち切り、論理の光速パスを手に入れるための設計論理を、骨の髄まで刻み込め。
—
1. なぜPROCSEQが必要なのか？（アーキテクチャの本質）
階層型DBMSの宿命、それは「物理的なポインタ（Hierarchical Pointer）による強固な結合」だ。
データはディスク上で物理的に隣接するか、あるいはポインタの鎖で結ばれている。この構造はツリーの垂直方向の走査においては神速のパフォーマンスを発揮するが、ひとたび「別の切り口」でデータを舐め回そうとした途端に無力と化す。
ここで登場するのが PROCSEQ（処理順序付けパラメータ） だ。
[物理的実態 (Physical Database)]
Root (Customer) —> Segment A —> Segment B
(物理的なポインタ順で格納されている)
▲
│ PROCSEQによる論理的インデックスパス (Secondary Index / L-Index)
│ 「契約日順」に再配列された仮想的なビューを提供
[論理的視座 (Logical View)]
PROCSEQは、DBD（Database Description）のセグメント定義において、「アプリケーションプログラム（AP）から見た論理的なアクセス順序（Processing Sequence）」を、物理的なポインタ構造とは独立して再定義するためのメカニズムだ。
要するに、アプリケーションには「最初からこのソート順・このアクセスパスでデータが存在するかのように」見せかけつつ、裏側では全く異なる物理構造を安全に隠蔽・調停する。これがPROCSEQの正体だ。
—
2. DBD / PSB定義におけるPROCSEQの実装パターン
百聞は一見にしかず。実際のDBD（データベース記述）とPSB（プログラム仕様ブロック）におけるPROCSEQの適用方法を見ていこう。
ここでは、物理的には「顧客番号（CUST#）」順に格納されている顧客セグメントを、PROCSEQを用いて「契約日（CONR-DATE）」順の論理シーケンスとしてアプリケーションに露出させる設計を例にとる。
【ステップ1】DBDでのセグメント定義とL-Indexの結び付け
———————————————————————-
- 物理データベース定義 (DBD) – 抜粋
———————————————————————-
DBD NAME=CUSTDB,ACCESS=HIDAM
- 根っこ（Root）となる顧客セグメント
SEGM NAME=CUSTSEG,PARENT=0,BYTES=100,PTR=TB
FIELD NAME=(CUST#,SEQ,U),BYTES=8,START=1 物理シーケンスキー
FIELD NAME=CONR-DATE,BYTES=8,START=9 二重インデックス対象キー
- セカンダリインデックス用データベースの定義（別DBDとして存在）
- PROCSEQはこのL-INDEXと物理DBを結合する橋渡しとなる
そして、この物理DBを特定のインデックス経由で処理させるためのDBD定義（あるいはプロシージャ）において、PROCSEQを指定する。
———————————————————————-
- PROCSEQ適用時のDBDマッピング定義イメージ
———————————————————————-
LCHILD NAME=(CONRIXD,CUSTDB),POINTER=SNGL
XDFLD NAME=CONR_XF,SRCH=CONR-DATE 探索キーの指定
【ステップ2】PSB（プログラム仕様ブロック）での宣言
アプリケーションがPROCSEQの恩恵を受けるためには、PSB側で「このプログラムはデフォルトの物理順ではなく、あのPROCSEQパスを使ってアクセスする」と明示的に宣言（`PROCOPT` および `PROCSEQ` パラメータ）しなければならない。
———————————————————————-
- プログラム仕様ブロック (PSB) 定義
———————————————————————-
PSBGEN LANG=COBOL,CMPiler=YES
- PROCSEQにセカンダリインデックスのXDFLD名を指定する
PCB TYPE=DB,DBDName=CUSTDB,PROCOPT=G, X
PROCSEQ=CONR_XF
SENSEG NAME=CUSTSEG,PARENT=0
PSBGEN
【チーフアーキテクトの解説】
このPSB定義を見て震え上がれ。
アプリケーションのCOBOLプログラム（`GU`, `GN` などのDL/Iコールを発行するコード）は、物理的な構造がどうなっているか、あるいはインデックスがどう構築されているかを知る必要が一切ない。
ただ通常のシーケンシャル・ゲット（`GN`）を叩くだけで、DBMSが勝手に `CONR-DATE` の昇順でデータを給送してくれる。これが抽象化の極みだ。
—
3. 実務で直面する「罠」と堅牢な設計パターン
しかし、甘い言葉に酔うな。PROCSEQは強力ゆえに、設計を誤るとシステム全体を死に至らしめる毒薬にもなる。現場のテクニカルリードとして、お前らが犯しがちな地雷と、その回避策を授ける。
罠1：更新系トランザクションにおける「インデックスメンテの呪い」
PROCSEQ（セカンダリインデックス）が絡むセグメントに対して `ISRT`（挿入）、`REPL`（置換）、`DLET`（削除）を発行する際、DBMSは実データとインデックスポインタの整合性を同期させるために、裏側で追加のI/Oを爆発的に発生させる。
- 症状: 読み取り専用バッチでは神速だった処理が、オンラインの更新トランザクションに入れた途端にリトライ・デッドロックの嵐となり、CPU使用率が100%に張り付く。
- 設計パターン（対策）:
- 「参照系と更新系のPCB分離」を徹底しろ。
- 更新を行うプログラムのPSBには、極力PROCSEQを指定するな。どうしても必要な場合を除き、更新系は物理シーケンス（HIDAM/HDAMのルートキー）で直撃させろ。
- PROCSEQは基本的に「参照専用バッチ（PROCOPT=G）」の特権武器として扱え。
罠2：非ユニークキー（NON-UNIQUE KEY）による予期せぬ「位置の喪失」
契約日（`CONR-DATE`）のようなキーは、一人の顧客が同じ日に複数契約していれば「重複（Non-unique）」が発生する。
- 症状: `GN`（Get Next）コールを発行した際、ユニーク性が保証されていないパスを辿ると、予期せぬ順序でレコードが返却され、バッチの突合ロジックが破綻する。
- 設計パターン（対策）:
- 非ユニークキーをPROCSEQに指定する場合、必ずシーケンスを保証するためのユニークな従属フィールド（例えば顧客番号や契約ID）をタンデム（複合）キーとしてXDFLDに含めろ。
- 例: `XDFLD NAME=CONR_XF,SRCH=(CONR-DATE,CUST#)`
- これにより、論理順序の完全な決定性（Determinism）が担保される。
—
4. パフォーマンス上の注意点とチューニングの極意
最後に、ハードウェアの限界とDBMSの挙動を熟知した者だけが知る、チューニングの奥義を伝授する。
1. バッファプール（Buffer Pool）の分離
PROCSEQで使用されるインデックスデータベース（L-Index）は、実データとは異なるアクセスパターンを描く。インデックス用のブロックとデータ用のブロックが同一のOSAM/VSAMバッファプールを奪い合うような愚行は避けたまえ。インデックス専用の独立したプールを割り当て、LRUアルゴリズムのヒット率を極限まで高めろ。
2. ポインタのメンテナンス（SNGL vs TWIN）
セカンダリインデックス側のポインタ連鎖において、重複キーが多い場合は `TWIN-FORWARD` などの適切なポインタオプションを選定し、チェーンのたどり過ぎによるCPUコストを抑えよ。
3. 不要なPROCSEQの即時廃止
「もしかしたら将来この順序で検索するかも知れない」というエンジニアの悪癖である「推測による過剰設計（YAGNI原則違反）」は死刑に値する。PROCSEQはそれ自体がメンテナンスコストを生む。本当に日次・月次バッチのSLA短縮に不可欠なパスであるというメトリクス（証拠）がない限り、安易に定義するな。
—
総括
PROCSEQパラメータは、階層型DBMSという古き良き巨獣に、現代的な柔軟性を与えるための鋭利なメスだ。
物理構造の制約に屈し、アプリケーション側で無理なソートロジックを実装したり、冗長なテーブル設計に逃げたりするようでは、お前らはただの「コードのタイピスト」に過ぎない。
データ構造の物理と論理を完全に分離し、ミリ秒単位のI/Oコストを計算し尽くした上で、このPROCSEQを意図通りに配置してこそ、真の階層型DBMSアーキテクトだ。
次の設計レビューでは、今回叩き込んだ知見が反映された美しいDBD/PSB定義を持ってくることを期待する。
解散！
コメント