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