RE: Restrict ability to alter variables in debugger on production

Lim,

We have a product I believe will suit your needs, but I don't want to
give a sales presentation here.  If you are interested contact me
offline.

Gary Monnier | Senior Software Developer

19426 68th Ave. S
Kent, WA 98032
(253) 872-7788 ext. 308
gary.monnier@xxxxxxxxxxxxx
www.powertech.com 
This email message and any attachments are intended only for the use of
the intended recipient named above and may contain information that is
privileged and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message or by telephone and delete the
message from your email system. Thank you.




-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Friday, November 12, 2004 7:55 AM
To: Midrange Systems Technical Discussion
Subject: 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

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