RE: Restrict ability to alter variables in debugger on production

I haven't found a way to completely (without any exception) keep programmer out 
of production data yet.  However, control can be put in place to 
minimize/discourage this type of activity.  AS400 have enough tools/functions 
that let you force audit/log on what data got changed by a specific programmer 
(probably require some programming though).  If there is a way to log the 
changes, there would be a way to force the programmer to provide evident as why 
he/she needs to change the data.  

However, as far as I know, there is no way to force logging in debugger.  Nope, 
can take this tool away from programmers completely, they needs it to do their 
job.

I've never work for a shop that actually copy production data to test system 
just so that he/she can figure out what cause the production program to error 
out.  Once again your quote about "And as for copying data to a test 
environment taking a long time, well if that is what it take then that is what 
it takes" is probably not practical if you do not provided any  exception.  Who 
is going to tell CIO that the inventory department might not be able to ship 
any good to our customer tomorrow because the "Order Entry - Inventory" 
Interface job errors out and the programmer is now copying data to test system 
to see what cause the problem, which might take 6 to 7 hours.    

  



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Raby, Steve (GE
Advanced Materials, consultant)
Sent: Friday, November 12, 2004 12:57 AM
To: Midrange Systems Technical Discussion
Subject: RE: Restrict ability to alter variables in debugger on
production


All the solutions then point out to the fact that there is no way anyone can 
fix anything in a live environment without impinging on SOX or data protection. 
That to me is an absolute nonsense, SOMEBODY has to be able to look at data, 
SOMEBODY has to be able to fix data. All this generating of test data as 
already pointed out may not be able to recreate the problem. The impression 
that I am getting from most of the replies here is that programmers cannot be 
trusted to look at data, or that they cannot be given the authorisation and 
sign some declaration of none disclosure. This is a pretty sad state of affairs 
in my humble opinion.  And as for copying data to a test environment taking a 
long time, well if that is what it take then that is what it takes, or use one 
of the "unauthorised" methods, the choices are limited! The solution below I 
think would be discounted straight away as it relies on someone bothering to 
put down what they did, not the system recording what they di!
 d. 

Steve