Given our natural fascination with disaster movies and stories of impending doom, it comes as no surprise that the Year 2000 computer challenge has captured wide-ranging interest. At one end of the spectrum are those who embrace, even relish, the concept that Year 2000 problems will bring down our whole socioeconomic structure. Then, there are those at the other end who continue to ignore the possible impact on business, public services, and social order.

The fact is, no one knows for sure what will happen because it's a unique event in history. Our best judgement is that there will be some disruption and some impact on the economy, but certainly no "nuclear winter" with a return to an agrarian society.

Possibly the most difficult Year 2000 fact we have to come to terms with is that there is no single solution. From time to time, a talking head on the nightly news will bring up the possibility that a teenage hacker has discovered a magic bullet. We need to get it through our heads that a single solution is not in the cards; there simply are too many date-affected components hiding out across too many different programming languages and hardware platforms for a single fix to be possible.

The Date Effect

The Year 2000 problem could more appropriately be called the date effect. This event could have as easily occurred in 1900 as now had computers been a big part of our life in the latter 1800s. It is just a coincidence that our reliance on computers and the change of centuries are occurring within the same time frame.

The culprit in the date effect is the century indicator - the first two digits in the four-digit year. Much of the hardware and many applications were designed to use two digits to indicate the year in a date. The last two digits in the date "01/22/63," for example, we understand as the 63rd year in what we asume to be the 20th century. But a problem arises with this assumption as we start dealing with dates across centuries. When we reach the year 2000, 00 could be interpreted as 1900 or 2000. And, of course, in date-sensitive calculations, the century cannot be an either/or proposition.

You probably know a word processing file with a save date of 12/12/00 was saved in the year 2000 and not in 1900. But what about earnings, compounding, and payments on a trust fund that was established in 1980? Where does the trust fund go when the system used to manage it says, "If the system clock says it is 00, then it must be 1900?" If the system reads 00 as 1900, the trust fund doesn't exist. If the system reads 00 as 2000, the trust fund still doesn't exist unless the system can also recognize 1900, the year in which the trust fund was set up.

Is Jan. 1, 2000, A Workday?

Other problems resulting from the date effect occur when dates are used to determine the day of the week or initiate a complex processing routine based on dates or a combination of dates and conditional criteria. The day of the week is an easy one to understand; Jan. 1, 2000, will be a Saturday. So, if you have a noncompliant employee work-scheduling application that uses the date to calculate the days of the week, you may find that the application schedules workers on Sundays when the business is closed. Similar day-of-the-week calculations can create havoc with certain payroll mechanisms, paying employees every Friday, for example.

Missing a payroll day probably would not be the end of the world for most companies. However, when day-of-the-week calculations are part and parcel of an application that manages more sophisticated processes, the implications of non-readiness of the application becomes a more critical issue.

Consider facility climate-control systems, security systems, or manufacturing process control systems that determine which routine to initiate based on the day of the week. If the system thinks it's Saturday instead of Monday, temperatures in a climate-controlled workspace could be set to weekend levels and security systems reset just as employees arrive for work. Similarly, machines in a busy manufacturing operation could be shut down automatically because the system that controls the operation calculates from the date that the present day is not a workday.

An Ageless Problem

Dates also are used in calculating age and time/money functions. Ever notice that most forms, such as insurance and loan applications, even a hospital admittance form, ask when you were born? In some instances, there may be a genuine need to know your date of birth. For the most part, though, the big deal about getting your date of birth is not the date itself, but rather to use it as a key value in a mathematical function that enables a computer to figure out how old you are. Say you were born July 4, 1966, and it is now July 4, 2000. The system would subract 1966 from 2000 and determine that you are 34 years old.

The leap year adds another wrinkle to Y2K math. Every year divisible by 4 is a leap year, with the exception of years that are divisible by 100; however, the exception to the exception is that years divisible by 400 are leap years. Therefore the year 2000 is a leap year, which means it will have 366 days. But 1900 was a non-leap year, with 365 days. So, to do any type of precise calculation involving number of days, for example, one that involves daily interest that spans the bridge between the two centuries, a computer system will need to understand there is an extra day, specifically, Feb. 29, 2000, that must be considered.

