Audit/400 Ages Data Before its Time
Many AS/400 systems that have undergone Year 2000 remediation may still be full of false positive (nonessential fields) and false negative (date-related errors are missed) changes, which will be brought to light during the testing phase. To help AS/400 managers catch these glitches before time and resources go into testing, Visionet Systems Inc. (Princeton, N.J.) recently unveiled a package for Year 2000 testing of OS/400 object code. Audit/400 creates a testing environment for AS/400 applications by automating the process of application execution on a Windows PC and testing both databases and spooled output on the AS/400.
Audit/400 can be used for double-checking of programs already renovated by previous tools, or even for the initial analysis phase, says Dr. Humayun Mian, chief technical officer for Visionet Systems. The system produces a "simulated run of dates by aging scripts and databases," says Mian. Aging data through simulation is considered "safer" than actually rolling the machine clock forward, because "IBM isn't sure what might happen," Mian says. Results of applications and data aged beyond the Year 2000 are then compared with current results.
Audit/400 is comprised of a suite of integrated tools, including DataAger/400, which ages data to pre-selected dates. Another module, ScriptAger/400, matches input parameters. ChangeTest/400 automates the comparison testing of DB2/400 tables as well as spooled outputs of different runs, working in conjunction with DataAger/400 to validate the correct workings of applications using different date values. An optional module, DateSearch/400, automatically seeks out appropriate date-related fields for aging.
Rather than using source code to simulate results, Audit/400 runs against unmodified object code. This strategy allows testing of both original as well as converted applications, using a copy of the actual production database and not test or sample data.
Mian cautions that not all unremediated two-digit date fields will hold back Year 2000 compliance. "All programs, which have millennium bugs in them, do not actually have a failure point against millennium change," he says. "It depends on the way the organization uses it on a day-to-day basis."