【実務・中級編】 REPL (Replace) 呼び出し – 階層型DBMS

階層型DBMSの心臓部：「REPL」という名の静かなる破壊と再構築

諸君、今日はあえて「階層型DBMS（IMSなど）」の深淵に触れよう。

最近のエンジニアは「JSONドキュメント」だの「NoSQL」だのと騒いでいるが、彼らが追い求めている「構造化されたデータの階層化」という概念を、半世紀以上前に極限まで最適化し、現在もなおミッションクリティカルな現場で稼働し続けているのが階層型DBMSだ。

その中でも、データの更新を司る `REPL`（Replace）命令は、単なる「値の書き換え」などという甘い認識で扱ってはならない。これは、物理的なポインタの迷宮を潜り抜けた先で行われる、極めて繊細な手術なのだ。

—

`REPL` を実行する際、諸君が必ず理解しておくべき大前提がある。それは、「GET系命令によって位置付けられたセグメントに対してのみ、REPLは有効である」ということだ。

階層型DBMSにおいて、データはツリー構造のパスとして物理的に配置されている。`GU`（Get Unique）や `GN`（Get Next）でターゲットを捕捉し、システムがその物理位置を特定した直後でなければ、`REPL` は牙を剥く。

実務において、REPLを「ただの値更新」として書くのは素人のやり方だ。以下のパターンを徹底せよ。

CALL ‘CBLTDLI’ USING GHU-FUNC, PCB-MASK, SEG-IO-AREA, SSALIST.

MOVE ‘NEW-VALUE’ TO FIELD-NAME.

CALL ‘CBLTDLI’ USING REPL-FUNC, PCB-MASK, SEG-IO-AREA.

なぜ `GHU` なのか？
`GU` で読み込んでから `REPL` を叩くまでの間に、他プロセスが同じセグメントを更新したらどうなる？競合だ。`GHU` を使うことで、読み込みから書き込みまでのトランザクションをアトミックに保護する。これが階層型DBMSの基本にして、最大の守りだ。

—

`REPL` の仕様で最も重要な注意点がある。それは、「キーフィールド（シーケンス・フィールド）の更新は許されない」という制約だ。

階層型DBMSにおいてキーフィールドは、ツリー構造を維持するための「インデックス」そのものだ。これを変更するということは、ツリー上の物理位置が移動することを意味する。もしキーを変えたいのであれば、以下の手順を踏まざるを得ない。

1. `GHU` で対象を特定。
2. `DLET`（Delete）で物理削除。
3. `ISRT`（Insert）で新しいキーで再挿入。

この「再配置」は、物理的に全く別の場所へ書き込まれる可能性があることを意味する。パフォーマンスを気にするのであれば、頻繁なキー変更が伴う設計は、階層型DBMSにおいては「設計上の敗北」と心得よ。

—

`REPL` を多用するシステムで最も恐れるべきは、セグメントの可変長化による「断片化（Fragment）」だ。

可変長セグメントに対し、`REPL` で元のサイズより大きなデータを書き込むとどうなるか。DBMSは同一ブロック内に収まらない場合、データを物理的に別の場所へ追い出し、ポインタだけを残す。

教訓： 頻繁に更新されるセグメントには、あらかじめ十分な余裕（スペース）を持たせた物理設計を行うこと。
教訓： `REPL` をループ内で叩くようなバッチ処理は、I/O負荷を激増させる。可能な限りバッファリングを行い、論理的な一塊の処理としてコミットポイントを設計せよ。

—

階層型DBMSは、現代のRDBのように「SQLを投げればよしなにやってくれる」便利な世界ではない。しかし、物理層を意識し、ポインタの挙動を掌握し、排他制御をコードで設計するこの経験は、間違いなく諸君のエンジニアとしての解像度を一段階引き上げる。

`REPL` を叩く時、諸君はただコードを書いているのではない。数百万件のレコードが連なる巨大なツリー構造の、特定の枝を正確に切り取り、接ぎ木しているのだ。

この緊張感を忘れないこと。それが、真のエンジニアへの道だ。

さて、コードレビューに戻ろう。君たちのコードに、`GHU` なき `REPL` が紛れ込んでいないことを祈っているよ。