【実務・中級編】 GU (Get Unique) 呼び出し – 階層型DBMS

【DBアーキテクチャ再考】GU（Get Unique）呼び出しの深淵：SSAパス指定による高速直接アクセスと極限の設計パターン

こんにちは。チーフアーキテクトの私だ。
現代のWeb系エンジニアの多くは、リレーショナルデータベース（RDB）やNoSQLの洗練されたクエリ言語（SQLやJSONベースのAPI）に慣れ親しんでいる。しかし、ミッションクリティカルな基幹系システムの深部――例えばメインフレーム上のIMS（Information Management System）などに代表される階層型DBMSの世界に足を踏み入れた時、そこにあるのは「宣言型」ではなく、完全に「手続き型」のデータナビゲーションの世界だ。

その中でも、特定のセグメントを直接捕捉するための最も基本的かつ強力な武器が GU（Get Unique）呼び出し である。

今回は、コードレビューの現場で若手エンジニアが陥りがちな罠を挙げつつ、SSA（Segment Search Argument：セグメント検索引数）を用いたパス指定のメカニズムと、実務で通用する堅牢な設計パターン、そしてパフォーマンスチューニングの極意をロジカルかつシャープに伝授しよう。

—

1. そもそもGU（Get Unique）とは何か？

RDBの `SELECT … WHERE` 句と混同してはならない。GUは、階層構造を持つツリー（データベース・レコード）の中を、DBMSのポインタチェーンを辿って「一意に特定のセグメントを直撃する」ためのDL/I（Data Language/I）コマンドだ。

論理的には「条件に合致する最初のセグメントの位置に位置づけ（ポジショニング）、ワークエリアに読み込む」動作を指す。
しかし、その裏側でDBMSは何をしているのか？リレーショナル脳のままでは、この挙動を見誤る。

物理的実態：ポインタチェインの迷宮

階層型DBMSにおいて、データは親子関係のポインタ（物理子ポインタ、兄弟ポインタなど）によって物理的に繋がれている。GUを発行すると、IMSは指定されたルートから順にポインタを辿るか、あるいは副次索引（Secondary Index）を経由してターゲットへダイレクトにジャンプする。

ここで重要なのは、「曖昧なSSAを書けば書ほど、DBMSの内部ナビゲーションコストが跳ね上がる」という事実だ。

—

2. SSA（セグメント検索引数）によるパス指定の極意

GUの真骨頂は、修飾されたSSA（Qualified SSA）を用いた「パス指定」にある。
単に「このセグメントが欲しい」ではなく、「どの親の、どの子供であるか」という階層のコンテキスト（文脈）をSSAの連鎖によってDBMSに伝えるのだ。

コードレビューで激突する「悪い例」と「良い例」

例えば、ある銀行システムで「顧客（CUSTOMER）の口座（ACCOUNT）の中の、特定トランザクション（TRX）」をGUで取得したいとする。

❌ 悪い設計：単一セグメントの安易な指定

パスを指定せず、トランザクションキーだけでGUを試みる

01 TRX-SSA.
05 FILLER PIC X(9) VALUE ‘TRXSEG ‘.
05 FILLER PIC X(1) VALUE ‘(‘.
05 FILLER PIC X(2) VALUE ‘TR’.
05 FILLER PIC X(2) VALUE ‘EQ’.
05 TRX-KEY-VAL PIC X(10) VALUE ‘2023100101’.
05 FILLER PIC X(1) VALUE ‘)’.

【アーキテクトの指摘】
ふざけているのか？これでは副次索引が張られていない限り、IMSはデータベースの最初からスキャン（あるいは不適切なルート）を始めるリスクがある。システムのスケールと共にCPU使用率が天井を突き破る原因だ。

⭕ 正しい設計：完全修飾パスSSA（Fully Qualified Path SSA）

— 1. 顧客セグメントのSSA —

01 CUST-SSA.
05 FILLER PIC X(9) VALUE ‘CUSTSEG ‘.
05 FILLER PIC X(1) VALUE ‘(‘.
05 FILLER PIC X(2) VALUE ‘ID’.
05 FILLER PIC X(2) VALUE ‘EQ’.
05 CUST-ID-VAL PIC X(8) VALUE ‘CUST9999’.
05 FILLER PIC X(1) VALUE ‘)’.

— 2. 口座セグメントのSSA —

