Another vote *against* the DD solution or the new keyword.
What do you do for something like TSO TEST? (ie. TEST (pgm) 'parm data')
If you had a new keyword, I woud expect that it would have to be mutually exclusive with PARM=.
Extending the parm length seems the simplest solution.
I also vote for the full 65535, although 32767 would be fine (and still a heck of a lot of parm data).
DanD ---- Original Message ---- From: "Taddei, Cathy" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Thursday, May 12, 2005 9:35 PM Subject: RE: PARM=
I agree with Gil and Charles. IMO, a DD statement would be pointless. If a programmer wanted to receive a parm via DD, they could have done it already. One of the advantages of PARM= is that you can stick it in a proc, where DD * will not work.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Charles Mills Sent: Thursday, May 12, 2005 6:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM=
I am 100% with Gil on this.
- Yes, let's do it. - Just expand PARM= - No need for new JCL operand - it is a non-fix to a non-problem. - The DD approach is a non-enhancement. You can do that now if that is what you like. - If there is a need to protect programs from overflow, do it with a binder bit - Gil has clearly thought through the non-issue with non-authorized programs - Make it 65535. I don't foresee the need for negative parameter lengths. 65535 is not an impossible number of continuation cards: lots of JCL today is program-generated, and it's no problem for a program.
Perhaps add a JCL message that gave the PARM= character count? Would be modestly useful in general, and would provide a clue for the debugger when PGM=OLDPROG,PARM=101characters blew up.
Charles
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Paul Gilmartin Sent: Thursday, May 12, 2005 3:37 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM=
In a recent note, Peter Relson said:
Date: Thu, 12 May 2005 17:36:08 -0400
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.
As regular readers of this list know, I'm in the contingent (at least a vociferous minority) that consider it a great idea.
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
Yes.
- 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
Why bother.
256One 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 modcharacters in some ways.
What do you think?
I strongly disagree with the followup that says a new keyword (e.g. "PARMX") is needed to force an "overt change to the JCL" when using a longer PARM string. As it stands an "overt change" is required, viz. adding characters to the current short PARM string.
Most of the concerns about buffer overflows, etc. are groundless: nowadays any program can be invoked via ATTACH, CALL, LINK, XCTL macros; from Rexx ATTCHMVS, likely from various other languages with a PARM string >100 characters. No one suffers ill effects.
If protection is necessary, provide an attribute on the load module, set by the Binder, indicating that the program can accept a long PARM. Tolerant legacy programs can simply be relinked to set the attribute; the macros above can test the flag and fail if not set and the PARM exceeds 100 characters. BUt again, why bother.
The one valid buffer overflow concern, IMO, is for APF authorized programs, which can not now be called from unauthorized callers with ATTACH, etc. Extending the PARM in JCL might provide a mechanism for ordinary, unauthorized users to exploit buffer overflows. Perhaps there should be a restriction that only AC=0 programs can be attached by the initiator with PARM>100 characters. Or, if the long PARM attribute is implemented, those AC=1 programs tolerant of long PARMs can be relinked to set the attribute.
The limit should be not 32,767 characters, but 65,535; the number that can be represented in 16 bits. Why waste a bit?
---------------------------------------------------------------------- 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
