On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote: > >I am *GUESSING* that the new statement is a nod to compatibility. >There are just too many programs that accept the current limit and >would be broken if the parameter passing was changed. I am OK with it >myself. Since any *NEW* program would have to be programmed to accept >the parameter list that IBM comes up with. I certainly don't object >as it maintain compatibility at no cost. > Nope. I got a peek at John Eels's February SHARE SF presentation:
• New PARMDD EXEC keyword support longer parameter strings • Mutually exclusive with PARM keyword • No other changes required for unauthorized programs So users will be able to call any old existing program with a long PARM. I hope you don't have too much trouble dealing with it. Me, I'm delighted. You, I suppose you could code a JCL exit to prohibit PARMDD. What do you do today about users who use LINK or ATTACH to supply long PARMS? The consipcuous concession to compatibility I see is in making the DDNAME selectable. This provides programmers the facility to work around any DDNAME conflicts that might have arisen if IBM had chosen a fixed DDNAME such as SYSPARM. Since PARMDD and PARM are mutually exclusive, I should be able to EXEC an existing library PROC, overriding with PARMDD.stepname=MYPARM and expect the PARM coded in the PROC to be nullified, right? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
