1 / 49

Section 2: Year 2000 Storm

Section 2: Year 2000 Storm. Shi-Ming Huang. References. Robert A. Martin, 1997, “Dealing with Dates: Solutions for the Year 2000”, IEEE Computer, Vol. 30, No. 3, March 1997.

archie
Télécharger la présentation

Section 2: Year 2000 Storm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Section 2: Year 2000 Storm Shi-Ming Huang

  2. References • Robert A. Martin, 1997, “Dealing with Dates: Solutions for the Year 2000”, IEEE Computer, Vol. 30, No. 3, March 1997. • Philip H. Newcomb and Melvin Scott, 1997, “Requirements for Advanced Year 2000 Maintenance Tools”, IEEE Computer, Vol. 30, No. 3, March 1997. • The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation, IBM Report GC28-1251-00, 1996; http://www.s390.ibm.com/stories/tran2000.html. • Federal Government Year 2000 Information Directory, http://www.itpolicy.gsa.gov/mks/yr2000/y201toc1.htm • The Year 2000 Information Center, http://www.year2000.com • Mitre Y2K Home Page, http://www.mitre.org/research/y2k • CA Discovery Home Page, http://www.cai.com/products/ca2000/2000menu.htm • The Year 2000: A Practical Guide for Professionals and Business Managers, the British Computer Society, November 1996, ISBN 0 901865 974 • Proposal Criteria for “Century Compliances”, GTE Technology & System, 1996.

  3. 2.1 What is the Y2K problem? • Representing the year as a two digit number, causing failures in arithmetic, comparisons, sorting, and input/output to databases or files when manipulating date data • Using an incorrect algorithm to recognize leap years for years divisible by 400 • Hardcoding “19” into software routines or using two-digit years with “99” and “00” as reserved values meaning “never delete this” or “this is a demonstration account,” respectively (sometimes called “magic numbers”) • System date data type that may roll over and fail due to the storage register filling up.

  4. Hardware – Problem Identify • A hardware timer is the key component in determining the date and time to an operating system or application. The timer is initialized with a value, based on a time and date, and is incremented at a sub-second factor. This value is then converted, upon request, to a date and time, and returned back to the operating system or application. Depending on the size of this timer and the routines used to convert this timer value into a time and date, errors can result when the timer value represents a year value of 2000 or beyond.

  5. Hardware – Problem Identify • Earlier systems did not contain an internal battery, so the time needed to be set during each power on/IPL (Initial Program Loading) sequence. Later systems included an internal battery, and were able to maintain the date and time across IPLs. Regardless of the method used, the date and time are accessible by the operating system and applications. However, when the date changes from 1999-December 31-to 2000-January-1 depending on how the timer is implemented, different results can be returned to the operating systems and applications.

  6. Hardware – Problem Scope Any hardware that contains a timer needs to ware the Y2K problem. For example: • Mainframe, • Midrange computer, • Microcomputer, • PC , • Storage machine, • Printer, • Network Machine, • Output Device, • PBX, etc.

  7. Hardware – Problem Testing The testing was focused on the hardware timers and associated firmware. Because of their age and lack of formal support, users must perform careful in-house testing well in advance of the year 2000.

  8. Hardware – Problem Testing For Example: • Personal computers (PCs) include read-only memory (ROM) software called the basic input-output system (BIOS), which is responsible for basic boot functions and managing persistent data such as the date and time. Some Intel-based PC BIOS software do not correctly roll dates across the year 2000 boundary. • PCs maintain two dates: one date in the hardware internal clock called the real-time clock (RTC), and one in the operating system software (e.g., DOS or Windows). The date in the operating system software is created by converting the date in the internal clock. • The RTC is battery-supported (to maintain the date and time when the system is powered down); the RTC is also where the computer gets the date as it boots. Older Intel-based PCs have faults in their RTC that prevent them from rolling the century over properly. This improper date is then picked up by the operating system as the computer boots up, and is passed on to application programs when they call the operating system for the current date and time.

  9. Hardware –Case Study: TATUNG TCS-8950T PC System Specification: CPU: Intel 80386 OS: MS-DOS Manufacturing Date: December, 1990 Manufacturer: Tatung CO., Taiwan

  10. Hardware –Case Study: TATUNG TCS-8950T PC MS-DOS Date Screen

  11. Hardware –Case Study: TATUNG TCS-8950T PC BIOS Setup Screen

  12. Hardware –Solution Hardware issues are the most basic in that solving them depends on manufacturer support .

  13. Software – Problem Identify • The software can be classified into two types: i.e. command-and-control system and information system. The main Y2K problems for both two types are the program code or data structure: • Representing the year as a two-digit number; • Using values such as 98, 99 and 00 as special flags or hardcoding "19" into output routines; • Failure to recognize 2000 as a leap year; • Rollover of date data types stored as offsets from a known date.

  14. Software – Problem Scope • Any software that does not pass the year 2000 compliance needs to ware the Y2K problem. For Example: • Languages and Compilers: such as Cobol, Fortran, C, etc. • Operating Systems: such as MVS, VM, OS/400, MS-DOS, etc. • Database Management Systems: DB2, IMS, SQL, etc. • And more: such as Transaction Processing Systems, EDI, Banking Systems, Spreadsheets, etc. .

  15. Software – Problem Testing The testing process involves date searching and impact analysis. • For the first problem, date keywords are used, for which there is considerable experience (see sample keyword lists). • Most Common Date Keywords: after, asof, as-of, before, begin, cal, calendar, ccyy, ccyymmdd, cen, century, clndr, cur, curr, current, cymd, date, day, days, dob, dt, dte, eff, effective, end, finish, first, fiscal, from, frm, fy, fye, greg, gregorian, horizon, jul, julian, last, leap, mdy, mmddyy, mmddyyyy, mo, modayr, mon, month, mos, mth, mm/dd/yy, m/d/y, m-d-y, post, roman, start, stop, sysdate, sysdte, through, thru, today, week, weeks, wk, wkly, wks, year, years, yr, yrs, yy, yyddd, ymd, yymmdd, yyyymmdd, yymmm, '00/00/00','12/31/99' ,'19','1999' • Impact analysis involves following data flow for inputs, parameters and constants to determine areas affected by potential non-compliant values.

  16. Software – Problem Testing The testing process involves date searching and impact analysis. • For the first problem, date keywords are used, for which there is considerable experience (see sample keyword lists). • Most Common Date Keywords: after, asof, as-of, before, begin, cal, calendar, ccyy, ccyymmdd, cen, century, clndr, cur, curr, current, cymd, date, day, days, dob, dt, dte, eff, effective, end, finish, first, fiscal, from, frm, fy, fye, greg, gregorian, horizon, jul, julian, last, leap, mdy, mmddyy, mmddyyyy, mo, modayr, mon, month, mos, mth, mm/dd/yy, m/d/y, m-d-y, post, roman, start, stop, sysdate, sysdte, through, thru, today, week, weeks, wk, wkly, wks, year, years, yr, yrs, yy, yyddd, ymd, yymmdd, yyyymmdd, yymmm, '00/00/00','12/31/99' ,'19','1999' • Impact analysis involves following data flow for inputs, parameters and constants to determine areas affected by potential non-compliant values.

  17. Software – Case Study:CA-Impact/2000 It is a powerful impact analysis tool that helps you determine the impact and cost of converting applications to support the Year 2000. CA-Impact/2000 analyzes all of your COBOL programs and copybooks on a library-by-library basis, looking for fields that may contain dates. Predefined date patterns identify the date fields in your program.

  18. Software – Case Study:CA-Impact/2000 Once the date fields are detected, the Analyzer provides helpful analysis at various levels.

  19. Software – Case Study:CA-Impact/2000 Once the date fields are detected, the Analyzer provides helpful analysis at various levels.

  20. Software –Solution • There are at least seven major, viable courses of action, which can be combined as appropriate, to deal with an organization's Y2K problems: • Expanding the year field to four digits: • Encoding century information in a six-digit space • Using a 100-year logic window • Employing a data bridge that uses a logic window • Reversing the system clock and using a 28-year time bridge • Removing hardcoded values and use of special flags in date fields • Code all three leap year rules into programs • Determine the span of time that date data types will work over and use them appropriately • Replacing the system (including retiring it)

  21. Software –Solution: Expanding the Year Field to Four Digits • This solution requires all references to and uses of a two-digit year format (YY) be converted to a four-digit year format(YYYY), and all programs must be converted to use the new format. The major risk in this approach is that a program may directly access the internal structures of a date field, thus changing the field size without also changing the logic accessing the internal structure will corrupt the revised system. • This solution is complete, and it ensures that your applications will operate correctly for the next 2,600 years. However, it involves modifying every program and every database that references date data; adjusting every positional reference to data fields; changing the format of every record that contains date data; and reformatting and rewriting every data file, including historic data files.

  22. Software –Solution: Expanding the Year Field to Four Digits • This approach may also require changing the format of messages among systems, initiating a chain of changes that will require simultaneous testing and rollout of the new systems across organizations.

  23. Software –Solution: Encoding Century Information in Six Digits There are at least five ways to do this: • Encode full Julian Dates (the number of days elapsed since noon January 1, 4713 B.C.4 ) in a binary 48-bit field, allowing values for dates well beyond anything we should care to record (YYMMDD [left arrow] BBBBBB, B = 8-bit binary). • Use the two 8-bit YY fields to encode the full year in a binary 16-bit field, allowing values for the years of 216 -1=65,535 (YYMMDD [left arrow] BBMMDD, B = 8-bit binary). • Encode a century field (0 = 18, 1 = 19, 2 = 20, and so on) and replace the MMDD with a day-of-the-year field DDD (YYMMDD [left arrow] CYYDDD). • Encode a century field as above and encode the month as a character field (M*) with values 1-9, A, B, C representing the 12 months (YYMMDD [left arrow] CYYM*DD). • Encode the entire six-digit date field into an offset from 1 January 1900, which would also be good for the next 2,600 years (YYMMDD [left arrow] DDDDDD).

  24. Software –Solution: Using Logic Windows • The sliding window technique uses a self-advancing, 100-year interval that generally crosses a century boundary. This technique determines the century of a 2-digit year by comparing the 2-digit year against a window of 100 years. The user specifies the number of years in the past and future relative to the system year. For example, if the range is 1 January 1954 through 31 December 2053, then YY greater than or equal 54 indicates 19YY otherwise YY less than or equal 53 indicates 20YY.

  25. Software –Solution: Using Logic Windows • Advantages: • Requires changes to only programs • Windowing is built into some programming languages • Disadvantages: • Considered a temporary solution • Not applicable for organizations whose data span more than 100 years • Does not provide collating sequence support • Does not provide indexing sequence support

  26. COBOL Example with Language Environment Sliding Window • The first example illustrates using the Language Environment century window for a date in the future, a maturity date. • Call CEEDAYS to convert the MATURITY-DATE to an integer Lilian date • Call CEESCEN to set the century window to the current year • Call CEEDATE to convert the Lilian to a character string with 4-digit year • In this example, the maturity date 090425 (year 09, month 04, day 25) becomes 20090425 (year 2009, month 04, day 25).

  27. COBOL Example with Language Environment Sliding Window IDENTIFICATION DIVISION. PROGRAM-ID. FUTURE-DATE. DATA DIVISION. WORKING-STORAGE SECTION. * feedback code for callable service 01 FC PIC X(12). * parameter for CEESCEN 01 START-CW PIC 9(9) COMP. * parameters for CEEDAYS 01 MATURITY-DATE. 02 Y2 PIC 9(2). 02 M2 PIC 9(2). 02 D2 PIC 9(2). 01 PIC2STR. 02 PIC2STR-LENGTH PIC 9(2) COMP VALUE 6. 02 PIC2STR-STRING PIC X(6) VALUE "YYMMDD". 01 LILIAN PIC 9(9) COMP.

  28. COBOL Example with Language Environment Sliding Window * parameters for CEEDATE 01 NEW-DATE PIC X(80). 01 NMDATE REDEFINES NEW-DATE. 02 YYYY PIC 9(4). 02 MM PIC 9(2). 02 DD PIC 9(2). 02 FILLER PIC X(72). 01 PIC4STR. 02 PIC4STR-LENGTH PIC 9(2) COMP VALUE 8. 02 PIC4STR-STRING PICX(8) VALUE "YYYYMMDD". PROCEDURE DIVISION. *************************************** * set century window to start with the * current year (current system date) *************************************** MOVE 0 TO START-CW. CALL "CEESCEN" USING START-CW FC. ******************************************* * convert 2-digit maturity date year into * integer value to get a COBOL Lilian date ******************************************* CALL "CEEDAYS" USING MATURITY-DATE, PIC2STR, LILIAN, FC. ************************************************** * convert COBOL Lilian date into YYYYMMDD format ************************************************** CALL "CEEDATE" USING LILIAN, PIC4STR, NEW-DATE, FC. END FUTURE-DATE.

  29. Software –Solution: Employing a Data Bridge Using a Logic Window This solution is very popular because: • it allows for a fairly straightforward conversion of the applications to a four-digit year, but; • allows external interfaces to continue in two-digit formats by having simple data bridges that map the internal and external date data through a logic window approach for all inputs and outputs.

  30. Software –Solution: Reversing the System Clock and Using a 28-Year Time Bridge • For systems that no longer have the source code, cannot recompile the source code, or have purchased components that are not century ready, there is an option other than replacement. • You can reverse the system clock by 28 years and write bridging scripts that add or subtract 28 years from the date data. The number is 28 because this offset retains the same days of the week and month. Adding 28 years to Saturday, 1 January 1972 will generate a new date of Saturday, 1 January 2000. • Note that this works only for periods that have a leap year every four years (1901-2100). So this approach is only good until 28 February 2100. .

  31. Software –Solution: Removing hardcoded values and use of special flags in date fields • The problem comes from hardcoded values in software routines such as "19" for the implied century and/or use of "99" and "00" as reserved values meaning "never delete this" or "this is a demonstration account," respectively (sometimes called "magic numbers") which limit the range of year values and may cause date comparisons to fail or pollute output values. • Other magic number dates include: 9/9/99, 99/99/99, 1/1/1, 1/1/11, 6/9/69, 6/7/89, 1/23/45, 6/6/66, 7/7/77, 8/8/88, and 12/31/99.

  32. Software –Solution: Calculating Leap Years Correctly The three rules which the Gregorian calendar uses to determine leap year are as follows: 1.Years divisible by four are leap years, unless... 2.Years also divisible by 100 are not leap years, except... 3.Years divisible by 400 are leap years. Therefore, the year 2000 is a leap year according to rule number three. The simple expression: if (year mod 4 == 0) && ((year mod 100 != 0) || (year mod 400 == 0)) {use 29 for days in February} else {use 28 for days in February} • The problem arises from difference between the internal representation and external representation. One common standard solution uses four digit years in the internal representation. This is okay for some purposes, but not all. For example, human interface may have been intended to be user friendly and supply the century, so that the actual input has just two digit years. The other issue is that the rest of the date fields (e.g., two digits for the month and the day in the month) may not be very convenient for doing the necessary operations. The whole eight digits also may not be very convenient for long-term storage. This of course is the Y2K problem.

  33. Software –Solution: Determine the span of time that date data types will work over and use them appropriately The most interesting issue is date representation. There are enough ways to do this to make procedural issues seem straightforward. What is involved is satisfying some familiar "application constraints" in a way that supports all the ways of using the data. When changes for Y2K compatibility become the major consideration, this means some alternative representations have to be considered. The external representations are almost always strings, since human readability is usually an overriding issue. The internal representation is affected by tradeoffs in storage size and operational efficiency. The major alternatives to expanding the representation to four digit years in a string representation (already identified as the simplest approach) are:

  34. Software –Solution: Determine the span of time that date data types will work over and use them appropriately • using days (or sometimes seconds) from some carefully chosen base • using binary representations (e.g., of year, month, and day) in an easily accessed data structure (like a C++ date class), • treating the string representation as having packed digit component values rather than ASCII values (e.g., using packed decimal in COBOL and PL/I), so that more range can be encoded.

  35. Software –Solution: Replacing or Retiring the System • For some systems, the best option may be to replace them with Y2K-safe commercial products that do most of what you need. An interesting alternative to buying a commercial product is to merge with or buy a company that has Y2K-safe systems and retire your own.

  36. The Methodology for the Year 2000 Problem • Technical experts tend to talk about what changes are needed in how software handles and stores date data. Program managers tend to talk about planning, estimation, and inventory. Higher-level managers tend to talk about the cost and the diversion of resources. Each person struggling with the Y2K challenge tendsto focus on that part of the solution uppermost in his or her mind.

  37. The Methodology for the Year 2000 Problem • A typical Y2K effort has six major phases. They are: • Awareness • Inventory • Assessment and planning • Renovation • Validation • Implementation

  38. The Methodology for the Year 2000 Problem

  39. Methodology: Phase 1-Awareness • Each organization must educate their people about what the Y2K problem is and how to deal with it. • Many have a hard time believing that something as trivial as a lack of two digits in a date can cause a serious problem.

  40. Methodology: Phase 1-Awareness • Each organization must educate their people about what the Y2K problem is and how to deal with it. • Many have a hard time believing that something as trivial as a lack of two digits in a date can cause a serious problem.

  41. Methodology: Phase 2-Inventory • Scope the problem and lay out a high-level plan of activities. • Inventory all systems and system components. Go beyond MIS systems to identify all systems at risk. Do a high-level inventory of potentially affected code. • Make a estimate of cost. Use source lines of code totals for developed systems multiplied by industry cost factors to generate a quick estimate. • Refine the plan. Identify priorities, using disaster recovery plans to identify critical systems. Rewrite disaster recovery plans to reflect the Y2K problem and include safety consequences and secondary effects.

  42. Methodology: Phase 3-Assessment, and Planning • Conduct a detailed assessment of the portfolio, using a consistent definition of Y2K problems. • For developed systems, use available tools, such as Impact Analysis, Software Conversion (Figure) • For purchased, interfacing, and other critical systems, use a compliance questionnaire to interview the owners of the systems. The questionnaire is focused on establishing the types of issues that are, or are not, addressed by the other party (see Appendix).

  43. Methodology: Phase 3-Assessment, and Planning • Once you understand this, you can gauge the risk this poses to your systems and then decide whether you want to negotiate a fix or a replacement. • Identify potential solutions and their costs in dollars, schedule, and ripple effects. • Refine the plan and get upper management approval of plan and its schedule and cost estimates. • Make a full system backup of everything.

  44. Analysis of Data Fields as Guided by Century-Compliance Criteria. (GTE)

  45. Methodology: Phase 4-Renovation • Now you are ready to commence implementing fixes. Here you must define new and/or revised procedures and accompanying training, brief upper management on changes and revisions so that adjustments can be approved quickly, and use modern techniques to identify needed design changes.

  46. Methodology: Phase 5-Validation • Testing against the century-compliance criteria falls into the following three categories: • General. Some aspects of century compliance are independent of technology and application domain. For example, Jan. 1, 2000 follows Dec. 31, 1999 for all hardware and software. • Technology-specific. Some aspects of century compliance depend on the technology and the behaviors and features of that technology. • Domain-specific. Some aspects of century compliance depend on the requirements of a specific application. For example, the valid ranges for dates to be tested can vary with each application.

  47. High-Level Guidelines for Test Cases in Y2K Test Procedures.

  48. High-Level Guidelines for Test Cases in Y2K Test Procedures.

  49. Methodology: Phase 6- Implementation • Here you field fixes, including training end users. While most organizations will be able to use their traditional methods for fielding new systems and upgrades for the changes needed for Y2K, there will probably be several additional issues that impact their traditional approach. The need to ensure that all changes are implemented on time against a firm, no-slip deadline, will be new for many organizations. The simultaneous changing of commercial components, developed components, and procedures will also be new for many. Finally, for those forced into a change in their interfaces, the coordination and simultaneous activation of your new release with your interfacing partners will be especially challenging when more than one interface is changing.

More Related