@Gil points out to me off-list that PARMDD can be longer than 100 per the message I was replying to but not PARM=.
Well then, yes, that is consistent with what I was saying. Had I designed it I would have just made PARM= longer than 100 subject to a binder-set bit. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, February 27, 2017 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question about PARMDD Well that was my recollection but looking at https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab600/iea3b6_Syntax89.htm It says Length: The length of the subparameters passed must not exceed 100 characters: So I thought I imagined the below. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2017 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question about PARMDD On Mon, 27 Feb 2017 09:18:04 -0800, Charles Mills wrote: >Admittedly poor technique, but a program allocates a 100-byte buffer. >It moves the parm info into that buffer using an executed MVC or an >MVCL without first verifying that the length is no more than 100. >Conceivably a security exposure: many exposures start with buffer overrun. > >What I think I would have done if I had designed the enhancement was >had a linkedit bit similar to AC(1) that said "this program is good >with JCL parms over 100 bytes." Admittedly not perfect: what if the >jobstep program calls another program that processed the JCL PARM= info. > z/OS MVS Program Management: User's Guide and Reference Version 2 Release 2 SA23-1393-01 Chapter 6. Binder options reference Binder options LONGPARM: Long parameter option The LONGPARM option indicates whether the program supports a parameter longer than 100 bytes. This applies mainly to programs that are invoked using a JCL EXEC statement or a z/OS UNIX EXECMVS callable service. LONGPARM or LONGPARM=YES specifies that the program can accept a parameter string of more than 100 bytes. In this case, an appropriate directory entry bit will be turned on. The system checks for this attribute only when the program is being invoked with a parameter string of more than 100 bytes and the program is APF authorized. In this case, if the LONGPARM attribute is not set on, the system fails the invocation. >This is a philosophy issue and not a detailed design issue, but I think >we are over-obsessed with compatibility. I understand why we are, I >remember the FS debacle, and I still feel that way. You can't make an >omelet without breaking eggs. I think the obsession with compatibility >sometimes holds the platform back, or makes enhancement unnecessarily >complex. I recognize the validity of other opinions. They anticipated your concern. It has always been the caller's responsibility either to validate the PARM or to ensure that the called program does so. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