Where "Today" Comes From

In your PC, the current date originates from the interaction of the real-time clock (RTC) and the Basic Input/Output System (BIOS). Part of the RTC is an incremental counter powered by a battery, so if you turn off your PC, the counter keeps counting. Although the counter steps up the year in increments of 1 from 00 to 99, the century indicator is hard coded in ROM (Read-Only Memory) to indicate 19. So, when the RTC counter rolls over from 99 to 00, it will automatically pair up with the hard-coded century indicator and come up with 1900; that is, unless your PC has a Y2K-compliant BIOS.

The BIOS, which is an application that provides the means for the operating system to talk to your computer's hardware, is stored in ROM (sometimes flash ROM, so it can be updated using software). The BIOS grabs the date and time from the RTC, and passes it and other information about your PC to the operating system during the boot process. When a Y2K-compliant BIOS checks with the system clock and sees the 00 value in the year counter, it will reinterpret the 00 and the hard-coded 19 as the year 2000. Typically, the BIOS will check the year value in the RTC. If it is, say, between 00 and 79, then the BIOS sets the century value at 20.

Some BIOS versions that claim Y2K compliance may need to be turned off and restarted in order for the BIOS to check with the RTC, these versions will not automatically roll over to the next century should you leave your PC on during the transition from 1999 to 2000. Some later BIOS versions get their information from the RTC each time an application sends a date request to the BIOS or to the BIOS via the operating system. These normally will recognize the rollover to 2000 even if the PC is left on during the transition.

BIOS Update Best

Although the safest appraoch to hardware compliance is physically replacing or flash upgrading the BIOS, there are several software products available to check BIOS compliance and provide third-party fixes to the hardware problem. See the section "Repair Solutions" in the main Y2K menu area for reviews of those products.

The date effect in PCs is small potatoes compared to probems in mainframe land, not because of the numbers of problems, but because mainframes, especially in big businesses, handle key mission-critical roles in U.S. and global economic and government infrastructures.

In any given corporation, there can be hundreds, even thousands, of applications containing millions of lines of code that often are written in early languages, such as COBOL and FORTRAN. Many were developed in-house, and have been patched and tweaked over the years without documentation and source code. Too often, the original programmers have moved on. This means reverse-compiling to discover the source code and figure how dates were handled.

What Y2K-Ready Means

Whether you are dealing with mainframes, PCs, or both, even the definition of century date compliance can be up for grabs. Definitions can vary by industry, by organization and by hardware and software vendor.

Most Y2K experts conclude the financial industry has probably done the best, both in defining the challenge and taking action to ready their systems for the new millennium. Little wonder! Banking operations involve interest computations, transaction fees, automatic payments and transfers, and other money/date operations.

Also, the banking industry is heavily regulated; there are at least four separate regulatory organizations that are interested in bank Y2K readiness, which adds a measure of motivation not always present in other industries. One of the nation's mega-banks First Chicago NBD, which recetnly merged with Banc One and soon will start doing business in all locations under the Bac One name, has been working toward Y2K readiness since 1995. Other businesses could learn from First Chicago's precise definition of what it means to be Year 2000 Readiness Disclosure statement.

Century date compliance essentially means that a system's functionality is not adversely affected by dates before, during or after the year 2000. Any system or application will be considered century date compliant when it demonstrates that it will not have a negative impact on our customers or business partners. First Chicago NBD has established the following rules for compliance:

1. Generally Integrity. No value for the current date will cause any interruptions of operation.

2. Date Integrity. Date-based functionality must behave consistently for dates prior to, during, and after year 2000.

3. Explicit/Implicit Century. In the processing of dates, the century in any date must be specified either explicitly or by clear logic techniques, such as windowing.

4. Leap Year. The year 2000 must be recognized as a leap year, and systems must process the date February 29, 2000 properly.

How Ready Are We?

In Year 2000 Global State of Readiness and Risks to the General Business Community, a report delivered to the Senate's Special Committee on the Year 2000 Technology Problem in October 1998, Gartner Group's Lou Maroccio concludes that, in addition to banking, the insurance and investment services "lead all other industries" in compliance efforts.

