What is the Y2K Problem ?

When computers first came into being, memory was very small(started at 4K) and it was very expensive, too. Therefore, as Peter de Jager documented very well, the practice of saving space on hollerith cards, in memory, and on storage devices, by not including the century portion of years, ultimately created the Y2K problems we are now faced with.

(i.e., Gregorian date MMYYDD or YYMMDD)

(i.e., Julian date YYDDD)

Problems arise when dates span more than one century.

This can cause the wrong century to be displayed, dates sorted out of order, erroneous results from calculations based on differences between two dates or extrapolation of dates into the future, or erroneous results caused by making wrong assumptions with date data in databases.

Hardware -

Make sure your computer is year 2000 compliant.

Software -

Make sure programs are year 2000 compliant or ready (i.e., COBOL, FORTRAN, Visual Basic, C++, Java, shrink-wrapped software(Microsoft Office, Excel, WordPerfect, Quicken, Encyclopedias, Graphics packages, etc.)

Data -

Make sure data is year 2000 compliant or ready

Fix (Remediate) an application by making all the data have 4-digit years, all the programs have 4-digit year logic, and execute these programs on a Y2K compliant computer.

Fix ( Remediate) an application by making assumptions about date data and apply the same assumptions to the programs that process these dates. This is called windowing. Windowing almost always refers to a 100-year span. One selects a 2-digit pivot year from which any year less than this year belongs in the next century, and any year greater than or equal to belongs to the current century.

Logic is added to programs to internally append the windowed century to the year, thereby faking out the system since the data will not change externally in the database.

(i.e., 50; (1950 to 1999, 2000 to 2049)

75; (1975 to 1999, 2000 to 2074)

25; (1925 to 1999. 2000 to 2024)

98; (1998 to 1999, 2000 to 2097))

Replace the application with a new year 2000 compliant application.

Retire the application because it is no longer required.

If you read Peter de Jager’s article, it sounds like companies have an insurmountable challenge to resolve Y2K problems, and if you take him literally, he is right.

If you read Gary North’s Y2K articles, Y2K will present doomsday predicaments.

So, the question is "How can companies prepare to solve these problems?"

Six steps should be taken. They must be followed in the order below:

Inventory – Take a complete inventory of all hardware, software, and data.

Assess – Categorize all inventoried items according to how important(mission-critical) they are and what risk is associated with each item when it would fail, and what impact that would have on the company.

Remediate – Fix or replace all items that are mission-critical and/or very important to the day-to-day operations of a company.

Test – Develop a baseline set of tests to assure that remediation efforts will not change the operational aspects of an application. Then apply the Y2K tests, verify, and validate the results.

Implement – Place the Remediated application into production.

Re-test – Develop a pseudo-test and execute it in production to verify that no production implementation problems occurred.

On an individual scale:

You may not be able to program your VCR

Your digital watch or clock may not set correctly

Your heating or air conditioning system may not go on or off when you want it to

The electronic ignition and fuel injection system in your car may not function properly

You may need to get a replacement BIOS chip for your personal computer if some of the software you have doesn’t work correctly

You may have some computer software that does not work correctly

Etc.,etc.,etc.,etc.,etc.,etc.,etc.

On a global scale:

Power outages could occur

State and Government computer applications may have problems (Pa Dept. of Revenue, Medicare, etc.)

Local banks and international banks could have problems

Stock Market crises could occur

All utility company companies could experience outages

All manufacturing companies could experience outages

World-wide telecommunications networks could experience outages

Satellite communications may have problems

International trade markets may experience difficulties

Some companies will go out of business because they did not prepare adequately(due-diligence)

Many applications have already experienced Y2K problems, and if any of these applications were critical to the operational aspects of a company, they have already been remediated, or the company may not be in business anymore. Many companies have applications which look ahead into the future. These applications have to be changed long before January, 2000, or they will not work correctly.

Different applications have different execution cycle requirements, and therefore one application may have 50 different pivotal dates it needs to check while another application has no Y2K requirements at all because either it has no date requirements or it has no 21^st century requirements.

Here are a list of common pivotal dates that could cause problems:
(the first two dates are not Y2K problems)

08/22/99 – Some satellite’s calendar clocks will have their week counter reset to zero because the counter registers were not designed to handle a large enough counter

09/09/99 – Many old programs used all 9s as an end-of-file delimeter. This will cause some programs not to work properly. It could also cause data to be lost or corrupted

12/31/99 – Many programs have roll-over logic from one day to the next. This logic could fail

01/01/00 – First day of 21^st century

01/03/00 – First business workday for many people

02/29/00 – Year 2000 is a leap year; therefore February has 29 days

03/01/00 – march 1^st is the 61^st day of year 2000 since it is a leap year

There are many, many more pivotal dates that different applications need to test, but each application needs to determine these dates independently.