Recommended Resources
Cyberhaven.com Offshore havens, asset protection, global investing and other useful techniques.
The Year 2000 Bookshelf Books to help your evaluate the Y2K problems you face.

Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)


Category: 

Introduction

Date: 

1998-06-01 10:21:29

Subject: 

U.S. NEWS Runs Straight Story, Filled With Bad News

  Link:

http://www.usnews.com/usnews/issue/980608/8y200.htm

Comment: 

The mainstream media are slowly beginning to deal with y2k as a news story, not as a joke.

This means that public awareness will slowly move to concern. But it will take a year.

From concern, it will move to panic.

People will not face this story. That's why the delay is so great. It is only this unwillingness to comprehend and face the issue that gives you time to act.

You can still buy solar panels. That means the public has yet to figure y2k out. But China Diesel Generators is now backed up three months. You may have missed that opportunity.

If sit there dawdling, you will miss many more.

This is from U.S. NEWS & WORLD REPORT (June 8). It confirms what I have been saying since 1996. But most of my readers have done nothing.

What will it take to get most of them to take action? Simple: public awareness of the crisis so great that they will not be able to afford to take action. They will have frittered away a two-year lead.

* * * * * * * * *

Fixing the Y2K problem is also simple--in concept. Someone must examine every line of code in every computer, locate the instructions regarding dates, and rewrite them to accept 2000 as a year designation. But despite the rising din of warnings, surveys indicate that too few managers in business and government recognize how little time is left to complete the task. Here's a look at five year 2000 myths that may promote complacency:

MYTH 1: There's plenty of time. . . .

In the private sector, entire industries are bracing for the worst: A recent International Air Transport Association survey of 44 major airlines shows that only 67 percent expect their systems to be fully Y2K compliant by Oct. 1, 1999. Any slippage would put them right up against the new millennium, with entire systems--from scheduling to maintenance--in jeopardy. "Failure to act decisively could have catastrophic consequences," IATA Director General Pierre Jeanniot has warned.

Among large companies that reported their Y2K progress to the Securities and Exchange Commission, a study shows that only 42 percent have finished inventories of their critical computer systems. And that's just the first step. Companies next must assess the size of their Y2K problem, decide whether to hire outside technicians, and then begin the slow process of repair. It turns out that progress is even slower in small and midsize companies. A National Association of Securities Dealers survey found that 61 percent of small businesses have not yet come up with a Y2K plan. . . .

Late starters are in big trouble because the

MYTH 2: Someone will find a quick fix soon. . . .

At least 600 different computer languages are in use throughout the world, containing several billion lines of code. Connecticut uses 19 different programming languages in its state-run computers alone. John Rowan, information-technology director for Fulton County, Ga., who has been tackling the Y2K problem for a year, says his mainframes, midrange computer systems, and 3,200 PCs use about 4 million lines of code in six different languages.

It gets worse. Many programs are written in "modular" style, meaning one segment may be written in one language, like COBOL, while the next segment might be in C++. A silver bullet for fixing COBOL would be very helpful in the COBOL segment but useless in the next. And one uncorrected module is like a burned-out bulb in a string of cheap Christmas lights: The whole string goes down.

If that's not enough, a lot of the earlier code that has survived in various forms through the years did not adhere to any standard that could be easily scanned by a fix-it program. The old programmers were as much artists as technicians: They simply created their own style. A programmer might use the name of a girlfriend or daughter as a code word to designate a date field, making it virtually impossible for another technician to tell from the program language which words refer to date fields and which don't. The only answer is for trained technicians to read each line of code and find the critical bugs. . . .

MYTH 3: We are throwing enough money and people at the problem to fix it. . . .

But even if enough money were allocated, there aren't enough people--debuggers and testing specialists who know ancient and varied programming languages--to renovate the billions of lines of code that need repair. Already there are more than 345,000 unfilled openings for technology specialists. That will only get worse as the year 2000 draws nearer and more companies move into the labor-intensive testing phase.

MYTH 4: With so many new computers out there, surely we can't be vulnerable to a problem created 25 years ago. . . .

Ironically, one reason the Y2K bug has survived is the concept of "backward compatibility," which was introduced in the 1960s to bring order to computer development. IBM and other computer companies, realizing they couldn't expect clients to buy new software every model year, made sure that each new model was largely compatible with earlier programs. That, however, created an environment in which the old Y2K bugs have been able to worm their way--program by program--into the most modern equipment.

MYTH 5: With luck, it won't affect me.

Not likely. At a recent congressional hearing, Gene Dodaro of the U.S. General Accounting Office warned that "critical services could be severely disrupted." . . .

One risk-management executive describes a client he won't name--a Midwestern electric utility--that ran a test for Y2K compliance. When the test clock turned over to the year 2000, a safety system mistakenly detected dangerous operating conditions, and the power generators completely shut down. Programmers worked on the problem for three days, then reran the test. A different sector failed, shutting down the system again. Technicians have yet to fix the problem. The debacle underscored one of the most unsettling aspects of the Y2K bug: Fixing the program that runs one piece of equipment can have disruptive effects on other parts of the system. . . .

In the end, prices of goods and services rise to pay for fixing the bug, for the inevitable failures afterwards, for legal costs and lost productivity. It could add up to a $600 billion problem, says Lou Marcoccio, year 2000 research director at GartnerGroup, and "we're all going to pay that tab.

Link: 

http://www.usnews.com/usnews/issue/980608/8y200.htm

Return to Category: Introduction

Return to Main Categories

Return to Home Page