RE: Ideas for debugging production w/o authorisation

On Thursday, July 09, 1998 9:43 PM, PaulMmn [SMTP:PaulMmn@ix.netcom.com] 
wrote:

<regarding lack of authority to look at production data during debugging>

> Programmers SHOULD NOT be able to do much to a production data base.  I
> feel they should be able to read production files (with proper controls
> over sensitive data like Payroll).  They should NOT be able to update
> production files using programmers' tricks or DBU.
>
> If a programmer has any access to a production data base, it should be
> via
> a *USER profile, just like every other user.  This does limit
> programmers'
> playing to using the proper menus and interfaces and controls built into
> the production system, but it's never a good idea to let programmers run
> things that they can program loopholes in.
>
> How -should- testing be handled?  Ideally, you should have a complete
> copy
> of the production environment on a test machine so that -you- can run
> the
> programs, watch yourself do things, and never, Never, NEVER risk damage
> to
> the production data base!
>
> Do you -really- want a user running a program that needs fixing?

I agree with Paul.  Unfortunately, most of us are used to the programmers 
having *ALLOBJ authority...  When push comes to shove and you already have 
a broken program in production and you absolutely can't create a duplicate 
test environment (some of us have hard coded OVRDBF's for security 
purposes!) then you have a few possibilities:

1. Ask management for a new user profile that has proper authority.  They 
will delete it when you're done.  This leaves your existing authorities 
unchanged, but gives the temporary access you need.
2. Ask management to grant debugging authority to the user.  Have her sign 
on and you debug under her data authorities.
3. Put "debugging code" in the offending program to actually print out the 
things you suspect are in error.  This requires no security changes, but 
is a real pain in the drain when you have to make a few dozen passes to 
find the problem.

None of these are as good as creating a test environment...

Buck Calabro
Commsoft, Albany, NY
mailto:mcalabro@commsoft.net

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---