Re: Y2K Testing - Budget infinite time for more testing

I do not have a question in here, just some observations

At Central Industries there is a common viewpoint which I think is flawed:  
Fix the software & data so that it is Y2K compliant, test test test, find all 
the problems, fix them, test verify satisfactory, and now we are done.  Aside 
from issues of hardware & supply chain, bad Y2K data can creep back into a 
Y2K compliant system thanks to a spectrum of users doing different actions 
without realizing all implications, and modifications & 3rd party software 
added to our collection.

BPCS Date Data is stored as numeric, not as OS/400 dates, which we are 
reminded of when trying to do date math in query.  This means that bad dates 
could be entered into our records via a variety of human error & new software 
bugs, after the whole thing was "certified" as Y2K compliant, so periodic 
inspections need to be a continuous process, like cycle counting, and 
financial reconciliation.  Even if our BPCS version has been tested to 
confirm it won't let user key invalid date in some place, we have people 
fixing things via DFU & other tools.  Mistakes are more often made when 
fixing other mistakes, than any other circumstance.

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---