Re: System administration without production data access? -- MIDRANGE-L

Hi Rob

as always you have a opinion (which can only be a good thing) :)

I've heard of a few shops having this "emergency" user profile available
for their developers.  One of our people went to a user group meeting in
which Charlie Massoglia suggested the same thing, and this person wanted
it here.  When I asked him when was the last time he was working off hours
and needed this, (and he 'was' here for years), he couldn't think of a
time.  There are several problems with this concept:
1)  'Most' times you are trying to solve a problem that doesn't exist.

Agreed. *ALLOBJ is the programmers safety blanket :)

2)  Once they have access to it, they'll find all sorts of reasons to use
it, versus fixing their problems the right way.  For example some of the
developers are upset that they can't look at one joblog.  My suggestion,
fix it so that it doesn't have to run under a user profile with *ALLOBJ,
and your problem will be solved.  Hasn't happened yet.

Well... this only happens if you let it. I provided this facility at one place I was at so that management knew there was a way the programmers could get the access if they need it at the level they claimed to need it. The deal was that the on-call programmer rang Ops support who ran a job to enable the profile (the profile was also disabled each day by a schedule entry for when support arrived back at the office). I only ever got rung once and eventually deleted the profile accidentally during a clean up :) I didn't put it back when I noticed as the loudest complainer had gone and everyone else had forgotten and were merrily working away without *ALLOBJ.

Another place I worked at made the programmers that used the profile fill out a form and get it signed by their manager and the applications user representative. This was a strong discourager for unneeded use. The manager was also asked about the level of use on a monthly basis. Overkill maybe but effective. Especially in this shop where it did legitimately get used regularly because they had a number of apps (home grown and vendor supplied) and very little time for delay in a support situation

With reference to the job log scenario I built a tool to let one group of programmer see a jobs job log without obtaining job control; again this was shown to be a smokescreen in terms of the amount of use it got, but it did knock over a concern and did actually get used and help the support effort. And I got to introduce one of the programmers to the joy of API's.

3)  Some of our developers already have multiple id's on our development
machine.  Once they have one with *ALLOBJ they tend to use that profile
for everything except for rare occasions versus the other way around.

I was talking about production environments - development environments are a different kettle of fish. I try and discourage it but if the application development manager won't and will go into bat for his staff to use it I don't waste my breath fighting it directly. A good adopted authority scheme combined with a disciplined approach to object ownership and library management ensures that production is insulated from the usual errors created by QSECOFR use in development. When the developers keep encountering problems deleting or managing objects created by Fred or his programs always fail in testing fails due to authority issues then eventually I have seen nature take its course.

I told you it was one of my favourite subjects :)

Regards
Evan Harris

Rob Berendt