The Year 2000 (Y2K) Problem a.k.a. the Millennium Bug

October 12, 1998 PSE MEMO FOR BROKERS NO. 484-98 SUBJECT : The Year 2000 ( Y2K ) Problem a . k . a . the Millennium Bug Foreword : This Memorandum to Brokers is being disseminated to Maintain the awareness of member-brokers about the year 2000 issues and other concepts in making one Y2k compliant, Update member-brokers about the readiness of the Exchange to handle the Y2k problem, Show to member-brokers how preparations are done to be Y2k compliant, and Announce the conduct of the integration test to be participated by all the stock market players xxx xxx xxx I. Introduction Everybody must have heard of the phrase "Year 2000 problem" or the buzzword "Y2K" one way or the other. There has been so much hype that no one can claim anymore that he has not even heard about it. But what exactly is it? How will it impact your computer or your company? If nothing is done about it, the problem could result to a significant confusion for your company as the year 2000 comes near. The following scenarios can happen to you on the first business day in the year 2000: Accounting tells you that the outstanding invoices system has gone mad and is spewing paper out demanding invoices that were paid years ago! Marketing tells you her customer database, now shows everyone's ages as having gone negative! Personnel says the payroll is showing nobody has gone to work! Research called in complaining that they cannot make their computer start even if they have switched it on several times already. In fact even before the year 2000 arrives, you may be experiencing your computer "hanging" whenever you deal with data that contain dates that when processed by the computer results to a date extending to the year 2000. Examples would be when you grant a loan now that will mature in January 2000, when you hire a contractual employee that will have to go by February 2000, or when you enter in your computer a lease agreement that will last until year 2002. To ensure that you will not have the dark scenarios described here, you must prepare your computer systems for the Year 2000. Since the activities to be done will be time consuming, you need to get every computer and piece of software running on it checked out NOW!!! When you have your systems checked for Year 2000 compliance have them check for 29 February 2000 compliance too! Year 2000 is a leap year and your computer system may just not be prepared to treat it as a leap year and therefore would result to wrong date calculations. LLphil An Explanation of the Year 2000 Problem The Year 2000 problem arises in computer systems that have not been designed to process date references to the year 2000 and beyond. Computer programmers in their effort to save valuable disk and program space adopted a convenient shortcut in handling years. Instead of storing 1998 as a four digit year, they simply stored it as "98". The programs they created understood the two digit year to be a year with the prefix "19". This convention worked just fine until we get near the next millennium. The next year to 1999 would be 2000 but the last digits "00" when used will be interpreted by the program again as 1900 instead of 2000. Date calculations such as computing the age of a person, number of days between two dates, or determining maturity dates will result to negative numbers or errors. Some computers when they meet an error in computation simply just hang and freeze thereby ruining your work. When programmers use the convention of storing years as a four-digit number, this problem will occur once again when we reach the year 10000. We need not solve that problem now and instead leave that to the next generation of people, if any, living that time! LexLib A definition of year 2000 conformity requirements By employing simple modifications in the currently running computer programs and ensuring that they pass properly and prudently designed tests, one can already claim that they are year 2000 ready. There is a however a widely accepted definition of Y2K compliance and we have quoted that definition here for the guidance of all concerned. While PSE has already come up with a thoroughly tested and now working Y2k ready system, yet we are still working towards a completely Y2k compliant system as per the definition of this standard. There are also some institutions that offer consultancy services by going through one's program of activities and render an opinion as to whether that company has done their Y2K compliance properly as per the standard Y2K compliance checklist. This following document addresses what is commonly known as Year 2000 conformity (also sometimes known as century or millennium compliance). It provides a definition of this expression and requirements that must be satisfied in equipment and products which use dates and times. It has been prepared by British Standards Institution committee BDD/1/-/3 in response to demand from UK industry, commerce and the public sector. LLpr Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during and after the year 2000. In particular: Rule 1. No value for current date will cause any interruption in operation. Rule 2. Date-based functionality must behave consistently for dates prior to, during and after year 2000. Rule 3. In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules. Rule 4. Year 2000 must be recognized as a leap year. cdll Amplification of the definition and rules Problems can arise from some means of representing dates in computer equipment and products and from date-logic embedded in purchased goods or services, as the year 2000 approaches and during and after that year. As a result, equipment or products, including embedded control logic, may fail completely, malfunction or cause data to be corrupted. To avoid such problems, organizations must check, and modify if necessary, internally produced equipment and products and similarly check externally supplied equipment and products with their suppliers. The purpose of this document is to allow such checks to be made on a basis of common understanding. Where checks are made with external suppliers, care should be taken to distinguish between claims of conformity and the ability to demonstrate conformity. Rule 1 1.1 This rule is sometimes known as general integrity. 1.2 If this requirement is satisfied, roll-over between all significant time demarcations (e.g. days, months, years, centuries) will be performed correctly. 1.3 Current date means today's date as known to the equipment or product. Rule 2 2.1 This rule is sometimes known as date integrity. 2.2 This rule means that all equipment and products must calculate, manipulate and represent dates correctly for the purposes for which they were intended. 2.3 The meaning of functionality includes both processes and the results of those processes. 2.4 If desired, a reference point for date values and calculations may be added by organizations; e.g. as defined by the Gregorian calendar. 2.5 No equipment or product shall use particular date values for special meanings; e.g. "99" to signify "no end value" or "end of file" or "00" to mean "not applicable" or "beginning of file". Rule 3 3.1 This rule is sometimes known as explicit/implicit century. 3.2 It covers two general approaches: (a) explicit representation of the year in dates: e.g. by using four digits or by including a century indicator. In this case, a reference may be inserted (e.g. 4-digit years as allowed by ISO standard 8601:1988) and it may be necessary to allow for exceptions where domain-specific standards (e.g. standards relating to Electronic Data Interchange, Automatic Teller Machines or Bankers Automated Clearing Services) should have precedence. (b) the use of inferencing rules: e.g. two-digit years with a value greater than 50 imply 19xx, those with a value equal to or less than 50 imply 20xx. Rules for century inferencing as a whole must apply to all contexts in which the date is used, although different inferencing rules may apply to different date sets. aisadc For Rules 1 and 2 in particular, organizations may wish to specify allowable ranges for values of current date and dates to be manipulated. The ranges may relate to one or more of the feasible life-span of equipment or products or the span of dates required to be represented by the organization's business processes. Tests for specifically critical dates may also be added (e.g. for leap years, end of year, etc). Organizations may wish to append additional material in support of local requirements. Where the term century is used, clear distinction should be made between the "value" denoting the century (e.g. 20th) and its representation in dates (e.g. 19xx); similarly, 21st and 20xx. LexLib II. How the PSE is handling Y2K Compliance To give member-brokers an idea as to how to prepare for the Y2k problem, the PSE experience is presented here for reference. PSE's very first Y2K related activity was when it issued on September 25, 1997 as its circular the Securities and Exchange Commission Memorandum Circular No 7-A calling for all securities related companies to submit a certification on their respective compliance to the Y2K problem. For its part, PSE's Y2K activities formally started as early as January 1998 and it expects to be completely compliant before the end of the year. The basic steps it has taken can be summarized as follows: a) Raise initial awareness on the problem, b) Inventory all critical and semi critical business systems, c) Assess their relevance, impact and readiness, d) Remedy the noted flaws, e) Test the upgraded and remediated systems, f) Make fixes to the noted defects, g) Further test, and h) Monitor compliance activities of all other interdependent systems. Preparatory Activities After the circularization of the SEC notice asking all securities companies to make appropriate preparation for the year 2000 problem, the PSE made a list of business critical systems and immediately undertook steps to remedy the easily remediable flaws. Certifications were requested from third party suppliers to advise PSE whether the equipment purchased from them are Y2K compliant. Some suppliers readily supplied the Exchange with the necessary patch and upgraded versions of software installed on the equipment while others demanded for a formal request to conduct a thorough healthcheck on the servers. By April 1998, the Exchange started to analyze the codes of all its application programs. About 650,000 lines of codes of both the Automated Order Matching engine and the related Marketworks programs running on Maktrade terminals, were analyzed and searched for date related codes. By May, these applications were rewritten in accordance with the rules to be Year 2000 ready as per the BSI definition. Generally, the PSE has adopted the date format mm/dd/yyyy in all its broadcasts, storage and displays. Internal testing were extensively done as each of these applications were made Y2K compliant. In July, all the application programs were thoroughly tested. On August 3, 1998, the Y2K compliant version of the Marketworks was put into production simultaneous with the upgrade of all Maktrade terminals to Windows 95 replacing the old Win 3.1 version of the program. Upgrade of broker's remote PCs Marketworks is being done according to schedule. Trading floor PCs have all been thoroughly tested and found to be Y2k compliant. As of this date, the following are the readiness status of these business critical systems: CRITICAL BUSINESS SYSTEMS SUPPLIER COMPLIANT REMARKS YES NO APPLICATIONS Automated Order Matching (AOM) In-house In production Aug 3, 98 Maktrade Marketworks In-house In production Aug 3, 98 Price Reporting system (PRS) In-house In production Aug 3, 98 Communication Front End (CFE) Datamat In production Aug 3, 98 Electronic Board System Han Sung Does not use dates SYSTEM SOFTWARES VAX 810 FT Digital VMS Layered Products ALPHA SERVERS 2000 & 1000 Digital VMS Layered Products Upgrade for purchase UNIX SYSTEM V/PA-RISC REL 4 Equicom NETX Datamat SecurNet Datamat Visual C++ Ver 5.0 Windows 95 NETWORK AND COMMUNICATION EQUIPMENT DEC SERVER 90TL Digital DEMSA Digital DEMSB Digital DEMPR Digital DELNI Digital DEC REPEATER 900TM Digital CISCO SERIES ROUTERS Datacraft AT&T Paradyne Modems Leverage Fastlane Multiplexer Leverage Access builder Terminal Server Micro-D Not critical. Dates for log only. Lanplex Network Switch Micro-D Not critical. Dates for log only. Tainet Data Sharing Device Macrotel SERVER HARDWARES VAX 810 ft VAX 4000-100 ALPHA SERVER 2000 ALPHA SERVER 1000 STRATUS 610 Continuum OTHER SOFT/HARDWARES VAX EXPANDER Digital UPS COMFAC FLOOR PCs IS COMP. With Win95 Y2K patch Offsite PCs (BROKER'S) Other PSE Systems Special attention is given to the PSE Trading Related Systems inasmuch as these will be the ones that will have a direct impact to all other dependent systems. Aside from them, the PSE has also examined its internal automated systems so that it can also continue with its internal operations free from the Y2k problem. These are the other systems that are needed for the normal operations of the Exchange but its impact is not as critical as the above systems: NAME OF SYSTEM Y2K COMPLIANT REMARKS YES NO HR Payroll System Finance GL System Jupiter Accounting/Finance System ? Awaiting certification PSE Website ? Awaiting certification Office PC's (independent applications only) On-going upgrade III General Assessment and Impact Analysis The PSE trading System is not a 24 hour continuously running system and instead runs only for the morning trading session. The Exchange has complete control of all the running applications having the source code of the core programs and all the program modules involved in printing, end-of-day and other utility programs. References to dates in the application have all been inventoried and remedied. Trading is not so date calculation intensive. The instances that dates are handled include the processing of "good-till-canceled" orders which are valid for the next 7 calendar days, and the displaying, processing and broadcasting of ex-dates, expiry dates and date-last-traded of listed issues. cdll After intensive testing conducted on the computer systems and applications, and based on our knowledge of the design, implementation and operation of the trading system, the MAKTRADE system's performance and functionality will not be affected by data prior to, during and after year 2000. However, to be fully compliant, PSE will still purchase the needed upgrades. The total cost to the Exchange to make adjustments for the Y2K problem is estimated at about P5 million. This includes the estimated cost of in-house man-hours in the analysis and remediation of about 650,000 lines of codes, the payment for the conduct of a health-check on the servers and the purchase of the necessary patches and version upgrades and the rest for the independent third party auditor/consultant to assess and audit the overall activities. cdlex IV. Activities Still to be done : 1. Make the other system fully compliant . The hardware and software that were found to be not yet fully compliant as of the third quarter of 1998 will be upgraded not later than December 1998. These are: a) Alpha 2000 and 1000 Server need to upgrade its DEC Windows Motif, DEC C and BASIC compilers. b) VAX 810 FT need to upgrade its DEC C and BASIC compilers. 2. Testing . The PSE will be conducting the first in a series of integration or street wide testing in November together with all brokers in a mock trading in the afternoon after trading hours. The test will be done by setting the dates of all the participating computers to the dates to be tested in the year 2000. Brokers will simultaneously set their office computers to the same dates as that of the PSE. After the mock trading, they are to test also their backroom systems whether they can process the trades for the day and the trades that will be settling for that day using the PCD terminals. Data vendors and other entities receiving data feed from the PSE will also conduct their test at this time to see if the data being broadcasted are as expected. The " street wide testing " is to see whether everybody has done their respective Y2k preparations and ensure that the inter-relationship of these systems are in order. The relevant dates for testing in the Philippines securities industry are: January 3, 2000 the first trading day of the year 2000 and February 29, 2000 the leap day in February 2000. All participants are expected to conduct internal tests on their systems to check on their ability to have the orderly changeover from the last day in 1999 (December 31, 1999) to the first day of the next year (January 1, 2000) and the February 28 to the leap day on February 29, 2000. By passing that internal tests will they be expected to pass the street wide tests for the two critical dates as above. If they cannot pass the changeover date tests, chances are they will also fail the tests for any date in the year 2000 and that their computers will not be able to recognize the date February 29, 2000. To include dates that would test "good-till-canceled" trades, the test dates are tentatively scheduled on the following dates: Date Year 2000 date to Remarks be tested November 27, 1998 December 24, 1999 Mock trading only. Brokers to (Fri) enter orders that will settle on Jan. 3, 2000. November 28, 1998 December 28, 1999 Mock trading only. Brokers to (Sat) enter orders that will be tested for GTCs still active on Jan 3, 2000. November 28, 1998 January 3, 2000 Brokers to enter trading data and (Sat) settlement testing using PCD PCs. December 4, 1998 February 23, 2000 Mock trading only. Brokers to (Fri) enter orders that will settle on Feb 29, 2000.