To me, the PARMX approach strikes the right balance: - You have to explicitly change existing JCL to have a program see > 100. - Existing programs that already support > 100 work with only a JCL change
As far as the argument that PARMX is dangerous because someone could code PARMX with a program that didn't support > 100: This seems selectively cautious to me... any program could fail if you change its input to something it doesn't support. You don't need a new JCL keyword. As far as starting a debate between the three suggested JCL enhancements (PARMX, JCL variables available at runtime, and SYSIN substitution) - why? IMO, its better to lump everything into a single requirement "bundle" that has wide rather than fractured demand. IBM will choose what and how to implement anyway (if at all). Maybe we should just be thankful that we have 100 and not 80 :-) On Wed, Nov 4, 2009 at 11:01 AM, Clark Morris <cfmpub...@ns.sympatico.ca> wrote: > On 3 Nov 2009 20:51:59 -0800, in bit.listserv.ibm-main you wrote: > >>On Tue, Nov 3, 2009 at 5:44 PM, Paul Gilmartin <paulgboul...@aim.com> wrote: >> >>> <snip> >>> You're inconsistent in your assumptions. You appear to believe that: >>> >>> o Some JCL programmers won't take responsibility ... but >>> >>> o All Assembler, Rexx, FORTRAN, COBOL, C, PL/I, ... can be >>> presumed to take responsibility for ensuring that the >>> interface requirements of any program they may call are met. >>> >>> I strongly doubt the second of those statements. Therefore, >>> to avoid breaking programs in unpredictable ways, the OS must >>> be reinforced to avoid ever passing a PARM >100 characters. >>> This must be done at the SVC level in order to preclude the >>> programmer's loading registers and issuing the LINK or ATTACH >>> SVC with an oversize PARM. In fact, there's no way to prevent >>> the programmer's coding LOAD followed by BALR. Give me a >>> program with AC=0 that doesn't check its PARM length and I'll >>> break it. (Wanna see me make ASMA90 S0C4? I needed to use >>> ATTCHPGM; couldn't break it with ATTCHMVS. I have a tester's >>> temperament; you can't assume I'll always for be responsible >>> for ensuring that a program's interface requirements, documented >>> or otherwise are met.) >>> <http://bama.ua.edu/archives/ibm-main.html> >>> >> >>No I am not inconsistent in my assumptions, but I've obviously failed to >>communicate them to you. Let me try one last time. >> >>The fact that you can find programs that are "well behaved" in the >>circumstances you're talking about is not at all in dispute. But neither is >>it in the slightest bit relevant. Whether you choose to accept it or not, >>the initiator's documented interface existed long before the other >>interfaces you're citing (with the exception of plain old "CALL") were even >>a developer's wet dream. Lots of horses fled the barn in the mean time. >> >>And I agree that I can't assume you will be responsible for ensuring your >>called program's interface requirements are met. In fact, I'm sure I can't. >>That's the whole point. Your "tester's temperament" is at odds with the >>stability needs of a production batch environment and I'll take a healthy >>sized bet that those production batch environments were there before you >>were, so whether you like it or not, they get grandfathered in, even if they >>don't play well by the rules you imagine they must. >> >>(Sorry if my "architect's temperament" is showing) > > The danger of a PARMX in JCL that passes parms greater than 100 bytes > is two fold. > > 1. A specific JCL will have an EXEC statement that invokes the program > with PARMX= without someone having tested the program to verify that > it can handle that PARM length. This is sloppy programming and the > installation deserves what it gets. > > 2. An installation will either change all JCL to use PARMX instead of > PARM or require it for new JCL without verifying that the programs can > handle it. Again this might be considered poor management because a > mass change is made to an interface without testing. > > Both cases require specific action to break something existing, i.e. > the JCL change. A change to existing JCL to create a PARM greater > than 100 bytes in length on an EXEC statement with PARM= would still > cause job failure. In one sense a more basic question is what do we > see the future of the z series as being. People on other platforms > look at many of the restrictions in JCL as being archaic (8 byte > program names, 44 byte data set names, upper case only, and so forth). > Even those coming from VSE (formerly Dumb Operating System) look > askance at some of the restrictions (like not being able to handle > FBA). > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
