************************************* * * * DB/C Newsletter * * March 1997 * * * ************************************* Editor's Notes DB/C 9.1 beta testing continues. You can get a copy of the latest beta test version of DB/C 9.1 at ftp.swc.com in directory /pub/misc/dbc91tst. This month's topic is the year 2000 problem. As you probably know, much of the data stored in the computer databases around the world uses a two digit field to store the year part of a date. This is going to cause a variety of problems in the near future. The problem is so large that the mainstream press has now started reporting about it. In this month's article we discuss some options and possible solutions. don.wills@swc.com ******************************************************************************* The Millennium Bug Computer systems are already starting to fail because of the largest computer program maintenance nightmare ever to hit the computer industry. The nightmare is the year 2000 problem, sometimes referred to as the Y2K problem. Contrary to what some think, this problem isn't going to be a bombshell that happens on January 1, 2000. It is actually a growing problem that is affecting systems right now. It will peak sometime early in 2000 and will continue to plague users of computer systems for many years. The many different types of databases store date information in a variety of formats: binary, binary coded decimal, EBCDIC, ASCII, etc. There are many different approaches to dealing with the Y2K problem. Some of the approaches are universal. Others are specialized for the encoding mechanism of the database. This article will focus on the way year information is stored in the DB/C filesystem. There are several approaches to dealing with the Y2K problem. Here are four typical approaches: 1. Convert the year fields in all data files, screen layouts, and report layouts to four digits. Change the related variable definitions and code in all of the programs. 2. Don't convert any data fields, but define a new coding mechanism that uses something different than a digit in the high order digit position of the year field. Change the screen layouts, report layouts, and program code to support the new coding mechanism. 3. Don't convert any files, just assume 00 is 2000, 01 is 2001, etc. Change the programs to fix date range calculations and to fix screen and report layouts to output "19" or "20" based on a 100 year time window. 4. Do nothing (or almost nothing). For whatever reason, many companies will use option 4. Because of the design of PL/B and of the DB/C filesystem, this approach has a moderate chance of not causing major business problems. Examples of minor problems that may occur are: Reports that don't sort correctly for a few months Reports and screen displays that show 19yy instead of 20yy Inability to do range selection across the 1999/2000 year boundary Companies that choose to do almost nothing will still need to make minor changes such as to check printing programs (banks might not honor checks that were written in 1900). If a business can live with the other minor problems that will occur, then the do-nothing option is probably the best course of action. It is definitely the least expensive. Most businesses will have to use one of the other options. There are many unknowns associated with these options. The primary unknown is cost. At first look, option 2 would seem to be attractive for DB/C users. It doesn't entail file layout changes, so many systems won't be affected in a major way. An example of this approach is to define the year 2000 as "A0", 2001 as "A1", etc. In DB/C this approach will work well if the programs are written using DIM 2 variables for the year fields. But if the programs are written using FORM 2 variables, this approach will fail. Another problem with option 2 is that the conversion should be done and in production before any date after 1999 is entered into the system. It may already be too late for this. You could still use option 2, but you will need to do a file conversion after all program changes have been made. At Subject, Wills & Company, we have chosen option 1 for all of our application systems that we sell to end users. This is the most expensive option, but it offers the best solution for everyone. Conversion of existing files is a time-critical part of the overall conversion. We built a special version of the REFORMAT command to help with the file conversions of the SWC applications. We have decided to put the features of this special version into the DB/C 9.1 REFORMAT command. The following paragraphs describe these new REFORMAT options. -Z=nnn is the insert century and fix date option. This option may be specified one or more times. Two characters are inserted at the position nnn in each record in the output file. The value of the characters inserted is as follows: If the two characters at position nnn in the input are digits with values "21" through "99", the inserted characters are "19". If the two characters at position nnn in the input are digits with values " 0" or "00" through "19", the inserted characters are "20". If the values are " 0" through " 9", then the blank is replaced with a zero. If the two characters at position nnn in the input record are any other values, then two blank characters are inserted in the output record. -ZZ is the alternate zero handling option. It may only be specified once and it applies to all -Z options. (It does not apply to the -ZR options). If the input characters are "00", then the inserted characters are "00". If the input characters are " 0", then two blank characters are inserted in the output record. -ZC=nn is the cutoff year option. nn is a two digit year specification. This option changes the cutoff year used in the -Z and -ZR options. If this option is not specified, the default cutoff year is 20. -ZR=nnn is the insert century and fix date for reversed year fields. This option may be specified one or more times. It is similar to the -Z option, except that it handles reversed years. A reversed year field is one that is reversed for sorting purposes. In the input record, the value is (99 - year). For example the year corresponding with 1997 is stored as " 2", 1996 as " 3", etc. The two digit year in the input record is first converted to its normal two digit representation. The "19" or "20" is then appended to the year based on the cutoff date. The resulting value is subtracted from 9999 and the four characters are inserted into the file, replacing the two characters previously at that location. For example " 3" is replaced by "8003". We plan to include these new REFORMAT options in the next beta release of DB/C 9.1. If you have any suggestions concerning these options, please send them to don.wills@swc.com as soon as possible. And good luck in your Y2K conversion! ******************************************************************************* DB/C Class Schedule Class Date Location DB/C 9 Fundamentals June 1997 Oak Brook, IL DB/C 9 Advanced Features June 1997 Oak Brook, IL For information, contact Judi Tamkevic at: voice 630.572.0240 fax 630.572.0390 email dbc@swc.com ******************************************************************************* Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you once a month, just send an email message to 'majordomo@swc.com' and put the line 'subscribe dbcnews' in the body of the email message (omit the ' characters). The newsletter will be delivered to the email address from which the message was sent. *******************************************************************************