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: