How to squash the millennium bug

City and county governments have a bug to kill by jan. 1, 2000. But it is not a problem they can delegate to their landscaping or parks and rec departments. This bug has to be killed by the information technology department. If it is not squashed, the millenium bug will cause computer mainframes and PCs across the country to spit out faulty data. According to one estimate, companies worldwide will have to spend between $300 billion and $600 billion to reprogram their computers.

The problem stems from the fact that programmers in the 1960s and ’70s opted, to store only the last two digits of the year in the date fields on the older mainframe systems.

The two-digit year was used rather than the four-digit field in order to conserve disk storage space, which, at that time, was extremely expensive and limited. For instance, 1965 was stored as 65 in the older mainframe systems.

Taken to its simplest level, this means that were a municipality to use one of the older computers to calculate, say, the age’ of a Social Security recipient, the date of birth would be entered as 1930, which, from the computer’s perspective is “30.”

The computer would then subtract 30 from 1996 to determine that the recipient is 66. If the computer has the millenium bug, however, on jan. 1, 2000, it will subtract 30 from 00 and conclude that the recipient is minus 30 years old.

The ramifications could be profound, especially for date-sensitive municipal applications that require calculating age, computing interest, issuing multi-year purchase orders, verifying expiration dates and generating invoices. Additionally, spreadsheets, accounting packages and e-mail systems would contain incorrect data.

The millennium bug has not surfaced as a major issue because some information system managers are reluctant to force the issue with management.

Many programmers are under the impression that they can solve the problem on their own as late as 1998 — an 11th hour operation for most systems. But, for. absolute certainty, the reprogramming should go through at least a year of testing.

Another problem is that the year 2000 seems distant to most managers because it does not concern bottom line figures and applications for this quarter or this year.

A number of city and county agencies rely heavily on older, mainframe-based programs, putting them in a risky spot. And, as Phoenix Project Manager Stan Price says, “Local government applications are very date intensive,” thus compounding the problem.

For instance, in municipal applications such as utility systems, licenses, city and county taxes, revenues and permits, the incidence of dates is more pervasive than in many types of private industry programs.

Another factor that makes municipal governments more vulnerable is that most mainframe systems are purchased from third-party suppliers.

Consequently, the owner must often rely heavily on the various vendors for any changes to the system, a reliance that could prove costly for city and county agencies, especially those that procrastinate in addressing the millenium bug issue.

And many vendors are going to the private corporations and ignoring city and county governments; money is better with private corporations and cleaning beauracratic red-tape is not necessary.

To prepare, municipalities must (1) be aware of the potential problem, (2) get the information to senior managers who understand the significance of the problem and (3) get the programmers involved in de-bugging affected systems by checking, mainframes, PCs and software.

By examining systems early, municipalities can ensure that they are not caught unprepared on Jan. 1, 2000.