Today's hot, new, custom-developed application is tomorrow's legacy code. It might do everything that the business needs now, but it will eventually need to be modified to accommodate new requirements, not to mention fix bugs. Validating a complex new application can be a challenge in itself, but an even bigger problem arrives when the original developers leave, taking their intimate knowledge of the software with them. Then, determining what the code does and how it does it in order to revise the application when necessary can be a cumbersome, costly, and error-prone task. Harkins Audit Software's Real-Time Program Audit (RTPA) addresses these issues by automating the code analysis process.

The philosophy behind RTPA is much the same as the one that the IT department has been pitching to the rest of the company for years: Use the power of the computer to, wherever possible, automate tedious, labor-intensive, error-prone tasks. Instead of programmers manually wading through thousands of lines of logic in an attempt to understand what is going on under the covers whenever they need to modify or debug a program they aren't familiar with, RTPA can facilitate that understanding without a code walkthrough.

RTPA is a programmer productivity utility that "audit-enables" RPG code. What this means is that it examines the source code and embeds auditing statements within it. The resulting expanded code is placed into a new file in order to leave the original version of the source code unaltered. The audit-enabled version is then compiled using a standard RPG compiler.

Audit Flexibility

When the audit-enabled object code is run, in addition to the normal business processes required of it, it also produces a separate output dataset referred to as an audit file or, more simply, an audit. The audit file can be reviewed in real-time as the program executes. Or after execution, the audit file can be printed because it is a normal spooled file. It can also be displayed online using the standard IBM WRKSPLF command, or by a fully searchable PDF file using IBM utilities. Displaying the file online makes it possible to search for values without having to manually hunt through the output.

The audit can capture a variety of information, depending on the options set by the developer. Data that can be captured includes source statements, comments, contents of variables, compile listing statement sequence numbers, source statement change IDs, statement change dates, and the time of execution.

In addition to determining what is to be audited, a developer can also specify when audit output is to be produced. For example, audit output may be started, stopped, and restarted based on the value of a particular variable or on the relative values of multiple variables. Furthermore, if you need to track down a bug that was introduced with a particular program revision, you can choose to audit only statements with a particular change date or ID.

Normally all of the executable source statements and data being processed are audited as they execute. There is also the flexibility to choose which statements are audited and when, auditing is performed only when needed, thereby limiting any performance impact. In any event, auditing generally introduces a relatively small load on the processor. In an iSeries environment, the additional load of a full audit is reported to be as little as 20% of the total CPU time for the job. Since audit-enabled versions of programs are typically not run in production, performance is usually not a serious issue.

In addition to any performance considerations, if you are auditing a large RPG III program, you might also choose to be selective in what you audit because of the source size limitation of, in particular, the RPG III compiler. Since RTPA adds auditing statements into a copy of a program, it may create a file that is three to five times the size of the original source if the full audit capabilities are used. Therefore, full auditing might push an already large program over the RPG III source restriction that typically limits a program to a maximum of 20,000 to 25,000 statements. This limit was increased with RPG IV, pushing the threshold up to approximately 40,000 to 45,000 source statements.

Audit Sequence

During runtime, the timing of the audit capture for a particular statement depends on the nature of the statement, as follows:

• For any data modification statements--such as ADD, MULTIPLY, MOVE, or CHAIN--RTPA captures results after the statement has been executed.
• Auditing of evaluation statements--such as EVAL, DOW, and WHEN--is not done until after both the statement and all associated OR and AND continuation statements are executed.
• The EXSR, GOTO, and IF branching statements are audited before being executed, and some statements, such as the EXFMT to a display, are audited twice, at the exact time of the Write to the display and then the Read from the display, with the contents of all variables and command keys on the screen shown.

Benefits

When a developer assumes responsibility for an application and must develop, modify or debug it, the traditional approach is to print out and then walk through source code in attempt to determine what it does with the data being processed. In contrast, RTPA reports on what actually happens during execution, thereby eliminating what, because of the complexity of the application, otherwise often ends up being largely guesswork. This ability to clearly report on what is happening when a program is running reduces the cost associated with losing the knowledge inherent in the original application developers because new programmers who must reengineer or debug an existing application can use RTPA to get up to speed on the application's processes more quickly than when using traditional manual approaches.

The auditing process itself places very small demands on IT staff. Once the auditing options have been chosen, the audit-enablement process is entirely automated. Programmers do not have to set breakpoints or code debugging statements as they would in a traditional environment. This reduces development time and the debugging labor costs and decreases the time required to find the source of a problem and implement a fix.

In addition to enhancing programmer productivity, RTPA can also improve software quality. Because the audit shows what is actually going on in the program rather than the developer trying to discern that from the code, considerable human error can be eliminated from the testing and debugging phases.

RTPA is easy to use and provides cursor-sensitive online help text, including detailed information about the screens, important screen fields, and command keys.

Requirements

RTPA works with any type of RPG III and RPG IV program--including RPG, RPT, SQLRPG, RPGMOD, RPGLE, SQLRPGLE, and SQLRPGMOD programs--running on OS/400 V5R1 and later. The minimum hardware requirement for RTPA is an IBM iSeries Model 170 (RISC) system.

You can explore RTPA further by visiting the Harkins Audit Web site and requesting the RTPA White Paper and the RTPA Users Manual.

Joel Klebanoff is a consultant, a writer, and president of Klebanoff Associates, Inc., a Toronto, Canada-based marketing communications firm. Joel has 25 years experience working in IT, first as a programmer/analyst and then as a marketer. He holds a Bachelor of Science in computer science and an MBA, both from the University of Toronto. Contact Joel at This email address is being protected from spambots. You need JavaScript enabled to view it..

Harkins Audit Software, Inc.
816 Daisy Lane
West Chester, PA 19382
USA
Web: www.harkinsaudit.com
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel: 888.350.9148