🧩今日の学び
・SEARCH ALLが見るのは定義ではなく「実行時に入っているデータの並び」である
・ASCENDING KEYは保証ではなく前提条件であり、責任は設計者が負う
・並びを作れないならSEARCH ALLを使わないという判断も立派な設計
なるお）ITEM-IDの並びが重要だってことは、定義の順番ってことっすか？
例えば、
MOVE "001" TO ITEM-ID(1)
MOVE "001" TO ITEM-ID(2)
MOVE "001" TO ITEM-ID(3)って005まで定義していくって感じです？
係長）そこ、勘違いしやすいポイントだな。
SEARCH ALLが見るのは「定義」じゃない、「実行時の中身」
係）重要なのは「定義の順番」じゃない。
「中に入っている値の順番」だ。
例えば仮に、こうやって入れたなら
MOVE "001" TO ITEM-ID(1)
MOVE "002" TO ITEM-ID(2)
MOVE "003" TO ITEM-ID(3)
MOVE "004" TO ITEM-ID(4)
MOVE "005" TO ITEM-ID(5)これは、たまたま並びが保証されただけだ。
つまり、SEARCH ALLが要求しているのはITEM-ID(1)～ITEM-ID(n)が昇順（または降順）に並んでいることなんだ。
これは、
- 定義順でも
- OCCURSの書き方でも
- インデントでもない
「実行時のデータの状態」だ。
並びをどう作る？実務での3つの保証パターン
実務ではどうやって並びを保証するかだが…
① 並んだデータを読む
まずは、最初から並んだデータを読む（王道）ことだ。
READ MASTER-FILE- マスタファイルがキー順
- 読み込んだ結果、テーブルも自然に整列
SEARCH ALL向き
② SORTする
並んでいないデータならSORTしてから使うんだ。
SORT WORK-FILE
ON ASCENDING KEY ITEM-ID- CSVや入力データはぐちゃぐちゃ
SORTで並べ替える- その後
SEARCH ALL
ファイルをSORTして、その結果をテーブルに読み込むのもいいし、最近のCOBOLならテーブルを直接並び替えるSORT表名形式もある。どちらにせよ、『並べる工程』を省くなということだ。
③ MOVEしていく
そして、手でMOVEするというのもありではあるが、実務用というよりは教材用だな。
MOVE "001" TO ITEM-ID(1)
MOVE "002" TO ITEM-ID(2)
MOVE "003" TO ITEM-ID(3) *> これならいいが
MOVE "001" TO ITEM-ID(1)
MOVE "003" TO ITEM-ID(2)
MOVE "002" TO ITEM-ID(3) *> こうしてしまった瞬間アウトきちんと並んでない状態でSEARCH ALLを使うと見つかったり、見つからなかったりする。
しかもエラーは出ないから、たちが悪い。
だからこう考えろ
- 定義：箱の設計図
- OCCURS：箱の個数
- MOVE / READ：箱に何を入れたか
- SEARCH ALL： 「その中身、ちゃんと並んでるよな？」 と信用して動く命令
SEARCH ALLは「並びをチェックしない」命令だ。
だからこそ、並びを保証できるなら使え。できないなら使うな。
な）保証って、自分が作ったデータじゃなかったら、保証も何もないんじゃないですか？
豚肉は消費期限が切れてから7日は行ける！マジだから！保証するから！って言葉は信じちゃだめだってわかりましたけど。
係）どんな肉くってんだよ…
な）思えば、なんの保証だったのかと。
あ、この際だから保険つくりません？ミスしたら係長から保障されるみたいなやつ。
係）お前が間違いまくって、俺が全損じゃねーか！
な）なんでですか！９割ぐらいに抑えますよ！ある程度ちゃんとミスは隠蔽しますから！
係）それで１割しか減らねーのかよ！
ゴホン！
ま、まぁ確かに自分が作ってないデータに、最初から保証なんてものは無い。
とはいえ、保証が無いからと言って、SEARCH ALLを使うなってわけでもない。
「保証を“作る”」んだ。
「保証がない」なら、保証を作れ
まず前提を疑え。外から来たデータは疑ってかかれ。
- CSV
- 他システム
- 他人が作ったマスタ
- 昨日まで動いてたファイル
全部、疑うんだ。
SEARCH ALLを使うなら、その前に必ずソートしろ。
SORT WORK-FILE
ON ASCENDING KEY ITEM-IDここで初めて 「このテーブルは昇順だ」 と言える。これが保証だ。
それでも100%は無いぞ。
な）100%にしてくださいよー！係長の保証なら888%ぐらいはあるでしょー。
係）なんなんだよ888％って。
な）末広がりだと縁起がいいかなって。
係）なんの縁起だよ。
な）だって通常の係長だと、顔が縁起悪いじゃないですかー。八八八八で、末広がりなのに４になって逆に縁起悪くなるみたいな。
係）お前は通常、体型が縁起が悪いだろ！
な）ひど！
係）ひどくない！
って、いいか！たとえ、SORTしたからって、
- 桁がおかしい
- NULL相当
- 文字コード違い
- 数値に見えるゴミ
は残る。
だから現場ではこうなる。
SEARCH ALL前に チェック用SEARCH- 件数が変なら止める
- ログを吐いて終了
止める勇気も保証の一部だ。
だから責任は「命令」じゃなく「設計」にある。
SEARCH ALLは「本当に並んでいるかなんて」言わない。黙って速く動くだけだ。
だからこそ、
- 誰が保証したのか
- どこで保証したのか
- 壊れたらどうするか
これを書いてないコードは、速いだけの地雷だ。
つまりだ、SEARCH ALLが危ないんじゃない。保証が無いまま使うことが危ないというわけだ。
おむすび
係）保証が無いなら、作れ。作れないなら、使うな。
これが、COBOLが何十年も事故らずに生き残ってきた理由だ。
な）ほわー係長が人を信じられず、わんこにだけ心をひらいている理由がわかりました。
係）なんでそうなるんだよ！
な）わんこと終末世界を歩くんすね。
虚しいんすね！やるせないんすね！この世は虚構なんすね！儚い夢なんすよね！そいうことなんすね。わかります。
係）何の何がわかったんだよ…。
な）それはそれとして、俺も係長のかわいいお弁当食べたいですー。俺のも作ってほしいなって。
係）弁当は俺が作ってるんだが？
な）え！？
係長のワンポイント
SEARCH ALLは「並べてくれる」命令じゃない。
並んでいると信じて探すという、宣言型の命令だ。ASCENDING KEYは保証ではなく、前提条件のラベルにすぎない。
その前提を書いたのが誰か──それが責任の所在になる。SEARCH ALL 速さより、覚悟を問う構文だ。
コメント