Peeking at Y2K projects' activities as the year 2000 nears

By Sudama

JAKARTA (JP): A few weeks ago I received a note from a company which stated that I had not paid my monthly bill.

It was a bit of a surprise to me. So, I phoned the company, saying that I had already paid the bill through a bank. The person in charge asked me to wait for a moment. After a while, he profusely apologized to me and informed me that I had already settled the bill.

The company upgraded its computer system to make it year 2000 compliant a few days before the bill's due date and some errors may have occurred during the process.

Anyone could have such an experience before 2000. Speaking of the year 2000 problem or the Y2K bug, I myself once felt professional guilt on the matter because long ago I created a millennium bug.

In 1970 I worked as a systems programmer in a bank and I was assigned to write a routine program which could manipulate dates. It would be used by all the bank's application programs which would pass Julian dates with the YYDDD format to the program in order to be increased or decreased by a number of days or month, usually for due date calculations. For example, the date Jan. 10, 1969 would be presented in Julian date format as 69010.

So, I simply defined the year in a two digit or YY format. The problem was that if by making additions to a given date, the resultant year became 00, 01 or more, 00 could be interpreted as 1900.

At this point I reported the matter to the bank's computer consultant who shrugged and commented that 2000 was still far away. He suggested I included a "bad date" status code to the application program should such a situation occur.

Usually, if an application program receives a "bad date" it just stops processing the transaction related to the input date and continues to process the next transaction.

Years later in 1988, I was working as an information systems auditor. Not until 1995 did I hear about the Y2K bug. I phoned the information systems department to inquire about my date manipulation program and to my relief I was informed that the program had not been used since 1990, when a new system was installed.

Since that moment I have heard more about the Y2K bug in meeting rooms, at seminars and in the press. It seems to be just a technical problem, but in fact it is a business issue.

There was a report which related how a company sold one of its divisions to another company due to the fact that it could not justify the costs of making the division Y2K compliant.

Then there were companies which were not aware of the problem, even though it was already the beginning of 1999, until their business customers inquired about their Y2K readiness.

These companies would scurry to set up Y2K project teams to look into their computer inventories and prepare schedules. In turn, they would also ask their suppliers about their readiness.

Just imagine a big manufacturing company; it could have more than 100 suppliers, both local and overseas. It could not risk having low-quality raw materials for production or defective OEM products for assembly due to their suppliers' Y2K problems.

The Y2K problem also relates to hardware. There is a lot of computer hardware, mainly mainframes and minicomputers, that are not Y2K compliant and have to be withdrawn and replaced.

Companies that use PCs or microcomputers would consider upgrades or replacements for Y2K readiness. There also might be problems with equipment like PABX, elevators and access/security systems that have computer chips in them.

People unfamiliar with computers, like a company's senior management, seemed to think the problem only involved hardware.

Afterward, they were aghast to hear that it also included software like application programs and operating systems. The most difficult part would be evaluating in-house produced application programs and making them Y2K compliant. It could take much labor and time.

Ideally, computer systems should be Y2K compliant at the beginning of this year, but for companies or organizations who are not yet "ready", there might or might not be ample time to finalize Y2K projects before 2000, depending on the magnitude of the projects.

For this reason, these entities, particularly those which depend heavily on information technology, are taking pains to construct contingency plans. Manual or semimanual systems are accordingly devised to anticipate computer operations failures.

Companies which need raw materials usually have some doubts about their suppliers' Y2K readiness. For example, in December 1999 tire manufacturing companies may plan to buy and hoard materials like sulfur and synthetic rubber produced by their suppliers, to be held in reserve for three months worth of production in the first quarter of the new millennium.

Ordinary people who are not knowledgeable about the Y2K bug, but who are somewhat aware of the problem, have only some vague imaginings of what might happen in the beginning of next year.

My friend planned to spend New Year's Eve in Hong Kong, but now he is having some misgivings. How about the elevators in the hotels, will they function normally on New Year's Day? The thought that he and his family might get stuck in a hotel elevator on the 15th floor scared him. And how about aircraft navigation and air traffic control systems? If credit card readers failed, how could he make payments?

Looking at the global awareness of the Y2K problem and at the serious worldwide efforts to beat the millennium bug, it may be reasonable to expect that most of what my friend and some other people are worrying about will possibly not occur.

The writer is a certified information systems auditor and a computer consultant.