正しい構文？のPARMLIBメンバーなのにIPLエラーになる？

MVSの動き方を決める重要なシステム設定パラメーターとして、PARMLIBメンバーがあります。元々はSYS1.PARMLIBという名称の区分データセットが使われていました。現在ではインストール時のカスタマイズによって異なるDSNにしたり、PARMLIBライブラリーを複数のデータセットに分散することもできます。

ずいぶん以前のMVSでは、PARMLIBメンバーにエラーがあるだけでもIPLが止まってしまうため、パラメーター・メンバーの修正にはずいぶんと気を使ったものです。運用で使用しているメンバーを直接直さずに代替のメンバーを作り、そちらを修正する。あるいは現行のメンバー内容をコピーした代替メンバーを作っておき、もしIPLに失敗したら、代替メンバーのパラメーターでIPLし直す、などはよく行われました。これらはIPLができないとOSが起動しないのでエラーを起こしてしまったメンバーを直したり元に戻したりすることができないからでもありました。
しかしOS/390、z/OSとなった現在のMVSでは、PARMLIBメンバーのパラメーター定義や値に誤りなどがあってもよほどのものでない限り、エラーは無視され（警告はされる）IPLが途中で止まるようなことはなくなりました。
そんな中で「これのどこがエラー？」と見えてしまいそうなものをひとつ。

コメントの終わり位置が悪いためエラーとなる例

NJEのテストをするためOS内にテスト用の代替JES2を追加したところ…

定義したPARMLIBメンバー

再IPLしたらJES2起動時（IEFSSN00メンバー処理時）にエラーになってしまいました

IEFSSN00に追加したのは「SUBSYS SUBNAME(JESB)」の行です。コメントもきちんと/*と*/で囲まれているし一見すると問題ありません。以前は追加した行の最後のカンマを付け忘れたため、以降の行がすべて無視されていたなどということもありましたが、現在主にサポートされているキーワード形式のパラメーターではそのような心配も減りました。

一見すると正しいのですが、PARMLIBメンバーの基本的な構文規則ではパラメーターはコメントも含め1桁目から71桁目に記述しなければなりません。この例ではコメントのストッパーが72桁目になってしまい、結果として無視されているからです。

落ち着いて見ればわかりますが、このような一見すると正しく見え、どこがおかしい？という類のものはなかなか原因を見つけられないというもののひとつでもあります。そうでなくてもIPLでエラーが出たりすると、（自分が直したのが原因であることが明白で）あせりが先に立ってしまったりするものです。