Well, without giving it much thought, would placing an unprintable character, say high or low values, in the first byte of the PARM value to indicate that the PARM was an XPARM, or PARMX, value work? Change the CI to support it and only programs that know how to handle the extended PARM would understand the meaning of the value.
Not that it matters to anyone... Back in the 80's I solved this problem by taking an idea from a PC program/utility. When passing a parm to the utility, if a value was prepended with an asterisk, @, that parm value was the name of a file which contained the actual parms. In everything 390 I've written since then, if the first character of the parm contains an asterisk followed by an alphabetic character, the rest of the parm, up to 8 characters, is assumed to be the name of a DD statement that contains the actual parameters being passed to the program. Without breaking my arm... I extended the concept by using semicolon's as parameter delimiters so any asterisk after a semicolon could be considered the name of a DD statement. Taken to the extreme, this allows at least 10 dynamic DD statements to be passed as parameters. I know, I know, the same thing could be accomplished with symbolic parameters, or JCL overrides, pointing to various datasets. This solution solved a problem and was expanded over time. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Thursday, May 12, 2005 5:36 PM To: [email protected] Subject: PARM= We all know and love (well, at least know) that the limitation in JCL for PARM= is 100 total characters. We are thinking (again) about expanding this, and would like to hear your thoughts. Some of the possibilities include - just extending, in JCL processing, so that the target routine gets what it does today (halfword length followed by string, only the string would potentially be >100). This is obviously the nicest from the target routine's perspective if it can handle the extended length - a service that the target routine can call to "give me my parameters". Obviously the target routine would have to change in order to utilize that service, and likely would have to dual-path for systems that do not have the service One choice that proved not feasible was using a second parameter. Various utilities already take advantage of the "known" structure and pass additional data as additional parameters. Some of the potential problems an existing target routine might have with an extended length parameter are - It provided an area via DS of 100 characters, "knowing" that the limit was 100, and then did an EX (execute) of an MVC to move the parameter string, using the length in the halfword. Unfortunately, if the length is (for example), 256, this would overlay the next 156 bytes - It did some operation (MVC, TRT, whatever) that is limited to 256 characters which works fine when the limit is 100, but if the routine was passed 257 characters of data, it might process that as 257 mod 256 characters in some ways. What do you think? Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 5/12/2005 ---------------------------------------------------------------------- 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
