× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Ideas for debugging production w/o authorisation
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Fri, 10 Jul 1998 08:32:51 -0400
  • Organization: commsoft

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.