【第42回】レガシーの深淵：SSA（セグメント検索引数）の極意と、現代的視点で魅せるDL/Iアクセス最適化
おい、コードレビューの手を止めてこっちを向いてくれ。
今日レビューしているそのCOBOLのバッチプログラム、IMS DBを叩いているな。そして、何気なく書いたその`GU`（Get Unique）コール……そこにぶら下がっているSSA（Segment Search Argument）、本当にパフォーマンスの限界までチューニングされているか？
「いや、先輩、正しくレコードが取れるんだから動くでしょ」と思ったそこの君。
現代のWeb系エンジニアから見れば、階層型DBMSなんて博物館の展示品かもしれない。しかし、金融、航空、流通の基幹を支えるミッションクリティカルな世界では、今この瞬間も数億件のセグメントがIMS DBの海を漂っており、その生死を握っているのはSSAの書き方ひとつなのだ。
今日は、DL/I（Data Language/I）における最強の剣であり、使い方を誤ればシステムを即死させる毒薬にもなるSSA（セグメント検索引数）の本質について、アーキテクトの視点から徹底的に叩き込む。
—
1. そもそもSSAとは何だったのか？
リレーショナルデータベース（RDBMS）の世界では、SQLの `WHERE` 句に条件を書けば、オプティマイザが勝手に最適なアクセスパスを考えてくれる。
しかし、階層型DBMSであるIMSには「オプティマイザの優しさ」など存在しない。私たちが書くDL/IコールのSSAこそが、DBMSに対して「どの道をたどり、どの枝を刈り、どの葉を掴め」という物理的な航海図そのものなのだ。
SSAは、DL/I呼び出し時に「どのセグメントを対象にするか」を限定するための構造体である。
メモリ上の限られた領域を切り詰めてデータをやり取りするため、構文の1バイトのミスや、論理の迷走は、そのままCPU時間の無駄遣い（最悪の場合はデッドロックや全件スキャン）に直結する。
—
2. 非修飾SSA vs 修飾SSA：その境界線と実務の罠
まずは基本のおさらいだが、実務でどう使い分けるかが肝心だ。
① 非修飾SSA（Unqualified SSA）
条件を指定せず、「特定のセグメントタイプそのもの」を指定する方式。
- 顧客セグメントの先頭、または次のセグメントを順次取得する場合
01 CUST-SSA.
05 CUST-SEG PIC X(8) VALUE ‘CUSTSEG ‘.
05 CUST-DUMMY PIC X(1) VALUE ‘ ‘.
- アーキテクトの視点:
単純なシーケンシャル・スキャン（全件舐め）を引き起こす。親セグメントが確定した状態で、その子セグメントをループで総なめにする以外には使うな。これを間違った文脈で使うと、バッチ処理の実行時間が夜間バッチの枠を超えて「朝が来ても終わらない地獄」を見る。
② 修飾SSA（Qualified SSA）
フィールド値やコマンドコードを用いて、取得するセグメントを厳密に絞り込む方式。実務の9割以上はこれだ。
- 顧客IDが ‘C1234567’ の顧客セグメントをピンポイントで狙う
01 CUST-QUAL-SSA.
05 FILLER PIC X(8) VALUE ‘CUSTSEG ‘.
05 FILLER PIC X(1) VALUE ‘(‘ .
05 CUST-KEY-F PIC X(8) VALUE ‘CUSTID ‘.
05 CUST-OP PIC X(2) VALUE ‘EQ’.
05 CUST-VAL PIC X(8) VALUE ‘C1234567’.
05 FILLER PIC X(1) VALUE ‘)’ .
- アーキテクトの視点:
ここで重要なのは関係演算子（`EQ`, `GE`, `LE`など）だ。
特に `GE（Greater than or Equal）` の扱いに注意しろ。「一致するものがあればそれを、なければそれより大きい最初のもの」を取得するこの演算子は、範囲検索や、存在しないキーを指定したときのフォールバック処理において極めて強力な武器になる。これを使いこなせていないコードは、二流の証拠だ。
—
3. 堅牢な設計パターン：複合SSAとコマンドコードの極意
実務では、単体のSSAではなく、階層パスを一度のコールで指定する「複合SSA（Path Call）」を構築することが求められる。ここで設計の美しさが問われる。
設計アンチパターン：バラバラの単体コール地獄
親を取ってから、ループ内で子を取りに行くコードを書くバカがいる。
[NG例]
1. GUコール (親取得)
2. 内部ループ開始
3. DNPコール (子取得) -> これを何万回も繰り返す
ネットワーク（IMS内部の領域）を何度も往復するラウンドトリップが発生し、I/Oが爆発する。
推奨設計：単一コールによるパス取得（複合SSA）
- 注文セグメント(ORDER)の下にある明細セグメント(DETAIL)を一撃で取得するパス
01 PATH-SSA-AREA.
- 1レベル目：親（顧客）
05 SSA-CUST.
10 FILLER PIC X(9) VALUE ‘CUSTSEG (‘.
10 FILLER PIC X(8) VALUE ‘CUSTID ‘.
10 FILLER PIC X(2) VALUE ‘EQ’.
10 C-VAL PIC X(8) VALUE ‘C1234567’.
10 FILLER PIC X(1) VALUE ‘)’.
- 2レベル目：子（注文） + コマンドコード
05 SSA-ORD.
10 FILLER PIC X(10) VALUE ‘ORDSEG ‘. ”はコマンドコード(Holdの意味)
10 FILLER PIC X(1) VALUE ‘(‘.
10 FILLER PIC X(8) VALUE ‘ORDDATE ‘.
10 FILLER PIC X(2) VALUE ‘GE’.
10 O-VAL PIC X(8) VALUE ‘20231001’.
10 FILLER PIC X(1) VALUE ‘)’.
ここで注目してほしいのが、`ORDSEG ` のアスタリスク（“）だ。これはコマンドコード（Command Code）であり、この場合は後続の更新（REPLやDLET）を見据えてセグメントをホールド（排他制御）している。
実務において、更新を伴う参照には必ずこのコマンドコードの指定漏れがないかをレビューで厳視している。ここを忘れると、いざ更新というタイミングで `A9` ステータス（不整合）を食らい、夜中に運用担当者から叩り起こされることになる。
—
4. パフォーマンス上の注意点：オプティマイザがない世界での闘い
RDBMSならDBAがインデックスを張り直せば解決する問題も、IMS DBではアプリケーション側のSSAの組み方がすべてを左右する。以下の3点を肝に銘じておけ。
1. 非修飾SSAの乱用は「全表スキャン」と同義と心得よ
階層の根元に近いセグメントで非修飾SSAを使うと、データベース全体を這い回るようなスキャンが発生する。特にHDAM（Hashed Direct Access Method）やHIDAMの構造を理解し、どのフィールドがシーケンス・フィールド（ルートキー）として機能しているかを意識してSSAの修飾子を組め。
2. 論理子・論理親の迷宮におけるSSAの依存関係
IMSの真骨頂である「論理関係（Logical Relationship）」を跨ぐSSAを書く際、パスの順序を間違えるとIMSは容赦なく非対称なエラーコードを返す。論理パスを辿るSSAは、あらかじめPSB（Program Specification Block）の定義と完全に一致していなければならない。デバッグ時には必ずDBDとPSBの定義書を机上に広げ、パスの整合性を指さし確認しろ。
3. 不要なフィールド修飾の排除
複合SSAの中で、検索に寄与しないフィールドまで修飾条件に含めていないか？ CPUの比較命令とはいえ、無駄な文字比較はミリ秒単位の積もり積もってバッチ全体の SLA（サービスレベル合意）を破壊する。
—
チーフアーキテクトからの最終メッセージ
「古い技術」と呼ばれるものには、それ長年生き残ってきただけの圧倒的な理由と、極限まで無駄を削ぎ落とした構造美がある。
SSAはその最たるものだ。
次に君がCOBOLの画面、あるいはバッチプログラムでDL/Iコールを書くとき、ただ動くコードをコピペするな。
「今、俺が書いたこのSSAは、IMSの物理バッファプール上でどのような軌跡を描き、どのセグメントに最短で到達しているか」を頭の中でイメージしろ。
その解像度の高さこそが、君を「ただのコーダー」から「真のテクニカルリード」へと引き上げる唯一のパスポートだ。
さて、レビューの続きに戻るぞ。次のコードを見せてみろ。
コメント