Remedial Health Checks
By now many organizations have completed a Year 2000 remediation process and are readyto execute a critical second step: quality assurance. Whether checking to ensure thatsystems purporting to be compliant do make the grade or checking the success of aremediation process, the quality assurance step is critical. Besides bolstering overallcorporate quality assurance and testing procedures and insuring against potentiallitigation over Y2K failures, a "health check" provides a safety net,demonstrating that an organization has done everything possible to ward off the "dateof doom."
Mainframe-driven IT divisions are well aware that their systems are not Y2K ready, butmany with UNIX or Windows 2000 (formerly Windows NT) assume that their system is. It's apotentially dangerous assumption. They figure that they don't have a problem because bothUNIX and Windows 2000 can recognize dates well into the 21st century. However, programmersusing mainframe techniques learned in languages such as COBOL could be embedding two-digitdates in character strings.
The techniques for a readiness health check are similar to those of a normalremediation effort. The big difference? The system is, ostensibly, ready. The healthcheck, however, assumes that the system is NOT READY and sets out to find points wheredates exist. The first step is to establish the number of programs or components that aredate impacted. This is accomplished by scanning the source code to identify where datesare referenced. For Y2K remediated applications, this should be a scan independent of theinitial effort and preferably with a different tool. Next, subject matter experts shouldbe interviewed to identify which programs or components are most critical and whichinterface with other applications.
A triage process is initiated to determine the risks to the organization should aparticular program or component fail. The team then prioritizes the review processstarting with those programs that will cause the greatest disruption if failure occurs.Adherence to company programming standards and change control procedures is reviewed toestablish a confidence level for the state of the source code.
A company's overall approach to testing is also important. If a company has done verylittle testing, a stronger effort should be undertaken. With this additional effort, thehealth check helps to develop a more rigorous test environment to use on an on-goingbasis.
Costs vary widely according to the scope of the check, which can range from a simplereview of the remediation process and rescan of source code, to a thorough century testingeffort to satisfy stockholders or regulatory entities. The health check provides anobjective third-party opinion, as well as a testing process that can be leveraged infuture scenarios. The level of testing and associated cost is to a great degree dictatedby the industry; that is, the more regulation involved, the greater the requirement for anindependent assessment.
"An ounce of prevention is worth a pound of cure," is a clichÈ thatcertainly applies when it comes to the Year 2000. The costs for a health check areinsignificant when compared against the costs of enduring a lawsuit. Those who use thehealth check will find their efforts well rewarded in the next millennium.
--James Patterson, Y2K Product Director, IMI Systems in Melville N.Y.,has been in the information technology arena since 1975, serving as a programmer/analyst,project manager and consultant most recently focusing on Y2K challenges.