When Mary Bandar didn't report to kindergarten as instructed by Minnesota state officials in 1993, she had a valid excuse: The 104-year-old Winona resident had already done her time with blocks and crayons. State computers mistook her as a 4-year-old because "89" was at the end of her birth date.

Similarly, year 2000-related glitches have already cropped up in many forward-looking computer applications, from drug-expiration dates to manufacturing systems. All provide a sneak preview of the problems expected to arrive in January 2000.

One survey found that 40 percent of companies polled have already experienced some type of year 2000-related disruption. Problems included processing errors, financial miscalculations and customer-service disruptions, according to an ongoing survey of 128 executives conducted by Cap Gemini America. The survey was updated last month.

But screwing up early has its rewards. Just ask Bob Vis, year 2000 coordinator at the US$6 billion Amway Corp. in Ada, Michigan.

About nine months ago, a PC-based mixing system in one of the company's plants rejected a batch of chemicals for a cleaning product because its expiration date of 2000 appeared to the system to have lapsed. The system read the 2000 date as 1900. And in mid-1996, a mainframe-based, five-year forecasting system quit forecasting beyond three years, eight months.

Neither failure brought the company to its knees. Plant workers manually overrode the mixing system, and programmers have since fixed the forecasting system.

Instead, Vis said, the snafus actually worked in his favor.

Before the failures, "senior management's attitude was that 2000 was a long ways off, and we'll fix it later," Vis said. "When they found out that some stuff was actually failing, they figured they better look more closely."

Now managers from manufacturing and facilities operations are part of the year 2000 project team. Amway also has set up an on-site coding factory, where about a dozen contract programmers are fixing the company's primarily mainframe-based Cobol applications.

"For most companies, all it takes is one good failure, and they get religion right away," said Lou Marcoccio, an analyst at Gartner Group Inc. in Westboro, Massachusetts.

Prime candidates for pre-2000 glitches include applications that have expiration dates, coverage dates, contract terms, project completion dates, delivery dates, payment schedules, age and birth dates, release dates, notification dates and graduation dates.

Even systems that haven't already had a year 2000 problem may encounter trouble in 1999, when budgets and sales forecasts look ahead one year.

So far, most of the failures have been isolated. Companies have worked hard "to keep a lid on them. [Companies] don't want any loss of confidence on the part of investors or customers," said Noah Ross, a vice president at Cap Gemini in Tarrytown, New York.

But some early glitches have been serious.

Last year, the year 2000 bug hit the agency that supplies food, fuel, medicine and clothing to the U.S. military, according to a congressional report. A date calculation error in the Defense Logistics Agency's materiel management system simply dropped 90,000 items from the inventory. Correcting the problem took 400 hours.

Because of its reliance on so many calculations and forward-looking systems, the financial services industry was hit by the first wave of year 2000 snafus. Until recently, retail point-of-sale systems couldn't read credit cards with "00" expiration dates.

As consumer complaints increased, Visa International, Inc. banned member banks from issuing credit cards with expiration dates beyond 1999. Visa lifted the ban last October, once most of the buggy card readers had been fixed.

Early point-of-sale failures led to what is believed to be the first year 2000-related lawsuit. Produce Palace International in Warren, Mich., filed suit last July because its computerized cash registers crashed when customers used credit cards with expiration dates in 2000.

The suit was filed against Atlanta-based TEC America Inc. and a local service vendor that had installed the system in 1995 with assurances to Produce Palace co-owner Mark Yarsike that it would serve his needs for at least the next 10 years. But within three weeks of its installation, the system began to fail, crashing more than 100 times and rendering the cash registers useless.

"It was very costly and very stressful and very embarrassing," said Yarsike, who said he had to hire additional employees to keep the books by hand while the computer was down.

His lawsuit is still pending. The defendants made an offer to settle, but Yarsike said he refused. He plans to proceed with the litigation. TEC America spokesman Jeff Warren confirmed that the lawsuit is ongoing but declined to comment on specifics of the case.

Some life insurers began tweaking policy administration systems as far back as the 1980s to support 20- and 30-year insurance policies. Companies "have run into trouble with three-year annuities and other date-sensitive systems, but they weren't major problems," said Lynn Ganim, a senior associate at LOMA Inc., an Atlanta-based financial services trade association with 900 members.

A silver lining is that the glitches helped insurers track down isolated problems quickly instead of having to scramble in January 2000, she said.

Early detection of a problematic certificate of deposit system helped BankBoston's millennium project team "break through some of the denial" of the problem within its management ranks, said Steven McManus, communications manager for the team.

During a 1996 checkup of systems at Rhode Island Hospital Trust, which BankBoston acquired in November 1985, BankBoston found that date problems with the bank's Cobol mainframe-based system could have created two potential snafus: Customers wouldn't have received their maturity notices, and CD accounts falsely recognized as 100 years old would have been put in a lost-and-found bin and transferred to the state.

The catch "was a real eye-opener," McManus said. The bank converted the CD system to BankBoston's year 2000-compliant mainframe platform in June.

Allstate Insurance Co. in Northbrook, Illinois, is capitalizing on failures that go back as far as 1990 by selling the software it developed in-house to fix date problems in its massive policy processing system. The date problems showed up so early because many customers' policies and loans extend into 2000 and beyond.

Supervalu Inc., a US$17 billion food wholesaler in Minneapolis, crossed its first year 2000 "failure horizon" on Feb. 28, said Fred Knotek, year 2000 director. That's the day the wholesaler's mission-critical forecasting system would have failed if Knotek's 60-person year 2000 team hadn't organized its work by that failure date.

Two years ago, a joint team of technology staffers and business users went through each of Supervalu's critical applications to determine when initial failures would occur. Since then, the company has outrun glitches that might be triggered by a year 2000 food expiration date, for example, by fixing systems in order of their break deadlines.

"As a result, we've been able to avoid problems before they occur," Knotek said. His advice: "Really know your applications in terms of when exactly it will fail, prioritize accordingly and do remediation and testing well in advance."