RE: Y2K testing -- BPCS-L

Well,
here's a few opinions:
To fully test an environment for Y2K compliance,
you have to change the system date. Just testing to verify that programs
still run, hopefully the same as before any Y2K fix, isn't a complete
test.

Changing the date on a production box borders on insanity and should
only be
done with a SAVSTG, and plenty of time to put everything back together.

Temporary licenses are great, just keep in mind that they generally
expire
based on the passage of time. Moving the date ahead will expire most
temporary licenses including the ones I got from SSA. SSA will gladly
generate a new temp for you, but to apply it you need to set to system
date
to the same date it was generated. If you then move the date too far
ahead....
Can you say Catch 22.

Moving the date around will give you a chance to deal with things you
would never
normally have a chance to see. Some of this can be less than fun. But,
until
you do some work during December 1999 and enter a forecast for dates in
2000,
and then roll into January 2000 and look up GL and Inventory
transactions
posted in 1999, and all the other assorted transaction and processing,
you cannot be sure your system will keep working.

One of the big issues, out of many, about moving to a Y2K ready version
of
BPCS (or any app) is the cut over. Assuming that date fields were
expanded,
then data expansion will need to be done. Don't forget to test and
verify this
step, and account for the time needed as part of the cut over.


Hey,
that's my cent and a half worth.
 -steve cotes
 -cotess@data-io.com

> ----------
> From:         Lisa Abney[SMTP:abney@iquest.net]
> Sent:         Monday, July 13, 1998 6:09 PM
> To:   BPCS-L@midrange.com
> Subject:      Re: Y2K testing
> 
> We're just now in the process of moving everything from our production
> box to a
> development box for Y2K testing.  We, too, were concerned about
> licenses, but
> found that vendors (including SSA!) were most co-operative in giving
> us a
> temporary license on the development box.  We are using a third party
> product
> with 4.0.5, rather than 4.0.5CD, and plan on changing the system date
> as a
> final test.  We've heard everything from "What's the big deal?" to
> "Don't
> change the system date even on a development box ... period!"  Anybody
> who's
> done it have an opinion?
> 
> Sue Underwood wrote:
> 
> > Hello all...
> >
> > We are looking for a way to test our Y2K converted applications
> (4.05CD) by
> > changing the system date and then performing a "real-time" systems
> test.
> > We have a separate AS/400 (V3R7) for development and will not affect
> our
> > production systems.  What types of problems can we expect in
> relation to
> > the operating system, licenses, other products, etc.?   If you don't
> plan
> > to change the system date, then how do you plan to get a 'real-time'
> test?
> > Any and all responses will be appreciated.
> >
> > TIA
> >
> 
+---
| 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
+---