Using The CA-Ideal Debugger

Document ID : KB000028315
Last Modified Date : 14/02/2018
Show Technical Document Details

Introduction:

The CA-Ideal Debugger is a powerful tool for debugging your application by displaying and, if necessary, modifying values in an environment that simulates the running of a program.

The Debugger is external to the CA-Ideal program being debugged, so you do not need to change the CA-Ideal program to use the Debugger. However, a program must be successfully compiled before it can be debugged. Below are instructions on using the DEBUG command:

Environment:

z/OS

Instructions:

To enter the Debugger, simply enter the DEBUG command:

DEBUG pgmname VERSION n

The DEBUG command closely resembles the RUN command, and you will probably be familiar with many of the commands used with the Debugger. The DEBUG command and supporting commands are outlined in the CA-Ideal Command Reference Guide with a more detailed analysis in the CA-Ideal Creating Programs User Guide.

Although a Debug session looks like a run of the program, the Debugger is separate from the RUN command. Their features differ, and you cannot enter the Debugger during a run of a program.

When a program is being debugged, all user interaction occurs at breakpoints. There are four types of breakpoints:

  • Init breakpoint (occurs when the Debugger is started)
  • User breakpoints (defined by the user)
  • Error breakpoint (occurs when an error is detected)
  • Quit breakpoint (occurs at the end of the debug session)

At these breakpoints, you can enter Debugger commands for:

  • Displaying program procedure
  • Displaying or modifying values, including working data, parameter data, dataview fields, and panel fields
  • Setting additional breakpoints
  • Modifying breakpoints

There are several ways to specify breakpoints for a program. The most common is the AT command, which can be issued from the command line:

>> AT STMT 1000

Or as a line command:

0000800
0000900
AT01000
0001100

To automate the use of the Debugger, you can specify Debug commands to be executed whenever a program reaches particular breakpoints. These are called attachments. An example is attaching a D WORK command (display working data) to a breakpoint. When that breakpoint is reached, the working data values will automatically be displayed on the screen.

All breakpoints and attachments created during a debug session are saved in a CA-Ideal member. This way, the next time you debug the program, you won't have to re-create the breakpoints and attachments. By default, the Debugger uses a member named DEBUG. To override the default, issue the DEBUG command with the COMMANDS parameter. For example:

DEBUG PGM TESTPGM VER 1 COMMANDS TESTMEM

Using different command members allows for several types of debugging scenarios with each debug session. For example, you can use various members to test different portions of a program.

Because CA-Ideal members are used to store this information, these members can be modified or duplicated outside of the Debugger for easy customization or maintenance.

Debugging Without Source

The CA-Ideal Debugger lets you debug not only TEST or PROD programs that have their source present, but also programs that do not have their source, such as load modules or object-transported programs.

However, because the source is not present, the Debugger is unable to display the procedure section at a breakpoint. Therefore, you need a hardcopy listing of the program to specify the statement numbers for your breakpoints.

Another result of the source being unavailable to the Debugger is that you may see messages during the debug session indicating that the production version of the program cannot be found. These messages do not affect how the Debugger or the program functions; they simply indicate that the Debugger could not find the source.

Debugging SQL, DB2, or VSAM Programs

When a breakpoint is reached in a Debugger session, it marks a transaction boundary (similar to a TRANSMIT). Therefore, programs using SQL or VSAM dataviews need special consideration to avoid losing a record or set of records because of the checkpoint issued with the breakpoint. Refer to the CA-Ideal Creating Programs Guide for additional information.

When non-Datacom mode SQL or VSAM is being used, the Debugger can be run without terminal interaction and without checkpoints being issued. If you make the last attachment in a breakpoint a GO, terminal interaction is suppressed.

To display values from a non-interactive breakpoint, use the LIST command instead of the DISPLAY command. The output is placed in an output member called DBUGLIST.

Debugging Subprograms

When a program being debugged calls another CA-Ideal program, the Debugger follows the call. All debug functions can be used in the subprogram. There are no special considerations when calling a subprogram, but the subprogram, like the main program, must have been compiled successfully. Breakpoints and attachments can be specified for the subprogram the same way they were specified for the main program.

You can display the Procedure of any program using the Debug PROC command. PROC without arguments shows the current program's procedure, but you can also specify a subprogram, as in:

PROC SUBPRO-1 VER 2 SYS MYSYSTEM

When the subprogram's procedure is displayed, you can easily add breakpoints and attachments using line commands.

If you know the line number where you want to stop and do not need to see the subprogram's procedure, you can use an AT command with the subprogram name to set breakpoints. For example:

AT 100 MYSYSTEM.SUBPRO-1

You can use the Debugger on programs that call non-Ideal subprograms, but it cannot track the execution of the non-Ideal program. Therefore, the CA-Ideal program can be evaluated immediately before and immediately after but not during the call to the non-Ideal subprogram.

There is much more to the Debugger:

  • It can debug batch programs in a way that requires very little change from online.
  • Display options allow you to look at data in several ways to better evaluate what happens at runtime.
  • Breakpoints can be easily removed or temporarily disabled in order to speed the debugging of a program.

The best way to discover the Debugger's features is to give it a try. Have fun!

Additional Information:

Please see Chapter 2 of the CA Ideal Command Reference Guide for additional information regarding the DEBUG Command.