Subject: Re: Data Ageing: PC/Client-Server databases
Date: Tue, 01 Dec 1998 00:01:08 -0500
I will take a stab at clearing up your confusion with a simple example.
Suppose you have a spreadsheet that tracks how much leave you have accumulated. Suppose
you started work six months ago (June 1, 1998) and have not taken any leave yet. The
spreadsheet works by subtracting the date you started working for origin-it from today's
date and multiplies the difference by 80/365.25, then subtracts the total amount of leave
you had already taken. As of December 1, 1998 you had accumulated 40 hours of leave.
You have just remediated your spreadsheet and want to test it for compliance. If you
merely change the system date by 1 year, you can not directly compare your output from the
program without intimate knowledge of what the spreadsheet does. If you only change the
system date by 1 year, it would tell you that you had accumulated 80 hours of leave.
Since 40 is not the same number as 80, it is hard to compare the numbers.
Now, if you age the data by 1 year, this is what it means. You add a "constant"
amount to "every" "date" in the spreadsheet.
The spreadsheet says that you started June 1, 1999 and the current date is December 1,
1999. It still calculates that in the six months you have been employed, you have
accumulated 40 hours. Since the non date values all match (in this case, the 40 hours),
the spreadsheet worked for the date it was aged to.
That aging didn't really prove very much because it is still doing work in the 19xx date
range. If you age it by 18 months instead of 1 year, the spreadsheet would believe you
started work on December 1, 1999 and the current date is June 1, 2000. Still, it would
calculate that you had accumulated 40 hours. This time though, the spreadsheet had to
calculate a difference between dates in two centuries, furthermore, the calculation had to
include leap year day.
It would probably also be wise to calculate a scenario where all the dates fall in the
next century, so age the initial data by 2 years. This would result in the
spreadsheet saying that you started on June 1, 2000 and the current date is December 1,
2000. Still, the spreadsheet would calculate that you accumulated 40 hours.
So, you see, setting the system date is a part of working with aged data, but not all of
it. You also must alter the data itself.
Carrying the example a little farther, there is typically a lot of work setting up a tool
to age the dates. You have to tell the aging tool where each date is in the file, the
format of the date and how to tell one record type from another.
It is generally as hard, if not harder to compare the resulting data, without a very
specific tool. (It is harder because some files - such as report files - may have no easy
way to specify one record type from another.) Most of the tools that do the comparison for
you, mask out the dates and do not compare them at all. (But doing this can miss data that
could point out a hidden Year 2000 problem, such as a leap year problem.)
You must decide if it is worth the effort to age the data for testing this specific
application (it is called "triage" - how important is the application to you
& where would you maximize the return for the time spent). You must decide how many
different system dates are appropriate to age the data to (even in my vary simple example,
I had to age the data at least twice to completely test it.) You must decide if it is
appropriate to age all the dates or just some of them (there are classes of dates that you
would never age). You must decide if you are going to age the data by a constant amount or
by s semantic constant (such as the quantity of work days).
We offer a general comparison tool which compares all date types you specify are in the
file without telling the computer where any specific date is, the format of any specific
date nor how to tell one record type from another.
Subject: Data Ageing: PC/Client-Server databases?
As I understand these tools (and my understanding is very poor), they:
1) insert a "shim" between the OS and the database date calls, so that the
database is operating in 2000 while the hardware is still set to the correct date, 2)
"age" the data in the database. Some also seem to 3) "assist" in
comparing aged and non-aged output, and 4) aid (my cynical reading is hamper) test case
So - what advantage do these tools give over the manual method of setting the clock
forward and fully testing, with a test plan. Feature 1) above seems useless in a PC
environment, given the ubiquitous nature of PCs and PC servers and the ease with which
they can be moved forward in time. 3) and 4) may or may not be useful (experiences
That leaves 2). Why age data? Exactly what does this mean?
Are there tools genuinely useful, or yet another example of trying to apply valid
mainframe methodology to the PC environment, resulting in invalid PC methodology?