RE: Restrict ability to alter variables in debugger on production

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

> Production data is for the most part clean data...

Ha! Have you seen most production data! <G> 

>ugly and full of inconsistencies 

I don't know that I would say "full of inconsistencies" but is should 
definately include boundry data -- that is data that probably will never 
happen, but is technically possible. For example, a negative price (or zero 
price). Or a customer with zero orders, used to test order display --  and also 
a customer with >9999 orders (file with subfiles. <G>)

If thats what you mean by "inconsistencies" great. I think of inconsistencies 
as an order for an item that doesn't exist in the item master. I don't know 
that I want my program to handle that, there are times that I do want a 
function check. Then again, with DRI that shouldn't happen.

-Walden

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx on behalf of John Earl
Sent: Fri 12-Nov-04 5:00 PM
To: Midrange Systems Technical Discussion
Subject: RE: Restrict ability to alter variables in debugger on production
 
Joe,

> One would hope that the auditors have enough common sense
> to realize
> that sometimes a bug only appears under specific data
> circumstances, and
> that a bug in production may not be able to be reproduced
> in test
> without the actual data.

That's one way to look at it - and it makes sense, but it misses another
important point (and I'll take my security hat off here - because it's
not a "security" issue)

If all you test with is production data, then you are doing what I like
to call an "endurance" test rather than a "function" test.  Production
data is for the most part clean data, therefore moving large production
files into your test environment will prove that you programs can run
for a long time with clean data.

A real test set of data should be ugly and full of inconsistencies - the
kinds of things that make most programs choke.  That'll will give you a
good sense of how your program will perform in the real world,

IMHO,

jte

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients 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.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
> Sent: Thursday, November 11, 2004 9:15 AM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: Restrict ability to alter variables in
> debugger on production
> 
> > From: Jamie Coles
> >
> > In some industries the use of live data - or copies of
> live data - is
> > theoretically not following the data protection
> legislation.
> 
> One would hope that the auditors have enough common sense
> to realize
> that sometimes a bug only appears under specific data
> circumstances, and
> that a bug in production may not be able to be reproduced
> in test
> without the actual data.
> 
> There needs to be some way to provide temporary access to
> a copy of
> production data in order to determine the existence of a
> bug without
> impinging on security.
> 
> Joe
> 
> --
> 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.