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 nThe 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:
At these breakpoints, you can enter Debugger commands for:
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 TESTMEMUsing 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 MYSYSTEMWhen 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-1You 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:
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.