Catch the millennium bug - before it's too late - financial services and Year 2000 - includes related articles on SunGard Financial Systems Year 2000 solution - Industry Trend or Event

Software Magazine, Jan, 1997 by Colleen Frye

Tick, tock. Tick, tock. It's January 1997: Do you know where all the dates are in all your lines of code? More importantly, do you know if those dates will accommodate the Year 2000? If not, experts say you'd better wake up and address the problem, because while squashing the "Millennium Bug" does not require rocket science, the effort is time-consuming and littered with small details.

"I think we'll all concentrate on the big packages and do a lot of testing on those," says Jim Adams, director of MIS, Gaylord Container Corp., a pulp and paper company in Deerfield, Ill. "It will be the little things that kill us for a month or so, like interfaces. If you think of everything you look at that has time/date built into it, it's mind-boggling how many dates we have floating around." At his division, Adams is grappling with older financial and manufacturing applications written in Business Basic that do not handle the Year 2000.

"Financials applications are being hit because of the date tendency," says Jannette Alston, senior analyst with Datapro Information Services Group, Delran, N.J. "Mortgages, loans and payrolls are all very date-dependent. And those applications interface with other programs, and institutions interface with other institutions, and they need to be prepared as well. Even if an individual bank is prepared, they may be interfacing with another organization that may not be."

Yet the millennium problem goes beyond core systems like financials. "In reality it affects every application an organization has," says Dave Wilkins, Year 2000 services manager at Atlanta-based Geac Host Technologies Division, formerly Dun & Bradstreet Software (DBS). "Every piece of code, every application if it's got a date it's suspect. This affects financial applications, but many mission-critical systems that are unique to an organization that may have been custom-developed are just as suspect, if not more so. It's an equal opportunity bug."

That "bug" is the two-digit date fields programmed into many systems a technique used in the past to save storage space. These will not recognize the "00" of the Year 2000, but instead will interpret the date as 1900.

Software developers are primarily using three coding techniques to achieve Year 2000 compliance, says Tom Oleson, research director at International Data Corp. (IDC), Framingham, Mass. One is replacing a two-digit date with a four-digit date using compression, putting two digits into a one-digit field. Developers are also expanding date fields to four digits. The third technique involves applying some logic to the two-digit field so that the Year 2000 and beyond are properly calculated. Says Oleson, "For long term, either compaction or expansion of the field eliminates future maintenance. Interpretation [applying logic] in the short run is the least expensive but involves future maintenance."

Both in-house developers and independent software vendors are feeling the impact of the Year 2000. Vendors, according to Dennis Byron, associate managing analyst for client/server analyst service at Datapro, have the issue under control, even though all their packages may not be fully compliant yet.

Financial applications vendors Geac and Atlanta-based Ross Systems Inc., for example, both have legacy bases that they've committed to support with Year 2000 releases. Geac's Wilkins says the company has well over 4,000 mainframe customers on maintenance. In addition, "We've had a number [of legacy customers] come back on maintenance. They find that getting the Year 2000-compliant release is more cost-effective than if they try to renovate or replace the code."

Most of the financial applications within Oracle's suite can handle the Year 2000 now, says Kerry Lamson, vice president, applications product marketing at Oracle. The entire suite will be fully compliant with the release of Version 10.7 in February, he says. Oracle is encouraging all customers to upgrade and has not decided yet if they will back-port compliance to Version 10.6. However, Oracle will provide a kit so customers can back-port themselves for Year 2000 compliance.

SAP America Inc., Wayne, Pa., says all releases of its R/3 programs are century-compliant, as well as versions 5.0 and 6.0 of R/2. According to the company, fewer than five R/2 customers are currently using R/2 release 4.3 or 4.4, which were not made compliant. All R/2 4.3 and 4.4 customers have already been supplied with release 5.0, which includes upgrade programs that automatically handle migration of data into the new four-digit year format.

While customers of vendor packages are being supplied with Year 2000 solutions, companies with homegrown software face a bigger challenge. "The big issue is with the underlying utilities and in-house-developed software," says Datapro's Byron. "Many of the applications written in the '70s and '80s that have a date problem are applications that companies feel give them strategic advantage, especially in the financial services industry. You can almost draw a chart that the more a system of enterprise management software is based on a legacy design, the more it has a problem."