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 VI)

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 Java^TM, 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!

TESTING

For Year-2000 conversion, testing will be doubly challenging. Existing systems must be proven compliant, after which, all converted systems must be tested again, in all stages of integration - unit, integration, and user. If the first tests are methodical and well-documented, the second test sessions should run more smoothly.

Often a unit of software works when tested in isolation, yet fails when connected to external systems. Bridge testing (both bidirectional and unidirectional - see the following section for a full explanation of bridging) is incomplete until all systems have been integrated and tested as a whole system.

Where dating files are used instead of direct queries to hardware or operating systems, additional configuration and testing will be required for the dating file and supporting code.

If a large section of the non-compliant inventory is hardware, previously compliant applications and operating system configurations will have to be tested again on new platforms.

BRIDGING

When systems or programs are in the process of conversion, the unconverted programs must still interface with the converted ones. Temporary programs called "bridges" can be written to accommodate the difference in data format between programs. For example, a bridge program could correlate between six-digits and eight-digits date fields until the system is fully converted. When conversion is complete, the bridge is decommissioned.

Bridges will be particularly essential in organizations where tape-based and electronic data interchange transfer takes place continuously, such as banks. It's almost impossible to convert and migrate all interfacing programs simultaneously, so version-activated interface definition switches can be built into bridge programs to ensure smooth operation during the Year-2000 transition.

Programmers can build a whole set of bridges to patch together converted and unconverted systems, then dismantle them as soon as both sides of the bridge are converted. As the clock ticks and pressure grows, there's a tendency to leave some bridges in place, treating them as an ad-hoc windowing solution. However, if the windowing is hard-wired, this approach can leave time bombs in the system. If data and structures are redefined in the bridge, it also confuses the DDL- and copybook-maintenance process.

One bridging technique that's gaining popularity is the temporary use of additional fields in tables: one for the original date, and one for the converted (expanded) one. This involves expanding the database and changing copybooks, but it significantly reduces bridging requirements. The old code continues to run without bridging until the conversion is complete, including batch data updates. At that time, both extra storage and redundant programs can be unplugged.

Before this method can be used, storage-requirement analysis must show sufficient space and sequencing of both development and testing storage. Since most systems have up to ten percent date content, an additional five to ten percent storage capacity is required to use this type of bridge. A more accurate assessment can be obtained from the detailed inventory.

DESKTOP PERSONAL COMPUTERS

They will be more difficult to deal with because of the distributed nature of desktop personal computer installations. Within a single organization, the variety of operating systems, packages, versions, and makes and models of hardware is alarming. That makes assessing potential problems very difficult.

In the Year-2000, there will still be literally millions of noncompliant PC-XT's, PC-AT's, 386's, 486's, and Pentiums in operation. File and directory listings on desktop personal computers can display all sorts of strange date derivations, depending upon the BIOS date, display-options, and operating system version. Some display YY without a century date, while others show the full date as ":0" or "19:0" depending upon the view option selected. Some files may be properly sorted, while others aren't.

Applications that use the system date, such as scheduling, version-control, delete-protection, and file-management programs, may have a variety of reactions to Year-2000 events. Some will hang, others will exit without saving, and many will just treat "00" as 1900.

Millions of small but vital spreadsheets, accounting programs, source code, and desktop personal computer databases are essential parts of day-to-day activities such as payrolls, production, distribution, leave, and cash-flow. Most of the original authors have disappeared and won't be available to assist with the conversion. These utilities must be evaluated and detailed fully in the inventory phase.

TECHNICAL CONSIDERATIONS
HISTORICAL DATES AND LEAP-YEAR THEORY

Early date systems worked on the assumption that the Earth took a whole number of days to rotate around the Sun (365 days, to be exact). This resulted in a shortfall of approximately one day every four years, which Julius Caesar decided to remedy by creating a new calendar. His Julian calendar added a day every four years, creating what we now call leap years. Unfortunately, he over-corrected slightly, and every 128 years his calendar was one day ahead of reality.

By the thirteenth century, this problem was apparent to astronomers, who recommended a variety of solutions. Finally, almost two hundred years later, Pope Gregory XIII decided to remedy the situation once and for all. He used the Lilian solution, which was provided by the physician Aloysius Lilius. In the year of 1582, a Papal decree was issued stating that the ten days that had accumulated since the time of Julius Caesar be dropped immediately. According to this decree, the day after October 5, 1582 would be October 15, 1582, not the sixth.

An adjustment was also made to the method of calculating leap years. Every fourth year would still be a leap year - except for any century-ending year (a year ending with two zeroes) that was not divisible by 400.

If you do the math, you'll discover that while the Year-2000 is a century-ending year, it's also divisible by 400. As a result, it'll be a leap year. This observation is important because some programmers accommodated only the century condition (and not the 400-years one), which would make the Year-2000 "not" a leap year.

The terms Julian Date and Ordinal Date are often used to represent a date format, such as YYDDD or CCYYDDD, where YY or CCYY could be any year or century and DDD is the day offset from that year.

