On Tue, 22 Sep 2009 15:12:25 -0500 Paul Gilmartin <[email protected]> wrote:
:>On Tue, 22 Sep 2009 14:35:40 -0500, Patrick O'Keefe wrote: :>>>:>>I'd be quite satisfied with this _provided_ it was compatible :>>>:>>with the existing CALL, LINK, ATTACH, etc. argument lists. :>>>:>>I.e. on program entry R1 points to a fullword which points :>>>:>>to a halfword containing the length of the PARMX followed :>>>:>>by the PARMX string. :>>It confirms that the end-of-parms flag must be set for parms :>>provided by JCL but also confirms that having both PARM and PARMX :>>would be misconstrued by those programs expecting an optional :>>list of overriding DDnames. This almost supports those saying that :>>only one parm - PARM or PARMX - must be allowed. Almost. :>I believe I stated pretty clearly above that I'd expect PARMX :>to replace the first PARM, not be added as a second. That violates compatibility. :>>A program (foolishly) written with the assumption that it will always :>>be invoked by via JCL with a 100-byte limit on parm length might :>>(foolishly) keep the length in a single byte. It *might* get by with :>>a max 255-byte parm but not a longer one. And when it abends :>>the owner (possible a vendor), not the JCL "coder", is probably :>>going to be called. :>One of the merits of "PARMX" as opposed to "PARM" is that :>it would provide an obvious indication to that "owner" that :>that "coder" might be passing a longer argument string. :>>Whatever technique used to pass a long parm is not going to be :>>safely handled byt the old, standard parm passing scheme because :>>a long parm passed that way will break old, standard programs. :>>Some new technique that can be verified by new programs is :>>needed or a lot of stable production jobs are going to die. :>No! Those programs will continue to work as they always have :>when supplied with the PARMs they've always worked with. :>When provided with longer PARMXs, they will fail (or work) :>as they always have when CALLed or ATTACHed from a program :>or EXEC with those same PARMS. It's trivial to CALL or :>ATTACH a program with a PARM of up to 32767 characters, yet :>I observe no consensus that SYS1.MACLIB(CALL) and Rexx should :>protect the aforementioned program owner by checking and :>restricting the length of the PARM to 100 characters (as :>TSO CALL dismayingly does). Because subroutines do not have a documented API. A program expecting a specific API, such as a jobstep APF program, cannot be provided with data which may cause an overlay or an integrity failure. And should you argue that they can be invoked as a subroutine with a long parm, that is not an exposure as not being invoked via JCL they will not be APF. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
