-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Craddock Sent: Wednesday, September 23, 2009 11:30 AM To: [email protected] Subject: Re: Long parms ... again (was: Reading DD card information)
On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve < [email protected]> 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. <SNIP> Not at all. The thing I was responding to was the APF side of things and inappropriate behavior by an APF program being handed a too long JCL PARM based R1. By definition, the area pointed to by R1 is not fetch protected. So an APF program doesn't have to resort to KEY0 to read the parm area. Now, from that perspective, I think what I originally said relative to PARM and APF programs should make more sense. As for the typical non-APF program and handling the JCL PARM based R1 upon entry, I don't even want to go there because of all the different ways that can be coded between, RPG, FORTRAN, COBOL, PL/1, etc. ad naseum. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
