COBOLのテーブル(配列)操作について

Question

金融系のシステムでPGをやっています。
命令文の違い（PERFORM文、SEARCH文）によるCPU効率などを教えていただきたく質問しました。

先日テーブル操作を行うプログラムを製造しました。
テーブル操作を行う際に、私たちのプログラム開発課では基本SEARCH文を使うようにする、
という標準があります。
仕様書にはテーブル操作がPERFORM文でかかれていましたが、SEARCH文でコーディングしました。
しかし、SEに修正で突き返されました。

おおまかな処理概要はこうです。
・取得してきたデータ(課コード)と一致する値をテーブルから検索する
｜・一致した場合（取得してきたデータとテーブル内データが）
｜ 同じテーブル番号の課名を返す
｜・一致しなかった場合
｜ エラーメッセージを出力する

仕様書
IF文
｜・課コードがテーブルに定義されているか調べる
｜ ・存在した場合
｜ 処理を続ける
｜ ・存在しなかった場合
｜ エラーメッセージ出力し、処理を終了する

   PERFORM VARYING I FROM 1 BY 1

｜(テーブル数の数を超えるまで)
｜・IF文
｜｜・課コードとテーブル定義が一致した場合
｜｜ 課名をDATA1に移送する
｜｜ 処理をぬける
｜｜・一致しない場合
｜｜ 処理を続ける

実際のコーディング
・SEARCH 課コードのテーブル
｜・AT END
｜ エラーメッセージ出力
｜・課コードがテーブルに存在したとき
｜ 課名をDATA1に移送する

こんな風に処理内容を書き換えました。

私は経験も浅くSEの経験はありません。
ＰＧには分からない大きな視点をSEが持っているという言い分もわかります。
ただ、これに関しては課コードが追加されるなどの変更があった場合、
保守性の観点からも後者の方が絶対にいいと思います。

しかし一つ懸念あり、SEARCH文のCPU効率はすごい悪そう(勝手な感想)だな、ということです。
実際のところどうなのでしょうか。
またCOBOLにおいてCPU効率などが記された書籍などはあるでしょうか。
ハードウェア的な側面も考えながらコーディングできたらいいなと考えています。

Answer 1

ＰＧには分からない大きな視点をSEが持っているという言い分もわかります。

ただ、これに関しては課コードが追加されるなどの変更があった場合、
保守性の観点からも後者の方が絶対にいいと思います。

コーディングに関してではありませんが、そもそもの設計として課名などを取得する内部テーブルを持つと、保守性が下がります。
半年ごとの組織改定でテーブルを修正してコンパイルしなければいけません。
よくOccursのMax値の修正を忘れて、検索できなかったりテーブルを飛びぬけたりします。

PG→SEというキャリアパスかどうかわかりませんが、そういう設計はまずいと知っておくのは重要だと思います。

Answer 2

SEARCHを利用してというのは、おそらくインデックスも指定しなさいということではないでしょうか？
インデックスを指定するとインデックスレジストリーという特殊なメモリを利用する（メインメモリーとは別の高価なメモリでメインメモリより入出力が高速）
ように指定することになり高速にサーチすることになります。通常PERFORM　VARYINGでサーチすると通常のメモリを利用するのですが、ＳＥがの意図はそこにあると思います。

Answer 3

SEARCH命令を知らないSEというもの困りものですね。
SEにSEARCH命令を教えて仕様を直してもらってから、SEARCHを使いましょう。
配列が検索するキー順に並んでいるならSEARCH VARYING より SEARCH ALLの方が速いです。

Answer 4

基本的な考えとして、プログラム仕様書というドキュメントが存在するときは、プログラム内容と一致していなければ成りません。仕様書と違うプログラムの書き方をしたければ、まず仕様書を修正する必要があります。それをしないというのは間違っています。

PERFORMとSEACHの比較ですが、PERFORMだとテーブルの先頭から順番に比較していくことになるので、平均でテーブルエントリ数の1/2回の比較が発生します。1000エントリーだと平均500回。
SEARCHの場合は、PERFORMと同じになる場合もありますが、テーブルがあらかじめソートされている場合は、書き方によっては二分探索を行うことが可能でその場合は比較回数は平均で、テーブルエントリ数の「2を底とした対数」回です。1000エントリーだと平均約10回。