DATE STORAGE AND PACKING OPTIONS

Desktop personal computer applications tend to use (and store) dates as displayed and formatted by the operating system, unless told to do otherwise. All tables, spreadsheets, and other documents created with these applications must be checked for manual and automatic input. In addition, all files in storage should be reviewed, especially if date-storage types are not of the type DATE.

DEALING WITH SINGLE-DIGIT CENTURY DATES

The use of the single-digit century dates doesn't often reduce update work, since logic windows must be added to interpret the data and then pour the full century information into output and display fields.

FILE AND DATABASE DATE CONVERSION

Changing dates in files and databases is usually a straight-forward process, once the decision to use the data approach as been made. Programmers can often rely on products that automatically expand files and databases. This activity usually requires an online data dictionary and repository. If dates are keys (indexes) or system-assigned, some systems will disallow attempts at field conversion. In these cases, the database itself will have to be redesigned.

Date expansion in files and databases involves the same approach as expansion of other fields, such as fields for Branch Number, Account Number, or Address. However, expanding fields via program logic is obviously more difficult, since substrings of dates are commonly used, and dates may be embedded in compound fields. Both code and data will need thorough testing to ensure that all dates have been properly converted without reducing functionality.

Storage limitations are a major concern when using the data-expansion method. Changing code itself adds minimal storage demands. However, databases may have to be duplicated, at least temporarily, to facilitate access by both converted and unconverted programs. Duplication may also be required when testing auto-population algorithms and bridging modules. Duplicated files could easily fill available storage and force a change in conversion plans. If you need space for only a short while, temporary storage can be obtained from service bureaus or Internet Service Providers (ISP's).

Y2K AND YOU. LAST DANCE?

Besides keeping your enterprise going, you need to pay attention to your own personal survival through the Year-2000. Here are some tips:

• Paper trail: keep bills, receipts, and balance reports for several months before the Year-2000. Keep paper print-outs of computer-based financial information.
• "00" shotgun: realize that any weird bill or notice involving the year "00" or anything ninety-nine years over-due is a Year-2000 glitch. Start dialing and calling. After the Year-2000, check your credit report to ensure there are no ninety-nine year-old debts listed.
• Bank check: toward the end of the year 1999, query your banks, brokers, and other financial institutions about their Year-2000 compliance status. Be especially clear about what accounts are - and are not - insured by the Federal Deposit Insurance Corporation, and for up to what amount they're covered.
• Stock clicker: think about which investments the Year-2000 problem might impact, for better or for worse. Remember that the month of December in the year of 1999 will see record trading volumes in the stock-markets, and probably panic-driven selling.
• Utility hook-up: find out about compliance by your local telephone, water, gas, and electric companies. Get a heating-oil delivery in the month of December in the year of 1999. Plan upon the possibility of losing electrical power altogether, or experiencing lower voltages or frequencies. Either have uninterruptible power supply sources for computer equipment or turn the equipment off.
• Drug run: refill your prescription medications before the Year-2000, and forgo pharmacy-compliance issues.
• Check stubs: examine paychecks carefully during the years of 1999 and 2000 for correct tax and social-security withholding amounts and time-based raises.
• Hardly working: make sure automated security systems at work won't lock you out and elevators won't keep you grounded. Find out if computer and network security passwords will time out in the Year-2000.
• Automated teller machine attack: keep some money available in the form of cash or travelers' checks.
• Get involved: raise the question of Year-2000 compliance with local governments and school systems. Inquire about plans, costs, and sources for funds.
• The business of government: renew your driver's license and automobile registration and transact any other government-related business before the Year-2000.
• Take off: check for Federal Aviation Administration, airline, and rail-travel announcements about Year-2000 compliance during the last few months of the year of 1999. Check with travel agents and airlines for correct arrival and departure times, especially if traveling overseas.
• Tank up: fill up your gas tank before December 31, 1999, in case electrical power and credit-card processing shut down.
• Home computing: check out the status of your own computing system with the many free utilities that are available. Find out about the compliance of your software. Back up your system before the Year-2000. Keep a paper print-out of any contacts and schedules that you may keep on your computer.

SAILING INTO THE SUNSET

So, it's all grim, right? Yes, mostly, but not entirely. Many enterprises are using the Year-2000 problem as a motivation to make other needed changes to their computer systems. For instance, they are doing such things as upgrading hardware to newer machines, tossing legacy applications for newer software, switching from in-house and proprietary systems to off-the-shelf solutions, and improving the quality and security of their systems. These are all positive responses to a negative situation.

Sure, fixing the Year-2000 problem is like learning to swim in frigid ice-cold waters in order to escape a sinking Titanic: there are more pleasant ways to achieve the same result. But given the situation, doesn't it make sense to leverage necessity to your advantage? With the right spin on this process, you could well emerge from the Year-2000 dilemma with better computer systems and a more viable enterprise - a happy ending even better than what happened to Leonardo DiCaprio's Jack Dawson character and worthy of Hollywood.

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