I might slightly disagree with removing the SAF and APF requirements. >From a sysprog perspective, I can allow my applications groups access to LIST >functions but NOT REC/APP/ACC. This is beneficial. I do not mind if they >want to look, I just do not want them to touch. In fact I would encourage >them or anyone to be able to research fixes.
I do not want them to be able to rec/app/acc fixes on my zones. If a shop wants to make it open, then just make UACC on the facilities open. And as for APF. It is another protection in the system. Since an APF authorized library can control to some extent the ability to modify some storage areas, I think this is also fine. Some of the functions in SMP/E could be dangerous if allowed to run amuck. Now if Kurt Q. would chime in, it would be helpful. But from my perspective, I am happy with how things have become. I was not a supporter of the new facility classes, but now I am. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf > Of Ed Jaffe > Sent: Wednesday, July 24, 2013 8:00 AM > To: [email protected] > Subject: Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) > > On 7/23/2013 5:21 PM, Paul Gilmartin wrote: > > On Tue, 23 Jul 2013 17:58:16 -0600, Roger Bolan wrote: > > > >> Application programmers should be able to use SMP/E. > > [snip] > > > A voice of reason. And it was safe, or at least believed to be safe, > > until IO11698/IO12263. > > This would make a good SHARE requirement. The goal should be to remove APF > authorization from SMP/E and, at the same time, remove the SAF checking that > was > recently introduced to limit who could use SMP/E. > > Originally, SMP/E required authorization only because IEBCOPY required it. > Now that > IEBCOPY no longer requires authorization (as of z/OS 1.13), it would seem > easy to > remove the AC(1) binder attribute from SMP/E. > Right? No so fast! It's entirely possible that additional features were added > to SMP/E > over the years that work only because it's APF authorized. If so, those > features will > need to be identified and additional development will be required to find a > way to > provide similar function from unauthorized SMP/E. > > Clearly, someone at IBM needs to work on this. SMP/E should go back to being > a utility > that anyone can use--just just a privileged few. > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
