|
The greatest single problem among the family of problems known as y2k is the problem of systems. To repair a single mainframe-based system is very hard to do. To repair a system of independent but connected mainframes is impossible. This is what the commentators refuse to discuss. This is the first question a journalist should ask: "How can the system hold up if any of the components is non-compliant?" If it is non-compliant, it infects the compliant computers, thus negating the entire repair. But if the noncompliant component is locked out of the system, all of its data are locked out. How many components can be locked out before the system ceases to be a system?" On this question hangs the survival of Western civilization.
Consider these systems: railroads, telecommunications, and public utilitites, especially a nation's electrical power grid. But, above all, there is banking. If the banks go down, the division of labor collapses because the means of payment becomes local: barter, small denomination bills, clad coins, silver coins, and for large transactions, gold coins.
The issue of coherent systems is the key question. How will all of the independent repairs -- if actually completed -- fit with each other? I have seen no better report on this problem than the article by Tim Wilson in the May 5, 1997, issue of NETWORK WORLD. I reprint parts of it here.
The key paragraph is the last one:
The problem doesn't end there: Even if all Year 2000 snafus are fixed, says Fairfax, Va. - based American Management Systems, the resulting format inconsistencies will create 1,768 ambiguous dates that computers could misinterpret in the first decade of the new millennium.
________________
The Year 2000 problem - a glitch that causes older applications to misinterpret data referencing dates from the new millennium is usually portrayed as a legacy mainframe issue. But IS managers, consultants and others who work on the problem say the bug could have a profound impact on client/server and networked applications-particularly in the world of electronic commerce, where businesses rely on each other for accurate data.
As a result, even if a company fixes the Year 2000 bug in all of its applications by the deadline - and many won't - that company still relies on external systems that have not solved the problem, or haven't solved the problem in the same way.
In short, unless networking issues are addressed, even organizations that have corrected their internal systems may import erroneous, incompatible, or Year 2000 - damaged data. The Domino Effect "Think of it as a virus," says Jon Church, general manager of the Insight 2000 consulting program at Software AG, Reston, Va.
"If you have bad data on one system and it's promulgated across the network, there's a domino effect on the other systems. Similarly, if you fix the problem on one system, all of the systems that rely on that data will have to be changed to reflect that change."
Steven McManus, communications manager at BankBoston, the country's 15th largest bank holding company with more than $62 billion in assets, offers a real-life example.
"At the bank, we might have 10 different products-checking accounts, savings accounts, mortgages, mutual funds-running on 10 different applications, some of which rely on external data," he says.
"One of the services we offer is a consolidated statement that shows all of the customer's financial assets on one page. But if all those applications are not Year 2000 compliant, the math on your statement is going to be wrong," McManus says. . . .
What's clear is that the bug affects virtually every business that uses computers and networks, and most companies will not fix the problem by Jan. 1, 1999 - the generally accepted deadline.
"We believe about 50 percent of all companies just aren't going to make it," says Ann Coffou, managing director of the Year 2000 Relevance Service at The Giga Group, a Boston research company.
"Of those, we believe about a quarter will be driven out of business, between the costs of resolving the problem technically and the legal fallout resulting from their failure to fix it." . . .
Some industries have formed Year 2000 groups that attempt to set standards for date formats. The Securities Industry Association, New York, is defining guidelines for electronic securities trading, and the American National Standards Institute is working on date specifications for electronic data interchange under its X12 standards 2E.
Most businesses, however, must find and fix the incompatibilities between networked applications without the benefit of industry standards.
"Companies are fixing the Year 2000 bug in a distributed fashion - each does it individually," says Ming Lai, senior director for Year 2000 analysis and implementation at Bellcore, Red Bank, N.J., which consults with many telecommunications carriers and large enterprise customers on the compliance issue.
"The problem is that none of them know much about the interfaces between systems, and they don't know what the others are doing. That's the scary part."
Lai says last month Bellcore published a date standard for the telecommunications industry - Generic Requirement 2945 - that it hopes will be widely adopted to prevent potential communications problems between the switches that deliver public voice and data services.
But IS managers are still wary about the Year 2000 problems that could have an impact on public data networks. . . .
"There will be a lot of situations in which the dates look fine - they have the right format and number of digits - but they are wrong because the computer has misinterpreted them," Rife says.
"They may use different pivot dates to determine which century they are in. They may use European date formats, which are different from U.S. date formats."
The slow deployment of Year 2000 solutions, combined with the incompatibilities of date-sensitive data transmitted across networks, virtually guarantees that the Year 2000 problem will affect interdependent systems well beyond 2000, Rife says.
"There's a rule that says for every 10 lines of code you write, you introduce one error. With this problem, we are writing millions of lines of new code, and we are exposing problems in the old code in the process," Rife says. . . .
There are two ways to fix the problem: date extension and windowing. In a date extension fix, the date field is expanded from two digits to four, leaving room for the full year. This approach is the most effective over the long term, but it's expensive and time-consuming because it requires changing each date-sensitive line of code-often by hand.
The windowing method lets developers preserve the two-digit date format by designating a "pivot date" to differentiate the centuries.
Example: Any two-digit date of 70 or over would be assumed to be a 1900 date; any date of 30 or under would be assumed to be a 2000 date. This solves the problem for the next 20 years, by which time the apps in question presumably would be replaced by newer apps containing the four-digit date format.
Unfortunately, there are no standards for windowing, so some apps may use 30 as the pivot date, while others may use 40 or 50. As a result, incompatibility in networked apps may occur that incorrectly translate data such as birth dates. And, there will be incompatibilities between apps that use data extension and those that use windowing.
The problem doesn't end there: Even if all Year 2000 snafus are fixed, says Fairfax, Va. - based American Management Systems, the resulting format inconsistencies will create 1,768 ambiguous dates that computers could misinterpret in the first decade of the new millennium.
|