Amazing how disappointed people appeared to be when planes did not start dropping out of the skies and governments didn't stop functioning. The Y2K crisis was then dismissed as a big hoax, a fuss about nothing. However, if they had any idea of what was going on in the computer-world world-wide for the previous 18-24 months people wouldn't have been so blasé about it. The reason we averted a major disaster was that computer programmers had been working their butts off to identify and fix as many Y2K bugs as they could uncover. That Windows and its applications were not affected was a matter of good planning, at best, or dumb luck, at worst. And, that's what most people think of when they think of computers. Didn't affect my computer games, so why should I bother? Also, large companies do not admit publicly that they have computer difficulties; it makes clients nervous. Rumors were that at least one major bank had serious problems. Other failures, such as some American slot machines, were regarded as trivial and so were not reported widely in the press.
At Algonquin I had to get across the reason for the bug and how to identify and fix it to a group of students who had virtually no computer experience. To do this I had to teach them the rudiments of an obsolete computer language that was meant to handle applications of a sort they probably had not seen before. COBOL was a business-oriented language. It was good for adding up expenses and tracking inventory and sales. It was a major job in itself to show someone who did not know how to operate a cash register how businesses calculate profit-loss and capital depreciation, let alone how to do it in a language they had never seen before that ran on computers they had almost no experience with. Add to that language and cultural barriers and you have a task almost impossible to complete in about 25 3-hour classes.
But, I tried.
The Y2K bug was really quite simple. Generally speaking, computers track time by incrementing a counter beginning at a given start time. Unix systems start counting seconds beginning at 1 January 1970 00:00:00 UT. Windows NT counts the number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT. (One nanosecond equals one billionth--or .000000001--of a second. For example, light takes 3.33564095 nanoseconds to travel one meter in a vacuum). These numbers are stored in a group of 128 bits--sometimes 256 bits depending on the accuracy needed. There is no problem inherit in that. Where the problem comes in is that programs get the date, or time, from that group of bits and then manipulate it. Different computer languages have different degrees of accuracy. For example, COBOL can get time from the internal clock to the second while Java Script can fetch time to the nanosecond.
Often programmers want to display the year as a two-digit number. This works okay when you are in mid-century, but, when you get to both ends of a century you are going to run into dates that in are another century--and that is going to cause problems. To make matter worse, sometimes those 2-digit numbers are used mathematically to calculate things like the number of days between events or to forecast a future date (eg., what's the date 90 days from now?) As a result, some computers could not tell the difference between 1900 and 2000; others insisted that the year after 1999 was 19100. Some programs calculated that the year two years before the year "01" is a negative number(01 - 2 = -01). Where these kinds of errors occur, systems crash, or display bizarre results in place of the year. (For example, instead of “00” for 2000 you might see “A&” or some other random collections of characters.)
There were two main methods that programmers used to reduce the year to a two-digit number. One way was simple to subtract 1900 from the date so that
1998 - 1900 = 98. However, if you subtract 1900 from 2001 you get 101 which takes us right back to the original problem. The computer might display this as “10” (taking the first two digits) or as random characters.
Another way was to turn the year into a character string and simply chop off the first two characters. However, you can’t do arithmetic with characters, so this method was not very popular. The solution I used for one Y2K contract I had was to do the arithmetic needed using a four-digit year and, only as the final step when the year was to be displayed, did I switch it into four characters then truncate the first two characters.
These were generally the kinds of solutions employed. To make the field reserved for the year four places could easily be done in new programs as it was just a policy decision. Older programs required a great deal more effort and programmer hours. An ingenious solution was to change six-digit dates (11/31/87) from three two-digit fields to two three-digit fields by converting the month and day to a three digit ordinal number (so 02/28 (February 28th) became 059) and the year could expand to three places, sometimes by dropping the second digit (making 1998 into “198” and 2001 into “201”). Another way of fixing it was to retain the year as two digits and include the century as a separate piece of information that could be fetched when arithmetic calculations were required.
If your head is spinning by now imagine that you are hearing this in a language you barely comprehend, from someone who looks and acts oddly to you (he expects females to address him directly and he wears pants instead of robes). Add to that the unfamiliar setting, unfamiliar weather, strange foods and customs, and you might be able to comprehend what my students were struggling with.
However, we stuck with it and most of them passed the course, though I wouldn’t have hired any of them to actually do any work on the problem.
No comments:
Post a Comment