1. 導入：なぜ「72列」を意識する必要があるのか
メインフレームのレガシーなソースコードを扱う際、私たちは「固定形式（Fixed Format）」という制約と常に隣り合わせです。特にCOBOLなどの言語では、ソースコードの記述は「72列目まで」と決まっています。
マクロ変数やプリプロセッサを使用してコードを動的に生成する際、展開後の文字列がこの「72列」を超えてしまうと、コンパイラはそれを無視（切り捨て）してしまいます。結果として、意図しないコードの寸断が発生し、不可解な構文エラーや予期せぬ論理バグを引き起こします。現代の開発環境では考えにくい「物理的な制約」が、メインフレーム開発では今なお重要な課題なのです。
2. 基礎知識：固定形式とプリプロセッサの仕組み
メインフレームのソースコードは、伝統的に1～6列目がシーケンス番号、7列目が注釈行指定、8～72列目がプログラム記述領域と定められています。
プリプロセッサ機能は、コンパイルの直前にマクロ変数を実際の値に置き換えます。ここで注意すべきは、「プリプロセッサは、置換後の文字列が72列目に収まるかどうかを判断してくれない」という点です。展開された結果が73列目以降にはみ出した場合、コンパイラはそこを「なかったもの」として処理するため、構文が崩壊します。
3. 実装/解決策：安全なマクロ設計
この問題を回避するための鉄則は、「マクロ展開後の最大文字数を常に予測する」ことです。
特に長い変数名や、動的に生成される複雑な数式をマクロに含める場合は、あらかじめ「マクロ名＋展開後の値」が72列以内に収まるかシミュレーションを行う必要があります。レガシーコードで見られる「短い変数名」や「独特な省略形」は、単なる好みではなく、この72列の制約を回避するための先人の知恵であることが多いのです。
4. サンプルプログラム：危険なコードと安全なコード
以下の例は、マクロ展開によって72列目を超えてしまう危険なケースです。
- — 危険なマクロ定義例 —
- このマクロを展開すると、72列目を超えて命令が途切れる可能性がある
DEFINE MACRO-CALC-VAL = “ADD 1234567890123456789012345678901234567890 TO W-TOTAL.”
- — 展開後のイメージ（実際には72列以降が切り捨てられる） —
- 123456789012345678901234567890123456789012345678901234567890123456789012
ADD 1234567890123456789012345678901234567890 TO W-TOTAL.
- ↑この「L.」の部分が72列を超えて切り捨てられ、構文エラーとなる
- — 安全な解決策：複数行に分割する —
- 72列に収まるよう、命令自体を分割して記述する
COMPUTE W-TOTAL = W-TOTAL + 12345678901234567890
+ 12345678901234567890.
- ↑継続行（7列目にハイフンを置く）を利用して安全に記述する
5. 応用・注意点：リファクタリングの際の心構え
既存のレガシーコードを現代的な命名規則に変更しようとして、不用意に長い変数名へリネームすると、この「72列の壁」に衝突します。
また、コンパイルリストを確認する際は、マクロ展開後のソースコードが出力されるオプションを指定し、「72列目付近で不自然な切り捨てが起きていないか」を必ず目視確認してください。
もし、極端に短い変数名が多用されているコードに出会ったら、それは「物理的な制約との戦いの跡」かもしれません。その意図を理解した上で、安全にリファクタリングを進めていきましょう。
コメント