With year 2000 less than 355 days away, your facility and business should be well underway with software accessment and remediation efforts.

Major manufacturers have to communicate the Y2K message to a number of audiences: employees, shareholders, and customers. While messages may differ, internally and externally, if adequate plans aren't in place, the majority of post-2000 communications may be with attorneys.

There's certainly no lack of information or advice; it seems the more you look the more you find (try the Y2K Solution Sampler).

Even U.S. law exists on the topic as of Oct. 19, 1998—the Year 2000 Information and Readiness Disclosure Act. Despite (or perhaps because of) revelations of sectors of U.S. government being woefully behind in remediation assessment, lawmakers use the act to encourage business-to-business communication on readiness, strategies, and tools related to Y2K. The law promotes "good samaritan" behavior among businesses, but doesn't cover business-customer relations.

While there's a sense of urgency involved, remediation experts say there's no need to panic, as long as the process is underway and on schedule. (If not, prioritization is necessary to determine what gets the resources.) Those who haven't gotten around to getting started may benefit by heeding some of the warnings:

• "Countdown to chaos"—with the ticking digital clock (www.y2knet.com);
• "Got your financial systems year 2000 ready? DANGER They may be counting zeros from a cold, dark factory" (www.tavatech.com);
• "It could take weeks to restore services" ("Surviving the Year 2000 Computer Crash," David William Brown, Flying Kiwi Press/Trafford Publishing,www.trafford.com); and
• Year 2000 typical disclaimer: Information herein is not intended as legal advice or a substitute for legal counsel (on almost everything).

Perhaps the economic stimulus related to forced upgrades to more productive tools (and propagation of lawsuits for noncompliance) will offset cessation of Y2K advise-giving activities.

The time bomb is the year 2000—a year that threatens to affect computer systems around the globe, transcending national boundaries and organizations.

Those charged with managing computer systems are aware of the date-change problems and related impacts, however the urgency is either not understood or not well communicated to senior management and shareholders. Part of the problem lies in the wide range of interpretations put upon the date issue. It varies from being treated as an amusing article, to the "we're all going to die" scenario. Surrealism sells copy, while pragmatism is what is required to address this issue.

This Year 2000 compliance (Y2K) problem was first documented in 1993 by a Canadian consultant, Peter de Jager, but the origins go back to the eighties, seventies, and in a few cases the sixties, when much of today's software was created.

Care should be exercised when reviewing the Y2K problem. It's not the hardware that is the problem; systems will power up and disk drives will still work. It will be the software, the rules which run businesses, that will stop working. All of us are affected by this problem. The chief issue is whether Y2K is viewed as a one-time expense, or an opportunity to improve the operation.

We have become accustomed to seeing dates abbreviated as 2-digit numbers such as "Decision '98''…that is exactly the same way some older software store and use dates. Many programmers, thinking the software would be replaced before year 2000, dropped the first two digits in dates to conserve what was, in the sixties, seventies and eighties, precious computer memory space. Ironically, a very similar problem arose in the early sixties when some database programmers used single-digit dates for the year.

Today, date dependent software resides in three possible locations in most computer systems. First is the ROM BIOS, a small computer chip that contains enough program logic to get the computer started when power is first applied. Second is the operating system software (such as MS-DOS, Unix, or VMS) that provides instructions needed to manipulate, display, store, retrieve, and print information. Lastly is the application software, much of which is custom written in software languages such as Basic, Fortran, or Cobol.

To counter effects of date-change errors, businesses have four main options:

• Repair the program logic;
• Repair the data-dependent database and program logic;
• Rewrite existing applications; and
• Replace existing applications.

Of these solutions, the first two are fixes that add no value to the enterprise and can cost a lot of money. The last two will cost money, but the long-term benefits outweigh the expense.

Assuming access to all the software, repairing the program logic is a medium-risk, quick-and-dirty solution that develops an interpreter program to read 2-digit dates and convert them to 4-digit dates. It's a medium risk because the original source code may be missing or poorly commented; it's quick because it touches a minimum amount of software; and it's dirty because there is no guarantee every possible combination of date dependent software gets found and tested.

Repairing the data entails rebuilding software to reflect 4-digit dates and repairing program logic to use 4-digit format from this point forward. This is a medium- to high-risk option that may take a long time to complete and verify.

Fixes were the solution in the first two options. Rewriting the application provides an opportunity for a tactical business benefit to implement changes and restructure systems for productivity and more effective support. As most experienced business leaders know, development includes delays, missed delivery dates, and bugs. Given the impending nature of the date change, would you bet the farm on a redevelopment of your system software? Remember it is not just the year 2000 that presents the problem, it can begin this year. If your system uses projections or forecasts, 1999 is when your system needs to handle year 2000.

The fourth option is to replace custom written applications with new packages. This provides the same value as rewriting the applications and can be completed in less time. Also, new packages minimize cost and risk because only business information needs to be implemented and tested, not the entire application.

The millennium could represent an opportunity to move ahead. Our markets have changed, become global in structure and approach, and new technologies affording opportunity to gain competitive advantages.

For more information from JBA, visit www.controleng.com/info