On Thu, 13 May 2010 10:31:39 -0500, Mark Zelden <mzel...@flash.net> wrote:
>Not if you define only 1 profile as GIM.*. I suspect that will suffice for >at least 95% of the shops out there. We've already discussed the >unlikelihood of shops desiring to do something more granular like >giving a certain set of users RECEIVE only (even though it could be done). > >Mark I say 'potato', you say 'potatoe'. :) I see your point, but I'm still defining discrete profiles here, and we are a small shop. Only two sysprogs with one working manager. We have a few scheduled jobs that kick off that do SMP/E work, like REPORT and RECEIVE. I guess my fear is of someone getting SURROGAT to that ID and could wreak havoc, which of course, is unlikely, but possible. So that ID only gets those attributes. <rant> All this said - what is the point of putting a restriction on SET? I mean, if you can SET to any zone you want, what is the point of it? I can see where you could put it down to the GLOBAL level for just RECEIVE's and such, and I also realize the managing nightmare of maintaining a profile for all of your zones[1], but do you not have to pretty much do a SET to do *anything* in SMP/E? [1] I realize that you could also put a generic profile of GIM.COMMAND.SET.*, if that capability was included. </rant off> ---------------------------------------------------------------------- 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
