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

by Patrick McDermott

 

Our Price: $59.00

Buy this book

Availability: This title usually ships within 24 hours. Hardcover - 301 pages (May 1998); Artech House; ISBN: 0890067252; Dimensions (in inches): 1.08 x 10.32 x 7.27; Amazon.com Sales Rank: 182,638; Avg. Customer Review:**** ; Number of Reviews: 1

Review

      Book Description
      The millennium is almost upon us, and with it comes the single most troubling dilemma in computer history: how to solve the Year 2000 (Y2K) problem. This expertly authored, one-source reference provides an answer to this problem by revealing practical how-to instructions on planning,  preparing and executing a project that will make your company Y2K compliant.

      Solving the Year 2000 Crisis helps programmers, managers, and consultants gain a clear understanding of the Y2K problem - and how to beat it - from the ground up. It closely examines and evaluates the 7 major problem-solving approaches currently available, helps you choose the best method for your particular company or organization, then provides you with the information you need to implement a solution.

      Well-written sections on project staffing and management help you determine whether to build your Y2K team with existing employees or consultants, and show you how to choose the best tools for improving their productivity. The book also addresses the business side of the Y2K issue - you learn the impact of the problem on PC and desktop systems, and how to find and test potential failure points. Appendices contain actual problem-solving program code in COBOL, C++, FORTRAN and Visual Basic.

      Solving the Year 2000 Crisis helps programmers, managers, and consultants gain a clear understanding of the Y2K problem and 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.

      The author, Patrick McDermott pmcdermott@msn.com , May 31, 1998
      No Doom and Gloom, just Practical Solutions
      Not Doom and Gloom, but hardheaded, practical solutions for planning, preparing and executing a project to make your company Y2K compliant.

      Excerpted from Solving the Year 2000 Crisis by Patrick McDermott.
      Copyright © 1998. 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. 
       

Buy this book