Paturi,

In reading your query, it is my understanding that you have two environments
in which you are performing your Y2K testing.  That's a good start and
should make testing easier!!  My understanding of how you are using these
environments follows.

The first environment is used for 'base-line' testing using 'current' data
(data without post 2000 dates).  This environment is used to establish
base-line test results produced by your current (unremediated) code which
are then to be compared to the results produced by the remediated code under
different time testing scenarios.  I would assume that once you have
established the initial 'base-line' results, you then execute the Y2K
remediated code in this same environment to prove that the remediated code
functions properly with 'current' data.  Comparing the results of these two
executions should verify this and that the Y2K changes did not adversely
affect the application results if moved into production today.

(Please note that this base-line testing assumes that you do NOT have any
post 2000 dates in this initial environment, as this will most likely cause
differences in the test results produced during your regression testing.)

The second environment is used for 'future' testing.  This environment is
used to 'prove' that the remediated code functions properly once its starts
to encounter post 2000 dates.  In this environment, you will only be running
the remediated code and would like to produce results which can again be
easily compared to your base-line test results.

Your question is 'How?'

To do this, two things need to be performed.  First, you need to move your
system clock ahead by some defined time frame.  (Let's use 2 years for this
example.)  This can be performed manually by actually resetting the clock on
your HP3000, or virtually by using a clock simulation tool such as HourGlass
2000 by Allegro, TimeMachine by Solution Soft, and Time Warp 3000 by SMGA.
(I would not recommend the manual approach since this change becomes a
system-wide change and will impact everyone else on the system.  It may also
cause third-party software to expire since the system date has gone past the
license expiration date - assuming this software is Y2K compliant when
dealing with expiration dates! - and you may not be able to re-activate the
software once you set the clock back to today.)  Second, you will need to
age your data by this same time frame by which you have changed your system
clock.  (Again, for this example 2 years.)  This can be done by using an
aging tool such as Time Shift 2000 by G.R. Helm.  (<<begin plug>> Both
HourGlass and Time Shift can be obtained from Orbit Software at
www.orbitsw.com <<end plug>>)  Once you have completed both these steps,
rerun your test (make sure any user inputs are also advanced by two years)
and if the software has been remediated properly, you should find that the
results will match that of your base-line, with the exception of the actual
'date values' dispersed throughout your results.  (i.e. in your case, the
number of records selected should be the same.)

You should also perform multiple tests in this 'future' environment to
verify that the software function properly with multiple combinations of Y2K
data.  For example, with the system clock pre-2000, but the data post-2000,
as data and/or the clock is rolled from one century to the next, with a
post-2000 system clock using pre-2000 data, and other combinations which may
be specific to the application or your business rules - and don't forget
leap year tests also.

I hope this helps!  Let me know if you have any additional questions.

Regards,
Gordon Helm
----------------------------------------------------------------------------
----
==============================================
G. R. Helm Information Srvcs, Inc.       Year 2000 Consulting
4993 Golden Foothill Pkwy, Suite 8       HP 3000 Specialists
El Dorado Hills, CA  95762                            (888) 999-7432
[log in to unmask]                         www.grhelm.com
Designers of TimeShift 2000™              Date Analysis/Aging
----------------------------------------------------------------------------
----


Date:   Sat, 26 Sep 1998 14:42:02 +0530
From:   Rambabu Paturi <[log in to unmask]>
Subject:        Y2k testing of Jobs

Hi All,


Can any one help us to test a job in power house.
In some jobs QTP,SUP and cobol programs are there and these are updating the
databases.
we are doing testing  by comparing the records selected and records
processed in both the test areas. In one area the unremediated code will be
there(which includes databases and all).The second test area the remediated
code will be there(which include remediated data bases and all) Due to the
updation of data bases and files ,records selection is not consistence with
original code.
How can avoid this, is there any way to rectify it.Or otherwise  there is
any other way to test these jobs for Y2k .

Thanks.
Paturi