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. 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. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Windt, W.K.F. van der (Fred) Sent: Monday, February 27, 2017 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question about PARMDD But how would support for a longer parameter possibly break an existing program? The program is passed the address of a binary half word (the length of the content of the parm) followed by that content. Even if a much longer parm was supported nothing would change for a program that is currently invoked with a certain parameter. The program would probably break if somebody passes a 1000 character parameter to a program that expects only 8 characters. But it would probably break as well if you pass such a program a 9 character parameter. Fred! Sent from my new iPad > On 27 Feb 2017, at 08:54, Allan Staller <allan.stal...@hcl.com> wrote: > > ">No. IBM chose **not to break** thousands upon thousands of programs that were perfectly happy with 100 byte parm fields, provided via JCL. >> They added a new mechanism for those program, where 100 bytes was not sufficient." > > > > My reply was to Gil who was complaining about IBM's implementation of PARMDD (it should have been....). The "not to break" is a good thing. > Gil seems to think that breaking existing programs by introducing incompatable function is OK to do. I disagree. > > I am in support of the path IBM chose. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Woodger > Sent: Monday, February 27, 2017 9:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Question about PARMDD > >> On Monday, 27 February 2017 15:00:03 UTC+1, Allan Staller wrote: >> No. IBM chose not to break thousands upon thousands of programs that were perfectly happy with 100 byte parm fields, provided via JCL. >> They added a new mechanism for those program, where 100 bytes was not sufficient. >> > > Unless you change the JCL to use PARMDD on the EXEC instead of PARM on the EXEC, nothing changes. > > If you make that change for no purpose, and then the program is doing something which relies on there being 100 bytes of data as a maximum implicitly, then you may have a problem. But how is that IBM's fault? No-one forced the JCL change. > > If you don't change the JCL, the program expecting a maximum of 100 bytes and never needing any more than that will work as designed for the next... well, forever. > > Have you got an example from one of the thousands and thousands of breaks caused? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ::DISCLAIMER:: > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > E-mail transmission is not guaranteed to be secure or error-free as > information could be intercepted, corrupted, lost, destroyed, arrive > late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of > the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, > copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. > Before opening any email and/or attachments, please check them for viruses and other defects. > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------- ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. ---------------------------------------------------------------------------- -------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
