【入門編】GOTO文のスコープ制限と非構造化プログラミングの弊害 – PL/Iの基本構文とデータ制御実践ガイド

こんにちは。メインフレームの世界へようこそ。

あなたがこれまでJavaやCOBOLで培ってきた「構造化」の常識を一度リュックに詰め込み、少しだけこの「PL/I」という広大な宇宙を覗いてみることにしましょう。PL/Iは、1960年代にIBMが「科学技術計算も事務処理もこれ一つで!」という野望を込めて設計した、非常に懐の深い言語です。

今日は、初心者の方が最初に遭遇する「迷宮への入り口」、つまりGOTO文とプログラム構造について紐解いていきます。

1. PL/Iの「お家」の作り方(PACKAGEとPROCEDURE)

まずは、プログラムの全体像を見てみましょう。Javaでいうところのクラスやメソッド、COBOLでいうところのプログラム構造に相当します。

1
/ プログラムの始まりを宣言します /
MY_PROGRAM: PACKAGE;

/ メインの入り口。OPTIONS(MAIN)は、ここからOSが実行を開始するという合図です /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);

DCL MSG CHAR(20) INIT(‘HELLO WORLD’); / DCLは変数宣言。COBOLのDATA DIVISIONに近いですね /

PUT SKIP LIST(MSG); / 画面やログに出力します /

END MAIN_PROC;

END MY_PROGRAM;

PL/Iでは、`PACKAGE`の中に複数の`PROCEDURE`を入れ子にしたり、並列させたりできます。「お家(PACKAGE)」の中に「部屋(PROCEDURE)」がたくさんあるイメージです。この「部屋」の境界線が、実はこれから話すGOTO文の重要な鍵になります。

2. 禁断の果実:GOTO文のスコープ制限

JavaやC言語で「GOTOは悪だ」と教わってきましたよね?PL/Iでもそれは同じです。ただ、PL/Iにはさらに強力な「物理的な壁」が存在します。

「一つのPROCEDURE(部屋)をまたいで、他のPROCEDUREの中に飛び込むことはできない」

これがPL/Iのルールです。もし無理やり飛び込もうとすると、コンパイラは即座にエラーを出してあなたを止めてくれます。

1
BLOCK_A: PROCEDURE;
GOTO TARGET_LABEL; / 別の部屋には行けません!コンパイルエラーになります /
END BLOCK_A;

BLOCK_B: PROCEDURE;
TARGET_LABEL:
PUT SKIP LIST(‘ここに来たかったけれど…’);
END BLOCK_B;

この制限は一見不便に思えるかもしれませんが、実は「スパゲッティコード」を物理的に封じ込めるための先人たちの知恵なのです。

3. なぜ「スパゲッティ」は生まれるのか?

では、なぜ「GOTO」が恐れられるのか。それは、「どこから来たのか」が分からなくなるからです。

もし大規模なPL/Iプログラムで、一つのPROCEDURE内で何百もの`GOTO`が飛び交っていたらどうでしょう?デバッグの際、変数の値がどのタイミングで書き換わったのかを追跡するのは、迷路で出口を探すような苦行になります。

初心者の方が陥りやすい罠

実務の改修現場では、古いコードに遭遇することがよくあります。こんなコードに出会ったら要注意です。

1
/ 悪い例:処理の流れが制御不能な状態 /
PROC_MAIN: PROCEDURE OPTIONS(MAIN);
IF ERROR_FLAG THEN GOTO CLEANUP;
/ … 100行の処理 … /
GOTO END_PROCESS;

CLEANUP:
/ 後始末処理 /
END_PROCESS:
RETURN;
END PROC_MAIN;

この「ラベル」へのジャンプが多用されると、コードの「入り口」と「出口」が何箇所もできてしまい、後から修正を加えるプログラマが「どこを通ってここまで来たんだ?」と頭を抱えることになります。

4. 怖がらないで。解決策は目の前にあります

もしあなたが、このような複雑なPL/Iコードの改修を任されたら、どうすればいいでしょうか?

1. 「ラベル」を追う前に「データ」を追う:
PL/Iはデータ属性が自由自在です(`FIXED BIN`, `CHAR`, `PIC`など)。`GOTO`で制御を追うよりも、その変数が「どのPROCEDUREの範囲(スコープ)で生きているか」を整理してください。
2. `IF-THEN-ELSE`と`DO-END`の構造化:
古い`GOTO`を、現代的な`IF`文や`SELECT-WHEN`文(JavaのSwitchに近いですね)に置き換えていくのが、リファクタリングの第一歩です。
3. デバッガを友にする:
メインフレームのデバッガ(IBM z/OS Debuggerなど)は、変数の値が変化するタイミングでプログラムを止めることができます。`GOTO`の迷路を歩く必要はありません。

最後に:PL/Iは「道具」です

PL/Iは古い言語かもしれませんが、その堅牢性は今も現役の基幹システムを支えています。`GOTO`の制限という「壁」は、実はあなたのコードを正しく守るための「防波堤」でもあるのです。

「なんだか難しそう」と思わず、まずは小さなPROCEDUREを書いて、コンパイルを通してみてください。PL/Iはあなたの挑戦を、非常に厳格ですが、正確に受け止めてくれますよ。

また何か具体的なコードの読み解きで困ったら、いつでも聞きに来てくださいね。現場の知恵を総動員して、一緒に解決しましょう!

タイトルとURLをコピーしました