Project 2000

Century Support Products for CA-IDMS


The year 2000 presents a problem to many software applications. For years, as a way to reduce data storage requirements, dates were represented in databases as YYMMDD (or YYMM or YYDDD). The YY representation for year assumed an implicit century value of "19". Now, however, with the rapid approach of the 21st century, an implicit value of "19" is no longer valid.

Both MIS professionals and end-users have become accustomed to the two-digit representation of year. Displayed on application maps (or screens) and reports the two digit year is easily recognized and understood. When users see a date of 04/01/96, they immediately recognize April 1, 1996. Similarly, when they see a date of 04/01/00, they will immediately recognize April 1, 2000. The century change will not inhibit our ability to recognize dates on reports and screens, however, it will seriously impact the database representation and code processing.

It is important to understand when a two-digit year representation in a database is a problem. In many instances, the two-digit representation is still perfectly valid. If a date is not part of a sort control field, it probably can continue to be represented with two digits. Dates that are essentially attributes in an entity record (i.e. birth date, employment date, etc.) can continue to exist with a two position year. Similarly, if a series of records are stored in chronological sequence (i.e. LAST) in a set, even if they contain a date field, the YYMMDD representation will continue to be valid. The sort sequence is maintained by the LAST option in the set definition.

The problem arises when the date is part of a sort sequence -- whether in a database as part of a sort control field or in subsequent batch processing after the date has been extracted and becomes part of a sort control element. When the data in a YY field changes from "99" to "00", the year 2000 sorts before 1999 (or even 1901 for that fact). Similarly, problems can arise if a program compares dates.

While I have your attention - here are a couple of other little items for everyone to consider.

The Y2K effort is a pure expense. By making the applications Y2K compliant - sales will not increase. This effort is necessary just to keep your company in business. Since it is an expense - get it over as quickly and as inexpensively as possible, with the minimum impact to the end-user community.

Management is often upset that they are going to have to spend BIG to solve the Y2K problem. They need to keep in mind that these applications were designed 20 - 30 years ago. They have been running the business very effectively for a long time. When these applications were developed no one would have dreamed that they would have been so effective. Consider what the return was on their initial software development. Here is another good question - ask management to consider the applications that are being developed today. How long are the software solutions being developed today going to survive? Will the return on today's development cost come close to matching the past performance? I DON'T THINK SO.

And finally - for all of those people out there that are saying -

"We will be off CA-IDMS before the Year 2000."

WAKE UP!! Your company has probably been on CA-IDMS for longer than some of your programmers have been alive. It is still running a majority of your production applications. Most companies have been saying they are going to leave IDMS for years. This deadline cannot be pushed back. It is REAL. Failing to start the conversion process will be fatal for some corporations. The closer it gets to the year 2000 the harder it will be to get contractors, consultants, programmers, etc. It is just supply and demand. Resources, including software products, will just continue to get more and more expensive. Get started today.

So you want to know the typical solution to the Y2K problem? Click here.

To return to Project 2000 click here.

To return to the HSL web page, click here.

Hybrid Systems Ltd., Inc.
200 University Park Drive
Edwardsville, IL 62025

E-mail: HSL