Because...PARM was originally intended for passing of small values of data. If you needed to pass more data than 100 bytes, that was a job for a control card data set. Only the C/C++ compiler (from what I've seen in my experience) has that capability.
I wouldn't care if it was 32767 or 65535 or 1024 or 4094 - just get off of 100. As a note - 65535 / 68 = 964 JCL cards at a minimum. That's one continuation I'd hate to see. :-) Ray -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Thursday May 12 2005 15:57 To: [email protected] Subject: Re: PARM= In a recent note, Ray Mullins said: > Date: Thu, 12 May 2005 15:49:45 -0700 > > I vote for doing it - but not 32767 - maybe 1022 or something like > that. I have found that the limitations of PARM are hit by compiler > invocations, especially as the options became verbose over the years. > Why would the increasing verbosity of options motivate you to suggest any limitation other than the largest possible? Do you simply want to reserve room for future expansion? -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
