On Tue, 22 Sep 2009 14:35:40 -0500 "Patrick O'Keefe" <[email protected]> wrote:
:>On Tue, 22 Sep 2009 08:15:59 +0300, Binyamin Dissen :><[email protected]> 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. :>>Actually the current interface does set the high order bit of the word :>>pointing to the parm to x'80'. All (almost all?) IBM utilities support :>>a three word plist, where the second word points to a list of :>>overriding DDNAMEs and :>>the third word points to a starting page number. :>I don't think any new arguments, counter-arguments, or proposed :>solutions are being raised here (and I'm certainly not about to), :>but the above comment adds a new twist. :>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. Or it can be provided as the fourth parameter. A null DDlist and a null page number can be in positions 2 & 3. :>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. Or if it is an APF program, it may fetch the length and do a MVCL in key 0. :>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. As the fourth parameter. :>I know some people see that as hobbling z/OS with severe :>limitations of the S/360 past, but I see maintaining compatability :>as a source of the great stability of z/OS and its ancestors. :>Thee is an obvious need for lifting the 100-byte limit on parms, but :>it needs to be done in a way that allows old programs to continue :>to work. Can easily be done. P1 points to an up to 100 byte string, P4 points to the full data. -- 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
