Much has been written on the subject of Year 2000 related to legacy applications. HP users have an especially daunting task when it comes to using IMAGE databases, because there is no datatype for DATE and TIME as there is in Allbase and other databases. In most HP 3000 cases, dates are represented as a six-character string in the format YYMMDD.
Adager has developed tools for data item migration, and Diamond Optimum Systems has an add-on for their Documentation/3000 product to identify "date" variables. These tools can help in converting the data and the programs, but in the end it will still be rote, grunt-work to get programs operating past 1999.
Client-server applications have two areas that need examination. First and foremost is the database. If a TurboIMAGE database (employing IMAGE/SQL or not) is being used, then these programs will need work -- again, there is no DATE or DATETIME data type. If a relational database is being used in conjunction with Windows 3.11 or Windows 95/NT, these applications should be just fine for the most part. Over 95 percent of all relational databases have a datatype of DATE and over 90 percent support DATETIME.
Windows-based development tools and the resulting programs use the Windows Control Panel format for date and use the Windows API for handling dates. Since Windows can handle the year 2000 in and of itself, then barring code which inhibits this, applications written with these tools will handle the year 2000 if the DATE datatype is used. These tools are Visual Basic, Visual C++, Visual FoxPro, Access and Excel.
An example in Visual Basic 4.0 -- dates should be stored in variables of the datatype VARIANT. This datatype has subtypes that are enumerated. A "type 7" variant is represented as a date. Arithmetic operations on these datatypes on January 1, 2000 against dates in 1999 or earlier will result in correct results.
For your HP 3000 applications and data, if you're using TurboIMAGE databases, I recommend you get Adager Model II immediately. Adager can report on and make the conversions in your data so you don't have to write conversion programs This is a real time saver.
If you haven't started with all the press given to this topic, all I can say is what the hell are you waiting for? Oh, and is your resume updated? This problem, no matter what your business, is right around the corner. We have already found that all it takes for the program to fail is for a user to hit the zero instead of a nine accidentally in a date field such as 06/23/06 instead of 06/23/96. It's more common than people think (just look at your keyboard).
As for algorithms, which are being discussed at length right now, the popular one is the the "0-49/50-99" algorithm. A subroutine is written which takes a six-digit date as input and compares the year. If the year isetween "00" and "49" inclusive, then the century is "20" and the date will be passed back as "20xx". Likewise, the century "19" is used if the year is between "50" and "99" inclusive. Microsoft is using this algorithm in their applications. Whenever arithmetic operations are performed, the dates are passed through this subroutine, then the arithmetic operation is performed.
Also, look at your "window of need". Depending on your archiving policies, the window is no more than five to ten years and in many cases, no more than three years. Why is this important to note? Because people are spending so much time worrying about getting this job done, and in many cases, each and every date field will be examined and converted, and code will be updated. Only convert dates and implement subroutines and code changes to those dates which need it. Informational date fields and others which do not have arithmetic operations performed on them do not need conversion and code does not need changing. Don't waste time addressing these fields as doing so detracts from those which do need the attention.
Summary: While it's true that come January 1, 2000, 12:00 AM, many applications will fail, yours should not, if you:
1. Start now, if you haven't already...
2. Get the tools to expedite the process such as Adager,
Documentation/3000 and others...
3. Address only those fields where arithmetic operations are being
performed and leave others alone!
4. Use subroutines called from all programs to return the century in a date, if you can't expand the field.
Also,
1. Client-Server applications using relational databases, with dates using a datatype of DATE or DATETIME should not need migration.
2. In Windows-based applications, use the VARIANT (or equivilent) datatype to ensure that proper date formatting and calculations are performed.
Joe Geiser is a principal at CSI Business Solutions, and can be reached at jgeiser@csillc.com.