Y2K problems threaten to begin early
10/26/98
By RICH MILLER
Staff Writer
EWING -- We have 431 days to fix the year 2000 computer problem, right?
Not necessarily.
At New Jersey Manufacturers Insurance and many other organizations, D-Day is Jan. 1, 1999, when some accounting programs will begin to encounter data with "00" as the end date.
Ewing-based New Jersey Manufacturers needs to finish its Y2K repairs a year early so it can sell one-year insurance policies in early 1999 that will expire in 2000. Company Vice President Paul Beiger Jr. said the company would wrap up its Y2K project well before the end of this year.
Programmers say Jan. 1 -- which is less than 70 days away -- is the first of several 1999 dates that could trigger failures.
Such "pre-Y2K" failures will be far fewer and less difficult to fix than those expected to occur Jan. 1, 2000, when many computers may not properly recognize the new millennium.
THE UNFOLDING of these pre-Y2K trigger dates, particularly those in the second half of next year, will serve as a leading indicator of whether the attention to the Year 2000 issue is justified or mostly hype. Other dates next year that could cause computer malfunctions include July 1 and Sept. 9.
As the time left for Y2K repairs dwindles, large corporations are now beginning to openly address potential problems:
-- KLM Royal Dutch Airlines said last week it might have to ground part of its fleet Dec. 31, 1999, because some international airports and air traffic control systems have not adequately addressed their year 2000 problems.
-- In an Oct. 20 SEC filing, PepsiCo expressed optimism about its Y2K project but acknowledged the possibility of "a temporary inability to manufacture or bottle product in certain locations" after Jan. 1, 2000.
Meanwhile, Y2K experts expressed concern about a new cousin of the millennium bug, a sneaky glitch that can cause the clocks on some types of computers to jump ahead unpredictably when the machines are restarted after 2000.
The most immediate concern is whether the arrival of Jan. 1 will unexpectedly jumble accounting programs. Such date-related snafus are not uncommon in computing, but are more problematic when they come in bunches.
"For the last few years there have been failures at the beginning of every year," said Joe Allegra, president of Princeton Softech in Montgomery. "There are also always leap year problems. Systems fail all the time. The scariest thing (with Y2K-related date triggers) is that everything's changing at the same time."
Many organizations that handle long-term agreements and licenses have already addressed these kinds of forward-looking Y2K problems. Mortgage companies with 30-year loans have had to process "00" transactions for years.
THE NEW JERSEY Division of Motor Vehicles has been successfully issuing drivers' licenses with expiration dates past 2000. Recently Visa and MasterCard have begun issuing credit cards with 2000 expiration dates.
But some Y2K observers worry that companies have delayed starting their year 2000 repairs, not realizing their computers may need to be ready months earlier than Jan. 1, 2000.
The programs most likely to be affected are those that sort transactions by dates. If on Jan. 1, 1999, a system still believes 00 is 1900 rather than 2000, it will treat a one-year contract with a 00 end date as ancient rather than brand new.
"Because it's a look-forward, it's not going to be particularly noticeable," said Steve Sroczynski of Visionet Systems, a South Brunswick-based Y2K company that repairs Y2K problems in IBM mainframes. "It tends to come up most often in business-to-business transactions."
Sroczynski said the impact of these failures is expected to be small compared to the potential problems at the Jan. 1, 2000, rollover. But it could seem like a big problem for the company that experiences it, he noted.
Several other 1999 dates also create potential problems.
The biggest pre-Y2K concern is fiscal year accounting. New Jersey will begin its 2000 fiscal year on July 1, 1999, and some companies start theirs even earlier.
In SEC filings this week, a number of corporations said they must complete their Y2K projects as soon as April 1 because of fiscal year considerations.
Sept. 9, 1999, is a date that could be a problem for database and spread sheet programs in which "9/9/99" was entered as a universal expiration date -- never anticipating that that program might still be in use.
Meanwhile, year 2000 experts are debating the possible impact of a related glitch that can cause random jumps in date and time when some Y2K-compliant computers are restarted after the year 2000 rollover.
The phenomenon, known as the Crouch-Echlin Effect, was first observed last year by two software engineers and confirmed last week by Digital Equipment. It was widely discussed last week on Internet newsgroups and e-mail lists devoted to the Y2K problem.
"The effect has the potential of causing such problems as randomly crashing your accounting system or, in the case of extreme system failures, causing a plant or factory to stop production," wrote Mike Echlin, one of the engineers who stumbled across the anomaly.
The Crouch-Echlin Effect occurs in computers with an internal clock known as a "nonbuffered" Real Time Clock. The problem has been found most frequently in older 286, 386 and 486 computers, but has also been documented in some Pentium computers and embedded processing systems.
THOSE MACHINES may handle the Y2K rollover just fine. But when they are turned off and on again, a glitch in the way the machine restarts itself can cause erroneous date and time settings to be sent to the computer's operating system.
In one test, a computer set ahead to Jan. 9, 2000, for Y2K testing jumped to April 17, 2000, when restarted the following day. Any files worked on were saved with the date of April 17 rather than Jan. 10, generating miscalculations. Within two weeks, the computer believed it was December 2000.
Several firms are now providing to utilities software that can find and repair the Crouch-Echlin problem
|
