🧩今日の学び
・SEARCH文は単体で理解できず、「宣言(準備)」と「処理(実行)」を分けて読むことで初めて意味を持つ
・DATA DIVISIONは動かないが、処理の成否を9割決める設計図である
・COBOLは「どこが動かないか」を読めるようになると、一気に迷子にならなくなる
なるお)係長はコメントだけでも話は盛り盛りできる人だと メモメモ
係長)どういう意味だよ。
な)まさかあんなに語るとは思ってなかったんで…
係)お前が聞きたいってうるさいからだろ!
な)だって、コメント一つで1時間も喋るとは思わなかったすよ!
億まで語るは伊達じゃないですね!
係)俺をバカにしてるだけだろ…
……でだ、話を戻すぞ。
な)えーまだあるんすかー?
SEARCHは地雷原:文法より「前提」を間違えると壊れる
係)コメントだけで終わるわけ無いだろ!次はSEARCH だ。
SEARCHはな中ボスに見せかけた地雷原だ。
な)それ中ボスとか言わないっすよ…。メインストーリーに一切関係ないけどやり込み要素としてラスボスより強い中ボスとかじゃないすか。
メインストーリーだと思って、必死に戦ってやられまくるやつじゃないっすか。最終的に強くなりすぎて、ぜんぜんラスボスが弱いじゃないっすか!
係)しらねーよ!
いいか、SEARCHはな、
- 文法はシンプル
- 名前も分かりやすい
- 処理内容も直感的
なのに──使いどころを間違えると静かに壊れる。
な)もっと主張してほしいもんですよね!
「おいこれ壊れるからな?いいな?いいんだな?だったらやってやるよ!ヒャッハー!」ぐらいエラー吐いてほしいですよね。いつまでもすました顔の七三分けじゃだめですよね!
係)お前の七三分け確定のイメージはどこから来てるんだよ…
な)え?ジョージ?
係)だれだよ!
な)バック・トゥー・ザ・フューチャーのお父さんっすよ?
係)う、うーん… (あながち間違いと言いづらい)
し、しかもだ、
SEARCHSEARCH ALL
ここでお前は必ずこう言うだろ。
「ALLの方が強そうだからALLで」
な)そりゃそうですよ。全魔法力を使い切らないと最強中ボス倒せないですし。
係)それ中ボスじゃないだろ、もう…
な)だから強いんですって! もう体力も魔法力も0よ! 通勤までリミット30分よ! ってぐらいですから。
係)お前、徹夜でゲームしてんのかよ…。仕事に影響出るだろ!
な)そりゃ出ますよ!
係)…… (堂々と言いやがった)。
もういい、さっさと行くぞ…
01 ITEM-TABLE.
05 ITEM-REC OCCURS 5 TIMES
INDEXED BY IDX.
10 ITEM-ID PIC X(3).
10 ITEM-NAME PIC X(10).
01 TARGET-ID PIC X(3) VALUE "003".
という前提のコードとデータがあったとして、今日の主役コードがこれだ。
SET IDX TO 1
SEARCH ITEM-REC
AT END
DISPLAY "見つかりません"
WHEN ITEM-ID(IDX) = TARGET-ID
DISPLAY "見つけた: " ITEM-NAME(IDX)
END-SEARCH
な)え…なんすかこれ…?
係)なにが?
な)いや、なんつーか…う!頭痛い!
係)は!?おい!
…ってお前、忘れたんじゃないだろうな?
な)へ!?いや、えーと、そうとも言うし、そうとも言わないんすよ。なんだかの猫の状態ですよ!えっと…そう!チェシャ猫ですよ!!エキゾチックショートヘアーの法則ですよ!
ケーキを食べたいか、食べたくないか、ご自分の気の持ちよう次第ですわって、アントワネットさんが言ってたか言ってないか、これも定かではないっていうのが定説ですよ!
係)エキゾチックショートヘアーは覚えてて、シュレーディンガーは出てこないと?
な)はい…
係)なんで「エキゾチックショートヘアー」だけ語感で覚えてるんだよ… で、忘れたところがあるんだろ?
な)はい…
係)…で、何忘れたんだ?
な)えと、SETとINDEX…です。
今日のコードは3つに分かれている:全部同一プログラム
係)基礎の基礎か…、だったら、そこの復習からいくぞ。
今日のコードが3つに別れている意図がわかってないってことだな。
な)意図っすか…?
係)そうだ。今回は頭の中を整理するために分けているだけだ。
ま、お前が右往左往してたときだからな。
こういうときにきっちり復習しておくのもいいだろう。
今回の3つのコードは ① データ定義(入れ物) ② 検索条件(探したいもの) ③ 処理本体(SEARCH) だ。 全部同一プログラム内で、PROCEDURE DIVISION に書くのは③だけだ。
一つ一つ行くぞ。
処理じゃない部分が9割:WORKING-STORAGEの役割
① データ定義(入れ物)
参考:【COBOL 読み1-5】WORKING-STORAGEのPIC・VALUE・OCCURSで箱づくりで死角なし
01 ITEM-TABLE.
05 ITEM-REC OCCURS 5 TIMES
INDEXED BY IDX.
10 ITEM-ID PIC X(3).
10 ITEM-NAME PIC X(10).
いいか、これは処理じゃない。
- 配列の形
- 1件の構造
IDXという索引INDEXを使う宣言
を決めてるだけだ。 つまりは、設計図を描いてるだけだな。
② 検索条件(探したいもの)
そして2つ目は「探す対象」の定義。
01 TARGET-ID PIC X(3) VALUE "003".
これも処理じゃないぞ。
- 検索キー
- 条件
- 比較対象
を用意してるだけだ。
な)これもまだ動かないんすね。
係)そう、料理の材料を机に並べただけだ。
③ 処理本体(SEARCH)
ここで初めて「処理」が始まる。
SET IDX TO 1
SEARCH ITEM-REC
AT END
DISPLAY "見つかりません"
WHEN ITEM-ID(IDX) = TARGET-ID
DISPLAY "見つけた: " ITEM-NAME(IDX)
END-SEARCH
ここが PROCEDURE DIVISION だな。
IDXを初期化して- テーブルを上から順に見て
- 条件一致を探す
な)やっと動くやつきた。
係)SEARCHはここで初めて意味を持つわけだ。 じゃあ、なぜ分けて説明したのか? 理由は3つある。
なぜ分けて説明したのか:現場コードの読み方訓練
理由①:COBOLは「宣言と処理」が混ざると死ぬ
係)データ定義、条件、処理。 これをごちゃ混ぜに説明すると、初心者は100%迷子になるな。
理由②:SEARCHの誤解ポイントを切り出すため
SEARCHで事故る理由はこれだ。
IDXはどこで決まる?- どこから探し始める?
- 何を比較してる? これ、前提を分けないと見えてこないということだ。
理由③:現場では全部同じファイルに書いてあるから
な)あ。
係)そう。 実際の現場では
DATA DIVISION.
WORKING-STORAGE SECTION.
(①と②が混ざってる)
PROCEDURE DIVISION.
(③)
…で、誰も説明してくれない。だから今回は「頭の中ではこう分けて読め」という練習のためでもある。
まとめると、
- 今回の3つは 全部同一プログラム
- 分けたのは 説明の都合
- COBOLは 「何が準備で」「どこから動くか」 を切り分けて読む言語
ということになる。
な)なるペソ。
おむすび
係)なら、SEARCHいくぞ!
な)いや、あの係長…
係)なんだ?
な)その、INDEX とか SET の「中身」の説明は…? さっきの「①データ定義」のところで、サラッと流しましたよね? 「IDXという索引を使う宣言」 って言っただけで終わらせましたよね?
係)あ…
な)へ?
係)忘れてた…。
な)えー! 係長にもエキゾチックショートヘアーの法則が!?
係)違うわ!
係長のワンポイント
SEARCHは書いた瞬間に動く命令じゃない。IDXがどこから始まり、何を見に行くかが決まって初めて意味を持つ。DATA DIVISIONでの宣言は準備であって、処理じゃない。
前提を読まずにSEARCHを追うと、正しいコードでも必ず迷子になる。
COBOLは「動く行」より「動く前」を読めるかで差がつく。

コメント