こんにちは！メインフレームの世界へようこそ。
JavaやCOBOLといった他のモダンな言語をご経験されてきた方にとって、IBMメインフレームの世界、そして「PL/I（ピーエルアイ）」という言語は、最初はちょっと厳めしい要塞のように見えるかもしれません。「なんだかルールが難しそう」「古い仕様で頭がこんがらがっちゃいそう」……そんな風に不安を感じていませんか？
大丈夫です、安心してくださいね。今日は、その要塞の門をスッとくぐるための第一歩として、JCLから渡されるパラメータ（PARM）をPL/Iでどうやってスマートに受け取るか、その秘密を一緒に優しく紐解いていきましょう。
—
1. 他言語とはココが違う！PL/Iの「予約語を持たない」懐の深さ
JavaやC言語、COBOLなどを触ってきた方なら、「この単語はキーワード（予約語）だから変数名に使っちゃダメだよ」と言われた経験が何度もあるはずです。例えば、`IF` や `DATA` なんて名前の変数は作れませんよね。
ところが、PL/Iの生い立ちにはちょっと面白い特徴があります。なんと、PL/Iには「厳密な意味での予約語」が存在しないのです。
どういうことかと言うと、コンパイラは前後の文脈（コンテキスト）を見て、「あ、ここは命令句だな」「おっ、ここはプログラマが名付けた変数だな」と空気を読んで判断してくれます。極端な話、`IF` という名前の変数を作ることすらできてしまうのです（もちろん、ソースコードが読みにくくなるので絶対にやめましょうね！）。
この「柔軟だけど、時々お茶目な」言語仕様が、JCLのパラメータ受け取りの場面でも独特の優しさを発揮します。
—
2. JCLのPARMをどうやって受け取るの？
メインフレームの世界では、ジョブを実行するJCL（Job Control Language）の `EXEC` ステートメントの `PARM` パラメータを使って、外部からプログラムへ文字データを渡すことができます。
//STEP01 EXEC PGM=MYPROG,PARM=’HELLO,WORLD’
この `’HELLO,WORLD’` という文字列を、PL/Iのメインプログラムでどうやってキャッチするのでしょうか？
Javaなら `public static void main(String[] args)` ですし、COBOLなら `LINKAGE SECTION` に受け皿を用意しますよね。
PL/Iでは、メインプロシージャの `OPTIONS(MAIN)` の後ろに、そっと引数を一つ書いてあげるだけで完了します。
百聞は一見にしかず、実際のコードを見てみましょう。
MYPROG: PROC(P_PARM) OPTIONS(MAIN);
/————————————————-/
/ JCLのPARM値を受け取るためのメインプロシージャ /
/ 渡される値の最大長を考慮してVARYINGで宣言します /
/————————————————-/
DCL P_PARM CHAR(100) VARYING;
/ 受け取ったパラメータをSYSOUTに出力してみる /
PUT SKIP EDIT (‘受け取ったPARM値: ‘, P_PARM) (A, A);
END MYPROG;
たったこれだけです！すごくシンプルですよね。
ここで、JavaやCOBOL出身の方が「おや？」と引っかかりやすいポイントをいくつか優しく解説しますね。
主役のデータ属性：`CHAR(100) VARYING` とは？
引数として受け取る変数 `P_PARM` に指定されている `CHAR(100) VARYING`。これは次のような意味を持っています。
- `CHAR(100)`：最大で100文字までの文字列を受け取れる入れ物だよ、という宣言です。
- `VARYING`（可変長）：ここがとっても重要です！Javaの `String` のように、実際にJCLから渡された文字数（例えば “ABC” なら3文字）に合わせて、実際のデータの長さが可変になります。COBOLでいう `USAGE IS INDEX` 付きの可変長アイテムや、C言語の終端文字付き文字列に近い感覚ですね。
もし `VARYING` を付けずに単なる `CHAR(100)`（固定長）にしてしまうと、JCLから渡された短い文字列の後ろに、JCL側（あるいはOS側）が埋めた余分なスペースがもれなくついてきてしまい、後続の文字列処理で思わぬバグの原因になります。PARMを受け取る時は、必ず `VARYING` をつけるのがレガシー開発の現場の知恵であり、お作法です。
—
3. 知っておくべき「最大長制限」のリアルな罠
さて、ここで実務で絶対に知っておかなければならない「メインフレームの歴史的な制約」についてお話します。
「じゃあ、JCLのPARMはいくらでも長く渡せるんだから、`CHAR(32767) VARYING` とか大きく作っておけば安心だな！」……と思いましたか？
残念ながら、そうはいかないのがメインフレームの奥深いところです。
JCL PARM自体の制限
OS（z/OS）のJCL仕様において、`PARM=’…’` で記述できる文字数は、最大で100バイト（正確には、継続行を使っても1ステップあたり制限があります）という歴史的な制約があります。
正確には、JCLのEXEC文全体の長さやオペレーティングシステムのバッファ制限により、プログラムに安全に渡せるPARMの長さに実質的な上限が存在します。現代のz/OSでは少し緩和されている部分もありますが、基本的には「PARMは短い制御フラグや日付、小さなコードを渡すもの」という設計思想で作られています。
万が一、長すぎる文字列を受け取ったらどうなる？
もしJCL側で指定したPARMの長さが、PL/I側で宣言した `CHAR(n)` のサイズを超えていた場合、プログラムが異常終了（ABEND：例えばシステムコード `S0C4` やコンパイラ起因のエラーなど）を起こすリスクがあります。
そのため、実務の現場では以下のように防御的なコードを組み合わせるのがプロの技です。
/————————————————-/
/ 安全にPARMを受け取り、長さをチェックする例 /
/————————————————-/
DCL P_PARM CHAR(100) VARYING;
DCL W_LENGTH FIXED BIN(31);
/ LENGTH組み込み関数で、実際に渡された文字数を取得 /
W_LENGTH = LENGTH(P_PARM);
IF W_LENGTH = 0 THEN
PUT SKIP LIST (‘パラメータは指定されていません。’);
ELSE
DO;
PUT SKIP EDIT (‘文字数:’, W_LENGTH) (A, F(4));
PUT SKIP EDIT (‘内容:’, P_PARM) (A, A);
END;
PL/Iには `LENGTH` や `SUBSTR` といった強力で直感的な組み込み関数が最初から備わっています。これらを使えば、可変長文字列の扱いで頭を悩ませることはありません。
—
まとめ：PL/IのPARM受け取りは怖くない！
いかがでしたでしょうか？
「PL/Iのオプションや宣言は難解そう……」と思っていたかもしれませんが、今回見てきたように、
1. メインプロシージャの `OPTIONS(MAIN)` の引数にカッコ書きで変数を用意する。
2. その変数は `CHAR(n) VARYING` で宣言し、可変長としてスマートに受け取る。
3. JCL側の長さに配慮し、必要であれば `LENGTH` 関数で文字数をチェックする。
この3つのポイントさえ押さえておけば、JCLからのパラメータ連携はもうバッチリです！他の言語での経験があるあなたなら、すぐにPL/Iのシンプルな構造の虜になるはずですよ。
日々のバッチ改修やマイグレーション調査でPL/Iのソースコードを開いたとき、この記事があなたの不安を解消する小さな道しるべとなれば幸いです。それでは、快適なメインフレーム・ライフを！
