Y2K Bug

Y2K – The Big Issue Abstract and Executive Overview What is the Y2K issue? This paper will describe the problems associated with Y2K and how Industry, Government, and Small Businesses are handling the problem. The first chapter introduces the Y2K issues. Chapter 2 will define how this affects the different businesses and Government agencies. Chapter 3 will develop an overall plan on how to attack the problem and recommendations. The majority of this paper will develop a plan on how each of the businesses and Government agencies should attack the Y2K problems. There should be a logical approach to planning how to investigate, test, validate, and if required, develop a contingency plan for Y2K. The job is to either form a team of personnel or hire a consulting firm to assess your situation. The team should employ the following steps: assess the system, renovate the system if necessary, validate the renovation if necessary, implement the renovation if necessary, test the renovation if necessary, and finally have a contingency plan in the event that renovating the system is not feasible and/or is too late. The only necessary or required action is to assess the system. This will be discussed in detail in my paper. The real issue is that less than a year remains before the year 2000 problems are here. The recommendation is to begin working this issue now. It may be too late, but that is when the contingency plan comes in handy. TABLE OF CONTENTS 1. What are the Y2K Issues? 2. What impacts are they’re to Government, Industry, and Small Business? 3. What can Government, Industry, and Small Business Do to Combat the Y2K Issues? 4. Recommendation 5. References 6. Glossary Chapter 1 What are the Y2K Issues? There are actually more dates than just the year 2000 date. There are dates that can impact the leap year algorithms; Julian dates, fiscal year dates, calendar dates, and ASCII code dates. The top dates that need to be checked are: 1. 9 September 1999. This date can be read in code as 9999. In computer language, specifically ASCII code, this translates into a request for the processor to stop processing. 2. 1 October 1999. This is the start of the new Fiscal year for the Government (FY00). The algorithm for this may not be able to go from FY99 to FY00. 3. 31 December 1999. At midnight, the date rolls over to 1 January 2000. This problem can exist in two areas. The first is in the BIOS’s that exist for most desktop machines. The BIOS’s normally contain the clock and date data. The operator updates this data, when the system is first turned on and is continuously updated by the computer from then on. The problem is that older versions of BIO software recorded the date in two year digits (99, instead of 1999) so that once the date rolls into the year 2000, the BIOS’s can not understand the rolling of the year and moves it back to 14 Jan 80, the default year date. The other problem is in the application software that uses the two-year date. The application software uses algorithms to roll over the dates and can not roll to the year 2000 date. It normally has to be manually input to get to the new date. 4. 28 February 2000. At midnight, the date should roll over to 29 February 2000. This is determined in the software by an algorithm that checks to see if the current year is a leap year. If it is a leap year then it should roll to 29 February 2000, if it can not determine the leap year, then it will jump to 1 March 2000. 5. 29 February 2000. This is almost the same problem as 28 February 2000. It will try to calculate the fact it is a leap year and roll the date to 1 March 2000. If it can not determine that it is the leap year, it will either go to 2 March 2000 or it will provide an incorrect date. There are several other dates that are important, based on each application software package, and needs. Examples are, a bank computer uses COBOL software that does not calculate the dates well, FORTRAN