Y2K problem

Y2K problem or Y2K bug: see Year 2000 problem.

---

Y2K problem

(Year 2000 problem) The inability of older hardware and software to recognize the century change in a date. The reason they could not was because the year was stored with only two digits; for example, 12-11-42 instead of 12-11-1942. Thus, when the year changed from 1999 to 2000, the date became 01-01-00, and the system thought it was January 1, 1900.

Dates Are Critical
Many financial transactions match dates in database records with today's date or with a future date. If the system does not handle dates correctly, bills do not get paid, notices do not get triggered and actions are not taken. After 2000, any system that could not recognize the millennium change caused erroneous output with applications that dealt with future dates.

It Was a Massive Job
The solution to this "millennium bug" required upgrading hardware to support four-digit years, converting files and databases to four-digit years and converting all the software that references dates. Enterprises had a huge amount of legacy data files and thousands of programs that accessed them. With many older applications, the programmers who wrote them were long gone, and program documentation was lacking. In many instances, the source code was missing. Even when changes could be made, the time it took to test them was taxing on the IT staff who were trying to run the daily work and implement new applications.

Just to Save Two Bytes!
The problem originated with punch cards that go back to the early 1900s. In order to cram an entire order or customer record into a single punch card with typically less than 100 character columns, the year was shortened to two digits. Why waste two columns for "19" when it was going to be "19" for such a long time. When punch card systems were converted to magnetic tape in the 1960s, and there was ample room to convert to four digits, 2000 still seemed very distant.

Saving two columns (two bytes) in a punch card was appropriate, but not when there was ample storage later. It was estimated to cost more than $600 billion worldwide to correct the situation.

Even Before 2000
Problems occurred before 2000. For example, imagine a company that wanted to delete records for customers who had not purchased anything in five years. The program logic would be to add 5 years to the date of the last order and compare the result to the current year. Suppose a customer last ordered in 1995 and the current year were 1996. Add 5 to 1995 in a non-Y2K compliant system and you got 1900 instead of 2000. Since 1996 was greater than 1900, the customer would be deleted. See data aging and Year 2038 problem.

About Time

This conference headline was from the Software Productivity Group, an organization that provided the necessary training to deal with this sticky subject. (Image courtesy of Software Productivity Group)

Making the Point

This ad for Isogon's TICTOC Year 2000 compliance software made a strong point. TICTOC was used to test Y2K compliance for MVS applications by setting fictitious dates on a job-by-job basis. (Image courtesy of Isogon Corporation, www.isogon.com)

Long Before Y2K

Program maintenance is always a problem in this industry. This commentary from PROCASE Corporation was created more than a decade before Y2K became daily news. The company provided software that could flow chart a program from its source code in order to make it understandable.