チーフアーキテクトが直伝する：SSA（セグメント検索引数）の極限最適化と実践アーキテクチャ
こんにちは。全社の基幹系システムを統括するチーフアーキテクトの私だ。
現代のエンジニアの多くは、リレーショナルデータベース（RDBMS）やNoSQLの洗練されたクエリ言語（SQL等）に慣れ親しんでいる。しかし、ミッションクリティカルな金融・物流の深部には、今なおIBMのIMS（Information Management System）に代表される階層型DBMS（Hierarchical DBMS）が深く根を張っている。
コードレビューの場で、若手エンジニアから「なぜこのDL/I（Data Language/I）のSSA（Segment Search Argument）はこういう書き方をしているのですか？」という質問をよく受ける。
結論から言おう。階層型DBMSにおけるパフォーマンスの優劣は、「SSAをどう設計し、どう組み立てるか」の1点で決まる。SQLのようにオプティマイザが賢く実行計画を書き換えてくれる世界ではない。プログラマが直接、物理的なアクセスパスを脳内でトレースし、最短距離で目的のセグメントを射抜くSSAを書かなければならないのだ。
今回は、DL/I呼び出しの核心であるSSAの構造、修飾・非修飾の使い分け、そしてコマンドコードによる拡張について、実務で即座に使えるレベルの知見を叩き込む。
—
1. SSAの物理的・論理的構造を理解する
まず、SSAとは何か。RDBMSの `WHERE` 句と同列に考えてはいけない。
SSAは、階層構造（Hierarchical Structure）を持つツリー内をナビゲートするための「精密誘導ミサイル」である。
SSAの基本構造は以下のように非常にプリミティブだ。
+—————-+——–+———————–+
| セグメント名 | 演算子 | 検索値 |
| (8バイト) | (2B) | (可変長フィールド) |
+—————-+——–+———————–+
- セグメント名（Segment Name）: ターゲットとなるセグメントの定義名（例: `CUSTSEG `）。必ず8バイト（右パディング）。
- 演算子（Relational Operator）: 同値（`=`, `EQ`）、大なり小なり（`>`, `<`, `>=`, `<=`）など。
- 検索値（Search Value）: 比較対象のリテラルまたは変数。
この単純なバイト列の組み合わせが、IMSのアクセスモジュール（DFSDLI0など）に渡され、ポインタチェーンを辿る際の絞り込み条件として直接使われる。
—
2. 非修飾SSA vs 修飾SSA：使い分けの境界線
コードレビューで最も指摘が多いのが、この2つの使い分けのミスだ。
① 非修飾SSA（Unqualified SSA）
条件を指定せず、セグメント名のみを指定する方式である。
- 顧客セグメントの次の兄弟（Twin）を取得する非修飾SSA
01 UNQUAL-SSA.
05 FILLER PIC X(8) VALUE ‘CUSTSEG ‘.
- ユースケース: 特定の親の下にあるセグメントを順次全件スキャン（Sequential Scan）する場合。例えば、一括バッチ処理でルートセグメントから順に下位セグメントを舐めていくとき。
- アーキテクチャ上の注意: 条件を指定しないため、IMSはポインタを順番に辿るしかない。該当セグメントが多い場合、I/Oコストが跳ね上がる。これをトランザクション系（OLTP）のオンラインプログラムで安易に使うと、即座にロック競合とCPU枯渇の温床となる。
② 修飾SSA（Qualified SSA）
フィールド名、演算子、検索値を指定し、特定のセグメントをピンポイントで狙う方式。
- 顧客IDが ‘C1234567’ の顧客セグメントを特定する修飾SSA
01 QUAL-SSA.
05 FILLER PIC X(8) VALUE ‘CUSTSEG ‘.
05 FILLER PIC X(1) VALUE ‘(‘.
05 FILLER PIC X(8) VALUE ‘CUSTID ‘.
05 FILLER PIC X(2) VALUE ‘EQ’.
05 FILLER PIC X(8) VALUE ‘C1234567’.
05 FILLER PIC X(1) VALUE ‘)’.
- ユースケース: オンライン画面からのリクエストなど、特定のキーでレコードを1件（あるいは一意に）特定する場合。
- アーキテクチャ上の注意: インデックス（HIDAMのSITなど）が適切に定義されていれば、ダイレクトに目的のブロックへアクセスできる。設計の基本は「可能な限り修飾SSAを使い、不要なポインタ走査を避ける」ことだ。
—
3. コマンドコード（Command Codes）による検索条件の拡張
実務で真価を発揮するのが、セグメント名の直後に付加するコマンドコードだ。これらを使いこなせるかどうかが、シニアとジュニアの分かれ道となる。
コマンドコードは、セグメント名と括弧（`(`）の間にアスタリスク（“）と共に入り組む形（例: `CUSTSEG D`）で指定する。
実務で必須の主要コマンドコード
1. `D` (Data) – 複数セグメントのワンショット取得
- 挙動: 通常、DL/I呼び出しでは指定した最下位のセグメントしか返されないが、`D` を付与した途端、パス上の親セグメントのデータも一括してアプリケーションの領域に返送される。
- 設計パターン: 階層の浅い親と子を同時に処理したい場合、複数回の `GU` (Get Unique) / `GN` (Get Next) 呼び出し発行はネットワーク・I/Oの無駄。`D`コードで1回の呼び出しにまとめよ。
2. `C` (Concatenated Key) – 連結キーによる直接指定
- 挙動: 物理的な親のキーを省略し、ルートからの完全な連結キーを指定して子セグメントを直撃する。
3. `U` (Hold) – 更新を前提としたホールド
- 挙動: 読み込みと同時に排他制御（ロック）をかけ、後続の `REPL`（更新）や `DLET`（削除）を保証する。
コード例：コマンドコードを活用した高度なDL/Iコール（COBOL）
01 ADV-SSA.
- セグメント名 + コマンドコード(D) + 条件修飾
05 FILLER PIC X(8) VALUE ‘ORDERSEG’.
05 FILLER PIC X(2) VALUE ‘D’.
05 FILLER PIC X(1) VALUE ‘(‘.
05 FILLER PIC X(8) VALUE ‘ORDERNO ‘.
05 FILLER PIC X(2) VALUE ‘EQ’.
05 FILLER PIC X(8) VALUE ‘ORD99887’.
05 FILLER PIC X(1) VALUE ‘)’.
この定義により、`ORDERSEG` を一意に引きつつ、その上位にある親セグメントのデータも同時にワークエリアへ展開させることが可能になる。
—
4. チーフアーキテクトが警鐘を鳴らす「パフォーマンスの罠」
階層型DBMSのプロジェクトでシステム障害や性能劣化が起きる原因の9割は、SSAの設計不良に起因する。以下のアンチパターンを確実に排除してほしい。
🚨 アンチパターン1: 不完全な階層パス指定（ボトムアップの悲劇）
階層構造が `ROOT` -> `BRANCH` -> `LEAF` となっているとき、いきなり `LEAF` セグメントを修飾SSAで取得しようとしていないか？
物理データベースの構造（HIDAM/HDAM）によっては、親をスキップした検索は全セグメントの非効率なスキャンを引き起こすか、あるいはIMSがエラーを返す。
鉄則: パス上の親セグメントから順にSSAを並べた「完全パスSSA」を構築せよ。
🚨 アンチパターン2: ワイルドカードや部分一致の安易な使用
DL/Iの演算子には、RDBMSの `LIKE` のような曖昧検索を簡単に実現する強力な機能は乏しい。無理に範囲検索や複雑な条件をSSAに詰め込もうとすると、IMSのバッファプールを圧迫し、データベース全体のスループットを低下させる。
鉄則: 複雑なフィルタリング条件が必要な場合は、SSA側での絞り込みはキー項目に限定し、取得した後にアプリケーション（COBOL等のロジック層）側でメモリ上でフィルタリングを行え。
—
最後に：レガシーとモダンを繋ぐエンジニアリングの美学
「階層型DBMSなんて古い」と切り捨てるのは簡単だ。しかし、何十年も止まることなく数千万件のトランザクションをさばき続けるIMSの底力は、突き詰められた物理アクセスの最適化にある。
SSAの1バイト、1文字の記述に神経を研ぎ澄まし、最短のパスで目的のデータに到達するコードを書く――。この泥臭くも美しい最適化の技法こそ、真のプロフェッショナルエンジニアリングである。
次回のコードレビューでは、今回伝授したSSAの構造とコマンドコードが適切に適用されているか、厳しくチェックさせてもらう。期待しているぞ。
コメント