@Gil, there are two issues: There is no *integrity* exposure (at least in theory) from long parms and CALL, XCTL, etc. Either both programs are loaded from an APF-authorized library (in which case we are forced to assume honesty and competence on the part of the authors*) or else the called program is certainly not running authorized, so while a longer than expected PARM might cause a S0Cx, it cannot affect the integrity of the system as a whole. In other words, it can overlay program storage but not system storage.
*Laugh if you want, but if you don't make that assumption then all of MVS integrity goes down the drain. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, November 30, 2017 7:27 PM To: [email protected] Subject: Re: LONGPARM On Thu, 30 Nov 2017 18:40:01 -0800, Ed Jaffe wrote: >On 11/30/2017 4:32 PM, Charles Mills wrote: >> Thanks. >> >> Got it. In order for a program to be passed > 100 bytes from // EXEC it must >> be either not authorized or linked with LONGPARM (or both). >> >> Am I right on bullet one? Parms greater than 100 bytes are a PARMDD thing >> only, never a PARM= thing? > >You can *never* pass more than 100 bytes via PARM=. If you want a >longer parameter, you *must* use PARMDD. > >The interface as seen by the program is the same in both cases: >halfword length followed by data. > What about the ATTACH, XCTL, LINK, and LOAD/CALL macros. Prior to the innovation of the LONGPARM attribute it was the responsibility of either the parent or child task (not clearly documented which?) to verify PARM length. Do these nowadays respect the NOLONGPARM setting? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
