On Tue, 22 Sep 2009 23:52:06 +0300, Binyamin Dissen wrote: > >:>I believe I stated pretty clearly above that I'd expect PARMX >:>to replace the first PARM, not be added as a second. > >That violates compatibility. > No, it preserves and extends compatibility. There are numerous programs extant that now accept and meaningfully process a first PARM longer than 100 characters when invoked from another program. Simply, this facility should be extended to JCL.
And passing a second, third, or fourth PARM to a program which expects fewer will break any program that loops over the parameter pointers until it finds one with the VL bit set, but might overrun a buffer if an unexpected number of PARMs exist. >Because subroutines do not have a documented API. A program expecting a >specific API, such as a jobstep APF program, cannot be provided with data >which may cause an overlay or an integrity failure. > >And should you argue that they can be invoked as a subroutine with a long >parm, that is not an exposure as not being invoked via JCL they will not be >APF. > ??? Are you saying that only JCL and not another program can invoke a program in the authorized state? I will, somewhat reluctantly, suggest PARMX as a remedy here: make a rule that if PARMX is specified, the program will be invoked in the unauthorized state (but I'd like to see this as an installation option, "AllowLongParmAuth", much as UserKeyCSA, another dangerous option is nowadays.) And I've suggested long ago that "accepts long PARM" might be a load module attribute, verified by the initiator, which could be changed merely by relinking; no recompilation necessary. But I consider this highly phobic: no one has yet evinced an existing program, not intentionally written as a refutation, that behaves in a dangerous or mysterious fashion simply because it was invoked with a long PARM. Howard Brazee is right: you can't eternally support antiquated restrictions because relaxing them might provide unexpected input to some programs. Should DASD block size have been capped at 12K because that was at one time a physical limitation and some programs might have static buffers of that size? -- gil ---------------------------------------------------------------------- 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
