 |
Business | Industries | Finance | Tax |
| Index: > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
|
|||||
| First Prev [ 1 2 3 ] Next Last |
date-related processing to operate incorrectly for dates and times on and after January 1, 2000. It turned into a major fear that critical industries (electricity, financial, etc.) and government functions would stop working at 12:00 AM, January 1, 2000, and at other critical dates which were billed as " event horizons." This fear was fueled by huge amounts of press coverage and speculation, as well as copious official corporate and government reports. In the end, few Y2K errors were encountered on January 1, 2000, and Y2K is now largely regarded as a non-event. Regardless, the preparation for it had a significant effect on the computer industry.
Y2K (or Y2k) was the common slang for the year 2000 problem. (The abbreviation combines the letter Y for "year", and K for the Greek prefix kilo meaning 1000; hence, 2K means 2000.) It also went by millennium bug (though there is a popular debate on whether or not the year 2000 was actually the start of the new millennium).
It was thought computer programs could stop working or produce erroneous results because they stored years with only two digits and that the year 2000 would be represented by 00 and would be interpreted by software as the year 1900. This would cause date comparisons to produce incorrect results. It was also thought that embedded systems, making use of similar date logic, might fail and cause utilities and other crucial infrastructure to fail.
In the years prior to 2000, some corporations and governments, when they did testing to determine the extent of the potential impact, reported that some of their critical systems really would need significant repairs or risk serious breakdowns. Throughout 1997 and 1998, there were news reports about major corporations and industries that had made uncertain estimates as to their preparedness. The vagueness of these reports, and the apparent uncertainty regarding what sort of breakdowns were possible—and the fact that literally hundreds of billions of dollars were reportedly spent in remediation efforts—were a major part of the reason for the public fear. Special committees were set up by governments to monitor remedial work and contingency planning, particularly by crucial infrastructure such a telecommunications, utilities and the like, to ensure that the most critical services had fixed their own problems and were prepared for problems with others. By early- to mid-1999, when the same corporations, industry organizations, and governments were claiming to be largely prepared, the public relations damage had been done. It was only the safe passing of the main "event horizon" itself, January 1, 2000, that fully quelled public fears.
In North America the actions taken to remedy the possible problems did have an unexpected benefit during the 2003 U.S.-Canada blackout, on August 14, 2003. The previous activities had included the installation of new electrical generation equipment and systems which allowed for a relatively rapid restoration of power in some areas.
The underlying programming problem was quite real. In the 1960sCenturies: 19th century 20th century 21st century Decades: 1900s 1910s 1920s 1930s 1940s 1950s 1960s 1970s 1980s 1990s 2000s 2010s Years: 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 Events and trends The 1960s was a turbulent decade of change around, computer memory and storage were scarce and expensive, and most data processing was done on punch cards which represented text data in 80-column records. Programming languages of the time, such as COBOL and RPGRPG or RPG IV is a native programming language for IBM's iSeries (aka AS400) minicomputer system. In its latest incarnation includes prototyped functions and procedures, static and dynamic binding, access to C routine libraries, dynamic link libraries, an, processed numbers in their ASCIIASCII A merican S tandard C ode for I nformation I nterchange , generally pronounced 'aski', is a character set and a character encoding based on the Roman alphabet as used in modern English and other Western European languages. It is most commonly used b or EBCDICEBCDIC (Fully, "Extended Binary Coded Decimal Interchange Code") is an 8- bit character encoding used on IBM mainframes and AS/400s. It is descended from punched cards and the corresponding six bit binary-coded decimal code that most of IBM's computer per representations. They occasionally used an extra bit called a "zone punch" to save one character for a minus sign on a negative number, or compressed two digits into one byte in a form called binary-coded decimalBCD" redirects here. For "Buoyancy Control Device" see Buoyancy compensator. Binary-coded decimal BCD is a numeral system used in computing and in electronics systems. In BCD, numbers are represented as a sequence of decimal digits in which each digit is, but otherwise processed numbers as straight text. Over time the punch cards were converted to magnetic tape and then disk files and later to simple databases like ISAM, but the structure of the programs usually changed very little. Popular software like dBase continued the practice of storing dates as text well into the 1980s and 1990s.
Saving two characters for every date field was a significant savings in the 1960s. Since programs at that time were mostly short-lived affairs programmed to solve a specific problem, or control a specific hardware-setup, most programmers of that time did not expect their programs to remain in use for many decades. The realisation that databases were a new type of program with different characteristics had not yet come, and hence most did not consider fixing two digits of the year a significant problem. There were exceptions, of course; the first person known to publicly address the problem was Bob Bemer who had noticed it in 1958, as a result of work on genealogical software. He spent the next twenty years trying to make programmers, IBM, the US government and the ISO care about the problem, with little result. This included the recommendation that the COBOL PICTURE clause should be used to specify four digit years for dates. This could have been done by programmers at any time from the initial release of the first COBOL compiler in 1961 onwards. However lack of foresight, the desire to save storage space, and overall complacency prevented this advice from being followed. Despite magazine articles on the subject from 1970 onwards, the majority of programmers only started recognizing Y2K as a looming problem in the mid-1990s, but even then, inertia and complacency caused it to be mostly ignored until the last few years of the decade.
Storage of a combined date and time within a fixed binary field is often considered a solution, but the possibility for software to misinterpret dates remains, because such date and time representations must be relative to a defined origin. Roll-over of such systems is still a problem but can happen at varying dates and can fail in various ways. For example:
Even before January 1, 2000 arrived, there were also some worries about September 9, 1999 (albeit lesser compared to those generated by Y2K). This date could also be written in the numeric format, 9/9/99, which is somewhat similar to the end-of-file code, 9999, in old programming languages. It was feared that some programs might unexpectedly terminate on that date. Another related problem for the year 2000 was that it was a leap year even though years ending in "00" are normally not leap years. (A year is a leap year if it is divisible by 4 unless it is both divisible by 100 and not divisible by 400.) Fortunately, like Y2K, most programs were fixed in time.
| Politics | Business | Finance |
 |
 |
 |
|