• Subject: RE: Y2K testing
  • From: "Hillock, Chris" <CHillock@xxxxxxxxxxxx>
  • Date: Fri, 10 Jul 1998 17:58:43 -0700

Changing the interactive session job date and the job description job
date is a good start.  But it is not enough.  To be sure that every time
program works properly when it requests the system date, you need to
either change the actual system date, or use a date simulation tool.  If
you change the actual system date, I wouldn't recommend it be on a
production system.  It's possible for some people to do it on like a
weekend day, but you can't be sure what adverse effect that will have on
software security codes for example.  Most permanent keys are serial
number sensitive, while temporary codes are date sensitive, but one
never can be sure.  And who wants to work on weekends from now until
1/1/2000?  You can do it on a development machine where you don't have
to worry about users, but the security codes issue still exists.

My suggestion is to get a date simulation tool that will allow you to
simulate the system date without effecting other users on the system.
There are several tools out on the market that will do this for you.  We
have worked with one called SIMDATE, which will allow you to simulate
any absolute date (i.e. 01012000) or relative date (i.e. + 30 days,
etc.) by user session for either interactive or batch jobs.  So you can
have as many AS/400 sessions running on your PC as you want, all
simulating different dates, without affecting other users.  You can
actually download a free 30 day trial of it from their website
(www.simdate.com).

The other thing to keep in mind is, and most people don't think about
it, is the data.  You really need to age it also if you are going to do
a proper test.  If you just set the system date forward, or simulate it,
your data is potentially years old and very out of date.  Think about
your financial data.  Your AR agings will probably show everyone in the
over 120 days category.  Not good.  To do it right you need to backup
the data, age it, set the date forward, test it, then restore the
original data.  Then repeat the process several times for several
different dates.  Again, I think there are several tools out there that
can help do this.

Hope this helps.

>-----Original Message-----
>From:  MikeB60046@aol.com [SMTP:MikeB60046@aol.com]
>Sent:  Friday, July 10, 1998 4:37 PM
>To:    BPCS-L@midrange.com
>Subject:       Re: Y2K testing
>
>you can change the user job date for interactive sessions and the job
>description job date for batch jobs (in a test library). this will change the
>date for you without impacting production systems. 
>+---
>| 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
>+---
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.