On Tue, 22 Sep 2009 16:30:18 -0500 Paul Gilmartin <[email protected]> wrote:
:>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. As the old program only expects 100 bytes, providing more can create an incompatibility - such as using the length to move the data to a 100 byte fi4eld. If the data is now longer, an overlay can occur. Programs that can accept longer values cannot be invoked with longer values in JCL, thus no compatibility issue with them - at all. :>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. If you have such a program that looks for the last N parameters it may be an issue. Such a parameter list is not documented for JCL thus this is moot. :>>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? Only another APF program, which should know what it is doing. :>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. So you would suggest that the C/I check the module attributes? Or have an ABEND instead of a JCL error? :>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. All it needs is one case. :>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? No problem, since their CCWs are built for that. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