01 ACCT-SSA.
05 FILLER PIC X(9) VALUE ‘ACCTSEG ‘.
05 FILLER PIC X(1) VALUE ‘(‘.
05 FILLER PIC X(2) VALUE ‘NO’.
05 FILLER PIC X(2) VALUE ‘EQ’.
05 ACCT-NO-VAL PIC X(10) VALUE ‘ACC1234567’.
05 FILLER PIC X(1) VALUE ‘)’.

— 3. トランザクションセグメントのSSA —

— DL/I 呼び出し実行 —

CALL ‘CBLTDLI’ USING
DL-GU
DB-PCB
TRX-IO-AREA
CUST-SSA
ACCT-SSA
TRX-SSA.

このパス指定（CUST-SSA ➔ ACCT-SSA ➔ TRX-SSA）こそが、階層型DBMSのパフォーマンスを極限まで引き出すキイだ。DBMSは迷うことなく、指定された顧客の、指定された口座の下にあるトランザクションへダイレクトに到達する。

—

3. 実務で直面する「ステータスコード」の罠と堅牢なエラーハンドリング

GU呼び出しを発行した際、返却されるPCB（Program Communication Block）のステータスコードをどう扱うかで、そのエンジニアの技量が測れる。

実務において、GUは「データが存在しない」ケースを頻繁に扱う。単なるバグなのか、業務上の想定内（データなし）なのかを綺麗にハンドリングするコードパターンを示そう。

堅牢なエラーハンドリング・デザインパターン（COBOL擬似コード）

EXEC-GU-CALL.
CALL ‘CBLTDLI’ USING DL-GU DB-PCB IO-AREA CUST-SSA ACCT-SSA.

EVALUATE TRUE

正常終了

WHEN PCB-STATUS = ‘ ‘
PERFORM PROCESS-NORMAL

データが見つからない (Not Found)

WHEN PCB-STATUS = ‘GB’
PERFORM HANDLE-NOT-FOUND

致命的な構造エラー、またはロジックバグ

WHEN PCB-STATUS = ‘AJ’ OR PCB-STATUS = ‘AK’
PERFORM LOG-FATAL-PATH-ERROR
MOVE ‘FATAL’ TO PROGRAM-STATUS
PERFORM ABEND-ROUTINE

その他のシステムエラー

WHEN OTHER
PERFORM HANDLE-UNEXPECTED-ERROR
END-EVALUATE.

チーフアーキテクトの教訓:
`’GB’`（Segment not found）を例外としてではなく、「ビジネスロジックの分岐点」として美しく処理しろ。そして、`’AJ’`（不適切なパス指定やセグメント名の誤り）などの構造エラーは、テスト漏れを意味する。これらは本番稼働前に絶対に潰しておかなければならない。

—

4. パフォーマンス上の注意点：GUとGNの使い分け

「ピンポイントでデータを取るなら常にGUだよね？」という短絡的な思考は今すぐ捨ててほしい。

大量のセグメントを順次処理（バッチ処理など）する要件において、ループのたびに完全修飾SSAを指定したGUを連発するエンジニアがいるが、これはアンチパターン（最悪の性能劣化）だ。

GU（Get Unique）のコスト:

毎回ルートセグメントからのパスを辿り直すため、インデックスやポインタのルックアップコストが毎回発生する。

GN（Get Next）の活用:

最初の1件目を GU で正確なパスを指定して取得（位置づけ）し、2件目以降はポインタを進めるだけの GN を使用する。これが階層型DBMSにおけるバッチ処理の黄金律（ゴールデンルール）だ。

[初回のみ] —> GU 呼び出し (パスSSAで正確にポジショニング)
[2件目以降] -> GN 呼び出し (位置づけられたポインタから順次スキャン)

この基本原則を無視してループ内でGUを乱発すると、IOPSが爆発し、メインフレームの資源を無駄に食い潰すことになる。インフラチームから呼び出しを受ける前に、この構造を頭に叩き込んでおいてほしい。

—

結びにかえて

階層型DBMSは古臭い技術ではない。データの物理配置とアクセスのパスをここまで強烈に意識させられるアーキテクチャは、現代の抽象化されたDB群の中ではむしろ稀有な存在だ。

GU呼び出しとSSAパス指定の本質を理解しているか否かで、書くコードの質、ひいてはシステム全体のスケーラビリティが決定的に変わる。
次に君がレビューアーの席に座る時、部下が書いたSSAの連鎖を見て、その裏で動くポインタの挙動が脳内にありありと浮かぶようになっていれば、私のこの講義の意味があったということだ。

さらなる高みを目指せ。設計に妥協するな。