RE: Restrict ability to alter variables in debugger on production

>> If the programmers were working in TEST libraries, the question wouldn't
need to be asked.  Since they are 
>> stepping through a program running over the development library, if they
only have read access then I'm 
>> pretty such the program will crash if it tries to open a file for update.

 
You're right. The program will fail if they try to update production data in
this situation. It does allow them to copy only the files that need to be
updated in the test procedure to a test library in their library list, and
not maintain a complete duplicate test environment. It also allows a fairly
quick analysis of a production problem, since the programmers can get review
the current status of production data and jobs.

The problem definition needs to be redefined. The problem is not "find a
tool that prevents updating data in this condition" . The problem is "how do
we prevent unauthorized, unaudited modifications to production data?" Even
if you stop programmers from changing data using the debugger, how do you
guarantee that they don't change production data with any of the other tools
that are available? 



Steve Morrison
Beacon Insurance
940-720-4672 

-----Original Message-----
From: CWilt@xxxxxxxxxxxx [mailto:CWilt@xxxxxxxxxxxx] 
Sent: Thursday, November 11, 2004 9:15 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Restrict ability to alter variables in debugger on production

Steve,

Don't think that solves the problem.

If the programmers were working in TEST libraries, the question wouldn't
need to be asked.  Since they are stepping through a program running over
the development library, if they only have read access then I'm pretty such
the program will crash if it tries to open a file for update.  

Even if it doesn't, or perhaps they get around it by running the program in
another job, you still have the original problem.  They could change the
output of the program from the debugger by changing variables in the program
while developing it.

I don't think there's an easy way to handle this.  Either the programmers
have access to the production data or they don't.

Charles Wilt
iSeries Systems Administrator / Developer Mitsubishi Electric Automotive
America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: Steve Morrison [mailto:smorrison@xxxxxxxxxxxxx]
> Sent: Thursday, November 11, 2004 9:52 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Restrict ability to alter variables in debugger on 
> production
> 
> 
> >> A customer has asked whether there is an iSeries-usable
> debugger that can
> be used
> >> in such a way that a programmer cannot change the values
> of variables
> while
> >> stepping through a program. 
> 
> Set up the programmers libraries as *TEST libraries. Allow them read 
> only access to the production data libraries. This will prevent them 
> from changing production data. The OS will enforce the security, and 
> there is no need for a special debugger that will not allow a 
> programmer to change data while stepping through the programs.
> 
> 
> Steve Morrison
> Beacon Insurance
> 940-720-4672
> 
> -----Original Message-----
> From: vhamberg@xxxxxxxxxxx [mailto:vhamberg@xxxxxxxxxxx]
> Sent: Wednesday, November 10, 2004 11:09 AM
> To: midrange-l@xxxxxxxxxxxx
> Subject: Restrict ability to alter variables in debugger on production
> 
> A customer has asked whether there is an iSeries-usable debugger that 
> can be used in such a way that a programmer cannot change the values 
> of variables while stepping through a program. Reason for this is SOX.
> They want to avoid
> all the documentation and special approval required to do this.
> 
> I know, programmer's should not even be looking at production data. 
> And they should probably have a set of test data to do this. And 
> trying to get around these requirements sounds like a breach in the 
> first place.
> Nonetheless,
> they are asking.
> 
> Thanks
> Vern
> --
> 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.

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