Re: Y2K Testing --- What Dates

[MacWheel99@xxxxxxx]

Media speculation about this day or that date in which the arguements seem 
rather far-fetched --- it might be smart to test some of those stupid dates 
anyway just to assure people that story does not apply to us.
When no date info is known - what value should be used for NULL?  What 
value(s) have people been using?
Should date field ever be used for something that is not a date?
How does our backup system handle tape retention expiration?  Especially PC 
backup systems.
Effectivity or expiration dates in which nothing actually will expire - key 
what in there?  e.g. Bill of Materials, Blanket Orders we don't want closure 
on, Special Pricing.
Which programs will be running at critical points - Dec-99 to Jan-00 
roll-over, leap year 2000, PC problematic dates?  Which programs calculate 
dates into the future or past?
What connections do we have to the outside world that feeds in data that our 
system then processes, with the implied assumption that the imported data is 
not corrupt?  EDI e-commerce fax scan direct-modem engineering-changes, 
orders & requirement changes, advanced ship notice, financial transactions, 
shipping info.
What mechanism tells disk drive that files or records are deleted & Ok to 
write over the top of, particularly on PCs?
BPCS has date math ALL OVER THE PLACE - key in mm-dd-yy & it is translated to 
yyyy-mm-dd for processing & might not neccessarily use the same shared 
subroutines consistently every time, so a flaw could be anywhere.
It would be smart to take an inventory of all instances where any corporate 
staff thinks it is Ok for a date field to be containing a bogus date, have 
some rule of thumb on what should be there, and communicate a common 
consensus.
What is NOT mission critical?  So what if the date math is off by a few days 
& we pay our bills a few days late, or order materials with insufficient lead 
time - that's what safety stock is for.  It may be more important that the 
software executes without a bomb, than every little error is eliminated.  
Triage what we cannot live without being precisely date accurate.

1999-2000 date range selection criteria - make sure that when we input yy-yy 
in BPCS, & any other software that we have, it always translates to ccyy-ccyy 
for internal processing - have valid test data so that SOMETHING should be 
selected in all instances, and verify this is in fact the case for every 
conceivable selection range that uses date input.

02/29/1999 Test for invalid leap year & some other test dates we have passed 
- in our case successful, but some places have not been so fortunate.

04/10/1999 - 99th day of the 99th year - PC backup retention
09/09/1999 - retention date in tables & backups

There is a date in the fall of 1999 - I forget which exactly, in which the 
Global Positioning Satelite resets its number system at zero - ground station 
units are supposed to also reset in sync, but many manufacturers allegedly 
did not read the GPS manual.

12/15/1999 - everything normal - 10 15 30 day ranges correct math for future 
dates
12/30/1999 - accepted as date & not indicator with special meaning
12/31/1999 - accepted as date & not indicator with special meaning
12/31/1999 - 23 hr 45 min - monitor behavior of screens & transactions to 
verify dates calculated & displayed properly around the century boundary - 
nothing shows up as 1900
01/14/2000 - everything normal - 10 15 30 day ranges correct math for back 
dated calculations
02/29/2000 make sure all software recognizes this as a valid date
03/01/2000 make sure date calculations not off by one day
02/29/2001 Test for invalid leap year
02/29/2004 Second leap year of new century
01/01/2021 Apple Macintosh artificial boundary
12/31/2027 PCs with 16 bit architecture vs. 2028 roll-over

Whatever your fiscal calendar is - include an end of week, month, quarter, 
year in 2000 & beyond

If anything goes wrong where expectations were a smooth test, it might be 
smart to add more dates to the testing targets.

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