With the Millennium comes perhaps the most troubling dilemma in computer history: how to solve the Year 2000 (Y2K) Problem. This text provides an answer to this problem by revealing practical instructions on planning, preparing, and executing a project which should make a company Y2K compliant. This text should help programmers, managers and consultants gain a clear understanding of the Y2K Problem - and how to beat it - from the ground up. It examines and evaluates the seven major problem-solving approaches currently available, helps the reader choose the best method for their particular company, and provides the information needed to implement a solution. Sections on project staffing and management help the reader determine whether to build their Y2K team with existing employees or consultants. The book also addresses the business side of the Y2K issue, as the reader learns the impact of the problem on PC and desktop systems, and how to find and test potential failure points.
| ||||||||||||
Book Description
Editorial Reviews
About the Author
Patrick McDermott has more than 20 years of computer industry experience as a programmer, analyst, developer, manager, and trainer. He currently teaches seminars on the Year 2000 Problem, and also runs his own consulting firm in California, where he specializes in training on the subject.
Excerpt. © Reprinted by permission. All rights reserved.
Chapter 1. The Seven Warning Signs of Y2K Like cancer in the human body, Y2K bugs might have silently spread throughout the computer systems that support your organization. Since early detection can mean the difference between life and death, you must be constantly alert for the warning signs of disease. The early symptoms of Year 2000 cancer have already been detected in most systems, and from now until the crisis has passed you'll need to watch for these warning signs to prevent serious damage to your organization. Here is a list of the seven most deadly symptoms to keep as a handy reference. Use this list to make sure you've covered all the bases. For example, if you're testing a system for Y2K impact, you can test for each type of symptom on the list. Or if you're evaluating a tool or solution, ask if and how it fixes each of the symptoms on the list. You might want to copy the list and post it in a prominent place so you can refer to it when pondering Y2K bugs. The Seven Warning Signs of Y2K I.
2001 > 1999; But 01 < 99 II.
2001 - 1999 = 2; But 01 - 99 = - 98 III.
00, 99 = Never, N/A IV.
The Last Shall Sort First V.
An Interface Built for Two VI.
The Days of our Weeks VII.
The One you Forgot About
1.1 Symptom I. 2001 > 1999; BUT 01 < 99 Using two digits for the year works just fine when you need to decide which of two years is earlier, as long as both years are in the same century: 1972 is later than 1968, and 72 is greater than 68, so a computer doing a comparison will get the correct answer. But 2001 is later than 1999, and 01 is less than 99, so in a comparison, the later year looks like the earlier year. Time has reversed itself-later becomes earlier, and earlier becomes later. As long as both years are in the same century, the greater number is the later date, but when years span the century divide, the opposite is true.
In any logical comparison or test, the computer will make the wrong choice every time. This may turn out to be an advantage, because things that are consistently wrong are usually much easier to find and fix than things that are occasionally wrong. So look for reverse conditions: overdue items shown as current, and accounts that were paid on time that are marked as overdue.
The most common form of date comparison on the computer is with the current, or today's, date. The computer will give an error message if the employee's date of hire is after today, or if the due date on an invoice is before today. There are also internal comparisons between two dates: the computer will not record a promotion if the promotion date is before the hire date. Keep your eyes open for both types. When you ask for items before or after a certain date, you get a lot more or fewer than you expect. The computer has incorrectly included or excluded 21st-century items.
1.2 Symptom II. 2001 - 1999 = 2; BUT 01 - 99 = - 98 Using two digits for the year will cause no problem when you need the difference between two years, as long as both years are in the twentieth century:
1966 minus 1964 equals 2
AND 66 minus 64 equals 2
Either method results in the same answer. The essence of the Y2K problem is that a simple subtraction will no longer work when one date is in the twentieth century, and the other is in the twenty-first:
2001 minus 1999 equals 2
BUT
01 minus 99 equals -98 (minus 98)
Instead of 2, we get minus 98! The computer will do any one of a number of things if it needs to use the minus 98 in another operation, all of them wrong, and some of them unpleasant. In what are referred to as "unsigned" storage methods (used to save the space for the sign), the computer will simply ignore the negative sign, and a two-year old baby boy may, to the computer, become a 98-year old grandfather! Or, the computer might simply stop processing and refuse to work until the situation is corrected. For example, under many unexpected data conditions, the program might execute what IBM calls an "0C7 1 Abnormal Ending", which essentially means "get sick and die", or crash. Or imagine this scenario, used to calculate an interest payment on a credit card:
2000 minus
1999 equals 1
BUT
00 minus
99 equals -99 (minus 99)
If the computer drops the minus sign, it might appear a Christmas gift bought on the credit card was charged almost a century earlier! Considering the interest rates on credit cards, you might wish you had left home without it!
Look for unusually large differences in dates, or extra large or small amounts calculated based on dates. If you see bills that are decades overdue, or interest penalties and late charges in the hundreds of thousands of dollars, you probably are encountering this symptom.
1.3 Symptom III. 00, 99 = NULL, Missing, Never, N/A Sometimes a field that normally contains a date needs to have something other than the date in it, or should have no date at all. Rather than track that information in another field, which would use more space, programmers often choose to encode it by giving certain dates a special, or "magic", meaning.
Some programs use low or high numbers as magic dates. If the item has no specific due date, the entry might have just been left as its default of zeroes (00/00/00). Or, when the date is inapplicable or unknown, we might enter 99/99/99. So you might have logic in your programs that says: "If the YEAR is equal to 99 then skip the normal processing." In that case, you'd obviously have a problem for all items in 1999. Sometimes the day of the month is left unspecified. For example, if a job applicant indicates employment from May 1995 to August 1997 without specifying the exact days of the month, the two dates might be entered as 05/00/95 and 08/00/97.
The year 2000 itself presents a unique problem. When you drop the first two digits from 2000, you're left with "00", "aught, aught". Numerically, 00 is zero, which is usually the default entry for numeric fields. So entries that were left blank will now appear to be from the year 2000. Likewise, if YEAR is required on a screen, and the entry is typed as 00, the computer might think the entry was left out. You'll need to adjust your edits to allow the double zero to be recognized as a valid entry meaning 2000.
In many file storage systems, the year 99 is treated as a special number, meaning "Never". For example, if you wanted a file to be retained forever, you would enter an expiration date of 99/12/31, meaning never let this file expire. And the Julian date 99-365 (meaning the 365th day of '99) or even 99366 (meaning the nonexistent 366th day 2 of 1999) was recommended by IBM for permanent file retention. In the year 2000, 99 might be interpreted as 1999, which is indeed before 2000, and all the files you wanted kept forever will be gone forever. And "foreign tapes" (tapes going to or coming from am outside data center) were given an expiration date of 98000. 3 These magic dates will now appear in the middle of any sorted list, instead of at the bottom or top of the list, once they've been expanded. So if you suddenly find you have no files that are to be retained forever, try looking in the middle of the list before you panic. If you're lucky, they'll just be just misplaced on the list.
1.4 Symptom IV. The Last Shall Sort First On sorted lists, the items from the twentieth century and the items from the twenty-first century will trade places. In your sorted list, for example, the oldest items will be the items from 2000, even when items from 1999 are on the list. All the items from year 98 and year 99 will be down at the bottom rather than at the top (see table). Within the century group they will be sorted correctly, but the whole group will move to the top or bottom, whichever is wrong.
This could be either an annoyance, or it could lead to serious errors if it is critical that items be processed in chronological order.
Table 1.1 Sorting by 2-Digit Year
YYMMDD
Date
Correct Order
00/01/01
Jan 1, 2000
7
00/02/02
Feb 2, 2000
8
00/03/03
Mar 3, 2000
9
01/01/01
Jan 1, 2001
10
01/02/02
Feb 2, 2001
11
01/03/03
Mar 3, 2001
12
98/01/01
Jan 1, 1998
1
98/02/02
Feb 2, 1998
2
98/03/03
Mar 3, 1998
3
99/01/01
Jan 1, 1999
4
99/02/02
Feb 2, 1999
5
99/03/03
Mar 3, 1999
6
Notice that in the list above, which should be sorted in order of occurrence, the items from 1999 and 1998 appear after the items from 2000 and 2001. This could lead to problems ranging from minor annoyance to items being misapplied costing large sums.
1.5 Symptom V. An Interface Built for Two Interface problems are placed in a category all their own even though many are actually reflections of problems discussed elsewhere on the list. This is done because screens and maps often live off in their own little world and can easily be missed when scanning program libraries. And even in the most trivial solutions, you will probably need to adjust communications with the outside world in screens and reports. If you have a client/server system, the interface will be located on an entirely different platform, possibly in a different city on another continent.
The most obvious problem is that if you want people to be able to type or see a four-digit year in a spot where previously there were only two digits shown, there will not be enough room for the extra two characters. So, in addition to expanding any fields in your database, be sure to check the screens and reports they appear on. Automated screen building tools in particular have a habit of assigning names like "SCREEN-FLD-13" to screen entries. Even if you can scan the separate screen library, you might have a hard time finding the Due Date that was named SCREEN-FLD-13. These screens often have logic embedded in them to validate entries and this also is difficult to scan for. In addition, you might need to re-arrange the screen if any fields change length.
On screens, you probably want, at a minimum, to allow people to continue to type dates as 01 and 02, but then behind the scenes automatically convert them to 2001 and 2002, or the opposite if your database fields were not expanded. Beware the interpretation of "00", meaning 2000, as "zero", meaning no entry was made, and vice versa.
It's probably cosmetic in impact, but watch out for hard-coded "19" appearing in reports and screens.
The fact that two-digit years will enter the valid range for days and months may introduce a new ambiguity to your systems. 97/03/17 and 03/17/97 are both clearly Saint Patrick's Day, 1997, but what about 01/02/03? Is it in 2001 or 2003? If you mix formats, or are international in scope (in Japan, the normal way to show a date is year-dot-month-dot-day: 97.03.17, and in Europe it's day-dash-month-dash-year: 17-03-97), your incidents of erroneous interpretations will increase dramatically in 2001. One consolation is that you get an extra year on this one: the problem starts with entries from 2001, not 2000.
1.6 Symptom VI. The Days of our Weeks
You've heard of programmers who don't even know what day it is? We may see a lot of them in the year 2000.
Twenty-first century dates lag their twentieth century equivalents by one weekday (from March 1, 2000 on-until Leap Day 2000 it will lag by 2 days). 4 January 1, 1901 was a Tuesday, but January 1, 2001 will be a Monday. December 25, 1980 was a Thursday; December 25, 2080 will be a Wednesday. This is because there are 36,525 days in the century (when the double-aught year is a leap year), and 36,525 divided by 7 leaves a remainder of 6. If there had been one more day in the century, we would have been fine. Maybe the United Nations could add an extra Saturday to the year 1999? We could have the extra day added to Christmas weekend...5
So, if any of your two-digit year programs are determining the weekday, they are probably assuming a date in the twentieth century as the base and will be off by one day. Watch out for scheduling programs especially.
Another possibility for error in the day of the week is occasioned by confusion over whether the year 2000 is a leap year (it is, see section 3.6). If any programmer mistakenly believed it was not a leap year, all days in the year 2000 after Leap Day would be off by one day, and Leap Day itself might be found invalid.
The day-of-the-week algorithm is one instance where a solution that involves expanding dates to four digits might require changes to program logic as well. Most day-of-week algorithms will need to be looked at to be sure they yield the correct result.
1.7 Symptom VII. The One you Forgot About Alas, this is the most insidious problem of all. Who knows what some sadistic programmer might have done to your innocent date fields in some program? That programmer might even have been you! Things to watch for:
The date or year is sometimes embedded in a key field used as an identifier for a record. This will be an especial problem if the key field is a storage key for the record on your database. In some storage schemes, for example, CODASYL hierarchical or network databases such as IDMS, the actual storage location is calculated from the key. This means that if you expand this year your database records will be in a randomly determined wrong location in the database. Therefore, the records will have to be moved as well as expanded, which could increase the demand on your system exponentially.
A special case of the one you forgot about is the one you didn't even know about. Computer users abhor a vacuum. Consider the case of an Accounts Payable system used in a dozen Pacific Rim countries. There was a six-byte field that was used in only a couple of the countries. When the field became obsolete in those countries, the programmers tried to remove the field, and there was a howl that could be heard across the Pacific! The other countries had used this field to cram an amazing amount of additional data into each record. Watch out for this situation and the opposite, where an unused date field contains something other than dates.6
The "Forgot About It" category is one reason why, no matter how carefully you test your systems, you'll need to be available for problem solving the weekend of December 31, 1999 through January 3, 2000. If it's any consolation, this weekend is actually not the turn of the Century or the Millennium (that's in 2001), so stick to ginger ale this time and make up for it when the Millennium turns in 2001. When does 21st Century begin?
Here's a philosophical question for you: When is the Turn of the Century (and thus the Millennium): 2000 or 2001?? Consider that there was no year Zero: the year before the year 1 c.e. was 1 b.c.e. This must mean that the First Century began on the first day of the year 1, and ended on the last day of the year 100. Therefore:
1 through 100 was the 1st Century 101 through 200 was the 2nd Century 201 through 300 was the 3rd Century
.
. 1801 through 1900 was the 19th Century 1901 through 2000 was the 20th Century 2001 through 2100 is the 21st Century
So, the Century, and Millennium, will turn not on January 1, 2000, but on January 1, 2001. That being said, the most people probably mean "the century that began in 1900 and ended in 1999" when they say "the 20th century", and this meaning is used loosely in this book. "What's the difference?" you may say. Well, if you're reading this item, the probability is very high you will be working, or at least on call, the night of December 31, 1999, and all day and night on January 1, 2000. If you believe the turn of the century will be in 2001, you may take some small consolation in the fact you are missing only New Year, not the New Century and New Millennium.
1.8 Fail Safe Many devices in use today have potential to cause harm. Elevators can fall from great heights, brakes can fail on automobiles causing accidents, and nuclear power plants can melt down. To prevent these kinds of accidents, engineers use a principle called "fail-safe". This means that when any error is detected the system must fail in the safest way possible. As a consequence, a computer controlling one of these devices may trigger a shutdown if it diagnoses any error, for example if it seems like periodic maintenance is long overdue; or if it can't determine what day it is because the date contains zeroes in the year. Normally, this fail safe mechanism is a good idea. But after reading about the Seven Warning Signs you can see how the year 2000 might trigger a fail safe shutdown. The elevator might return to the ground floor so it can't fall; the car might not start so the brakes won't fail; the nuclear power plant might shut down to prevent meltdown.
Computer systems often fail-safe. IBM has set up its MVS mainframe runtime system to "Abnormal End", or Abend, a program that encounters bad data or incorrect file formats. The concept is that it is better to stop the program from running than it is to allow it to run and produce an error. This can be frustrating, since a minor error in one record in a file of one million records will prevent you from processing any of the records. So if the program has trouble printing the run date of the report, it may refuse to print the report at all until the run date is fixed. This normally prudent philosophy may cause a completely inconsequential date field to block processing for your entire system if any field becomes corrupted by twenty-first century dates.
Less drastic, but just as frustrating, is what Keogh calls "Error Detection Gone Crazy"[1]. In their zeal to prevent bad data from being accidentally entered into the computer, programmers may have inadvertently made it impossible for you to enter correct data. Often, dates entered on screens are tested to be sure they aren't zero, aren't too low, aren't less than today's date. Thus the very edits designed to protect you from error may make it impossible for you to do your job. Luckily, disabling edits is usually a simple program fix, but if there are hundreds to be disabled at once, it might take some time, and of course you'll lose all the protection the edit afforded. It may be necessary for a lot of people to become liars-it will be necessary to lie to the computer about a lot of dates to defeat the error detection mechanism the programmers so carefully designed. For example, if the driver license expires in '00, you may have to lie to the computer and tell it the license expires in '99, or '01 to make the transaction work. Try to keep track of the lies so you can clean them up after the program is fixed.
1.9 Embedded Systems Modern people use computers in their daily life without even knowing it. Almost every modern home has several computers that the owners are not even aware of. Many devices in operation today contain what is called an embedded system which is a computer is built into the device. VCRs, microwaves, washing machines, and automobiles can all contain computers that control the device's operation. Unbeknownst to the owners as well, these may fail come the year 2000.
Modern factories, assembly lines, industrial robots, and machine tools are controlled by computers-on-a-chip called PLC's (Programmed Logic Controllers). If a date problem causes a failure, assembly lines may shut down. There are even warehouses in Japan where there are no lights. Since the warehouse operations are conducted by robots, light is unnecessary. If these robots fail, the ability of the warehouse to function could be limited by the supply of miners' hats with lights on them.
As an example of how responsible computers have become, consider the navigation of ships at sea. American President Lines (APL) operates some of the largest, most modern container ships in the world. You might be surprised to learn that at night the crew goes to sleep! The entire crew. Everyone. The ship is steered by a computer. If something goes wrong that the computer can't handle, it rings an alarm in the appropriate cabin. It knows which problems need a mate and which need an engineer, and who is on call. Sometimes, in the morning, there'll be a message from the computer: "Computer changed course to avoid a storm." Or: "Computer slowed ship to save fuel since ship was ahead of schedule." It might be a good idea for someone on those ships to stay up to bring in the new year, 2000.
The point to be considered is this: businesses and homes may have surprising failures caused by these ubiquitous embedded systems. 7 Perhaps the device or appliance was built such that the product may be unusable if the dates are bad. It is difficult to get a definitive answer about any given product or group of products. Fear of lawsuits and adverse publicity seem to have conspired to exacerbate the potential problems with uncertainty. But the news isn't all bleak. In the next chapter, we'll look at some of the factors that are on our side.
1.10 Other Date Range Limits The two-digit date representation is not the only one that can cause problems. Some dates are stored in a date and time format that counts the time to a small increment, sometimes a fraction of a second, in a small field. Like two-digit dates, these fields have limitations, but they will occur in various years depending on how they are formatted. An example is the GPS (Global Positioning Satellite) counter that will roll over on August 21, 1999. The MITRE Group classifies this as one of the four aspects of the complete Y2K problem [2]. Most business systems, however, are probably unaffected by GPS.
Before Microsoft Excel 97, dates could not be specified beyond 12/31/2078, so if you haven't upgraded to Office 97 there could be a problem if you need to record dates far into the future. The Microsoft Foundation Class (MFC) CTime object used to program many PC's running Windows is limited to dates between January 1, 1970, and February 5, 2036. The good news about these date limitations is they are random so you don't have to face a crushing volume of millions of bugs. The bad news is they are random so there is no consistent date they can be expected on.
1.11 Levels of Software Another factor clouding the issue is the number of levels of software involved. As Figure 1.1 shows, there are frequently as many as seven levels of software involved in what seems to the user to be a single product. There is a physical machine, running an Operating System (O/S), storing data in a Data Base Management System (DBMS), with a Language providing a package that in used for the Application. A Y2K problem at any level can cause you grief. And often these levels are provided by different manufacturers at different times, so compatibility is a problem under the best of circumstances. Software levels will be discussed further in Section V. References [1] Keogh, Jim, Solving the Year 2000 Problem, Boston: AP Professional, 1997, page 41-42. [2] The MITRE Group, "What is the Y2K Problem?" www.mitre.com, p. 2.
Product Details
Would you like to update product info or give feedback on images?
|
More About the Author
Discover books, learn about writers, read author blogs, and more.
Customer Reviews
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
4.0 out of 5 stars
Quite good & easy to understand.,
By A Customer
This review is from: Solving the Year 2000 Crisis (Artech House Computer Science Library) (Hardcover)
I enjoyed reading this book. It is quite interesting and also easy to understand. I will be happy if some more details of Y2K solutions are given.
Share your thoughts with other customers: Create your own review
|
|
Tag this product(What's this?)Think of a tag as a keyword or label you consider is strongly related to this product.
Tags will help all customers organize and find favorite items. |
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
Customer Discussions
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|
