Disaster Recovery Journal

• Consider who has a stake in the IV and Vresults: Those responsible for remediation may fear that IV&V will find a high number of missed bugs, casting their conversion work in an unfavorable light. Consultants tend to fight hard to extend their engagements to include IV&V; then, any problems that crop up during IV&V can be hidden from the client. Similarly, the vendor whose tool was used for the original conversion work argues that its IV&V tool should also be used to double-check the repaired code. But using the same search technique for both stages of the Y2K compliance process is fraught with danger (more on this later).
• Do not be lulled into a false sense of security: Fear of IV&V also results in another phenomenon: sample code selected for the IV&V vendor "bake off" may have been pampered, coddled and scrubbed until there is absolutely no chance that Y2K bugs remain. This way, the contention can be made that IV&V is unnecessary. The problem here is that the sample code has gotten far more attention than other applications, which may have many problems.

 The truth is, IV&V is crucial for achieving Y2K compliance, and the key to successful IV&V is independence. Managers must be wary of Y2K cover-ups. Look out for the consultant who protests too much about controlling the results of an IV&V audit. Insist that you, or a technically competent staff person, have control over the IV&V output. As for the MIS manager who may feel threatened, reassure him or her that IV&V is simply an integral portion of the Y2K compliance program — not a means of assessing the remediation and testing job performance that’s been done.

Most of all, you should demand that the search technique used for IV&V differ from that used for remediation. The most commonly used search technique in Y2K remediation is glossary-based (see below); if that approach was used to remediate the code, a different approach should be used to check it. Think of IV&V like the financial auditor’s practice of verifying, or "cross footing," the figures on a spreadsheet. First, all of the columns are added vertically. Then, each row of numbers is added horizontally. If the sums don’t match, you’ve got a problem. That’s what good IV&V should do. It should employ a search technique that hits the code at a right angle, if you will. Otherwise, you’ll miss the same errors in IV&V that were missed during remediation.

And in truth, first-generation Y2K search engines, used in both remediation and IV&V tools, are somewhat flawed in their basic approach — a flaw that results in missing anywhere from 5 to 20 percent of Y2K errors. This approach is called glossary, or pattern matching, search. The premise of this search technique is that the names of date variables (such as, typically, YY-MM-DD for year, month, day) identify a date-sensitive computer operation that must be fixed. Typically, these tools conduct glossary searches for variable names based on a pre-defined list of key words (again, such as YY-MM-DD). If the date variable name matches a key word placed in the glossary search engine, the variable is selected for conversion.

The problem is that when programmers write computer code, they give date variables any name they wish, without reference to any established variable naming standards. All too often, the variable name falls outside the scope of a key word search. For example, one programmer was known to name variables after women he was "dating" at the time; as a result, a date variable in his program was called "Shirley." With an almost infinite variety of programmer-defined variable names available, it’s no wonder that date variable names frequently elude Y2K tool search engines.

This is why most search engines are only 80 to 95 percent accurate in identifying date-sensitive code. This means that if, of a million lines of code, 50,000 lines are date-sensitive, between 2,500 to 10,000 lines (or 5 to 20 percent) requiring fixes will be left unconverted after remediation. Using the same technique for IV&V will result in many of the same errors going undetected a second time.

What’s needed is another way to look at the code. In the same way that writers ask someone else to proofread their copy, IV&V should bring a pair of "fresh eyes" to the post-remediation phase of Y2K compliance projects. For example, one technique, called "operations-based search," rejects the premise that Y2K-sensitive code can be identified only via date variable names. Instead, this operations-based approach searches for computer language used in the addition, subtraction or comparison of dates. In essence, it performs a search for a relatively small group of critical operations ("compare less than," "compare greater than," "sort," "subtract," etc.) used in the math and logic that causes Y2K problems.

This approach focuses on the computer language-defined math operations that are necessarily involved in Y2K-sensitive code. This is a finite and highly exacting basis for Y2K searching, and it has the benefit of lying outside of the caprice of programmers, who cannot alter the way a computer is commanded to subtract or compare dates.

Here’s an analogy. Think of the computer program undergoing remediation IV&V as a large novel. Using a conventional glossary search engine, you would need to input all of the character names that might potentially be used throughout the book to find all of the Y2K problems. If you leave out a noun, you’re in effect missing a Y2K bug. With an operations-based approach, you simply search for four or five verbs — the verbs used in the calculation of dates that cause Year 2000 problems. Examined in this independent way, the remaining Y2K bugs in remediated code cannot escape detection.

Only with true IV&V independence can you be assured of practicing real Year 2000 due diligence. This means IV&V independent from political influence and independent in the search technique. Conducted correctly, IV&V will allow you to enjoy a truly happy new year in the year 2000.