Please feel free to forward this newsletter to as many friends as possible. I have a personal goal of reaching one million readers. I can achieve it with your help.

  the Software View: What, me worrY2K? or How I stopped worrying and learned to love the Year-2000 problem. (Part V)

Welcome back, gentle readers. For those of you with Web access and a Netscape Navigator browser, please click here:
http://www.softwareview.com/
Scroll down the page and you will notice a link entitled, "Daily view weblog". The daily news page is also known as a "web log". It is en vogue and the fashion of these days to call it that. Click on the link, click "reload" on your browser or clear your browser cache to ensure that you always receive the freshest, hottest daily news concerning JavaTM, Linux, XML, and the software industry! The link never changes, but I will be updating the HTML file page behind it every day. Please, do take a gander at it every day.

Also, gentle readers, the Software View is an Associate Internet World Wide Web site of Amazon.com. I'd like to extend my sincere, heartfelt gratitude and thanks for your patronage. I'm offering links to books, et cetera that you can purchase from my web site. I'd greatly appreciate it if you would purchase software industry books from my web site. Help support my newsletter and web site by purchasing items from Amazon.com from my web site. Here is the URL (Uniform Resource Locator):
Click here

Now, dear readers, on with this week's episode of the Software View!

As you probably deduced, the real world just does not allow for simple, one-size-fits-all solutions. There are some excellent arguments for using the date-field expansion approach:

  1. There's usually more programming associated with the two-digits approach than with the four-digits year. You'll have to convert formats before doing simple comparisons or calculations.
  2. When storage is expanded, code should still be checked to ensure that the whole four-digits year is being processed, not just the YY part. Data structures and definitions must also be scanned, and sometimes modified, to store the extra two bytes within the code.
  3. Windowing processes continue to work even when deriving realistically incorrect output. With a four-digits system, invalid input data will trigger instantaneous notification.
  4. Routines for sorting and validating two-digits years will require additional modification to handle "windowed" derivations. Since extra code must be added to nearly every program to handle dates, the project size does not diminish - it may even increase.
  5. Data input and output to third parties may not match their data definitions, standards, formats, or conversion timing when two-digits dates and windowing are used.
  6. Some date ranges, such as those found in scientific data, span more than one hundred years. A windowing approach would be impractical in these cases.
  7. The logic approach usually adds processing cycles, millions of instructions per second (MIPS) and reduces throughput. Sometimes windowing-driven performance requirements minimize the resources saved by avoiding bridges and conversion.
  8. A logical date-derivation operation (window) developed for one date may not fit each type of date that the program handles, resulting in poor maintainability and proliferation of "base" dates.
  9. Fixed windows can leave logical time bombs in programs that are used beyond their life expectancy (a common scenario).
  10. Expanding all stored dates to four-digits years and correcting the code to match is certainly the cleanest solution, and it's the easiest to understand and manage.
  11. Zoned or packed-decimal dates in the YYYYDDD format take up the same amount of physical space as the YYMMDD format stored as numeric data.
  12. Four-digits dates must still be carefully reviewed to ensure data integrity. Sometimes the century digits aren't initialized; they could contain anything.
  13. For seldom-used archived data containing two-digits years, conversion programs will need to be written to ensure compliance with new programs.
  14. Expanding the date fields uses more storage, and some database designs aren't conducive to expansion. For example, you'll have problems if the date is also an index or key, or if expansion would overwrite adjacent data.
  15. When expanding files and databases, automatic population routines based upon windowing have to be written and run to fill the additional two bytes with valid data.

The range and repercussions of date-related problems make preparing for Year-2000 compliance a unique exercise, so there are no previous examples or case studies to emulate. The Year-2000 project forces an exploration of unfamiliar methods in all of the following areas:

  1. Cataloguing programs and identifying redundant or obsolete files and data.
  2. Scanning code and hardware to determine the scope of the problem.
  3. Converting programs to different languages, platforms, and versions.
  4. Changing systems-management programs, file resource management, performance monitoring, archiving, service subroutines, and communication utilities.
  5. Coordinating vendor compliance, upgrade and performance undertakings, and obligations.
  6. Revising and redesigning data formats and storage techniques.
  7. Redesigning or replacing hard-coded processes in equipment and devices (for example, point-of-sale equipment, automated teller machines, private branch exchanges, hand-held scanners, access-control terminals, remote-monitoring devices, etc.).
  8. Accommodating data import and export requirements outside the control of the enterprise.
  9. Revising user interfaces for both data-capturing and reporting processes (forms, reports, screens, etc.).
  10. Changing hardware, such as BIOS and CMOS, that can't store dates correctly.
  11. Purchasing and implementing new tools, methods, and systems.

