RE: Giving *SERVICE special authority to developers on production machine

This is not a vendor plug. Nor is there payment involved so let me just say...

You need AUTHORITY BROKER!

One more time...

You need AUTHORITY BROKER!

:)

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Wednesday, September 25, 2013 10:58 AM
To: Midrange Systems Technical Discussion
Subject: Re: Giving *SERVICE special authority to developers on production machine

Funny, I am just looking at this here - where we have only *USE authority to programs at production level on our development LPAR.
Anything we create in our development libraries, no problem.

So I looked up *SERVICE special authority - it's not needed for STRSRVJOB that I can tell - the requirement there is that you have *USE to the user profile of the job user.

*SERVICE lets you use STRSST and do some traces. And it lets you debug programs without needing *CHANGE authority to the programs.

Taking access to STRSST away is not hard, and the InfoCenter article says that traces can be authorizes using function usage commands. You don't need *ALLOBJ, which was mentioned there.

So that's all I know right now - hope it makes sense.

Vern

On 9/25/2013 8:47 AM, rob@xxxxxxxxx wrote:

I understand the general concept of not giving developers access to
*SERVICE special authority on a production machine. That is, they
could use the graphical debugger (which uses STRSRVJOB under the
covers) to debug a production program, change a running variable, and
monkey around with data ( eval netpay=999999.99). Knowing this, is
there other reasons not to give them *SERVICE authority? Like, "I
read how to stop/start parity protection and wanted to try stopping it
to see if it improved performance"?

We already do not give them *ALLOBJ. One, for security reasons. Two,
stops some of the "gee, it works for me". The latter was serious egg
on the face when our BOFH used to be a developer and turned over our
first
AS/400 based accounting system to the masses.


Rob Berendt

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.