 |
||
|
Office of Inspector General |  |
 |
||
|
|
|
|
|||||||||
|
|
|
Report of Review: Major EPA Information Systems are Vulnerable to Failure Due to the Upcoming Century Change#6400036
System managers within EPA are not fully prepared to address the problems associated with the year 2000. Although the scope of this review was limited to 22 major application systems and seven major hardware platforms, the potential effect of the problem within EPA is tremendous. EPA's Information Systems Inventory (ISI) describes approximately 300 systems, databases, models, modules, and other computer applications. EPA's Office of Information Resources Management (OIRM) must accelerate its Year 2000 campaign in order to ensure Agency preparedness for the century change. In order to reduce EPA's exposure to major system failure, a determination of the risks associated with each system in the year 2000 must be made. Once the risks have been evaluated, careful planning and budgeting must be conducted to ensure that all necessary changes are identified, performed, and tested in time to prevent system failure. Purpose The objectives of this survey were to: (1) determine how major EPA application systems currently store date information; (2) determine which application systems will require modification; (3) determine if planning for upgrade of these systems is adequate; and (4) determine how vendors of major EPA platforms are addressing the century change in their operating systems. Background The upcoming century change is considered to be one of the most critical problems facing data processing today. Because most computer systems were developed to maximize storage capacity, dates were often stored as 6-digit numeric fields, omitting the century identifier. This was an effective cost saving technique in the early days of computers. However, as the century change approaches, information resources management (IRM) is beginning to realize the potential impact of this methodology on major information systems. Because almost every system performs date calculations, almost every system is vulnerable to failure or production of unreliable information. There are two basic problems associated with the year 2000: inverse dates and incorrect leap year assumptions. The first problem, inverse dates, primarily effects application systems and is caused by application logic interpreting "00" as occurring prior to "99". When this occurs, dates associated with "2000" will be interpreted as "1900", causing the system to either fail or return nonsensical dates. Either result would have extremely negative impacts on mission-critical Agency systems. Example: A human resources system determines length of service by subtracting an employee's service computation date (SCD) from the current date. Current Date: 11/15/05 - SCD: 11/15/70 = Length of Service: -65 Years The second problem, incorrect leap year assumptions, primarily effects the hardware platform's system software and occurs as a result of the inverse date problem. There are three leap year rules:
Because 2000 is divisible by 4 and 400, it is a leap year. The incorrect leap year assumption occurs when the system interprets "00" as "1900" and assumes it is not a leap year. This result could also have negative impacts on individual hardware platforms, as well as the processing of mission-critical systems. Although the problems themselves are relatively simple, the solutions can be complex. In order to fully assess the magnitude of the problem in a system, several issues need to be addressed:
EPA's OIRM has begun an information campaign to make the IRM community aware of the problems and solutions associated with the year 2000. The Director of OIRM sent a memorandum to all Senior Information Resources Management Officials (SIRMOs), System Managers, and Regional IRM Chiefs informing them of the problem and advising them to expand all necessary date fields to prepare for the century rollover. As part of a monthly project status briefing, the Systems Development Center (SDC) evaluated the year 2000 status of 36 EPA systems being developed or modified at the center. Additionally, Enterprise Technology Services Division (ETSD) personnel developed several queries which will help managers of systems within the central database identify potential date codes that need to be modified. Finally, EPA will be participating as a member of the Federal IRM Policy Council (FIRMPOC) government-wide taskforce on the year 2000. Scope and Methodology The primary focus of this audit was to evaluate EPA's vulnerability to major system failure due to the upcoming century change. Fieldwork was conducted from June through October 1995, at EPA Headquarters, Washington, D.C., and the ETSD, Research Triangle Park, NC. We selected 22 major application systems in 6 program offices for review to evaluate their planning for year 2000(1). We requested data dictionaries and other forms of year 2000 documentation from system managers. We also discussed operating system preparedness and testing for seven major Agency platforms with ETSD representatives. This work was not conducted as part of an audit, and accordingly was not done in accordance with governmental auditing standards. Instead, the work represented a special review which was conducted in accordance with provisions of OIG Manual Chapter 150. Year 2000 Requirements and Guidance Office of Management and Budget (OMB) Circulars A-130, A-123, and A-127 respectively provide Government-wide policy and guidance for: (1) the management of Federal information resources; (2) the improvement of accountability and effectiveness in Federal programs and operations via management controls; and (3) the development, operation, evaluation, and reporting requirements of financial management systems. OMB Circulars A-130 and A-123 outline policy and guidance that define the basic responsibilities of Federal managers. They impact directly or indirectly on all managerial decisions and activities, including those that affect the threats associated with the year 2000. OMB Circular A-127 addresses the issue of IRM standards and has more direct influence on year 2000 solutions. Date standards are critical to the development of a successful strategy to combat the threats associated with the year 2000. OMB Circular A-127 states "Standard data classifications (definitions and formats) shall be established and used for recording financial events. Common data elements shall be used to meet reporting requirements and, to the extent possible, used throughout the agency for collection, storage and retrieval of financial information." This circular also states "Common processes shall be used for processing similar kinds of transactions throughout the system to enable these transactions to be reported in a consistent manner." EPA developed policies and guidance which augment these Federal directives. For example, the Information Resources Management Policy Manual contains policy statements that assign the primary functional responsibility for IRM policy development and overall management of the Agency's IRM program to the Director of the OIRM. Furthermore, the Agency Catalog of Data Policies and Standards states that it is EPA policy to create and maintain consistency in the form of data elements that have more than one application within the Agency. This consistency will permit the cross media approach necessary to achieve environmental results. This catalog also acknowledges EPA's adherence to Federal Information Processing Standard (FIPS) 4-1, entitled "Representation for Calendar Date and Ordinal Date for Information Interchange," which states that the standard format for the year contains four digits. EPA's Office of Administration and Resources Management (OARM) fiscal 1995 IRM Strategic Plan discussed "...a bold new course for information management at EPA." The plan states that "EPA will ensure its data can be integrated to support comprehensive environmental protection and public access to environmental information." The plan further states that "EPA commits to standardize its data, thereby increasing the value and usefulness of its information resources." This plan was developed by a team with broad representation including the Agency's Senior Management, program and IRM staff, external stakeholders, and partners. Finally, in May, 1995, the Director of OIRM issued a memo regarding the year 2000 date change. In this memo, he reminded Agency management of the need for providing four digits for the year instead of two. To reiterate the point he stated again that,"in most circumstances, it would be better to change the year to four digits rather than try to formulate (and then maintain) logic work-arounds." Major EPA Systems Are Not Fully Prepared for the Century Change OIRM's awareness campaign has been successful in that nearly all system managers interviewed were aware of the year 2000 problem and understood the importance of addressing it. However, during the interview process, several system managers stated that they were unaware of some of the issues brought out by the questions asked (e.g., sources of data, embedded date codes, etc.). Additionally, several system managers expressed concern over the lack of detailed information from OIRM, stating that an electronic forum for posting information, questions, and answers would be helpful to them.
There is great variety in the way system managers have responded to the OIRM memorandum encouraging system managers to upgrade their information systems to handle dates beyond 2000. For example, 9% of the system managers interviewed felt that there was no need to make changes to their system. Additionally, while industry recommendations and the OIRM memorandum state that it is preferable to expand year fields to four digits rather than try to formulate and maintain logic work-arounds, 23% of the system managers interviewed are planning to implement some form of logic work-around in their system. The remaining 68% of system managers intend to expand all date fields to four digit years as recommended or are unsure of how they will address the problem. Every system surveyed exchanges data with at least one other Agency system. Additionally, 54% of the systems exchange data with systems outside EPA (e.g., Federal, State, and Industry systems). However, only 15% of the system managers surveyed have addressed their systems' interfaces. Table 2 provides a summary of how system managers planning to address the year 2000 problem intend to address their system interfaces. While 25% of system managers indicated that their interfaces would not be effected by year 2000 compliance, the remaining 60% of systems rely on date-sensitive interfaces and have few plans to ensure that these interfaces will continue to function at the century change.
EPA Systems are Vulnerable to Year 2000 Problems The effects of year 2000 related problems are generally described in terms of 'event horizons.'(3) In 1995, four major Agency systems experienced problems when processing permits and contracts with a five year event horizon. Because these systems would not accept dates beyond 1999 as valid, it was necessary for date information to be stored manually. This information will be re-entered into the systems as they are upgraded to accept future dates. In the mean time, these systems still contain improper dates that compromise the integrity of Agency data. As time goes by, more systems will reach the point where their event cycle crosses the year 2000 boundary. This will cause increasing problems with the integrity and usability of Agency data. Although many systems are beginning to plan for modernization or upgrade of their systems, time is running short. A common industry recommendation is for year 2000 compliant systems to be fully implemented by the end of 1998, in order to allow for one full year of normal, year-end, and quarter-end processing. However, systems should be completely modified by the end of 1997 in order to accommodate the lengthy testing, training, and implementation processes. Based on the lack of detailed plans, current budget uncertainties, and time delays associated with contracting, it is questionable whether or not these systems will be fully compliant before their event horizon reaches 2000. Additionally, the use of logic work arounds by several systems only postpones the general problem. Currently, all date dependent systems must deal with a failure date of 2000. However, as system managers decide to implement the logic work-around approach, they will choose the most appropriate cut-off date for their system. This will effectively hide the problem within the code of each application and scatter failure dates randomly across the Agency. The large quantity of date-dependent interfaces within major Agency information systems further complicates EPA's vulnerability. Because system managers are using inconsistent methods of dealing with the year 2000, there is uncertainty regarding how well these systems will interact. One of the biggest interface concerns is the network of financial systems within EPA. IFMS, the main financial information system, is planning to implement a logic work-around approach to the year 2000. This approach will require systems supplying data to IFMS to strip off the first two digits of the year prior to sending the data to IFMS. IFMS will then use an algorithm to determine if the 2-digit year should be preceded by a '19' or a '20' and add the appropriate number. This same process will be reversed for systems pulling data from IFMS. This process is inefficient, contrary to the requirements of A-127, and could lead to incorrect century assumptions. Finally, while IFMS system management believes that the algorithm to determine the appropriate century will not fail, this belief is offset by the criticality of IFMS's and other financial system data. As paper-based processes are replaced with system interfaces, the stability and integrity of those interfaces becomes critical. However, the majority of system managers have not yet begun to address the question of how their system will exchange data with other systems. Because of this, there is no guarantee that data will flow correctly from system to system. This situation reduces the integrity of shared data and jeopardizes the current Agency initiatives regarding electronic data interchange, data sharing, and public access. These initiatives are totally dependent on exchanging correct data among EPA systems, as well as with other Federal Agencies and industry. Regardless of the level of planning and upgrading done by system managers, each major application is ultimately vulnerable to the faults of the hardware platform on which it resides. Almost all system managers reported being dependent on the operating system to provide the correct date. Additionally, system managers listed several operating system tools and utilities which are necessary for their programs to function. There is no consistent approach to ensuring that the operating system will return the correct date in the years beyond 2000, and no methodology for evaluating software tools and utilities for year 2000 compliance. Because of this, system managers have no guarantee that their programs will continue to function as intended in the year 2000. OIRM Needs to Accelerate Their Year 2000 Campaign According to the IRM Policy Manual, OIRM is responsible for the development of IRM policy and overall management of the Agency IRM program, including development of data policies and standards. The framework provided by this policy invests OIRM with the right and responsibility to lead the Agency's effort to respond to the year 2000 threat. Although OIRM has launched an effective year 2000 awareness campaign, they have not stepped forward with specific policies, procedures, and methodologies. This has left system managers on their own to bring their systems into year 2000 compliance. During audit interviews, several system managers stated that they were unaware of some of the anticipated problems. Unfortunately, date logic is pervasive, and some of the more serious problems will result because important aspects are overlooked during upgrades. Identification of these more obscure concerns need to be addressed during the planning stages of modifications so that solutions can be formulated. Retrofitting a solution can be both time-consuming and costly. Identification of these issues can be addressed through the dissemination of guidance, as well as interactive discussion with responsible management. Contrary to OIRM's earlier memorandum, they have since determined that the existing Agency data standard, requiring a four-digit year date, is too restrictive. However, they have not introduced supplemental guidance to identify acceptable alternative solutions. At a time when so many systems are undergoing change, standards are necessary to ensure consistency for data integration and data sharing across the Agency. The use of standards can also cut costs. A reliable, comprehensible and portable date routine is an integral part of the overall 2000 solution, and would help lessen testing costs and save project dollars. As the Agency's manager for establishing IRM policy, OIRM has a responsibility to promulgate and enforce the use of data standards across the Agency. We recognize that year 2000 testing should be relative to the complexity of the individual application, the criticality of its data, as well as the particular system'senvironment. However, we discovered that certain common aspects of testing had not been adequately addressed within the Agency. For example, little emphasis had been placed on developing tests to: (1) ensure the accurate operation of date-sensitive interfaces; (2) detect operating system idiosyncrasies; or (3) validate leap year processing. In order to effectively address these common problems, OIRM needs to devise and disseminate a testing strategy which adequately addresses these and other concerns, and yet is flexible enough to permit creativity and customization, depending on each system's particular needs. This strategy should provide guidance and set milestones for system managers. Because the modification process is lengthy and deadlines are critical, strategic progress should be measurable and problems must surface as early as possible. OIRM has acknowledged the need to assume a broader role. To successfully address the many challenges associated with year 2000 exposures, it is imperative that this effort is managed through a central focal point. This focal point should be responsible for critical project aspects, such as setting general milestone dates, coordinating commercial vendor actions, and establishing a consistent methodology through all project phases. During a recent discussion, OIRM representatives described their plan to embark upon a comprehensive year 2000 campaign which encompasses all of the aforementioned areas. Unfortunately, OIRM's plant is not scheduled to begin until fiscal 1997. Meanwhile, some Agency systems have already experienced year 2000 problems and system managers are actively seeking solutions. OIRM must begin immediately to analyze the extent of the Agency's problem and accelerate it's year 2000 campaign, accordingly. There is a problem now and there will undoubtedly be additional future repercussions, unless the time to act is moved forward rather than backward. Recommendations 1. OIRM endorse the use of its existing four-digit year standard, and require the system managers to obtain a waiver if they choose a solution other than the standard. 2. OIRM expedite the development of guidance documents to direct ongoing and future efforts to overcome the year 2000 dilemma. At a minimum, guidance documents should: (1) identify common problematic concerns; (2) identify reliable methods for testing date fields for year 2000 compliance; and (3) identify tests designed to ensure compatibility between Agency applications systems. 3. OIRM employ one of its existing communications mechanisms to: (1) disseminate guidance to system managers; (2) serve as a central repository devoted to year 2000 issues; and (3) provide an avenue for the exchange of ideas and experiences among system managers. Agency Comments and OIG Evaluation In a memorandum dated December 12, 1995, the Acting Director for Information Resources Management responded to our draft report (see Appendix 1). In summary, the Agency partially agreed with all three of our recommendations. Discussions with OIRM representatives resulted in a revised set of recommendations which should alleviate some of OIRM's concerns and yet adequately address the conditions noted in our draft report. To provide a balanced understanding of the issues, we have summarized and commented on the Agency's general concerns regarding the draft report.
The Agency's response noted inaccuracies and/or omissions in our draft report. We have addressed these concerns below:
The following Agency comments relate to specific recommendations cited in the draft report. However, this final report contains a revised set of recommendations. Recommendation 1. While OIRM officials agree that they should establish a standard for the date field, they maintain that the four digit approach is too restrictive. They stated that FIPS Publication 4-1 allows for the use of a four or a two digit date field. OIRM insists that system managers have the flexibility to build year 2000 compliance within their unique technology framework and in the most cost effective way. The Agency responded that, whatever standard is established, there "should be a requirement built into the IRM procurement process through the EPA Acquisition Regulations. This would require that all commercial software developers and providers assure year 2000 compliance in all future software development or enhancement products they provide to the Agency." According to FIPS Publication 4-1 and EPA's Data Standards Catalog, the four-digit year is the existing Agency standard for the date field. As an existing Agency standard, it is already required by EPA Acquisition Regulations. However, we realize that to rigidly impose this standard on all existing systems would be impractical. There are a number of reasons why existing systems might be exempt from the standard. For example, expanding the date field is too costly a solution for systems nearing replacement or retirement. Our concerns are based on the fact that there are a number of alternative approaches being used throughout the Agency, but few of the system managers interviewed had plans to ensure that their system interfaces would operate properly. We recommend the use of waivers to accommodate situations where systems are justifiably exempted from the standard. We contend that the use of waivers allows system managers ample flexibility in justified situations. In addition, the use of waivers would provide OIRM with a much needed mechanism for controlling, coordinating and acknowledging decisions to deviate from the Agency standard. Despite OIRM's objections to the use of waivers, we found that Agency Directive 2100 clearly advocates their use. Recommendation 2. OIRM agreed that reliable methods for testing date fields for year 2000 compliance were necessary. However, the Agency suggested that the recommendation be reworded to use the phrase "test methods guidance document." In their opinion, this terminology would allow system managers more flexibility to choose a methodology appropriate and cost effective for their environments. In addition, OIRM anticipates that commercial vendors will modernize their operating system utilities and software tools to accommodate the century date change within the next one to two years. We have no objection to modifying the wording of this recommendation. We agree with the need to have reliable methods for testing date fields for year 2000 compliance. In our opinion, these guidance documents will provide (1) consistency to the issues being contemplated when planning a solution and (2) uniformity in the approaches being taken to carry out those plans. We reiterate that these guidance documents should be completed in a timely manner, to allow adequate time for the implementation of suggested methodologies. Recommendation 3. OIRM agreed that managers needed to be kept informed of relevant year 2000 policies, procedures and methodologies, but maintained that there are sufficient existing communication mechanisms to facilitate this process. We concur that there is no need to establish a new forum. Our intention is to influence the Agency to utilize an existing forum to disseminate guidance or relevant information, as well as encourage an open exchange of ideas and experiences among system managers. Appendix 1 Electronic version of Appendix 1 not available. Appendix 2
Office of Inspector General Inspector General (2410) Deputy Inspector General (2410) Assistant Inspector General for Audit (2421) Principal Deputy Assistant Inspector General for Audit (2421) Associate Assistant Inspector General for Internal and Performance Audits (2421) EPA Headquarters Acting Director, Office of Information Resources Management (3401) Associate Administrator for Congressional and Legislative Affairs (1301) Agency Followup Official (3101) Attn.: Assistant Administrator for Administration and Resources Management Agency Followup Coordinator (3304) Attn.: Director, Resources Management Division Audit Followup Coordinator (3102) Attn.: Program & Policy Coordination Office EPA Headquarters Library Audit Liaison, Office of Air and Radiation (6102) Audit Liaison, Office of Administration and Resources Management (3102) Audit Liaison, Office of Enforcement and Compliance Assurance (2221) Audit Liaison, Office of Policy, Planning, and Evaluation (7101) Audit Liaison, Office of Solid Waste and Emergency Response (5101) Audit Liaison, Office of Water (4102) Audit Liaison, Office of Information Resources Management (3401) Research Triangle Park, North Carolina Director, Office of Administration and Resources Management (MD-20) Director, Enterprise Technology Services Division/OARM (MD-34) Footnotes 1. The following systems were surveyed: AIRS, CFEIS, GMISS, CPS, EPAYS, FINDS, GICS, ICMS, IFMS, MATS, SCRIPS, CRIMDOCK, DOCKET, PCS, TRIS, CERCLIS, CLP, RCRIS, FRDS/SDWIS, IDEA, NEEDS, and STORET. The platforms reviewed included: PC Workstations, LAN servers, IBM Mainframe, DEC/VAX Cluster, Cray Supercomputer, UNIX Workstations, and Macintosh Workstations. 2. The term "year 2000 compliant" is used to describe a system where all date fields have been expanded to use 4-digit years. 3. An application's event horizon is defined as the latest future date that will be processed in the application.
|
|
|
|
|
||
|
|
Despite the general awareness of the problems associated with the century change, only three system managers (CLP, CERCLIS and SCRIPS) stated that their systems are currently year 2000
compliant
Finally, the system software associated with EPA's hardware platforms (e.g. IBM Mainframe, UNIX workstations, Supercomputer, etc.) supporting most of these major information systems may not be completely year 2000 compliant. When we interviewed ETSD staff regarding the ability of EPA's major platforms to correctly process dates beyond 1999, the response was initially positive. Many of the Agency points of contact for these platforms indicated that they had performed, or were willing to perform, some level of testing to ensure that dates beyond 2000 were considered valid. However, there was no consistent test plan used to ensure that all idiosyncrasies of the operating systems were tested and some points of contact stated that they
had not tested the validity of leap year processing in 2000.