NCL Debug Facility › NCL Debug Facilities › Start and Stop an NCL Debug Session

Start and Stop an NCL Debug Session

An NCL debug session is started in an environment by issuing the first DEBUG START command. The environment and scope of the session are defined using the operands of the DEBUG START command. Subsequent DEBUG START commands add additional scopes to the debug environment already established.

When the DEBUG START is processed, any NCL processes that fall within the specified scope, and which are not already debugged, will be attached to the debugger's session. If an NCL process starts, and its environment is being debugged, or it falls within the scope of a debug session, it will be attached to that debug session.

Once an environment has established a debug session, other debug commands can be issued to control the NCL processes that have been attached. The commands to manipulate these processes must be issued from the same environment that issued the DEBUG START. The process has no awareness of being debugged.

Once debugging is complete, the debug session can be terminated using the DEBUG STOP command. There are three options for the DEBUG STOP command that affect the actual processes that have been attached to the debugger.

• The CONTINUE option tells debug to remove all breakpoints from the processes and resume any that are suspended, leaving them to continue as if no debugging had taken place.
• The FLUSH option causes all attached processes to be flushed.
• The SUSPEND option leaves the debug environment intact and disconnects it from the debugger's environment (the debug session is suspended).

The CONTINUE and FLUSH options both result in the debug session being deleted. All breakpoints and scopes are cleared and any new processes that start, and fall within the scope, will not be attached.

The SUSPEND option leaves the debug environment intact. Breakpoints and scopes remain in effect. If a process starts within a scope, that process will be attached to the debug environment and any breakpoints that are pertinent will be applied. The debug session will be flagged as suspended, and a debug ID will be assigned to it. When the debug session needs to be reconnected, a DEBUG START command can be issued specifying the DEBUGID that was assigned to the suspended debug session.

A debug session can be reconnected to another environment of the same user ID. Conversely, a session can be reconnected from another environment of the same user ID. During the time that the session was suspended, new processes can be attached from the debug session. If an attached process encounters a breakpoint, it is suspended, and remains suspended until the debug session is reconnected and a command issued to resume processing for the process. The same applies for a process that was suspended at the time the debug session was suspended.

The following sequence of commands shows how to establish and stop a debug session:

DEBUG START WINDOW=2 -* debug any procedure in
                     -* window 2
DEBUG START USER=NM1BSYS PROCEDURE=MYBPROC
                     -* debug background procedure
                     -* in BSYS region
-* other debug commands control the process in the two scopes
DEBUG STOP TYPE=FLUSH-* terminate the debug
                     -* session and flush the
                     -* procedures