Mr. Chairman, Distinguished Members of the Subcommittee:
My name is Ed Yardeni. I am the Chief Economist of Deutsche Morgan Grenfell, a global investment banking firm. I appreciate the opportunity to testify before this Subcommittee on the issue of mandating Year 2000 disclosure by publicly traded companies. The title of my prepared testimony today is, The Year 2000 Problem: We Need Answers. Of course, all the opinions I express today are my own and may or may not be shared by my company. I am here as a concerned citizen, not as an official spokesman of my company or industry.
The Year 2000 Problem (Y2K) is a very serious threat to the US economy. Indeed, I believe that it is inevitable that it could disrupt the entire global economy in several ways. If the disruptions are significant and widespread, then a global recession is possible. The depth and duration of such a downturn is hard to predict at this time. To do so requires answers from government and business leaders around the world to many questions about the problem. They must publicly provide much more information, so that we can determine the economic risks ahead and prepare for any foreseeable and plausible worst-case scenarios if we fail to fix the problem properly in time. With regard to the specific topic of this hearing today, I believe that all businesses, both incorporated and unincorporated, should be required by a new law to publicly reveal their cumulative and current quarter outlays on fixing Y2K. They should also be required to reveal their best- and worst-case projections of such outlays. Most importantly, all business establishments should be required to post a "Y2K Progress Report" of their current and projected progress. This report should be very detailed, including:
I recognize that the current regulatory system does require each individual corporation to report Y2K outlays and risks that are likely materially to affect the corporation's financial condition. The current requirements for reporting Y2K issues are the same as those required for any other event that might have a material impact on a corporation's balance sheet and income statement. However, Y2K is a unique business risk that requires unique disclosure requirements. It is a systematic risk that will affect all businesses, all vendors, and all customers all of us. It will affect even those who long ago anticipated the problem and expect to be completely ready for the year 2000.
In other words, it is a risk to the well-being of our entire local, national, and global community. We must protect not only the interests of investors, but also the general public. As I discuss below and in the attached appendix to my testimony, there will be Y2K problems that are bound to disrupt all our lives. We need all the information available to prepare for this problem as a community. Our system of self-interested capitalism is not designed to handle a systemwide indeed global risk to our collective well-being. Individual business management must protect the interests of their own entities. For competitive reasons, they are likely to reveal as little as possible about material risks to their business. In this case, the public's need to know all the Y2K risks must prevail over the legitimate, but parochial interests of business managers.
I am not a lawyer. I am an economist. My proposal might raise legal issues, possibly even issues of constitutionality. I am not advocating any change in our supervised and regulated free-market system of capitalism. I am advocating a leveling of the disclosure playing field. If all companies are required to disclose their Y2K activities and risk, then none will be at a competitive disadvantage if it provides full Y2K disclosure, as it is under the current disclosure system.
As an economist, I need more information to assess the risks to our national economy and global financial markets from Y2K. The current disclosure system simply will not provide our policy makers with the information they need as soon as possible to anticipate and to prepare for plausible worst-case scenarios. Conceivably, such information may show that the economic risks and the risks to our well-being are quite small and temporary. I hope so, but I doubt this will be the case. If we don't get more information soon, then we risk more problems and greater hardship.
It is not too late to reduce the risk of Y2K failures by giving this problem a top priority. My proposal would focus public pressure on management who are not appropriately addressing the problem. One objection is that too much information especially as much as I am asking for might panic the public. Perhaps, if we all panic a bit now, we can minimize the disruptions two years from now. Besides, I have talked to reporters who are working on Y2K stories. The public may be relatively uninformed and unconcerned about Y2K now, but they are bound to become increasingly anxious as the millennium date approaches.
This Subcommittee is responsible for banking issues, as well as disclosure issues. Bank loan officers must assess the risk of earnings losses and even business failure of their borrowers who fail to be Y2K compliant. My proposal would establish a national standard Y2K reporting system that would level the playing field for our bankers. It would force them all to use more or less the same checklist for assuring Y2K compliance. Of course, my proposal might increase the macroeconomic risk of a Y2K "credit crunch," as bankers refuse to lend to companies that are not likely to meet the Y2K deadline. Again, it is better that we increase this risk for business borrowers now, than later, so that they will take Y2K more seriously as a threat to their survival. Those that won't survive may come to this conclusion sooner and seek Y2K-compliant acquirers while there is still enough time to integrate them into compliant computer systems.
I have spent the past six months collecting as much information as possible on Y2K. Based on what I know so far, I believe there is a 40% risk of a worldwide recession that will last at least 12 months starting in January 2000, and it could be as severe as the 1973-74 global recession. That severe downturn was caused by the OPEC oil crisis, which is a useful analogy for thinking about the potential economic consequences of Y2K. Just as oil is a vital resource for our global economy, so is information. If the supply of information is disrupted, many economic activities will be impaired, if not entirely halted.
The Y2K problem is both trivial and overwhelming at the same time. Unless fixed, most computers, including many PCs, will produce nonsensical results or crash because "00" in the widely used two-digit year field will be recognized as 1900 rather than 2000. Obviously, there are simple solutions to this. The two-digit fields can be found and replaced with four-digit ones. The software programs can be "windowed" to recognize incoming years in a range, say, between 0 and 40 as being in the 21st century. New software programs can be written to replace "legacy" programs that may be too difficult to fix.
The problem is time. All the money in the world will not stop January 1, 2000, from arriving at the rate of 3,600 seconds per hour. There is not enough time to fix and test all the systems, with billions of lines of software code around the world, that need to be fixed. Many businesses, governments, and organizations have become aware of the Year 2000 Problem only recently and may simply run out of time.
Testing is much more time-consuming than repairing noncompliant code. This might not be a problem for some stand-alone systems. However, the majority of software programs are part of a bigger corporate, industrial, national, and even global network. They often depend on input information generated by other programs. They must all remain compatible as they are fixed.
In other words, the sum total of all interdependent computer systems must all be compliant. The network is the computer. A problem in one system could trigger a Domino Effect, which poses a great risk to all who fail to test whether their local compliant system is compatible with their global network. The networks that must function perfectly at the risk of partial and even total failure include:
In other words, the Y2K virus has infected all the vital organs of our global body. It must be removed from all of them. A failure in any one system could corrupt other systems. Most obvious would be a serious disruption in the supply of electricity. The Year 2000 Problem will be a non-event only if the global network is fixed 100%. Undoubtedly, much will be fixed in time. But there is no doubt that some significant fraction will not be ready in time. Indeed, most so-called embedded microchip systems will be stress tested for the first time under real world conditions starting at midnight on New Year's Eve 2000. There are billions of these mini-computers embedded in appliances, elevators, security systems, processing and manufacturing plants, medical devices, and numerous other vital applications. Most are probably not date-sensitive. But many are and could seriously disrupt vital economic activities and create serious safety hazards.
Of course, those of us who earn our living on Wall Street have known about Y2K for at least two years. Investors have sharply bid up the prices of several Y2K companies that offer various tools and solutions for fixing the problem. However, none has a "silver- bullet" solution that can fix Y2K over a weekend. They can help to find and repair code that is not Y2K compliant. But every change requires time-consuming testing of each system. Each change has the potential of creating a new bug in the repaired program, which then requires another round of "debugging" and testing. There is simply no silver bullet for this process.
I am amazed by the lack of concern about Y2K by our political and business leaders, journalists, and the general public. The widespread mantra I hear over and over again is "Bill Gates will fix it." The official position of Microsoft is that this is a problem that everyone must fix on his own. It is too big and overwhelming for even Microsoft.
The lack of concern may also reflect the fact that we have become very dependent on technology in a very short period of time the last 20 years. We depend on it, but very few of us understand how it works and its limitations. We marvel at the achievements of technology. But it doesn't always work as expected and as promised. Anyone who owns a PC has experienced the frustration of unexpected crashes. Most PCs work fine as long as we don't add any new programs. As soon as we do so, other programs sometimes misbehave. None of us would be happy if our PC was 95% functional. So why are we so complacent about a global computer network that might be 95% Y2K compliant in a best- case scenario and maybe only 50% compliant in a worst-case scenario?
Software programming is far less disciplined and rigorous than most of us realize. Two different programmers can and do write completely different programs that will perform exactly the same task. Programming is more of an art than a science. One of the biggest Y2K headaches is that few programmers take the time or are even asked to document the logic of their programs. Also, the original source code for many older programs is lost. The source code was translated into "machine language," i.e., the binary combinations of zeros and ones that computers understand, by so-called "compiler" programs. Reverse compiling is possible, but many of the original compiler programs are also lost.
On Wall Street we have focused our research efforts on how to make money on Y2K. I think it is time for all of us to focus more on the disruptions that may occur because the problem will not be completely fixed in time. There are plausible worst-case disruption scenarios that would undoubtedly cause a global recession, possibly one of the longest and deepest on record. With so much at risk, we must do more to prepare for possible troubles. To do so, we need answers; we need more Y2K disclosure from our business community. Then we can prepare for the worst, and thereby realistically hope for the best.
New Era Recession: Odds Are Rising. The Year 2000 Problem is a serious threat to the global economy. Yet it isn't being taken seriously enough. I've been studying "Y2K" press and official sources available to the public on the Internet for several months. The more I read, the more convinced I am that some economic disruptions are inevitable.
Unless fixed soon, almost all older mainframe computer software systems, many PCs and software programs, and millions (perhaps billions) of embedded semiconductor chips potentially could crash on January 1, 2000 simply because the new year will appear as "00" in the standard two-digit year field and will be read erroneously as 1900. Undoubtedly, most of the systems will be fixed in time. But even if only a small percentage fail, the resulting disruptions are bound to cause some trouble, and worse if the minority of noncompliant Y2K systems have an adverse Domino Effect on compliant ones.
In mid-July 1997, I concluded that the probability of at least a mild global recession in 2000 is around 30%. Now, I am raising the odds to 35% based on some unsettling documents posted on the Internet by US and international official sources:
No Silver Bullet. When I talk to institutional investors about the Y2K problem, they don't believe it is a serious one "You must be kidding." There is a great deal of confidence in American ingenuity: "This is a recognized problem and it will be fixed in time."
You know me, I prefer to be an optimist. However, I am taking Y2K seriously. The more I study it, the more convinced I am that there is no "silver bullet." I hope I am wrong, but there are too many different software languages, programs, and computer systems than can be fixed with one simple, ingenious solution. Y2K solution companies can help their customers repair their noncompliant software. But the process is still time consuming, especially the testing phase.
There is no single way of fixing existing applications and databases. There are two common approaches: 1) The most obvious is to add two digits to the year field. 2) The windowing technique analyzes the two-digit year field and automatically recognizes years under a specified number (say 60) as being 20yy, while years over are 19yy. Windowing is not always feasible, e.g., when birth dates are part of a database. All Y2K fixes require repetitive, time- consuming testing each time an application is modified to be Y2K compliant to make sure it works with linked internal and customer-based and vendor-based applications that might have been repaired with a different technique.
Some currently noncompliant systems are just so huge and complex that there simply isn't enough time left to fix and test them. The Internal Revenue Service is an especially relevant example. (For more on the IRS, see Chapter 5.)
Don't Shoot The Messenger. This is the third issue of The Y2K Reporter. So far, the response has been underwhelming. I am convinced that the Y2K problem is bound to cause economic disruptions around the world. There is at least a 35% risk of a recession in the year 2000. Nobody seems to care. In recent discussions with institutional money managers in Minneapolis, Chicago, and New York, I was amazed at how many of them believe that somebody will find a silver-bullet solution before the immovable deadline. Many assured themselves by telling me, "Bill Gates will find a solution."
Don't count on it. Mr. Gates' Microsoft Corporation doesn't want to touch Y2K with a 10 foot pole:
Microsoft expects that its biggest Y2K problem will be "getting end users to not 'shoot the messenger.' Many PCs are used as terminals into mainframe-based applications. Microsoft warns, "It is highly likely that not all mainframe programs will function properly when we reach the year 2000." But the end user will see the information coming from their PC and may believe that it is a Microsoft problem. Microsoft hopes "to build awareness of this issue so people can quickly identify the real problems and take appropriate and cost-effective steps to solve the problem."
Is Microsoft Y2K Compliant? A few of Microsoft's products have had Y2K-related bugs which are documented in the Microsoft Technical Support Knowledge Base. All of Microsoft's operating systems, including MS-DOS, were designed to handle four-digit dates well into the next century. Users can enter two-digit shortcuts that are then stored as four digit dates by Microsoft products. Since there is no industry-wide standard on how to interpret two- digit shortcuts, some PC applications may interpret a two-digit date differently than a user needs. The user will need to type in all four digits e.g., "2000" instead of "00" in order to ensure accurate data. "Users must of course take responsibility for the accuracy of the data that has been entered under either the two-digit or four-digit method, but Microsoft products give users the ability to properly enter and store dates into the next century. Relative to the severity and expense of the mainframe problem, this is a minor issue." [Emphasis added.]
Are You Confused Yet? Many of Microsoft's products do not actually store dates. Instead, they rely on the operating system, and sometimes databases, for storing and manipulating dates. Every Microsoft database product including Microsoft Access, Visual FoxPro, and Microsoft SQL Server stores years in a four-digit form. Microsoft Access 97 interprets manual year input from "00" to "29" as short cuts for the years "2000" to "2029." Access 97 converts all two-digit years within imported text files to 1900-based years. Microsoft recommends "that all legacy data sources be updated to contain four-digit years to avoid incorrect conversions." Microsoft Access 95, and earlier versions, interpret manual year input from "00" to "29" to be short cuts for "1900" to "1929." Microsoft Excel versions 4, 5, and 7 all interpret "00" to "19" as short cuts for "2000" to "2019." Microsoft Excel 97 interprets two-digit years from "00" to "29" as "2000" to "2029" and the short cut "30" will resolve to "1930." Got that? Are you ready for the quiz?
Free Advise. In effect, Bill Gates is saying, "Don't expect me to fix the world's Y2K problem. It's too big for my company to solve." Fix it yourself:
While Microsoft does provide the tools for others to build solutions, we do not provide the vertical applications (e.g., payroll, accounting, Medicare, social security, and tax systems). Software developers can create their own software to collect, store, and manipulate dates. If they have not accounted for the year 2000, they may have problems. Microsoft strongly encourages software developers to use the date functions supplied by the operating system, software development tool, or database to avoid this problem. Microsoft also recommends that year 2000 testing be included in the software development process.
The Prozac Solution. Hey, is everybody on Prozac, or what? No single individual or corporation on this planet can solve this problem for us. There are no quick and easy miracle drugs to make this depressing issue go away. Y2K can be fixed, but it will require a huge coordinated community, national, and global effort. We must also prepare for disruptions in the event that Y2K isn't completely fixed by the turn of the century. I urge Mr. Gates to make a public statement to this effect. Then, perhaps our leaders and the public will take Y2K more seriously and make it a top priority. Or, maybe I should take Prozac.
Surprising Survey. The Information Technology Association of America (ITAA) conducted a survey of IT companies in July 1997. Asked if they have all the Y2K business they can handle for the next six months, over 80% of respondents said no. Only 4% were at full capacity! Only 22% expected to be turning away Y2K customers by January 1998.
Y2K vendors are clearly disappointed by the lack of panic buying. However, they believe that last-minute Y2K shoppers will strain the resources of the industry. In fact, 82% of respondents think capacity is a serious issue. Asked the same question in a slightly different context, 62% of respondents said the Y2K capacity issue has not been "over-hyped."
ITAA sent the e-mail survey to 375 companies and received 98 back. Most companies polled are "not realizing significant sales revenues" from Y2K. Almost 53% told ITAA that Y2K accounts for 25% or less of their revenue. Only 9% said it accounted for 75% or more of their total sales.
Software Programmers' Pay. Over the past 12 months through July, average hourly earnings for software programmers are up only 6.1%. This is another indicator suggesting that companies are not panicking about their Y2K problem. There have been many predictions that IT compensation will soar as demand for skilled talent overwhelms supply. It could still happen, but so far there is not even a hint of this scenario in the wage data that are released along with the monthly employment report by the Bureau of Labor Statistics. Of course, the wage data may not show some of the upward pressure on compensation because employers may be offering their IT personnel big bonuses payable in 2001 if they stay.
Laugh Or Cry? Could it be that companies with Y2K problems are fixing it with the
resources they already have in-house? Could it be that the problem is not so serious after all?
Or, could it be that business managements are not taking the problem seriously enough?
Nukes. According to the OMTS, the US Nuclear Regulatory Commission has only seven mission critical systems, and will replace three and repair four of them. On December 24, 1996, the NRC issued Information Notice 96-70: "Year 2000 Effect on Computer System Software." Here is an interesting item from the notice:
In 1995, approximately one-fifth (22 percent) of the nation's electricity was generated by 109 operating nuclear reactors in 32 states. US electric generating capability totaled approximately 706 gigawatts. Nuclear energy accounted for approximately 14 percent of this capability. There are currently 110 commercial nuclear power reactors licensed to operate in 32 states. Six states relied on nuclear power for more than 50 percent of their electricity. Thirteen additional states relied on nuclear power for 25 to 50 percent of their electricity.
I spoke with a fellow who works on the NRC's Y2K committee. He reminded me that his agency is responsible only for the industry's safety, not output. Apparently, the NRC was not overly concerned about Y2K issues at the end of last year: They sent Information Notice 96-70 "to alert addressees to the potential problems their computer systems and software may encounter as a result of the change to the new century." The commission expected that "recipients will review the information for applicability to their facilities and consider actions, as appropriate, to avoid potential problems." Suggestions contained in the information notice "are not NRC requirements; therefore, no specific action nor written response is required."
(On September 17, one day after I spoke with the NRC official and I signed up for the e-mail Discussion Group sponsored by the NRC for the industry, I received a message from the NRC informing the uncensored group that it would be a "moderated forum" from now on. It must have been a coincidence.)
They Are Safe, But... In the September 23, 1997 issue of my Y2K Reporter, I raised some concerns about the Y2K compliance of the nuclear power industry. I based my analysis on an Information Notice posted December 24, 1996 on the Web site of the US Nuclear Regulatory Commission (NRC). The NRC alerted the industry to potential problems their computer systems and software may experience if not fixed. What disturbed me most is that the notice did not require any formal or even informal feedback: "This information notice requires no specific action nor written response." It was obviously a cover-your-butt document.
Now, I am less concerned about the safety of nuclear reactors, but more concerned about the supply of electric power in 2000 after reading a September 24, 1997 memo from the NRC's chief information officer to the agency's commissioners. It too is posted on the NRC's Web site.
The good news is that "safety-related initiation and actuation systems" don't have a Y2K problem because they do not rely on date-driven databases to perform their required functions. The NRC bases this conclusion on "discussions" with vendors of digital protection systems including Westinghouse, General Electric, Combustion Engineering, Foxboro, Allen Bradley, and Framatome/Babcock & Wilcox.
I feel better. Don't you? Well, not so fast; there's more to this story.
...Will The Lights Go Out? The NRC memo notes that numerous "not-safety-related, but important, computer-based systems, primarily databases and data collection necessary for plant operations" are date sensitive and must be made Y2K compliant. [Emphasis added.] I guess this means the lights might flicker, or possibly go out, in some areas that depend on nuclear power plants if they are not fixed in time.
Here is a list of some of the systems that might be affected by Y2K problems at your neighborhood power plant according to the NRC:
Y2K-Challenged Operators. It is hard to tell if the NRC is 100% sure that Y2K won't pose a safety threat. The NRC staff "believes that safety-related safe shutdown systems will function as intended." However, the NRC staff sees a possible "worst-case scenario" where several non-safety-related systems go berserk and "significantly challenge the plant staff."
For example, plant operators may be unable to track the status of the reactor after a Y2K- tripped shutdown if emergency data collection and communications systems fail. "Note that even under such a scenario, plant operators are trained to use their symptom-based emergency procedures and safety-related-post accident monitoring parameter indications to maintain safe plant shutdown conditions." Of course, the risk is that the operators might be overwhelmed by the Y2K havoc but only in a worst-case scenario. (In this case, they might go fission.)
Dealing With The Problem. So what is the NRC doing to minimize the risks? They are leaving it up to the industry to fix Y2K.
So the NRC is still "considering" whether to require plant operators to provide them with the information they might need to determine if a plant is or will be Y2K compliant. If not, I presume the NRC will order the shutdown of noncompliant plants.
"Defense-In-Depth." On the Internet, I found a report titled "Nuclear Regulation: Preventing Problem Plants Requires More Effective NRC Action," dated May 1997, and prepared for Congress by the General Accounting Office. It reviews how the NRC: (i) defines nuclear safety, (ii) measures and monitors the safety conditions to ensure the safety of nuclear plants, and (iii) uses its knowledge of safety conditions to ensure the safety of nuclear plants. On all three counts, the NRC was found to be deficient by the GAO auditors.
The relatively new commissioners (see insert box on page 8) have shown a strong commitment to reforming the NRC by expanding the inspection program and revamping the process of identifying plants with long-standing safety problems. "However, changing NRC's culture of tolerating problems will not be easy," warned the GAO report.
The NRC presumes that plants are safe if they operate as designed. Because there are so many redundant ("defense-in-depth") safety systems built into plants' designs, the agency allows some to operate even when some of the systems are not working properly. The GAO audit report observes that not all plants are operating as designed especially because nuclear plant owners are pursuing cost-cutting strategies to stay competitive following the deregulation of the electric utility industry. As many as 37 nuclear sites are vulnerable to shutdown because their production costs are higher than projected prices in a more competitive market for electricity.
The GAO report faults the NRC for not effectively overseeing the plants that have problems; not getting licensees to fix deficiencies in a timely manner; relying too much on plant managers to fix problems; taking enforcement actions too late to be effective; and failing to ensure that licensees maintain competent management.
Hooked On Fission. In my Y2K Reporter #2, I reviewed the importance of nuclear energy in the United States. Here are some more facts for the United States and the rest of the world:
| Percent of
Source: Nuclear Energy Institute
Editorial: NRC Too Passive. It seems to me that the NRC is a bit too passive about Y2K. It should get more pro-active. It is true that its mandate is to ensure the safety of the nuclear power industry, but it should also take some responsibility for ensuring the supply of electrical output from nuclear power plants. Rather than obtaining its information from the industry's association and from informal discussions with plant operators and vendors, the NRC should send staff inspectors to assess the situation on site. A monthly "Y2K Watch List" from the NRC would help the public and political leaders to assess the risks of brown outs or black outs in 2000 and to prepare for such disruptions if necessary. "Prepare for the worst. Hope for the best."
The Nuclear Regulatory Commission In Brief:
The Nuclear Regulatory Commission is an independent agency created by the Congress in 1974. Under the authority of the Atomic Energy Act, it licenses the construction and operation of nuclear power plants; develops, implements, and enforces the rules and regulations that govern nuclear activities; inspects facilities to ensure compliance with legal requirements; and conducts research to support its programs.
NRC's fiscal year 1997 budget is estimated at $477 million. Its staff of about 3,000 is responsible to five commissioners appointed by the president and approved by the Senate. Currently, there are four commissioners and one vacant position. NRC Chairman Shirley Ann Jackson, a theoretical physicist, joined in 1995. The other three joined in 1996 and 1997.
The NRC maintains at least two inspectors at every operating nuclear reactor site. Staff from any of its four regions and from NRC headquarters supplement the on-site inspectors, who prepare reports about every six weeks. The comprehensive Systematic Assessment of Licensee Performance (SALP) is written every 12 to 24 months for all reactors.
A Senior Management Meeting (SMM) process was created in 1986 to provide an early warning on troubled plants. The goal is to take steps to prevent the problems at these plants from worsening. An important outcome of the semi-annual SMM is the Watch List. As of May 1997, there were 14 plants on the list, the highest number since 1988. Over the past 11 years, 41 plants made the list, and 24 of these were on for two or more years.
The NRC uses orders to demand more information from licensees. The NRC has three primary enforcement sanctions notices of violation; civil penalties; and orders to modify, suspend, or revoke operating licenses. Depending on the severity of the violation, a notice can be accompanied by fine of up to $110,000 per violation per day. A shutdown can cost a licensee between $249,000 and $310,000 per day in operating costs and in purchase of alternative power.
Natural Disasters. In his Y2K testimony on July 30, 1997 before the Subcommittee on Financial Services and Technology of the US Senate's Committee on Banking, Housing, and Urban Affairs, Federal Reserve Board Governor Edward W. Kelly, Jr. said, "as a result of our experience in responding to problems arising from such diverse events as earthquakes, fires, storms, and power outages, as well as liquidity problems in institutions, we expect to be well positioned to deal with problems in the financial sector that might arise as a result of CDC [Century Date Change]."
Last Resort. The Fed is prepared to function as the data processing vendor of last resort for financial institutions that are "unable to access their own systems." Mr. Kelley added that the Fed can also operate paper-based payment systems should there be problems with the electronic payment system. The Fed would join other banking agencies in the takeover of any banks that become insolvent as a result of Y2K.
Mr. Kelley threatened "possible use of enforcement actions as appropriate" against banks that don't move quickly enough to become Y2K compliant. He told the Congressional committee that large banks are moving faster than many small ones that have underestimated the efforts necessary to ensure Y2K compliance. The Fed is working with the Bank for International Settlements and the Group of Ten central banks on global banking Y2K issues. (See below.)
The Century Date Change project was initiated in the Federal Reserve System in late 1995, according to Mr. Kelley. The Fed is setting up an isolated mainframe data processing center for "testing our payments system applications." Testing with banks is targeted to begin June 1998.
By the way, Fed Chairman Alan Greenspan was invited to testify before the Congressional committee. Mr. Kelley went instead. Mr. Greenspan will retire from the Fed during June 2000.
Credit Crunch. The G10 Basel Committee on Banking Supervision sent a wake-up call to the global banking industry on September 8, 1997 in a memorandum titled "The Year 2000: A Challenge for Financial Institutions and Bank Supervisors." It advises bankers to move decisively and immediately to become compliant or face almost certain business death.
It also warns bankers to closely examine the compliance of their loan customers. In other words, don't lend to businesses that might fail in 2000. This is good advice with potentially very bad economic consequences: Borrowers will certainly fail before that date if they are cut off from bank financing by their loan officers!
Dire Consequences. The Basel Committee observes that if a bank fails to fix the Y2K problem:
Complicating the problem for global banks is that they must also program their computer systems to deal with a brand new currency, the Euro. The Committee warns banks against taking on any new projects like merging with or acquiring a noncompliant bank. On the other hand, noncompliant banks are advised to consider finding a compliant buyer as "an approach to contingency planning."
Systematic Risk. Compliant banks must develop contingency plans in the event of
"systematic issues," a.k.a., the domino effect. Weak links in the payment chains could "rapidly
affect others if payments fail to move as expected."
Light At The End Of The Y2K Tunnel. The recent turmoil in Union Pacific's railroad system is a very useful example of the sort of disruptions that may become widespread after January 1, 2000. Some old-timers say the current situation is the biggest railroading crisis in decades. According to the October 13, 1997 issue of The Wall Street Journal, "The nation's largest railroad has lost its ability to accurately track the movements of hundreds of freight cars ." The problem started when Union Pacific acquired Southern Pacific Rail Corp. last year. Each company had its own computer system and dispatching method. Integrating the two has been a nightmare according to a Union Pacific spokesman.
Early Y2K Effort Derailed? This problem is disrupting business for many companies as they prepare for the usual seasonal rebound in sales during the final two months of the year. It could be much worse in the year 2000 if Union Pacific is distracted from addressing its Y2K problem by the current mess.
Ironically, the company was among the first to recognize and start working on the Y2K problem. According to the January 1, 1996 issue of Datamation, the company began experiencing Y2K problems in 1995 with software programs that handle five-year car scheduling, budgeting, and forecasting tasks. It was an early wake-up call. A company analysis revealed that 82.5% of the programs had date-related fields. The Y2K project manager estimated that his team had to fix 7,000 COBOL programs totaling about 12 million lines of executable code. He estimated the job would require 200,000 hours or 100 staff years.
State-Of-The-Art In Theory. By its own description, Union Pacific is "one of North America's leading transportation, computer technology, and logistics companies, with operations in all 50 states of the United States, Canada, and Mexico." Union Pacific Technologies (UPT) was founded in 1987 as the technical arm of the corporation. It provides state-of-the-art computer and telecommunications systems and services throughout the corporation. The corporation's Web site boasts that UPT's Transportation Control System (TCS) is the premier freight car management system in the rail industry. "With TCS, Union Pacific has been able to centralize train dispatching and customer service, since it remains the only system with proven capability to schedule shipments from origin to destination all firsts in railroading."
UPT has sold TCS to others to improve Union Pacific's "capability to deliver reliable, seamless service" when it involves other transportation companies. Several US railroads now use TCS. UPT's systems helped to modernize the National Railways of Mexico. According to the corporate Web site, "UPT has extensive experience in railroad computerization. Personnel currently associated with UPT were responsible for the original development of the Transportation Control System (TCS) on the Missouri Pacific Railroad and its subsequent implementation on the Union Pacific and Western Pacific Railroads after the 1982 merger. TCS is recognized as the most comprehensive freight car management system in the railroad industry today."
Over 2,000 man-years have been spent developing a highly integrated system that controls all aspects of railroad operation, including:
State-Of-The-Art In Crisis. In an October 1, 1997 press release, Union Pacific announced that the Railroad division filed a Service Recovery Plan with the Surface Transportation Board. It presented a plan that should return the Central Corridor roughly stretching from Chicago to Oakland back to "acceptable levels" within 30 days. Service in the Southern Corridor, running from Memphis and New Orleans through Texas and into southern California, should be back to normal within 60-90 days. "Once this occurs, UP will begin to restore services that were temporarily withdrawn." The press release also claims that the schedule for implementing the computerized TCS on the former Southern Pacific "has been advanced by several months and will be entirely completed by March 1, 1998." (Gee, I sure hope TCS is Y2K compliant.)
Editorial. This entire sorry mess should give you a hint of what sort of disruptions could occur in transportation, shipping, manufacturing, retailing, and power generation in plausible worst-case scenarios. In Washington, the policy makers are asleep at the switch. Just the way UP has lost track of many of its freight cars, we could lose track of vital components of our economy. Many companies are so busy acquiring and integrating with other companies that they are derailing the Y2K efforts of their IT departments. I still think there is a 35% chance of a recession in 2000. Why aren't I raising the odds? I probably will soon.
Will It Fly? The OMB is especially concerned about the lack of Y2K progress at the Department of Transportation (DOT). The Federal Aviation Administration (FAA) in the DOT may be their biggest concern. The Year 2000 effort is decentralized within the FAA, which first established its Y2K Steering Committee in July 1996. The committee's members represent the FAA's seven lines of business (LOBs). The committee is chaired by the director of Information Technology. The director issued a "Guidance Document for Year 2000 Date Conversion" during September 1996. An April 1997 updated version is available on Internet.
Each LOB is responsible for the Year 2000 conversion of its own systems. The LOB is responsible for funding the conversion, developing an overall inventory of systems, prioritizing the conversion of the systems based on the criticality of each system to the mission of the LOB, and developing and implementing a conversion plan.
Here are some less-than-reassuring excerpts from the Guidance Document about the FAA's year 2000 problem:
Triage. The FAA document raises an interesting problem for everyone working on Y2K: "The battlefield term 'triage' has come into frequent use in discussing Year 2000 planning .Impact assessment should identify which systems are mission critical and must be converted in order for the FAA to keep airplanes flying safely " In other words, most organizations are dependent on decisions made by their outside vendors about which IT products and services they consider to be "mission critical." Vendors may kill some applications that are critical to the survival of their customers.
Embedded Systems. In an April 3, 1997, response to a Congressional inquiry on embedded microchips, the FAA noted that they have "no formal plan to assess vulnerability of microchips embedded in airborne electronic equipment." However, both Douglas Airplane Company and Boeing Commercial Airplane Company are aware of the problem and are contacting their suppliers. Autopilot systems do not use a year function.
Bungled Modernization. Last week, in the first issue of The Y2K Reporter, I reviewed the sorry mess at the Internal Revenue Service. Attempts to modernize this agency since the late 1980s only worsened the situation. Similarly, the US General Accounting Office reports that the FAA initiated an ambitious air traffic control (ATC) modernization program in 1981. "Over the past 15 years, the modernization program has experienced cost overruns, schedule delays, and performance shortfalls of large proportions particularly in the $7.6 billion former centerpiece ." The good news is that the FAA acquired a functioning interim replacement for its "outage-plagued" system that processes data into radar screens. Nevertheless, the FAA still lacks a modernization blueprint and is poorly managed according to the GAO.
Where In The World Is...? Before January 1, 2000 comes August 21, 1999. The US Naval Observatory warns that some Global Position System (GPS) "receivers may display inaccurate date information [and] some may also calculate incorrect navigation solutions" after midnight August 21, 1999. The world's aircraft control software must be modified to expect and compensate for this Year 1999 Problem. Shipping and trucking software may also need to be fixed.
According to Mitre Corporation, "Global Position System is a satellite positioning system developed by the Department of Defense that provides precise position, velocity, and time information to users. There are 24 satellites in six orbital planes with four satellites per plane. They orbit the earth every 12 hours at a height of approximately 20,000 km, and transmit ranging signals modulated with satellite identification and location information. A user's receiver determines its position by determining the pseudorange to four or more satellites. A pseudorange is the range to a satellite plus the user's clock offset from GPS time. The pseudoranges are used to determine the four unknowns of the user's 3-D position and clock offset."
So what's the problem? The GPS Week Number count began at midnight on January 5, 1980. Since that time, the count has been incremented by one each week, and broadcast as part of the GPS message. The GPS Week Number field is modulo 1,024. This means that at the completion of week 1,023, the GPS week number will rollover to 0 on midnight of the evening of August 21, 1999.
The US Navy warns, "Once the rollover has occurred, it is the responsibility of the user (i.e.,
user of equipment or software) to account for the previous 1,024 weeks. Depending upon the
manufacturer of your GPS receiver, you may or may not be affected by the GPS Week
Number Rollover on August 22, 1999. Contact the manufacturer of your GPS receiver to
determine if you will be affected by the GPS week number rollover." Fortunately, planes and
ships that use GPS to navigate around the globe are unlikely to be driven off course: GPS is
rarely used as the sole means of navigation.
A Flat Tax Rate In 2000? The government may have to impose a flat tax-rate system in 2000. Why? Because it is increasingly likely that the federal tax collection, processing, and compliance systems will break down in that year. I realize this is a strong statement, but it comes directly from the IRS. The May 15 "Request for Comments for Modernization Prime Systems Integration Services Contract" is a distress call to private industry to bail out the taxing agency. They are already overwhelmed and simply don't have the resources to handle Y2K, a.k.a., Century Date Conversion: "A still greater and far-reaching wave of work in the form of the Century Date Conversion is cascading over the diminishing [IRS] workforce that is already insufficient to keep pace with historical levels of workload." The IRS is so desperate that they want to form "strategic partnership" relationships with private industry:
Running Out. Aside from troubling confidentiality issues, the big question is whether there is even enough time for any prime contractors to fix the IRS. I seriously doubt it since the schedule in the RFC anticipates that prime contracts will be awarded no sooner than October 1, 1998. Most Y2K experts agree that any organization that doesn't begin to fix the problem by October of this year won't meet the unmovable and unforgiving January 1, 2000 deadline.
Big Brother, Big Mess. It turns out that Big Brother is totally and hopelessly disorganized, notwithstanding a modernization program during the 1980s and early 1990s which in many ways exacerbated the situation. "Overall, the IRS computing environment evolved into an extraordinarily complex array of legacy and stand-alone modernized systems with respect to both connectivity and interoperability between the mainframe platforms and the plethora of distributed systems." The IRS has more than 62 million lines of computer code, three big mainframes, and 60 other mainframes in 10 regional offices. According to the RFC, "None of the mainframes are century date compliant, thereby necessitating immediate actions ranging from systems software upgrades to replacement." Thousands of applications systems are "undocumented," i.e., lost, if they ever existed.
There is no central data base. The IRS "neither maintains the source payment documents nor posts either detailed transaction-specific payment or tax case information to the Master Files. Instead, the detailed tax and tax case information is stored on stovepiped systems with stand- alone databases which, for the most part, are not integrated with either the Master Files or the corporate on-line system."
In 1988, the IRS implemented the Tax System Modernization (TSM) plan to upgrade and modernize the agency's technology. The program created stand-alone ("stovepipe") systems for the 10 service centers based on "the principles of distributed computer processing, an approach to computing en vogue during the late 1980s and 1990s." The numerous databases are difficult to synchronize and to manage. The system is breaking down. Y2K will break it for sure. The IRS observes:
In 1995, the General Accounting Office reported that TSM was a disaster. The system's multiple computers and databases could not integrate with existing computers. It made the IRS even less efficient. Congress ordered the IRS to produce a new modernization plan by May 15, 1997. A seven-volume Blueprint for Modernization was produced and the Request for Comments was issued. (See the "Today/Target" flow chart on page 8.)
"Stay In Business" Is The Goal. "Under the crushing time constraints of the millennium change," the IRS is working with its current contractors on interim Y2K fixes, but admits that it "lacks the capacities and capabilities to simultaneously manage the existing workload and effectively partner with the private sector to commence Modernization. Any reasonable strategy to move forward, therefore, would focus on managing the immediate crisis 'stay in business' while building capacity to prepare for future Modernization."
CIO Is Worried About Living On This Planet. In the September 15, 1997 issue of my Y2K Reporter, I reviewed a May 15, 1997 IRS "Request for Comment" (RFC) posted in the US tax- collecting agency's Web site. This procurement document has the tone of a desperate plea for help. The cover letter was signed by Arthur Gross, the Chief Information Officer at the IRS.
According to the October 17, 1997 issue of the Year 2000 Outlook, an e-mail weekly service of the Information Technology Association of America (ITAA), Mr. Gross recently spoke at their industry gathering in McLean, Virginia. Apparently, he is as concerned about his agency's Y2K problem as I surmised from the RFC. He was quoted as saying, "Failure to achieve compliance with Year 2000 will jeopardize our way of living on this planet for some time to come."
1997 Taxpayer Relief Disrupts Y2K Fix. According to the ITAA account of his candid speech, "Mr. Gross used words like 'massive' and 'numbing' to describe a program which has jumped from three people to 800. With the IRS software inventory 'not fully fleshed out,' Gross said the Y2K accounting covers up to 70 million lines of code, 95,000 components, and 120 mission critical systems." Not only does the IRS have to achieve Y2K compliance, but also the agency must simultaneously change its software to reflect the 1998 and 1999 changes required by the Taxpayer Relief Act of 1997. He indicated that the IRS was also preparing worst-case contingency plans that probably "won't be shelfware." Mr. Gross said the IRS is in a "marathon race" to the Y2K finish line. This is perhaps "the last opportunity to fix the tax system as we know it ."
The IRS man's speech was also covered in the October 20, 1997 issue of Federal Computer Week in a story titled "CIO: Tax bill hampers IRS's millennium fix." As a result of this year's Taxpayer Relief Act, the IRS loses three months and the entire system will be tested during the final 12 months of the century.
Countdown To Meltdown. The November 3, 1997 issue of Insight, a publication of The Washington Times, focused on all the problems at the IRS. One of the stories is titled "IRS Countdown to Meltdown." I spoke to the reporter, and I believe I inspired his investigation with my September 15 expos‚ of the Y2K problem at the IRS. His story mostly confirmed my analysis. Indeed, it quoted Arthur Gross telling a congressional commission that "failure to identify, recode, and retest each of these date-based fields could result in the generation of millions of erroneous tax notices, refunds, bills, interest calculations, taxpayer account adjustments, accounting transactions and financial reporting errors. Put another way, the IRS' capability to carry out its mission could be jeopardized."
Editorial.Is anybody listening to Mr. Gross? He is saying that the IRS might fail to fix its
Y2K problem and that the consequences of such a failure could be a calamity for the
government and the economy. He is saying Congress dramatically increased the risks of such
a calamity by legislating major tax law changes for 1998 and 1999 two very precious years
for those who are trying to fix Y2K at the IRS. Maybe Congress should postpone at least the
1999 tax law changes. Maybe Congress should prepare a simpler back-up tax system just in
case Mr. Gross puts up the white flag. Based on Mr. Gross' comments, I would advise you to
fine-tune your 1999 tax withholding so that you won't be waiting for a refund check in 2000.
Down To The Wire. In mid-September, the US Office of Management and Budget (OMB) issued its quarterly report "Progress on Year 2000 Conversion," as of August 15, 1997. OMB found that 18 of the 25 major government agencies are planning to implement their Y2K solutions during the last three months of 1999. As noted above, four agencies were warned about "insufficient evidence of progress." All agencies are advised to prepare contingency plans in the event that mission-critical systems are not fixed in time. The OMB also identified three new government-wide Y2K problem areas that must be compliant: telecommunications, bio-medical devices, and laboratory equipment and facilities. "In these areas, the problem occurs in commercial products that have computer chips inside."
Mission Critical. The OMB found 8,562 mission-critical systems ("excluding the Social Security Administration that has identified 29,139 modules"), which is 913 more than the number identified in the May survey. Of the total, 13% must be replaced and 62% must be repaired. Of the 5,332 mission-critical systems that are to be repaired, only 2% are fixed and working, 5% are fixed and have been tested, and 12% are fixed and being tested.
Chief US Auditor Sounds The Alarm. In Congressional testimony on July 10, 1997, Joel C. Willemssen the Director of Information Resources Management of the Accounting and Information Management Division of the US General Accounting Office (GAO) warned that federal agencies are running out of time to prepare for the new millennium. The General Accounting Office, the investigative arm of Congress, performs audits and evaluations of government programs and activities and examines matters relating to the receipt and disbursement of public funds.
The GAO Director was also critical of the implementation of the federal government's Y2K strategy by the Office of Management and Budget (OMB). Mr. Willemssen stressed that there is an urgent need to accelerate agency Y2K programs.
Four Pathetic Pitfalls. The GAO's top auditor proceeded to list four major shortcomings of the OMB's Y2K battle plan:
Other Critical Issues. There are at least three other major issues that Mr. Willemssen worries about:
Editorial: Prepare, Just In Case. If time is running out to fix the Y2K problem, maybe it is time to think about plausible worst-case scenarios and to prepare for them. Neither the government nor business is preparing contingency plans nor providing the information the public needs to understand and assess the risks of Y2K disruptions. There is no doubt in my mind that there will be disruptions. Consequently, I believe that there is an increasing chance of a recession in 2000. But I don't have enough information to predict either the duration or depth of such an event.
The Senate has yet to pass S.22, a bill introduced by Sen. Daniel Moynihan (D-New York) on January 21, 1997, that would authorize the president to at least appoint a bipartisan commission to evaluate the magnitude of Y2K and recommend solutions. The first sentence of the bill warns: "A devastating computer problem will have extreme negative economic and national security consequences in the year 2000 and in subsequent years, unless the Federal Government addresses and remedies that problem."
The Y2K commission should be authorized to establish several task forces with the power to
collect the information necessary to assess the vulnerability of our economy to Y2K
disruptions at key choke points in the following vital sectors: electric power,
telecommunications, transportation, manufacturing, finance, health care, national defense,
and government services and administration. Since this is a global problem, our national
efforts must be coordinated with those of other nations around the world.
Stress Test? Most news stories about Y2K focus on "legacy" mainframe computer systems. With a great deal of effort and expense, these can be repaired or replaced. However, the biggest and most widespread disruptions might be caused by a far tougher Y2K problem to fix, namely, embedded systems that are not Y2K compliant.
There are billions of embedded systems all over the planet. First the good news: Most are not date sensitive. But, some are, and no one can tell where they all are and how many of them might fail. All I know for sure is that they will be stress tested on January 1, 2000. This is one reason why I am certain that there will be Y2K disruptions, but uncertain about the magnitude of the trouble ahead.
What Are They? According to the Institution of Electrical Engineers (IEE), embedded systems are devices used to control, monitor or assist the operation of equipment, machinery or plant. "Embedded" means they are an integral part of the system. Consequently, a casual observer won't see them and even a skilled technician might need to examine the operation of a piece of equipment for some time before concluding that an embedded control device is in there.
All embedded systems are computers. Some of them are very simple devices compared to a PC. The simplest devices consist of a single microprocessor chip which may itself be packaged with other chips in a hybrid or Application Specific Integrated Circuit (ASIC). Its input comes from a detector or sensor and its output goes to a switch or activator, which, for example, may start or stop the operation of a machine or may control the flow of fuel to an engine by operating a valve.
Where Are They? They are everywhere. Table 1 on page 35 is a long, but not an exhaustive list prepared by the IEE of all the places these little gizmos reside. They are in elevators, traffic lights, and cars. The ones that are really worrisome are embedded in industrial, utility, telecommunication, medical, navigation, and military systems.
Can They Be Fixed? The thought of fixing/repairing/replacing embedded systems can make your head spin. First, you have to find them and determine if they have a Y2K problem. Engineers have reported finding chips performing the same function in identical equipment, yet some are Y2K compliant and others are not. Replacing embedded chips isn't easy. Some are customized and hard to duplicate. The manufacturers of some are out of business or have been acquired by other companies that do not intend to upgrade an "out-of-print" chip. Replacing chips older than three years is almost impossible because they have a short technical life span.
When Might They Fail? In embedded systems, the concern is often with intervals rather than
with specific dates. An event might need to occur at 100-day intervals rather than on the 5th
day of each month. This implies that Y2K problems may occur both before and for some time
after January 1, 2000 and not at all on the date itself. On the other hand, there is a possibility
that devices with cycles that are measured in hours, and minutes (or even seconds) may be
affected by the problem because year numbers are the basis of time calculations. In such
systems, the failure may not occur on the stroke of midnight but during the following 24
Embedded controllers may be found in the following kinds of system. This list is not exhaustive.
Escape From New York. The September 11 issue of Computer Weekly reported that the governor of New York State banned all non-essential IT projects to minimize the disruption caused by the year 2000 bomb after reading a detailed report that forecasts the millennium will throw New York City into chaos, with power supplies, schools, hospitals, transport, and the finance sector likely to suffer severe disruption. Compounding the city's Y2K risks is the recent departure of the head of its year 2000 project to a job in the private sector.
In July, a state official told the New York Year 2000 User Group that New York was only 5% of the way through its millennium projects, costing between $100 million and $185 million. New York City is spending $300 million to replace its non-compliant budget and accounting system and on fixing or replacing other systems. Despite these efforts and those being made in the private sector, an independent study of New York's infrastructure has estimated that the city still faces massive disruption for up to a month at the start of the year 2000.
The study, carried out by UK-based Corporation 2000, expects the city's hospitals to be
reduced to accepting emergency cases only, and schools to be closed for up to a month. Power
supplies and telecoms are only expected to be available at half their normal levels, and banks
and the stock market will be shut for up to eight days. This story was also covered in the
September 12, 1997 issue of the Financial Times: "New York City faces significant disruption
at the turn of the century despite being among the best prepared of the world's cities.
Home | Menu | Links | Info | Chairman's Page