|
Chicago-Soft
ATTN: TSO Times
One Maple Street
Hanover, NH 03755
(603) 643-4002
information
@tsotimes.com
|
|
Data-Aging Tools: Key Evaluation
Criteria
By Jeff Furman
The magnitude and urgency of the Year/2000 problem has changed the requirements
for data aging. Until now, we've gotten by aging test files manually.
We've advanced plenty of dates to test event horizons such as month-end
or year-end and to process changes such as trade date plus 3. We've always
been able to handle these tests using our editors and utilities or by
coding quick-and-dirty CLISTS, EXECS, and COBOL programs and running them
against our data.
New Testing Requirements
Today, a typical mid-size shop uses thousands of files for testing
application changes. These files hold millions of records, each with
several date
fields. Even on the same record, these dates are often different because
they contain different customer information: trade dates, settlement
dates,
birth dates, purchase dates, sell dates, claim dates, expiration dates,
hire dates, anniversary dates, maturity dates and many more that are
unique
to each business. You cannot change dates hastily with a "CHANGE ALL" command.
For accurate testing, when you move dates into the future, you want
to make sure they all land on valid business days, not weekends or
holidays. Often, relationships between dates (e.g., hire dates and
anniversary dates) must be kept intact.
And there are more date formats than one might imagine when contemplating
the permutations of CC, YY, MM, DD and DDD. They can:
-
Be Gregorian or Julian
-
The
century can be literal, like "19" or "20", or symbolic like "0" or "1" for
the 20th or 21st.
-
Have no century, or a one-byte
century or a two-byte century
-
Be exotic (e.g., 9s complement
or Lilian date)
-
Be all-numeric or have
the month spelled out fully or abbreviated.
Moreover, date fields can be packed, binary, or display signed or unsigned,
and stand-alone or part of a table. Files can be sequential, partitioned,
VSAM or databases such as IMS, DB2 and others.
The Need for Automated Solutions
The volume of testing required for Year/2000 is unparalleled. We need to
replicate quickly many test files with many flavors and run applications
under several date scenarios (e.g., 1999 rollover and various critical Year/2000
dates). You can use date simulators or a Year/2000 LPAR to test your applications.
Either way, dates in your test files must be synchronized with system dates.
Birth of a New Product Category
Data-aging tools emerged late last year, just about the time we needed them
at the Prudential Insurance Company of America. That's when we were completing
assessment and remediation and preparing for full-blown system testing.
At Prudential Securities, a unit of Prudential, we examined three of the
leading vendors of date-warping tools. The tool we bought quickly became
one of Prudential Securities' most popular, heavily used Year/2000 products.
We've already conducted more than 25 demonstrations for our programmers.
Listed below are the 15 key criteria we used to evaluate date-warping tools.
These criteria apply generically for any company looking for such a tool.
However, companies should conduct their own evaluation based on their own
unique needs.
Top 15 Criteria for Date-Warping
Tools
1. Does the tool support COBOL OCCURS DEPENDING ON (ODO)?
-
ODOs are important and widely
used in COBOL applications. So we were surprised to find that few products
handle them. Only one of the three vendors we approached during our
evaluation agreed to add this essential support, which we needed for
many of our files. We appreciated the speed and quality of the enhancement.
It gave us confidence that this vendor would stand behind their product
and continue to support it.
2. Does it support COBOL MULTIPLE OCCURS?
-
This is even more common
than ODOs, so you need to make sure any tool you are evaluating fully
supports it.
3. Does it support semantic data aging?
-
This is an important feature
that most, if not all, vendors support to varying degrees, though some
via different names. An example of semantic data aging is the ability
to age dates by a certain amount such as two years - while ensuring
that the new date lands on a valid business day. An ideal tool can move
a date forward or backward, so you can bump it to the next business
day or the previous one. It should also let you advance a date to the
end of the month, quarter or year. Look for the tool that has the most
flexibility and best supports your needs.
4. Does it support copybooks other than COBOL language?
-
If you have PL/1 and the
product only supports COBOL, all you'd have to do is make a COBOL version
of your copybook and use that when aging your files. But if you have
to do that work for thousands of copybooks, this could be an important
factor in your decision.
5. Does the tool work directly on your copy book or does it convert
your copy book to an intermediate entity first?
-
If so, you won't always
be working with the latest version of a copybook and errors could result.
6. Does the tool support all the databases you use?
7. If a vendor claims to support several databases, is this via one
tool, or do they require you to buy and use several tools?
-
This may be a drawback and
it raises additional questions: Are the interfaces different for the
various tools? Will that mean separate learning curves for each one?
Are the aging rules consistent across the different flavors? Did different
vendors write the different pieces? If so, do you need to go to several
places for support?
8. Is the product easy to learn and use?
-
What is the ramp-up time?
Will the programmers and testers like the tool and want to use it enough
to replace existing methods?
9. How versatile is the product in supporting changes?
-
Once you set up aging criteria
for a file, is it easy to save the information, so you can go back and
easily change and rerun it again?
10. Can you hard-code dates?
-
Does the product only age
dates or can it ripple hard-coded dates throughout a file? If so, does
it validate the hard-coded date? Can you apply semantic or business
logic to the date you specify (e.g., holiday and weekend filtering)?
11. Does the product support "selective warping"?
-
Does the product let you
specifically select certain fields for warping - for instance only those
dates whose value does not equal all zeroes or all blanks?
12. Does the product work both batch and on-line?
13. Is the product CPU-efficient?
14. Does the product offer useful features in addition to warping?
-
Some
of the new data-aging products are actually "add-ons" to legacy
products vendors were selling before addressing Year/2000. Vendors
may offer to include
the legacy
components to sweeten the deal. Some of these may provide additional
help with Year/2000.
15. How flexible is the product in handling holidays?
-
Does the product let you address
easily all the holidays your business respects? When you warp the dates,
can you skip all holidays properly? Does it let users define more than
one holiday table, so users have a choice? Can they choose one holiday
table for one date field and another for a different field, within the
same warping job?
Disclaimer
We realize the market has changed since our evaluation more than six
months ago. There are more products to choose from now and the vendors
we evaluated may have addressed the problems we found with earlier products.
About the Author
Jeff Furman is vice president of Programmer Support and manager of Change
Management with Prudential Securities. He has been working on the Year/2000
project since 1993, when his group was one of the first shops to work
with date simulators. This article was reprinted with the permission
of Year/2000 Journal.
|
 |
|
