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

Reply via email to