On Wed, 27 Mar 2013 07:06:58 -0500, Tom Marchant wrote: > >>When long PARMS have been discussed here previously, the reactionaries >>and IBM loyalists have objected, "Oh, no! We can't have that! Suddenly >>programs that clearly failed on JCL errors will instead program check >>on buffer overruns and our help desk bandwidth will be strained." > >Really? I don't remember anyone saying that. What I remember seeing is >that any program that accepts a PARM should be coded so that it can be >called from a program that might pass a longer PARM. > Non-zero, but not as many as I thought I remembered. Searching the archives for May, 2005, I find, e.g.:
On Fri, 13 May 2005 15:56:50 -0400, Arthur T. wrote: > ... > There *must* be a method to make sure the system does >not pass more than 100 bytes to a program which isn't >prepared to receive them. Merely expanding PARM= or >changing to ZPARM= does not provide that protection. > ... And Peter Relson mentioned it as a concern when he originated the thread. It's interesting how many features coming in z/OS 2.1 were mentioned in that thread: o Long PARMs (of course). o A load module attribute indicating a program's willingness to accept long PARMs. o PARM generated from a data set (e.g. PARMDD). o Instream data sets in PROCs o Symbol substitution in instream data sets. o System symbol substitution in batch JCL. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
