Todd, First, lets not make this personal. *I* didn't pass 64K bytes to a program not expecting it, someone else did. (I know better.) The result could be a program failure. Some sites will launch a witch hunt to assess guilt, etc. But the architecture in place when the program was written completely precluded that possibility... so it really was IBM who broke the program. Especially since the rules in place even TODAY continue to preclude the possibility.
Second, when *I* want to pass 64K (or more) to a program I use the existing mechanism that works very, very well: a FILE. If you try passing 64K worth of "PARM=" to a program, you'll be looking at just about 1000 JCL statements to carry that (PARM=file) data. (Would someone from Kansas call that "intelligent design"? I wouldn't.) You've made the internal reader (and C/I) busier just to satisfy misguided methods of avoiding another file. Finally, if you want to establish a new convention for "stdparm" in addition to "stdin" and "stdout" I am behind you 100%. (If you want to break old programs why don't you do that under an alternative platform instead?) On Fri, 20 May 2005 13:51:55 -0500, Todd Burch wrote: >Tom, your argument doesn't hold water. > >First, you want your s/360 program to run unchanged. I do too. So does >Don. > >> Don, >> >> If you limit the long parms to 32K instead of 64K I have little issue, but >> by raising your limit to unauthorized programs to 64K you create an >> architectural problem: Old programs loading the "halfword length on a >> halfword boundary" length value using the LH instruction will receive >> negative values for such long parameters. They are unlikely to >> successfully handle such arithmetic values as they would have been very >> unanticipated when they were written some 30-35 years ago. >> >> If a 32K PARM string isn't long enough I hold out little hope that a 64K >> string is going to always satisfy the user's requirements. >> >> -- >> Tom Schmidt >> Madison, WI >> (Yes, old programs will be using LH instead of ICM since they may well >have >> been written using the 360 instruction set. IBM promised not to break old >> programs with incompatible changes, remember?) >> > >I voted for 32K too, but hey, 64K is even better. > >IBM, by implementing this, will not have "broken" anything. Your s/360 >program that is runing today from JCL is expecting no more than 100 bytes. >Fine. Why would you pass 64K bytes to a program that is expecting a max of >100? If you do, you've broken it, not IBM. > >Todd Burch -- Tom Schmidt Madison, WI ---------------------------------------------------------------------- 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
