Setting breakpoints outside the Debug Tool engine

Competitive products allow breakpoints to be set outside of the debug session. A big improvement would eliminate the requirement that Debug Tool stop at the beginning of the program. t.

This requirement should be considered for the GUI and the 3270 interface.

This requirement was brought to my attention by the State of Georgia. Customers prefer to set the breakpoints prior to starting the Debug Tool session. This reason for setting breakpoints in advance are to minimize the time in the debugging session, due to time-outs in a CICS environment. Other reasons are due to the usability of scrolling through listing-like data sets to locate and set breakpoints with ISPF-like browsing functions.

A second distinctive improvement is the capability to not stop at the beginning of a program. With Debug Tool, using DTCN in a CICS environment, the only way we can avoid stopping at the beginning of a program is to
a) Set the breakpoint in advance
b) Use the DFHCOMMAREA with some variable to stop at subsequent invocations.

This is important for the scenario described below:
The transaction invoked to display a page of data. The user initiates a page forward operation. The data we want to test with is on the 35th page. With the competitor products, they can set the breakpoint in advance, and use a conditional breakpoint to stop exactly where they want. With Debug Tool, it stops at the beginning of the program for every page. This is a big deal to some of the developers.

This approach also provides a number of usability enhancements. For example, there is no command to show only lines that have breakpoints. There is a requirement (20804) to improve label processing, by showing all labels in a program, with the ones that have breakpoints. If we allow label breakpoints, then the navigation to exclude lines without breakpoints or labels with breakpoints turns into simple ISPF exclude and find all commands, rather than having to re-invent the commands to perform this function.