Red Alert!

width="176" height="300" alt="bl.jpg (16999 bytes)" align="right">

Millions of Indian users will have begun to
feel the impact of the Y2k problem by the time this column goes to print. For the real
start date for the Y2k problem was 01/04/1999 and not 01/01/2000. Most users tend to treat
the millennium bug as the Calendar Year 2000 problem. It is not. The millennium bug is
actually the Financial Year 2000 problem. Millions of users will understand this subtle
distinction when they create the next financial year with start date as 01/04/99 and end
date as 31/03/00, only to be shown an error message like "End date must be greater
than start date".

Time has run out for most users who have
not finished their Y2k-compliance exercise by now. And it’s precisely to people like
this that this column is addressed. The first suggestion for such users is to create a
six-month financial year (software permitting) to gain some breathing space. Such an
expedient will give you at least six months to put your Y2k plan into place.

The next step depends on the kind of
software you have. Owners of packaged applications can contact vendors for a fix. Large
corporates with RDBMS-based systems can pressurize their IT departments to move faster.
The people who will be hardest hit are SMEs with custom-designed xBase applications. Such
organizations have neither large IT departments nor the resources required to handle
expensive consultants. Fortunately for these people, fixing an xBase application is not a
very tough affair.

The key to Y2k compliance in xBase is the
"set century on/off" command. When century is on, xBase automatically uses four
digits for the year component of a date, while two digits are used if century is off. You
can use the following steps to fix more than 90 percent of the code in a typical xBase
application:

• Set century on in the top-level program
  of the system.

• Compile a list of programs that input
  dates. Modify the screen formats of these programs to accept a ten-digit date. If the
  format is too cluttered to allow such redesign, then place a filter after every get
  operation to change the year component of the date to a correct value.

• Write a small function that accepts a
  ten-digit date of the form dd/mm/yyyy as a parameter and returns a string of the format
  dd/mm/yy, that is, with the epoch removed. Now compile a list of all programs that output
  dates to screen, disk, or print. Call the above function instead of writing the date
  directly or using a dtoc() function call. You will find that you get the correct output
  without having to alter a single format.

• Now compile a list of all programs that
  make sophisticated use of date information. Typical examples are financial year change or
  modules to update monthly stock balances and the like. You will have to study these
  programs individually and fix them, redesigning algorithms if required.

As mentioned earlier, these four steps can
take care of more than 90 percent of the code in a typical xBase application. They cannot,
however, guarantee that they will remove all the Y2k-related problems. Surprisingly, the
problems that remain might have nothing to do with dates at all, as the next example
illustrates.This example is based on a series of
formatting routines for dialog boxes. Several years ago I wrote a series of routines that
accepted as parameters the contents of a dialog box, and produced a series of arrays
containing placement coordinates of the components of the dialog boxes. It seemed a good
idea at that time, but the Y2k problem has added a new dimension to it. Since these
routines are called to format dialog boxes—both date and non-date containing—it
has become complex to fix screen formatting. The solution, as you might have guessed, is
not very complicated—write another set of routines for dealing with date-oriented
dialog boxes and call the new routines. The point is that generic utility routines can
have an impact on the Y2k effort.

One final point. If your application is
running on a variety of sites, be sure to factor in the lead time for distributing the
application.

The bottom line: