I'm also relatively ignorant in this field, but it was a PITA when I was looking after the compilers .... ISTR that the PL1 compiler allowed you to code 'DD:PARMDD' in the Parm field, but the COBOL compiler did not ... For COBOL we had to get as many of the options set to the correct site default as possible so that the parm field was not exceeded ... I always wondered why the two compilers differed in this way ?
Cheers, Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas Berg Sent: 28 October 2009 15:33 To: IBM-MAIN@bama.ua.edu Subject: SV: A modest PARM proposal Although ignorant in this field, I'm wondering why this approach wouldn't work (as noone is suggesting it): Today: lengthfield + parm (max 100 bytes) Tomorrow: lengthfield + parm (max 100 bytes) + padding to 102 bytes + newlengthfield + newparm (max 4GiB ? :) ) This of course has the limitation means that the receiving part has to add 102 to get the long parm. But it will only affect new programs that need to handle more that 100 bytes parms, I think ? Regards, Thomas Berg __________________________________________ Thomas Berg Specialist IT-U SWEDBANK > -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] För Shmuel Metz (Seymour J.) > Skickat: den 28 oktober 2009 12:16 > Till: IBM-MAIN@bama.ua.edu > Ämne: A modest PARM proposal > > Over the past decade there have been several discussions of > issues relating to the size limit for PARM. The basic problems are: > > 1. The field in the SCT is only 100 characters. > > 2. While the OS/360 documentation said from day one that any main > program could be used as a subroutine, some programmers assumed > that their parameter lists came from the Initiator and were > limited to a single parameter point to a HW+string that had > at most 100 characters. > > 3. Some programmers used an EX of an MVC with length-1 into a 100 > byte field without checking whether the length exceeded 100 bytes. > > While I would argue that the programs mentioned in 2 and 3 > are broken, correcting all of them would be a lot more work > then simply identifying them. Accordingly, I would like to > throw a suggestion open for discussion that I believe will > address the various issues that have been raised. > > 1. Provide something in the SWA that allows the C/I to pass a large > PARM string to the Initiator. > > 2. Include a table in the C/I containing PARM size limits indexed by > program name. > > 3. Provide for installation extensions and 3rd party extensions to > the table, preferably driven by PARMLIB. > > 4. Provide a default of 32 KiB - 1or 64 KiB - 1for programs not in > the table, with a facility for the installation to provide a > smaller default limit. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