He does interject one caveat regarding banking, though. "Banking has a unique status since small banks are lagging and large banks in the United States are ahead of many other industries," Marcoccio says. Another Gartner analyst, Jim Cassel, says, "There likely have been shotgun marriages already between banks," indicating the bank regulators are innsisting that every bank better be ready for Y2K or link up with another bank that is.

Other "infrastructure utilities" and "emergency services" that the Garner report describes as "critical for sustaining business operations and well-being," seem to be in pretty good shape, at least as far as the general infrastructure is concerned. Marcoccio says, "In the U.S., we predict that general infrastructure, power, non-wireless telephones and critical services will continue mostly uninterrupted."

Maroccio goes on to say, "Natural gas utilities are lagging the utility industries. Health care lags in areas of medical practices, hospitals, and elderly care. Public, private, and higher education also lag far behind. Many world governments are also far behind. The U.S. and Canadian governments are more than 40% ahead of any other government in the world, but lag large private industry in the U.S. State governments differ widely in status."

Mike Chuba, a Gartner Group mainframe hardware procurement analyst, says keeping systems up to date has always been a problem with governments. At the national level, progress depends on which agency you are talking about. For example, concerning the IBM systems that Chuba says "FAA installed in early 1980's to bring them into the 20th century," the systems are so antiquated that it is not possible to renovate them for Year 2000 compliance. In such instances, the only choice is to replace old systems with new ones. Unfortunately, replacement can take 18 months or longer.

Gartner's studies show that, at the end of the third quarter of 1998, only 50% of U.S. state governments had detailed Year 2000 project plans and resources in place. Also, 65% of U.S. cities and towns simply do not have Year 2000 projects. Chuba suggests the reluctance of municipalities to get going on Y2K involves a misture of budget priorities and a lack of awareness.

Big businesses (companies with more that 20,000 employees) are well ahead of midsize (2,000-20,000 employees) and small (fewer than 2,000 employees) organizations. Gartner's Q3 1998 figures indicate large companies have completed 20% to 80% of remediation on internal systems. Also, between 30% and 50% of large businesses have started testing. Companies in the midsize category vary from 0% to 30% in remediation, and from 20% to 40% of midsize businesses have begun testing. Small companies are way behind; 0% to 5% have remediated their systems, and of those that have remediated, 30% percent have begun testing. Gartner points out that small compnaies are relying mostly on vendors to correct their systems, whereas large and midsize businesses are using a combination of internal resources and outside help.

If the Gartner Group's predictions are correct, the United States and several other countries, including Austrlia, Belgium, Canada, England, Holland, and Sweden, will be in better shape than others to meet the new millennium. Unfortunately, many of the countries that are lagging behind in Y2K readiness also have been facing financial problems, and in some cases, political instability, which can only increase the likelihood of Y2K-related failures in both their govenmental and industrial infrastructures.

Process Of Repair

Except for the fact that it is industry-specific , First Chicago NBD Banks's Year 2000 program is typical of the complexity facing large enterprises throughout the United States. Pen Hollist, first vice president and the bank's Century Date Program Manager, says the bank's reach for compliance involves 93 million lines of code across 561 applications. Moreover, multiple programming languages are normally involved. Because not all programmers know all languages, and the way date codes are handled varies from language to language, the task of attaining readiness is a daunting one, to say the least. It also is expensive. First Chicago's budget for Year 2000 fixes through 1998 is $100 million. Hollist estimates an additioinal $25 million will be required for external interface testing in 1999.

In a large enterprise, attaining Year 2000 readiness is much like clearing old military ordnance from thousands of acres of dense forest. Robert O'Malley, a knowledge manager in Ernst and Young's Center for Business Knowledge, put together a Resource Kit on the Year 2000 for Ernst and Young's large enterprise clients. "You first have to take a helicopter view of the enterprise. From there, you can get an idea of the size of the IT territory and nature of the business terrain," O'Malley says.

Ernst and Young's Y2K people call this "Scoping the Challenge." Scoping is followed by Portfolio Assessment to identify the date-affected components within the organization's application inventory. With this information in hand, the company can proceed with renovation, which includes conversion, testing, and implementation of the Year 2000 fixes.

