RE: Justification for modifications?

["DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>]

Ron, perhaps a trigger program could validate your data before writing the 
order to DASD.  In this case, it wouldn't necessarily need to throw and 
application exception, but it could simply log the exception and send a report 
daily/weekly to a supervisor who could track the errors and initiate 
remediation.

All in all, simply notifying someone of these potential errors can be VERY 
effective in getting these problems corrected.  At the least, the employee can 
be objectively measured during their annual performance review.

Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Ron Adams
Sent: Friday, March 02, 2007 1:54 PM
To: Midrange Systems Technical Discussion
Subject: Re: Justification for modifications?


Interesting info John. I'll have to look more into that so I do combat with
our CFO and auditors on the whole testing/signoff of all the groups thing.

As far as validation goes, it's a purchased ERP that's more than 12 years
old. We own most of the code, but another issue here is a mandate not to do
any further modification of the system unless it's considered critical or
business impacting. The plan is to be off this system within 18 months.

But, then I have to ask the question, if I should choose to modify it and
validate a quantity entered, what's the best approach to doing so? Are
others validating quantity fields? If so, how?  I would think the best
approach would be to check the value entered if greater than a set value
like maybe 10,000 or some other arbitrary number, then query the user "Are
you sure?", or simply restrict a single line from exceeding that number.
Otherwise, how do you tell the difference between a date of  030207 and a
quantity of 30207?