【COBOL学習｜実務向け】SEARCH ALLの要諦：KEY IS句が必須である本当の理由と実装の鉄則

1. 導入：なぜSEARCH ALLにはKEY ISが必要なのか

COBOLの表引き処理において、全件を順次探索するSEARCH文に対し、二分探索を行うSEARCH ALLは圧倒的な速度を誇ります。しかし、現場で「SEARCH ALLが期待通りに動かない」「コンパイルエラーになる」という相談を受ける際、その原因の多くがOCCURS句におけるKEY IS句の指定漏れや、データ順序の不一致にあります。本稿では、SEARCH ALLを正しく使いこなし、保守性の高いコードを書くためのポイントを解説します。

2. 基礎知識：二分探索の仕組み

SEARCH文が先頭から順に要素を比較する「線形探索」であるのに対し、SEARCH ALLは「二分探索（バイナリサーチ）」を行います。このアルゴリズムは、探索対象のデータが「昇順」または「降順」に整列されていることを前提としています。
COBOLにおいて、この整列ルールをコンパイラに明示し、かつ探索キーとして使用することを宣言するのがKEY IS句の役割です。この宣言がない場合、コンパイラは効率的なバイナリサーチアルゴリズムを生成できません。

3. 実装と解決策

実装における鉄則は以下の二点です。
・データ定義（OCCURS句）での宣言：探索対象のテーブル項目に対し、必ずASCENDING（昇順）またはDESCENDING（降順）のKEY IS句を指定する。
・データの事前整列：プログラム実行時、SEARCH ALLを実行する前に、対象データが定義通りの順序でソートされていることを保証する。

4. サンプルプログラム

以下は、IDをキーとして検索を行う標準的な実装例です。

5. 応用・注意点：現場で陥りやすい罠

現場で最も多いトラブルは「データがソートされていない状態でSEARCH ALLを実行する」ことです。二分探索は、途中のデータが順序通りでない場合、正しい結果を返しません。
・デバッグのヒント：データが動的に更新されるテーブルに対してSEARCH ALLを行う場合は、更新処理の直後に必ずSORTを行うか、挿入時に順序を維持するロジックが必要です。
・パフォーマンスの罠：非常に小さなテーブル（要素数10以下など）であれば、SEARCH ALLによるオーバーヘッドよりも、単純なSEARCHの方が高速な場合があります。テーブルサイズとアクセス頻度に応じて使い分けるのが「プロの勘所」です。

また、KEY IS句で指定した項目は、SEARCH ALLのWHEN句で比較対象にする必要があります。この整合性が取れていないと、コンパイル時に警告が出る、あるいは予期せぬ動作を招くため注意してください。