Another stage in this process, which, ultimately, may be as important from a business standpoint as renovation, is managing activities with external agents. Typically, these include customers, service bureaus, banks, and other financial institutions, hardware vendors, software vendors, and stock suppliers," O'Malley says.

Those companies that are late to the Y2K remediation party may find they have to move quickly through the scoping stage of the Year 2000 process. However, they would do well to keep in mind some guiding objectives that Ernst and Young sets out. According to O'Malley, these include "analyzing the entire enterprise and its current capacity and ability to address the Year 2000 challenge; inventorying vendors and external agents, describing the status of their current Year 2000-readiness program; identifying alternative approaches to addressing the Year 2000 challenge; evaluating the costs and benefits fo ridentified alternatives; determining resource requirements and availability."

Companies also should keep in mind scoping from only an IT perspective misses the point of conversion. Gartner Group, Ernst and Young, and others who are deeply immersed in dealing with the Y2K challenge, point out Y2K is a business problem with IT issues, not the other way around. For this reason, Ernst and Young suggests scoping be done from several perspectives - from the perspective of the enterprise, the business process, the IT infrastructure, and the people process.

The specific strategy used for addressing Y2K depends on to what degree a system is technically and functionally able to handle the Year 2000 in its current state. When a system simply is incapable of handling dates beyoind 1999 and cannot do what it was designed for beyond this date marker, then there is no alternative but to replace or retire it. In systems that are technically adequate but functionally impaired, it is often possible to install an update or new version of an application that is Year 2000 ready.

For systems that are both technically and functionally adequate, the appropriate strategy may be to update the date-affected code in current systems and then test them for Year 2000 readiness. Except for mainframe systems that are simply too antiquated to work beyond 1999, renovation has become the preferred strategy. This is not always out of choice, but out of necessity, given the time constraints.

In a renovation strategy, work normally begins after a detailed inventory of the organization's date-affected components. To make renovation manageable, these components are arranged n clusters. Think of a cluster as a natural grouping that may include up to several hundred active programs within systems or sub-systems that also may share data and other related components.

Besides making it earier to deal with renovation by groups that share common traits, clustering also establishes a framework for setting priorities. For example, clusters that include date-affected components impacting billing, purchasing, inventory, logistics, and process control would likely be high on the list for renovation in a manufacturing organization.

Most companies are taking either a data-expansion or procedural-conversion approach to renovation. In data expansion, a century indicator is added to a two-digit year and stored in the system's data files. This is a permanent change to the date field. The procedural approach, in contrast, does not require changing the date field; here, changes are made in application logic, which enables the application to link to two-digit year to the correct century, enabling the application to process 01 as 2001 instead of 1901, for example.

One of the most proceduaral approaches is called windowing, in fixed and sliding versions. With fixed windowing, the system retains the existing two-digit format, but employs an external routine based on specified century assumptions to place the two-digit date in the right century. A threshold is set, for example, at 40. If the year is 40 or less, then the century is designated as 20. Moving in the other direction, if the year is between 40 and 99, the century is 19. Another variation is the sliding windowing technique, in which the threshold year varies with the system date.

The Y2K Storm

Gartner's Jim Cassell sys there will be problems, but points out that there is a difference between the importance of fixing mission-critical systems and all systems. In terms of critical services, such as gas, electricity, and telecommuncations, Cassell suggests the problems will be akin to those experieced from a passing storm. For one thing, Jan. 1, 2000, is a Saturday, so response teams have two days to fix last-minute glitches before the business week begins. His projections are that "70% of all problems in the U.S. that are failures will likely be fixed within hours and 90% within three days.

In addition to date-affected embedded logic devices, some really sneaky date effects will likely turn up in user-created PC application spin-offs, such as spreadsheet macros and databases created by desktop users. Most of these are not listed in a company's inventory, and the only way to find them is to go from PC to PC or wait for the frantic help desk call. Chances are that these secondary problems will show themselves after the rollover to Year 2000 and will be replaced or renovated as needed.