Debugging tools and oncall support

Debugging tools can require a fair amount of effort to set up, which sometimes earns them the reputation of being a waste of time. "Just put a DISPLAY message in the code, for God's sake!"says the project leader whose programming days are long behind him.

If a debugging tool is seen as a "waste of time" it is usually because the installation hasn't put enough effort into tailoring it for local use.

When we installed IBM Debug Tool in our shop, we altered all of our standard compile procs to support the TEST option and to link in the CEEUOPT module when needed. All the programmer has to do is select the TEST option on a panel and provide the VTAM LU of his debug terminal.

We never use the IBM supplied ISPF dialog to set up our debug sessions. I am not knocking IBM, but their dialog, of necessity, has to be generic, and like all generic tools requires a fair amount of effort to use. (This is where the "waste of time" perception comes into play).

We also provided each developer with a private DB2 data base for unit testing/debugging, and developed some in house tools to help them maintain them. This addresses data base contention concerns cause by people sitting at a breakpoint.

Finally, we renovated our once rarely used BTS environment to accommodate all of these changes.

It is the programmer who puts Display messages in the code that is "wasting time".



Having said that, a well-placed Display message is a useful thing to have in a production program when it blows up in the middle of the night.

After copying the data to a test environment, recompiling the program with TEST options turned on, you may be able to re-create the problem using a debugging tool. Of course, by then the batch window will be long over and you'll be too busy updating your resume to care about the problem any more.

On call support is not the time to exercise your debugging skills. Finding the logic error and fixing the program is #4 on my list of priorities at a time like this.

1. Bypass the failing job.
2. Bypass the failing step and proceed with the rest of the job.
3. Pull record from input file or take some other action to bypass the problem record.
4. Fix the offending program.
5. Recover the data base and abandon the entire batch run. Update resume.

A well chosen DISPLAY message can make #3 very easy to do.