Authorized programs should be written to a higher standard. Above and beyond normal error checking, they should be written to prevent intentional abuse. That is the standard IBM uses when they accept APARs on their authorized programs. A malicious user can be expected to attempt to use any and all unintended means to invoke an authorized program. JCL is not the only way to invoke an authorized program. There are other means to invoke an authorized program which pass more than 100 characters. Authorized programs should already be protecting themselves from any problems which could be caused by long parameters. PARMX passing more than 100 characters would not be a new risk, although arguably easier than other methods. Regardless, if an authorized program is discovered to behave in a destructive manner when passed more than 100 characters, then you are already at risk and it should be corrected. That is what IBM does. That is what everybody should do. If you feel that PARMX would be increase the risks in your environment, then it could be controlled with the SAF (RACF, etc.) protection addendum.
1. Is there a significant number of frequently used authorized programs known to have highly undesirable consequences? I don't think so. 2. Is it likely that the PARMX proposal would have undesirable dire consequences? I don't think so. 3. Does simply making it easier to pass more than 100 characters to an authorized program, justify canning the PARMX proposal? I believe the benefits far outweigh the risks. Don Williams -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: Tuesday, November 03, 2009 5:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: An Alternative Modest PARM Proposal On Tue, Nov 3, 2009 at 1:36 PM, Shmuel Metz (Seymour J.) < shmuel+ibm-m...@patriot.net <shmuel%2bibm-m...@patriot.net>> wrote: > In <6fh0f55c4lt4scbntma0r9udums736r...@4ax.com>, on 11/03/2009 > at 05:06 PM, Binyamin Dissen <bdis...@dissensoftware.com> said: > > >The API is defined as 100 byte maximum > > There is no such formal API. The limitations of the R/I and C/I were just > that, limitations. They were never a contract to the programmer. Au contraire. The 100 character limit has been documented since the beginning of time. An unknowably large number of programmers wrote an unknowably large number of (arguably incorrect) batch job step programs that functioned correctly ONLY because they were guaranteed never to get more than 100 bytes of parameter data from the initiator. You can play verbal semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We can all agree it was a bad idea and that wiser programmers might have properly dealt with the interface even then, but so what? All of those bad programs will, for better or worse, continue to run safely because the behavior of the initiator is not going to change. > >New programs wishing to use a > >larger plist can be coded to use a new way to get to the data. > > If it were only a case of new programs then I would agree that the > existing format is obsolete. However, existing programs, including those > from IBM, support the existing interface for parms longer than 100. > <http://bama.ua.edu/archives/ibm-main.html> > No Shmuel, that's where you have it precisely backwards. SOME existing programs can/do correctly interpret the existing interface when called with a longer parm string by a program other than the initiator. An unknowably large number don't behave that way and giving a JCL programmer a means (even accidentally) to pass longer parameter data to those existing programs through the existing interface is just begging for trouble, which is why it won't happen. Dressing the proposal up with a cheat-sheet approach where the initiator can consult a secret decoder ring to decide whether the long parameter string is allowed or not is (frankly) kinda nutty. It presents loads more mechanism and complexity for the OS and creates a maintenance problem with no guarantees of avoiding a 3AM collision with an otherwise valid program whose interface needs have not yet been documented. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- 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
