🧩今日の学び
・SUMは固定値だけでなく、入力を受け取りながらTOTALを更新し続けることで実現できる
・入力 → 計算 → 出力という流れを設計することで、実務に近い処理構造を作れる
・COBOLは計算そのものではなく「状態（TOTAL）をどう管理するか」を設計する言語である
係長）今までは値固定だったが、ユーザー入力でSUM（ACCEPT × ループ）ができないと意味ないだろう？
なるお）いいえ、意味はあります。
係）ねーよな！
な）あ、あい…あります…。
ホント横に暴れるんだから…（ボソボソ）
固定値から「入力型SUM」へ進化する
係）今回は簡易計算機を作っていくぞ。
な）ほ？
係）計算機というか、足し算機だな。
な）ふむぅ。
係）で、どういう流れを考えるかだ。説明してみろ。
な）流れっすか…。
最初に、数字を入力したら、それを足す数字変数（A）に記憶して、次の入力を誘う。数字の入力があれば、足される変数（B)に最初の足す数字変数合計して、計算結果変数（C）に入れる？
最後に=を入力するとSUM結果表示でどうでしょ？
係）70点ってとこだな。
な）え、意外と高くてびっくり。係長やっぱり俺のこと認めてたんすね…
係）ほんと、うるさいわ。
計算機の基本は「入力 → 計算 → 出力」
入力 → 計算 → 出力
この流れはよし。
構造が見えてるのはいいな。
「 = で終了」発想
操作を設計しているという点で、実務レベルの発想と言えるな。
変数で分けようとしてる
考え方としては正しいとは言えるな。
な）いや、そんな、天才だなんて。俺にも恥じらいってもんがあるんで。テレテレ。
係）そして、減点ポイントだ。
な）いやもっと褒めてくれていいんすよ！褒められて伸びるくんなんで！
係）減点ポイントだが！
な）ぶー。
変数多すぎ
COBOLでは事故る可能性が高まる
データの流れが曖昧
どこが最終結果なのかいまいちわかりづらい。これはバグのもとになるからな。
累積の概念が弱い
合計のみの設計だからな。
な）えーと、減点30点の説明のが辛辣なんすけど…
シンプルにする：TOTAL一本で考える
係）つまり、
・シンプルにする
・変数を減らす
・流れを一本にする
ということを考えることが大事だってことだな。
ちなみに、お前が言う流れを具体化してみるとこうだ。
TOTAL = 0 入力 → X IF "=" → 終了 TOTAL = TOTAL + X 繰り返し
な）それほんとに俺のやつっすか…
係）よし、それでは、もっと形にしていくぞ。
俺が具体化した構造を見ながら、変数を考えてみろ。
な）あい。
えーと…
01 X PIC 9(3) VALUE 0. 01 TOTAL PIC 9(3) VALUE 0.
で、いいっすかね。
係）整理されたが…足りないな。
な）え？
係）お前が言ったんだろ。
「=」を判定するには文字入力が必要
な）へ？……んー……あ、「=」っすか？
係）そうだ。それも文字として認識させたいんだったら、文字も入力できる事が必要だな。どうする？
な）えっとPIC系をもう一つ作るっすかね…
係）文字はPIC Xだったな。
な）となると、
01 X PIC 9(3) VALUE 0. 01 TOTAL PIC 9(3) VALUE 0. 01 Y PIC X.
でいいすか？
Yにも初期値入れておいたほうが良いですかに？
係）よく考えてみろ。なぜ初期値が必要だったかだ。
な）えーと、0が入っているとは限らないから、計算をするとずれる可能性があるってことで、初期値を入れるって理解してたので…、あーYは絶対入力がさきになるから、Yが更新されて、ずれるとかの誤作動はないってことっすか！
つか、そもそも計算に使われるわけではないから、初期値とか考えなくてもよいかしらね。
係）なんかムカつくな。
な）ええ！？なんかしました！？
係）100点の回答するんじゃねーよ！
な）極悪非道の理不尽！？
おむすび
係）ま、ここまではいいな。次は計算ロジックと終了判定だな。
な）大変そう…
係）そりゃ大変だろ。
な）この世に、こんな大変なことあるんすかー！？
係）お前、そんなんだから会社入るの大変だったんじゃないのか？
な）え？ここ行ってこい言われて、行って喋ったら、合格みたいな流れでしたよ？
係）なんの苦労もないとか…バブルかよ…
な）みんなから好かれる存在ってことっすね！
係）俺はそうでもないが。
な）え！？
係長のワンポイント
計算機は「計算するもの」じゃない。
入力を受け取り、状態（TOTAL）を更新し続ける仕組みだ。
変数を増やすと見えなくなり、事故の原因になる。
だから流れは一本、結果は一つに集約する。
COBOLは計算より、状態をどう持つかを設計する言語だ。
コメント