Solving the Year 2000 Crisis (Artech House Computer Science Library) - Hardcover

McDermott, Patrick; McDermott, Peter

Hardcover

ISBN 10: 0890067252 ISBN 13: 9780890067253

Publisher: Artech House Publishers, 1998

Synopsis

Solving the Year 2000 Crisis helps programmers, managers, and consultants gain a clear understanding of the Y2K problemand how to beat it - from the ground up. It closely examines and evaluates the seven major problem-solving approaches currently available, helps readers choose the best method for a particular company or organization, then provides the information needed to implement a solution. Well-written sections on project staffing and management help project managers determine whether to build a Y2K team with existing employees or consultants, and provide advice on choosing the best tools for improving their productivity. The book also addresses the business side of the Y2K issue - it explains the impact of the problem on PC and desktop systems, and details how to find and test potential failure points. Value-added appendixes contain actual problem-solving program code in COBOL, C++, FORTRAN, and Visual Basic.

About this title

About the Author

Patrick McDermott has more than 20 years of computer industry experience as a programmer, analyst, developer, manger, and trainer. He currently teaches seminars on the Y2K Problem, and also runs his own consulting firm in California, where he specializes in Y2K Problem training.

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 200...

Edition details

• Publisher: Artech House Publishers
• Publication date: 1998
• ISBN 10: 0890067252
• ISBN 13: 9780890067253
• Binding: Hardcover
• Language: English
• Number of pages: 310