INPUT AND DISPLAY ISSUES

Before getting down to the nuts and bolts of devising a Year-2000 solution, there are a few basic issues that must be taken into account. One of the most important of these, especially for organizations with an international presence, is the fact that dates are displayed differently across the globe. Some are in the format MMDDYY, while others are displayed as YYMMDD. In some European countries, they appear as DDMMYY. Within the same country, the format sometimes varies between corporations and government departments. Mixing formats already causes confusion, and the year of "00" will make it worse. Add to this the completely different dating systems sometimes used in Asia and the Near East, which must be adjusted for if they appear in some of an organization's records.

In other words, when designing a Year-2000 solution, it's not enough to ask only if the year should be preceded by "19" or "20". Programs and computers will also have to be smart enough to answer questions like "What is the correct interpretation of 020304?" It could be any of these:

During the years "01" through "12", there will be additional confusion - does 011201 denote the date of January 12, 2001 or December 1, 2001?

EMBEDDED DATES

One of the more ubiquitous contributors to the Year-2000 problem is embedded dates. These are hard-wired or constant identification data, field-layout masks, or components of larger alphanumeric fields. Embedded dates are difficult to detect, analyze, and convert: first, it may not be immediately obvious that these numbers contain dates; second, the dates within these numbers are probably essential to program functions.

DATE-STAMPING

Sometimes an embedded date (often with a time stamp, as well) is employed to uniquely identify a particular item or event, such as a telephone call logged to a digital list. This convention is commonly used in serial-number algorithms, such as account numbers, license numbers, and invoice numbers. Date-stamps are also attached to records of communications and transactions, as well as to records kept by backup and recovery programs. Errors in the format and processing of these date-stamps due to Year-2000 roll-over could have widespread implications.

Date-stamps often create problems when their formats change, such as when old dates aren't recognized by new recovery routines. If changes aren't made, the transactions or records could be processed out of sequence.

EVENT HORIZONS

The Year-2000 problem won't suddenly catch up with the world at midnight on December 31, 1999. Many business applications look ahead months or years to create expiration dates, due dates, and other future dates.

A Year-2000 event horizon is the date when a system could, or will, fail due to an inadequate or invalid date. Here are a few examples of how far ahead you can expect systems to fail, and when they should be converted. The following time line is a future chronicle of the slow collision ahead.

EMBEDDED SYSTEMS

Embedded systems show up for monitoring and controlling in places as diverse as power stations, water plants, phone switches, and burglar alarms. One commonly cited problem is associated with gadgets that monitor periodic maintenance. When the clock strikes twelve on New Year's Eve, in the Year-2000, these devices might think it has been ninety-nine years since their last maintenance, realize that it's too long a period for safe operation, and shut down. That wouldn't be good, especially if it's the device that monitors your intravenous fluids.

Embedded systems differ from embedded dates. They often appear as firmware on read-only memory (ROM) and EPROM, which hold the programs for starting or running greater systems. They may also be present within compiled Dynamic Link Libraries (DLL's), where date handling is abstracted from the internal workings and hidden from the programmer. It's difficult to locate the source code or original programmer, so problems with embedded systems can be especially serious.

ARCHIVING SYSTEMS

Most organizations store data for a minimum of seven years, as dictated by the Internal Revenue Service (IRS) rules and other statutory reasons. Existing archives must be recoverable after a Year-2000 update.

Stored data must be available for auditing and historical inquiry purposes, as well as for emergency backups. It's vital that archiving systems be inspected early in the project, since existing material may need reformatting. If a system writes an expiration date of 12/12/00 on a tape, it's possible that this tape will be recycled (and reformatted) when the system deduces that the data has expired, or that the tape has never been used at all!

This problem will be compounded by each new archival cycle, so Year-2000 strategists must ensure the synchronized conversion of both systems and archived data.

To be continued ...

Sincerely,
Mark Kuharich

Join my free e-mail newsletter called the Software View by clicking here or by sending an e-mail to thesoftwareview-owner@west-point.org