On Wed, 23 Sep 2009 12:57:46 -0400, Barkow, Eileen <ebar...@doitt.nyc.gov> wrote:
>The argument that an existing program cannot handle a longer >parm area if it was available is nonsense - just don't pass it the >longer area and there will not be a problem. I don't buy that. Whether you are talking about a you-bet-your- company production program or a critical system utility, Murphy says that somebody will pass the program an invalidly long parm as soon as the operating system allows it. Documenting "Don't do that" may protect your rear end but it won't your company from the results. Pat O'Keefe > >A perfect example on why a longer parm area over 100 bytes is needed is the CICS Web Service Assistant job streams (DFHLS2WS/DFHWS2LS) that IBM stupidly wrote to require long-winded hfs file names passed in the parm field. I had to use convoluted links and 1 character file names in order to fit every thing in. > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock >Sent: Wednesday, September 23, 2009 12:30 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: Long parms ... again (was: Reading DD card information) > >On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve < >steve_thomp...@stercomm.com> wrote: > >> >> Might I suggest that you are being a bit myopic? Or perhaps suffering >> from tunnel vision? >> >> APF programs are to be written to a higher standard. >> >> From what you have written, you believe that if someone passes an APF >> program you have written, an invalid parm, that program should accept >> that as gospel and go clobber some part of the address space (say the >> JSCB, or change the ASCBSENV, etc.) and give the caller authorities they >> should not have, right? >> >> >I think you're missing the point entirely Steve. This has nothing to do with >APF or non-APF and nothing at all to do with abstract program A calling >theoretical program B. The consequences for an APF program are potentially >more serious, but the problem is the same. Back before the flood the PARM >interface was explicitly limited to 100 bytes. So a valid program written to >that specification could legally pick up the length and mindlessly move that >many bytes from the parameter data into another pre-allocated (or >dynamically allocated) 100 byte area knowing full well there was no chance >of overflow because the OS guaranteed (then) that the actual length would >never be greater than 100. > >Fast forward 4 decades and change the interface so the length could go over >100 and now you have valid programs that can suddenly overlay their 100 byte >area. Nothing good can come of it and if you're lucky you just abend right >then and there. If you're an APF program then things can go awfully pear >shaped. > >An interface definition is a contract. You can't break it, even if the >original contract (as in this case) was stupid. > > >-- >This email might be from the >artist formerly known as CC >(or not) You be the judge. > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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
