by March 31, 1999 0 comments

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

  • 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

The bottom line: The Y2k problem
begins on 01/04/1999. However, hope is not completely lost, especially for xBase-based
The Y2k problem
begins on 01/04/1999. However, hope is not completely lost, especially for

Related Tech Articles

Similar Posts From Tech Category

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.