【COBOL学習｜実務向け】現場でハマる「ADD GIVING」と「TO」の決定的な違い

1. 導入：なぜこの違いが重要なのか

COBOLの実務において、計算結果を格納する際の命令選択ミスは、致命的なバグの温床となります。特に「ADD … GIVING」と「ADD … TO」は、一見似たような加算処理に見えますが、計算結果を保持する変数の「初期値」をどう扱うかという点で、プログラムの挙動を左右する重要な違いがあります。この作法を理解していないと、意図しない数値の重複加算や、旧値の残存による計算誤りを引き起こすことになります。

2. 基礎知識：GIVINGとTOの仕組み

COBOLの算術演算において、結果を格納する際の論理は以下の通りです。

ADD A TO B
これは「累積加算」です。変数Bに格納されている既存の値にAを加算します。Bの初期値がそのまま計算のベースとなります。

ADD A B GIVING C
これは「代入演算」です。AとBの合計値を算出した後、その結果を強制的にCへ上書きします。この際、Cに元々入っていた値（旧値）は完全に破棄され、計算結果に一切影響を与えません。

3. 実装・解決策

現場では、合計値を計算する場合に「GIVING」を使うのが一般的ですが、累計（累計金額やカウンタなど）を求める場合は「TO」を選択する必要があります。特に、ループ処理の中で「GIVING」を誤用すると、直前の計算結果が常に上書きされてしまい、正しく合計値が積み上がらないという事態が発生します。意図が「代入」なのか「累積」なのかを明確に区別することが、バグを防ぐ唯一の手段です。

4. サンプルプログラム

以下は、GIVINGとTOの挙動の違いを比較検証するためのサンプルコードです。

5. 応用・注意点

現場で陥りやすい罠として、GIVINGを使用する際に、計算の受け取り側（GIVINGの後に続く変数）に「編集項目（PIC $ZZ,ZZ9など）」を指定するケースがあります。

GIVINGを使用する場合、受け取り側の変数は数値型であることが望ましいです。編集項目に直接GIVINGで値を代入すると、コンパイラや環境によっては予期せぬ動作をしたり、性能劣化を招いたりすることがあります。複雑な計算結果を編集項目に出力したい場合は、一度「数値項目」で計算を確定させてから、MOVE文を用いて編集項目へ転記するのが、保守性の高いCOBOLプログラミングの鉄則です。