I think that would "break" many programs. Many standard utilities, compilers, etc. expect to invoked from either JCL where there is only one parm or dynamically called with one or more parms. Off the top of my head I can't remember for format of the second parm other than it is used to dynamically change the standard DDNAMEs to user specified. This mean that if you accidently executed one of those programs with PARMX='....' it would get all confused.
I still vote for a simple PARMX='long-string' where the GPR1 -> fullword (w/ high bit set to 1) -> 2-byte-length followed by a long string. I originally said that the max length could be 32k-1 or 64k-1, but only because that's was a convenient max for a 2 byte length field. However, a max size even as small as 1024 to 4096 would very likely satisfy well over 99% of anyone's true need to pass a long parm. I find it difficult to envision JCL with a parm string that was many thousands of characters long (that's a lot of continuations). Besides there are very likely other limits in the converter/interpreter, text units, JES, etc. that would make massively long parms difficult to implement. If even longer parms are needed, the various current methods to pass longer parms by dynamically calling the program could still be used. I think that my proposal seems to be the simplest (KISS), seems likely to break fewer things, and the very important to IBM, cheaper to design, implement, and test while satisfying many customer's long standing desire to have a much long parm field. Don Williams -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John P. Baker Sent: Thursday, October 29, 2009 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: An Alternative Modest PARM Proposal All, The proposal previously set forth is interesting, but I would like to put forward an alternative proposal. For a short PARM= value (compatibility mode), R1 -> fullword address of PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by a string buffer not exceeding 100 bytes. For a long PARM= value, R1 -> fullword address of PARM= info, consisting of a 4-byte length prefix (negated (high-order bit = B'1'), value 101..installation-defined-maximum), followed by a fullword address of a string buffer not exceeding installation-defined-maximum bytes, followed by a fullword ALET identifying the dataspace wherein the string buffer is located. FWIW, z/VSE currently allows a maximum PARM= length of 300 bytes, coded in up to three (3) PARM=value specifications on an EXEC statement, with the values being concatenated by the JCL processor. John P. Baker ---------------------------------------------------------------------- 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
