(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 2000 arrived, the date became 01-01-00, and the system thought it was January 1, 1900.
Dates Are Critical
Financial transactions often 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 change caused erroneous output with applications that dealt with future dates. Although warnings of disaster prevailed, there were only a few incidents when all was said and done.
Fixing 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 referenced 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 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.
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 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, laziness prevailed because 2000 seemed very distant. Saving two columns (two bytes) in a punch card was appropriate, but not when there was ample storage on tape. Costs were estimated to be more than USD $600 billion to correct the situation worldwide.
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 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 the result was 1900, not 2000. Since 1996 was greater than 1900, the customer would be deleted. See data aging
and Year 2038 problem
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 a Strong Point
Isogon's TICTOC Year 2000 compliance software was used to test IBM mainframe applications for Y2K compliance by setting fictitious dates on a job-by-job basis. See MVS
. (Image courtesy of Isogon Corporation, www.isogon.com)
Even Before Y2K
Program maintenance is always a problem in this industry. This commentary from PROCASE Corporation was created more than a decade before Y2K. PROCASE provided software that could flow chart a program from its source code in order to make it understandable.