Gil wrote <snip> For compatibility with historic behavior, I'd expect NOLONGPARM (the default) not to be enforced when a program is invoked by LINK, ATTACH, etc. or from an unauthorized STEPLIB concatenation. </snip>
LONGPARM is relevant only for the building of the parameter area for the jobstep program and for some z/OS Unix stuff. So it does not apply to any other program-fetch-type interface. There is nothing to enforce. This is not a question of compatibility. There is no historic behavior to be compatible with for the jobstep program through JCL, because a parameter longer than 100 bytes had not previously been allowed. Allowing longer parm via PARMDD is nominally incompatible (it could/would break an existing program that was coded to handle only 100 bytes), but was chosen to be allowed for unauthorized jobsteps with no change to the directory entry because there was no security ramification of such breakage. Conversely, for security reasons, it was not allowed for authorized jobsteps unless the program identified via LONGPARM that this was OK. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
