Many years ago, my first APF authorized program was to solve the normal vs. the abnormal DISP problem for utility programs that trap and prevent abends. At the time I was too green to realize that there were many public domain solutions readily available (via tape, there was no Internet, yet), so I carefully crafted my own solution. My program could invoke either an APF authorized utility/program or a non-authorized one. I was careful to ensure that a non-authorized program could not alter my program or any of my storage, etc. One of my first assumptions was assume the PARM length field could be 0 to 2^16-1. While JCL and TSO CALL had a 100 character limit, it simply did not feel right to assume or depend on that artificial limit. IBM could have expanded that limit without changing the basic structure of the parameter. Also, other programs/interfaces could invoke my program and they might pass me more than 100 characters. I never dreamed that anyone would consider depending on the 100 character limit and would have argued that it should be an APARable situation. Of course, my opinion plus a buck wouldn't get me a good cup of coffee.
Therefore, I think IBM solution to allow longer parms to JCL (or TSO CALL) invoked programs is reasonable. When user/vendor written programs/exits invoke other APF authorized programs, those users/authors are the ones who should responsible to ensure system integrity is maintained. Don > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Shmuel Metz (Seymour J.) > Sent: Wednesday, April 03, 2013 9:14 PM > To: [email protected] > Subject: Re: 32760? (was: PARMDD?) > > In <[email protected]>, on > 04/03/2013 > at 07:29 AM, Paul Gilmartin <[email protected]> said: > > >It leaves a couple holes > > Not really. > > >o Jobstep program is AC(1), from an authorized library, so > > the environment was authorized. > > Then that program is responsible for not creating any security > exposures. > > >o Jobstep program ATTACHEs a subprogram AC(0), from an > > authorized library, bound with NOLONGPARM, passing an > > argument longer than 100 bytes. > > Is that program written to work properly with that parameter? If not, > then the AC(1) program has an integrity violation for calling it. > > >Or: > >o JCL specifies "EXEC PGM=jobstep program,PARMDD=ddn" > >o Jobstep program is AC=1, from an authorized library, no > > LONGPARM attribute. > >o The PARM resolved from ddn is no longer than 100 bytes. > >o Is this permissible? I would actually hope not: > > - there's a lower potential astonishment factor if the > > restriction applies to any such use of PARMDD, > > I would consider that to be a bug and at best to be more surprising > than only testing the length. There's nothing in the string "LONGPARM" > to suggest that it applies to short parm data. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > Atid/2 <http://patriot.net/~shmuel> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
