【実務・中級編】JCL PARMパラメータの受け取りとCHARACTER VARYING属性の活用 – PL/Iの基本構文とデータ制御実践ガイド

メインフレームの現場から:JCL PARMの「賢い」受け取り方とVARYING文字列の極意

諸君、お疲れ様。今日も今日とてJCLのパラメーター(PARM)と格闘しているか?

「PARMで渡した値がうまく読み込めない」「固定長文字列の末尾の空白をいちいちTRIMするのが面倒だ」といった嘆きを、最近の若手からよく聞く。PL/Iは古臭い言語だと思われがちだが、実はメモリー管理や文字列操作において、現代の言語にも引けを取らないほど緻密な制御が可能だ。

今日は、メインフレームのバッチ処理において避けては通れない「JCL PARMの受け取り」と、それをモダンに捌くための`CHARACTER VARYING`属性の活用法について、実戦的な知見を授けよう。

1. PARMの受け取り:PROCEDUREの引数指定

まず、大前提となる`PROCEDURE`文での受け取り方だ。`OPTIONS(MAIN)`を付けたメインプログラムにおいて、PARM文字列をそのまま受け取るには、引数を一つ用意する。

ここで最も重要なのは、「受け取る変数をどのように定義するか」だ。

1
/ — サンプルコード: PARM受取の基本 — /
MYPROG: PROC(PARM_DATA) OPTIONS(MAIN);

/ 文字列の長さは最大100バイトと想定 /
DCL PARM_DATA CHAR(100) VARYING;

/ JCL側で指定された実際の長さは、LENGTHビルトイン関数で取得可能 /
DCL ACT_LEN BIN FIXED(15);
ACT_LEN = LENGTH(PARM_DATA);

PUT SKIP LIST(‘入力されたPARM: ‘ || PARM_DATA);
PUT SKIP LIST(‘実際の長さ: ‘ , ACT_LEN);

END MYPROG;

なぜVARYINGを使うのか?

`CHAR(100)`のような固定長で受け取ると、JCL側で`PARM=’TEST’`と指定しても、PL/I側では後ろに96個の空白が付いた`’TEST …’`として認識される。これを毎回`TRIM`や`SUBSTR`で切り出すのは、コードの美観を損なうだけでなく、バグの温床だ。

`VARYING`属性を付けると、コンパイラが先頭2バイトに自動的に「現在の長さ」を保持してくれる。これにより、以降の処理では、あたかも入力文字列そのものの長さが動的であるかのように振る舞えるわけだ。

2. 実戦:VSAMアクセスと組み合わせた動的制御

現場のバッチ改修では、このPARMを「読み込むべきVSAMファイル名」や「処理対象のキー」として使うケースが多いはずだ。

以下に、実務で使える「堅牢な文字列処理」のパターンを示す。

1
MYBATCH: PROC(PARM_IN) OPTIONS(MAIN);

DCL PARM_IN CHAR(255) VARYING;
DCL KEY_VAL CHAR(10) VARYING;

/ ONユニットでファイルエラーを補足し、安全に終了させる /
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘処理完了: 正常終了’);
END;

/ PARMから処理キーを切り出し、VARYINGの利点を活かす /
/ 固定長だとSUBSTRで空白をケアする必要があるが、VARYINGなら不要 /
KEY_VAL = SUBSTR(PARM_IN, 1, 5);

/ VSAMアクセス例 /
READ FILE(VSAM_FILE) INTO(REC_BUF) KEY(KEY_VAL);

/ 処理ロジックへ続く… /

END MYBATCH;

3. ベテランからのアドバイス:デバッグと落とし穴

最後に、現場で泣きを見ないための「PL/Iの心得」を伝えておく。

1. 最大長の設定に余裕を持て:
JCLのPARMは最大100バイト(システム設定によるが)までという制約があることが多い。しかし、将来的な拡張性を考え、`VARYING`で定義する際は少し大きめに取っておくのがリスクヘッジだ。
2. 型変換には注意せよ:
`VARYING`で受け取ったデータを、固定長のDB2ホスト変数やVSAMのキーに渡す際は、必ず`TRIM`や`SUBSTR`を意識すること。暗黙の型変換に頼ると、予期せぬ空白混入でキーが見つからないという「メインフレームあるある」な障害に直面する。
3. ONユニットの活用:
入力データが異常な場合(空のPARMが渡された等)、`ON CONDITION`や`ON ENDFILE`を適切に定義して、プログラムが異常終了(U0001など)する前に、ダンプを出力し、かつ綺麗なログを残して`STOP`できるようにしておけ。

結びに代えて

PL/Iは、書き手が意識すれば非常に強力なツールになる。`VARYING`属性一つとっても、単なる文字列の入れ物ではなく、プログラムの制御フローを簡潔にするための武器だ。

「昔からこう書いていたから」という惰性でコードを書くのではなく、なぜこの属性が必要なのか、なぜこの関数を使うのかを常に問いかけてほしい。君たちが書くその一行が、明日、誰かの夜間バッチを救うことになるかもしれないのだから。

さて、そろそろ次の案件の設計書を確認しに行くとしよう。諸君、健闘を祈る。

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