OS/2 Shareware BBS: 10 Tools/10-Tools.zip/vacbdbg.zip/betadbg.zip/help/derdhx1.hlp

OS/2 Help File | 1998-02-13 | 280KB | 9,507 lines

ΓòÉΓòÉΓòÉ 1. Procedure Help for Debugger ΓòÉΓòÉΓòÉ

The Debugger Online Help is divided into four types of information:

     Procedures - how to perform a specific task or set of tasks

     Reference - technical information you may need to understand how to
      perform a task

     User Interface - context-sensitive help pages displayed when you press F1
      from within the debugger

     Concepts - overview information you may need to understand basic
      principles of debugging or components of the debugger interface

 Procedure help is organized hierarchically, so that you start from a
 high-level task and follow it down to the specific task you want to perform.
 Help is available for the following high-level tasks:

     Prepare a program for debugging

     Start or stop debugging a program

     Set breakpoints in your program

     Step through, run, or halt your program

     Debug variable contents and memory

     Debug logic and program flow


ΓòÉΓòÉΓòÉ 1.1. Prepare a Program for Debugging ΓòÉΓòÉΓòÉ

To prepare a program for debugging, you may need to perform some or all of the
following tasks:

     Establish a debug environment

     Write programs for debugging

     Compile a program for debugging


ΓòÉΓòÉΓòÉ 1.1.1. Establish a Debug Environment ΓòÉΓòÉΓòÉ

To establish a debug environment, you need to perform some or all of the
following tasks:

     Set environment variables for the debugger

     Specify command-line options for your program

     Start the debug session


ΓòÉΓòÉΓòÉ 1.1.1.1. Set Environment Variables for the Debugger ΓòÉΓòÉΓòÉ

The debugger user interface running on the workstation uses certain environment
variables to determine where it looks for source files, executables, online
help, and so on. See the Related Topics below for help on the environment
variables themselves.

To set an environment variable for a given session of the debugger, do the
following on your OS/2 or Windows workstation:

   1. Open a command shell window.

   2. Use the SET command to set each environment variable to the required
      value:

            SET VARNAME=VAL1;VAL2;VAL3

      where VARNAME is the name of the environment variable, and VAL1, VAL2,
      and VAL3 are values assigned to it (normally multiple values for a
      variable are separated by semicolons).

      If you want to add more values to an existing variable, use the following
      syntax:

            SET VARNAME=%VARNAME%;VAL4;VAL5

      This adds both the existing contents of VARNAME and the new values to the
      variable.

   3. Invoke the debugger user interfacefrom that command shell.

 If you want to set these environment variables permanently, do the following,
 depending on the operating system you are using:

 From Control Panel select System, then within the System notebook choose the
 Environment tab. Select the variable you want to change from the list, or
 enter a new variable name in the Variable entry field, and enter its values in
 the Value entry field. Click on OK or Apply to save the changed or new
 variable.

 Add the SET... commands to your CONFIG.SYS file. A reboot is required for
 these changes to take effect.

 Related Information

 Reference
 Environment Variables


ΓòÉΓòÉΓòÉ 1.1.1.2. Start the Debugger ΓòÉΓòÉΓòÉ

You can start a local debug session on OS/2, Windows 95, or Windows NT from the
command shell using the following syntax:

idbug [ debugger-options] [program-name [program-parameters]]

where:

 debugger-options includes zero or more valid options supported by the
           debugger.

 program-name is one of:

               The name of an executable file, with a valid path (or no path,
                if the executable is locatable through the PATH environment
                variable), and the extension .EXE (optional)

               The name of a post mortem dump file (OS/2 only)

 program-parameters includes zero or more parameters your program expects; for
           C++ programs, these parameters are usually accessed by your program
           through the argc and argv arguments to the main function.

 If you do not specify a program name, the debugger opens a Startup dialog in
 which you can choose what you want to debug.

 Related Information

 Reference
 Debugger Options
 Postmortem Debugging

 Procedures
 Attach to a Process
 Debug a DLL


ΓòÉΓòÉΓòÉ 1.1.1.3. Invoke the Debugger ΓòÉΓòÉΓòÉ

You can invoke the debugger remotely (where the program being debugged, and the
debugger user interface, are on different machines or operating systems), or
locally.

Related Information

Concepts
Remote Debugging

Procedures
Start the Debugger


ΓòÉΓòÉΓòÉ 1.1.1.3.1. Specify Command-Line Parameters for Your Program ΓòÉΓòÉΓòÉ

You can specify command-line parameters for your program either from the
command shell where you invoke the debugger, or in the Startup dialog of the
debugger.

Specify Parameters from a Command Shell

To pass arguments to your program from a command shell, make sure that they
appear after the name of the program on the command line:

idbug /debugger-options program-name program-parameters

where debugger-options are any options supplied to the debugger itself,
program-name is the name of the executable you want to debug, and
program-parameters are the arguments or parameters you want to pass to your
program.

Specify Parameters from the Startup Dialog

To pass arguments to your program from a startup dialog, do the following:

   1. Open the startup dialog, either by invoking the debugger without a
      program name, or by choosing File->Startup from the Session Control
      window or a Source window.

   2. Enter the name of the program you want to debug in the Program entry
      field, or select a file from the pulldown list.

   3. Enter the program parameters in the Parameters field.

   4. Click on OK to start debugging the program with the supplied command-line
      parameters.

 Related Information

 Procedures
 Invoke the Debugger
 Start or Stop Debugging a Program

 Reference
 Debugger Options


ΓòÉΓòÉΓòÉ 1.1.1.4. Use the Source Window ΓòÉΓòÉΓòÉ

Use the Source window to view the progress of your program as you debug it. The
Source window displays your program's source code, disassembled code, or both,
and updates the display after each step or run command. You can set or clear
breakpoints, add variables or expressions to a monitor, and more. See the
following tasks related to using the Source window:

     Change views in a Source window

     View different source files

     Set and clear breakpoints

     Add expressions and variables to a monitor

     Run, step through, start and stop your program

     Open other windows and monitors

 Related Information

 Concepts
 How Step Commands Work in Different Views


ΓòÉΓòÉΓòÉ 1.1.1.4.1. View Different Source Files ΓòÉΓòÉΓòÉ

When you start the debugger, a single Source window appears.

If your executable file was linked from several object files, you can open a
Source window for each object, and view several source files at once:

   1. Raise the Session Control window by selecting it from the Windows menu of
      any main debugger window

   2. Click on the + icon beside the name of the executable, to open a list of
      object files

   3. Double-click on the object file you want to view. If that object file is
      not already in a Source window, a new Source window opens containing the
      source file for that object file.

 You can also open new Source windows from the File menu of the Session Control
 window or of an existing Source window:

   1. Select File->Open new source

   2. Enter the name of the source file. This source file must be a part of the
      application you are currently debugging.

   3. Click on OK. A Source window for the new source file opens, if the
      debugger is able to locate the file.

 Related Information

 Procedures
 Change Views in a Source Window
 Open Other Debugger Windows
 Use the Source Window

 Reference
 Problems Getting a Source or Mixed View


ΓòÉΓòÉΓòÉ 1.1.1.4.2. Change Views in a Source Window ΓòÉΓòÉΓòÉ

The Source window supports three views for programs compiled with debug
information:

     Source -- you see your program's source code

     Disassembly -- you see the assembly code that the debugger disassembles
      from the executable or DLL

     Mixed -- a combination of source code and disassembly code

 You can use the  toolbar button to toggle through available views, or you can
 go directly to a particular view by selecting that view from the View menu.
 For example, to switch to a disassembly view, select View->Disassembly.

 Related Information

 Concepts
 Source View
 Disassembly View
 Mixed View

 Procedures
 View Different Source Files

 Reference
 Problems Getting a Source or Mixed View


ΓòÉΓòÉΓòÉ 1.1.1.5. Open Other Debugger Windows ΓòÉΓòÉΓòÉ

You can open other Source windows from a Source window or from the Session
Control window.

To open a monitor window from a Source window, click on a monitor toolbar
button or select the desired monitor from the Monitors menu. You can also open
a monitor window by adding a variable to that monitor, in one of the following
ways:

     Click the right mouse button on the variable in the Source window, then
      select the appropriate monitor from the popup menu.

     Double-click the left mouse button on the variable, to add the variable
      to the Program monitor.

     Click the right mouse button on the variable, press Ctrl+M, and select
      the desired monitor from the Monitor Expression dialog.

 To open the Breakpoints list window, select Breakpoints->List from the menu
 bar, or press Ctrl+X.

 To change the focus from a Source window to another window that is already
 opened (or minimized), select that window from the Windows menu.

 Related Information

 Procedures
 View Different Source Files
 Add Expressions and Variables to a Monitor


ΓòÉΓòÉΓòÉ 1.1.2. Debug Optimized Code ΓòÉΓòÉΓòÉ

Problems that only surface during optimization are often an indication of logic
errors that are exposed by optimization, for example using a variable that has
not been initialized. If you encounter an error in your program that only
occurs in the optimized version, you can usually find the cause of the error
using a binary search technique to find the failing module:

   1. Begin by optimizing half the modules and see if the error persists.

   2. After each change in the number of optimized modules, if the error
      persists, optimize fewer modules; if the error goes away, optimize more
      modules. Eventually you will have narrowed the error down to a single
      module or a small number of modules.

   3. Debug the failing module. If possible, turn off the instruction
      scheduling optimizations for that module. Look for problems such as
      reading from a variable before it has been written to, and pointers or
      array indices exceeding the bounds of storage allocated for the pointer
      or array.

 See the Reference information below for tips on uncovering problems with
 optimized code you are debugging.

 Related Information

 Reference
 Notes on Debugging Optimized Code


ΓòÉΓòÉΓòÉ 1.1.3. Write Programs for Debugging ΓòÉΓòÉΓòÉ

You can make your programs easier to debug by following these simple
guidelines:

     Do not hand-tune your source code for performance until you have fully
      debugged and tested the untuned version. Hand tuning may introduce new
      bugs or make the logic of your code harder to understand.

     Where possible, do not put multiple statements on a single line, because
      some debugger features operate on a line basis. For example, you cannot
      step over or set line breakpoints on more than one statement on the same
      line.

     Assign intermediate expression values to temporary variables to make it
      easier to verify intermediate results.

 To be able to debug your programs at the level of source code statements, you
 must specify C++ or COBOL or PL/I compiler options that generate debug
 information, and in some cases you must specify options that enable the
 debugger to work properly with your code.

 Related Information

 Reference

 C++ Compiler Opetions
 COBOL Compiler Options on Intel Platforms
 Intel Options for PL/I Programs


ΓòÉΓòÉΓòÉ 1.1.4. Compile a Program for Debugging ΓòÉΓòÉΓòÉ

In order to be able to debug your program at the source code level, you need to
compile your program with certain compiler options that instruct the compiler
to generate symbolic information in the object file. The Related Topics section
below points to information on how to compile your program for a specific
environment.

Related Information

Reference
C++ Compiler Options on Intel Platforms
COBOL Compiler Options on Intel Platforms
PL/I Compiler Options on Intel Platforms

Procedures
Debug Optimized Code
Write Programs for Debugging


ΓòÉΓòÉΓòÉ 1.2. Start or Stop Debugging a Program ΓòÉΓòÉΓòÉ

To start or stop debugging a program, you will need to know how to perform some
of the following subtasks:

     Invoke the debugger

     Start debugging an already running process (not available from OS/2)

     Start debugging a DLL

     Set breakpoints in your program

     Step through, run, or halt a program


ΓòÉΓòÉΓòÉ 1.2.1. Attach to a Process ΓòÉΓòÉΓòÉ

You can attach to an already running process (on Windows 95 and Windows NT )
from the Startup dialog, or from the Process list item on the File menu of the
Source or Session Control windows.

The Startup dialog appears when you start the debugger and do not specify a
program to debug. You can also get to this dialog by choosing File->Startup
from the Source or Session Control windows. Choose Process list from the
Startup dialog, and select a process to debug.

Select a process from the process list. See under 'Related Topics' for guidance
on when to attach to a process, and for more details on using the Process List
dialog.

When you attach to a process, the Run->Restart menu item is disabled.

Related Information

Procedures
Invoke the Debugger

Reference
When to Use the Process List Dialog


ΓòÉΓòÉΓòÉ 1.2.2. Debug a DLL ΓòÉΓòÉΓòÉ

To debug functions within a DLL, you first need to do the following:

   1. Compile the DLL source files with symbolic information, if you have
      access to them and you want to be able to debug DLL functions at the
      source code level.

   2. If you do not already have an executable program that calls the DLL
      functions you want to debug, write such a program and link it to the DLL.
      See your compiler documentation for information on how to do this. For
      VisualAge for C++ for Windows and VisualAge for C++ for OS/2, see the
      corresponding Programming Guide.

 Related Information

 Procedures
 Set a Deferred Breakpoint
 Start Debugging a DLL from a Load Occurrence Breakpoint Dialog
 Start Debugging a DLL from a Source Window
 Start Debugging a DLL from the Breakpoints List Window
 Start Debugging a DLL from the Session Control Window


ΓòÉΓòÉΓòÉ 1.2.2.1. Set a Deferred Breakpoint ΓòÉΓòÉΓòÉ

A deferred breakpoint is a breakpoint set in a DLL that is not currently
loaded.

To set a deferred line breakpoint, do the following:

   1. Open a Line breakpoint dialog in one of the following ways:

          From a Source window or the Session Control window, select
           Breakpoints->Set line

          From a Breakpoint List window, select Set->Set line.

   2. Choose the DLL from the Executable pull-down field.

   3. Choose the source file from the Include File pull-down field.

   4. Enter the line number where you want the breakpoint set

   5. Specify any additional information you wish in the Optional Parameters
      group box.

   6. Check the Defer breakpoint check box.

   7. Click on OK or press Enter.

 Related Information

 Procedures
 Debug a DLL
 Start Debugging a DLL from a Load Occurrence Breakpoint Dialog
 Start Debugging a DLL from a Source Window
 Start Debugging a DLL from the Session Control Window


ΓòÉΓòÉΓòÉ 1.2.2.2. Start Debugging a DLL from a Load Occurrence Breakpoint Dialog ΓòÉΓòÉΓòÉ

You can set a breakpoint in a DLL that causes execution to stop when the DLL is
first loaded by your application. The DLL is generally loaded by your
application the first time a function contained within the DLL is called by
another function within your application.This type of breakpoint is called a
load occurrence breakpoint.

To set a load occurrence breakpoint, do the following:

   1. From the Breakpoints menu of the Session Control or Source windows, or
      from the Set menu of the Breakpoints List window, choose Set load
      occurrence breakpoint.

   2. In the Load Occurrence Breakpoint dialog, enter the name of the DLL you
      want to set the breakpoint in.

   3. Click on OK to set the breakpoint and close the Load Occurrence
      Breakpoint dialog, or click on Set if you want to set more load
      occurrence breakpoints.

 When you run your application, execution will stop when the DLL is first
 loaded.

 Related Information

 Procedures
 Debug a DLL


ΓòÉΓòÉΓòÉ 1.2.2.3. Start Debugging a DLL from the Breakpoints List Window ΓòÉΓòÉΓòÉ

You can start debugging a DLL from the Breakpoints List window by setting a
line breakpoint in that DLL, then issuing the Run command. You can only do this
if the compile unit you want to place the breakpoint in was compiled with debug
information. To set a line breakpoint in a DLL and then start debugging the
DLL, do the following:

   1. Open a Breakpoints List window

   2. From the Set menu choose Set line

   3. In the Line Breakpoint dialog, from the Executable pulldown list choose
      the DLL you want to debug.

   4. From the Source pulldown list choose the source file containing the code
      you want to debug.

   5. In the Line entry field, enter the line number within the source file you
      want to place a breakpoint in.

   6. Click on the Defer breakpoint check box.

   7. Issue the Run command by pressing Ctrl+R.

 Related Information

 Procedures
 Debug a DLL
 Set a Deferred Breakpoint
 Set a Line Breakpoint


ΓòÉΓòÉΓòÉ 1.2.2.4. Start Debugging a DLL from the Session Control Window ΓòÉΓòÉΓòÉ

You can use the Session Control window to access a Source window containing the
source for a DLL you want to debug.

   1. In the Session Control window, expand the Components Pane entry for the
      DLL you want to debug.

   2. Continue expanding appropriate items in the list until you find the
      source file or function you want to debug. If the source file or function
      is not listed, you may not have compiled the function with debug
      information.

   3. Double-click on the source file or function to raise a Source window for
      it.

   4. Set a line, function, or other breakpoint at an appropriate point in that
      source window.

   5. Run your program.

 Related Information

 Procedures
 Debug a DLL
 Run a Program
 Set Breakpoints


ΓòÉΓòÉΓòÉ 1.2.2.5. Start Debugging a DLL from a Source Window ΓòÉΓòÉΓòÉ

You can start debugging a DLL used by your application from the Source window
containing the current execution point, provided you can use step commands to
reach a statement that calls a function within your DLL.

   1. In the Source window, use a combination of breakpoints and Run, Step
      Debug, and Jump to Location commands to execute or skip over portions of
      your code, up to the call to the DLL function you want to debug.

   2. Issue a Step Into or Step Debug command to enter the DLL function.

 A Source window showing the DLL function is raised, and the current line is
 the first line within the function.

 Related Information

 Procedures
 Debug a DLL
 Set Breakpoints
 Run, Step Through, or Stop a Program


ΓòÉΓòÉΓòÉ 1.2.2.6. Debug OS/2 REXX and WorkPlace Shell DLLs ΓòÉΓòÉΓòÉ

Note: This section applies only to programs running on OS/2.

You can use the debugger to debug OS/2 REXX DLLs and WorkPlace shell DLLs.

To debug a REXX DLL, type the following from an OS/2 command shell:

idbug cmd.exe /K myrexx.cmd

where myrexx.cmd is the name of your REXX command file. When the debugger stops
at the beginning of CMD.EXE, do the following:

   1. From the Breakpoints menu, set a Load occurrence breakpoint to stop when
      your DLL is loaded.

   2. Run the program. When the load occurrence breakpoint is encountered, a
      Source window for your DLL displays.

   3. Set breakpoints, run, step, and use other debugger features to debug your
      DLL.

 To debug a WorkPlace Shell DLL, replace the RUNWORKPLACE line in your
 config.sys with the following line:

 SET RUNWORKPLACE=X:/OS2/CMD.EXE

 where X:/OS2/CMD.EXE is the drive letter and path name for the OS/2 CMD.EXE
 command interpreter. This prevents the Presentation Manager shell from loading
 automatically on system restart. After rebooting, type the following from an
 OS/2 command shell:

 idbug x:/os2/cmd.exe

 When the debugger stops at the beginning of PMSHELL.EXE, follow the same steps
 as for debugging an OS/2 REXX DLL.

 Related Information

 Procedures
 Debug a DLL


ΓòÉΓòÉΓòÉ 1.2.3. Debug Dump Files ΓòÉΓòÉΓòÉ

Note: post-mortem debugging and the ITRAPPER program are only available on
OS/2.

You can debug dump files created by the ITRAPPER utility in much the same way
as you debug live executables. However, because a dump file is not executable,
any debugger commands to do with running, stepping, or setting breakpoints will
not work when you are debugging a dump file.

To start debugging a dump file, from the command shell type:

idbug [path]dumpfilename

where dumpfilename is the name of the dump file you want to debug. You can also
enter the dump file name from the Startup dialog, by starting the debugger
without parameters, or by choosing File->Startup from the Source or Session
Control windows.

Once you have started debugging a dump file, you can use a subset of debugger
features to examine registers, storage, and code for the executable that caused
the trap. You can access all the debugger monitors (registers, call stack,
storage, local variables, program, private and popup), but you cannot change
the contents of items in these monitors (for example, registers in the
registers monitor).

The following debugger commands are disabled, and icons for them are hidden or
greyed out, when you are debugging a dump file:

     Halt command

     Step commands

     Commands to set, clear, disable, enable, or delete breakpoints.

 The Run command is available, but its only effect is to cause a redisplay of
 the exception that caused the trap.

 Related Information

 Procedures
 Obtain a Dump File


ΓòÉΓòÉΓòÉ 1.2.3.1. Obtain a Dump File ΓòÉΓòÉΓòÉ

Note: This section applies only to OS/2.

The end user who is experiencing the unanticipated exception or trap must load
the application under the dump collector utility, ITRAPPER. When the program
fails, ITRAPPER creates a dump file. If the failure is recoverable (for
example, some OS/2 exceptions), ITRAPPER lets the program continue running, and
subsequent failures result in new dump files being created. For unrecoverable
exceptions and for traps, ITRAPPER terminates the application after creating
the dump file.

You need to ship the ITRAPPER utility with your program. This utility is part
of the OS/2 version of the product. If you want to change ITRAPPER's default
parameters, you also need to provide a parameter file.

Related Information

Procedures
Debug Dump Files
Start ITRAPPER

Reference
Postmortem Debugging Overview


ΓòÉΓòÉΓòÉ 1.2.4. Debug PM Applications ΓòÉΓòÉΓòÉ

The PM system is message-based. As program events are encountered by PM
programs, the programs communicate with each other by passing messages and by
receiving user input through input messages. When a PM program encounters an
enabled breakpoint, the input queue can become blocked and dependent program
events, or processes, can also become blocked as a result. For example, the
input queue can become blocked when your program stops at a breakpoint that has
been triggered by an input event.

The debugger provides two modes of operation by which PM messages can be
processed while the debugger has control.Asynchronous mode prevents the input
queue and dependent events or processes from being blocked, but can cause
problems for your application in some situations. Synchronous mode avoids these
problems, but does not prevent blockages. You can select one of these modes
from the Debugging mode group box.


ΓòÉΓòÉΓòÉ 1.2.5. Debug a Microsoft Visual C++ Program ΓòÉΓòÉΓòÉ

Note: This section applies only to programs being debugged on Windows 95 or
Windows NT.

You can use the debugger to debug programs compiled by the Microsoft Visual C++
Compiler Version 5.0, provided the debug information is imbedded in the
executable. Both C and C++ programs are supported. To debug such a program
follow these steps:

   1. Use the Visual C++ compiler to compile the program with the /Z7 option,
      to produce Microsoft C 7.0 debug information.

   2. Link the .obj files with the /DEBUG and /PDB:NONE linker options to
      generate the necessary debug information and imbed it in the executable.

   3. Start debugging the program.

 For example, to compile, link, and debug the program hello.c, use the
 following commands:

  cl /Z7 /c hello.c
  link /DEBUG /PDB:NONE hello.obj /OUT:hello.exe
  idbug hello.exe

 If you do not compile and link with these options, debug information, if
 generated, is stored in a separate .PDB file which the debugger cannot read.
 In this case the debugger treats the executable as if it had no debug
 information, and only disassembly views of the code are available.

 Related Information

 Procedures
 Start the Debugger

 Reference
 Limitations when Debugging Visual C++ Programs


ΓòÉΓòÉΓòÉ 1.2.6. Halt Execution of a Debuggee Program ΓòÉΓòÉΓòÉ

To halt execution of a debuggee program that is currently running, do one of
the following:

     From a Source window or the Session Control window, select Run->Halt

     From any window that has toolbar buttons displayed, click on the  button

 You may find that execution halts in a function other than the one you are
 debugging (for example, a system library function). To run to the end of that
 function and stop in your own code, do one of the following:

     Issue the Step return command from the Source window execution stopped in

     If the previous technique results in the debugger displaying the message
      'Cannot determine return address', issue the Step debug command until
      execution returns to your code

     If you know what line in your program will be the next to execute after
      the current function returns, go to the source window containing that
      line, set a breakpoint on it, and issue the Run command.

 Related Information

 Procedures
 Set a Line Breakpoint
 Terminate a Debug Session


ΓòÉΓòÉΓòÉ 1.2.7. Restart Your Program ΓòÉΓòÉΓòÉ

Note: You cannot restart a program that you attached to with the debugger.

You can start debugging your program again from the beginning (the start of the
main function) by doing the following:

   1. If the program is currently executing within the debugger, issue a Halt
      command by selecting Run->Halt from a Source window or the Session
      Control window, or pressing the  button.

   2. Set a breakpoint at the location you want to run to, if it is not the
      start of the main function and you have not already set a breakpoint
      there.

   3. If the previous run of your program performed file output and the program
      logic will be changed by the existence of such files from a previous
      debug session, you may want to erase these files before restarting.

   4. Select Run->Restart from a Source window or the Session Control window.

   5. If you want to run up to a breakpoint, issue the Run command by pressing
      Ctrl+R from any window (or R from a Source window) or pressing the
      button.

 Related Information

 Procedures
 Halt Execution of a Debuggee Program
 Set Breakpoints


ΓòÉΓòÉΓòÉ 1.2.8. Start the Debugger and the Remote Program ΓòÉΓòÉΓòÉ

To remotely debug a program, follow these steps:

   1. On the machine where the program to be debugged will run, issue the
      irmtdbg command.

   2. On the machine where the debugger will run, issue the idbug command and
      provide the remote host name. Either specify the program you want to
      debug as the last argument of the command, or enter the program name in
      the Startup dialog that appears.

 The irmtdbg command has the following syntax:

 irmtdbg [-qprotocol=tcpip [-qport=port]] [-qsession=single|multi]

 where:

 -qprotocol=tcpip Specifies the communications protocol to use. Only the TCP/IP
           communications protocol is supported. This is the default protocol.

 -qport=port Specifies the TCP/IP port used for the connection. If you specify
           -qprotocol=tcpip but you do not specify a port, or if you do not
           specify a protocol (so that TCP/IP becomes the default protocol),
           the default port is 8000.

 -qsession=single|multi Specifies whether to support single session debugging
           or multiple session debugging. The default is single session.

 The command for invoking the debugger has the following syntax when used for
 remote debugging:

 idbug [-qprotocol=tcpip [-qport=port]] -qhost=remotehost remote-program
 [program-parameters]

 where:

 -qhost=remotehost Specifies the TCP/IP name or address of the host to connect
           to. This argument is required.

 remote-program Is the name of the executable program on the remote machine
           (including an optional path)

 program-parameters are any parameters you want to pass to the executable
           program

 The communications options for the idbug command are the same (and have the
 same defaults) as those for the irmtdbg command. Note that you do not specify
 a host name on the irmtdbg command because the remote machine initiates the
 connection.


ΓòÉΓòÉΓòÉ 1.3. Set Breakpoints in Your Program ΓòÉΓòÉΓòÉ

You can set breakpoints in your program from a number of windows. See the
following subtasks:

     Set breakpoints from the Breakpoints List window

     Set breakpoints from a Source window

     Set function breakpoints from the Session Control window


ΓòÉΓòÉΓòÉ 1.3.1. Set Breakpoints in the Breakpoints List Window ΓòÉΓòÉΓòÉ

To set breakpoints from the Breakpoints List window, open the window (if it is
not already open), using one of the following methods

   1. Type Ctrl+X from any main debugger window or monitor

   2. Select List from the Breakpoints menu of the Source window

   3. Click on the  button in the Source Window

   4. Position the cursor in the prefix area, click mouse button 2, and select
      List from the popup menu.

 Then do the following:

   1. From the Breakpoints List window, select the type of breakpoint you want
      to set from the Set menu.

   2. Enter the information for the breakpoint in the dialog, and click on OK
      or press the Enter key.

 You can set breakpoints from the Source window and the Session Control window
 as well. Unless you want to set multiple breakpoints with the same nonstandard
 optional parameters, you may find it easier to use the Source window for
 setting line breakpoints and address breakpoints, and the Session Control
 window for setting function breakpoints. Storage change breakpoints and load
 occurrence breakpoints can be set from any of the three windows.

 Related Information

 Procedures
 Set Multiple Breakpoints
 Set and Clear Breakpoints from a Source Window
 Set Function Breakpoints from the Session Control Window

 Concepts
 Types of Breakpoints


ΓòÉΓòÉΓòÉ 1.3.2. Set and Clear Breakpoints from a Source Window ΓòÉΓòÉΓòÉ

You can set and clear breakpoints from a Source window in the following ways:

     Toggle a breakpoint on or off for a line. There are three ways to do
      this:

        -  Double-click on the prefix area for that line

        -  Highlight the line using either the up and down cursor keys or the
           mouse, then press the space bar

        -  Highlight the line, then select Breakpoints->Toggle at current line.

     From the prefix area, or while the pointer is over a function name, click
      on mouse button 2 [note] and select a breakpoint option from the popup
      menu

     Open a Breakpoints List window, and set or clear the breakpoint from
      there

     Select a type of breakpoint from the Breakpoints menu, and enter the
      appropriate information.

 Note: Clearing a breakpoint deletes it, meaning that you must recreate it if
 you want to use it again. If you plan to use a breakpoint again later, it is
 better to disable the breakpoint instead.

 Related Information

 Procedures
 Enable and Disable Breakpoints


ΓòÉΓòÉΓòÉ 1.3.3. Set Function Breakpoints from the Session Control Window ΓòÉΓòÉΓòÉ

You can set function breakpoints in the Session Control window by either of the
following methods:

     Go to the Breakpoints menu and choose Set function breakpoint

     Select a function in the Components pane, click mouse button 2 to bring
      up a popup menu, and choose Set function breakpoint.

 Related Information

 Procedures
 Set Breakpoints


ΓòÉΓòÉΓòÉ 1.4. Run, Step Through, or Stop a Program ΓòÉΓòÉΓòÉ

You can use debugger toolbar buttons, accelerator keys, and menu commands to
accomplish the following subtasks:

     Run your program

     Step through your program

     Halt execution of your program

     Restart your program

     Terminate a debug session


ΓòÉΓòÉΓòÉ 1.4.1. Step through a Program ΓòÉΓòÉΓòÉ

You can use step commands to step through your program a single line  or
disassembly instruction at a time. You can issue step commands from the Source
window that contains the current execution point.

The following types of step commands are available:

     Step over - executes the current line, without stopping in any functions
      called within the line

     Step Into - executes the current line. If the current line contains a
      call to a function, execution stops in the first source line or
      disassembly instruction of the called function. If the called function
      was not compiled with debug information, the function is shown in a
      disassembly view.

     Step Debug - executes the current line. Execution stops at the next line
      encountered for which debug information is available. This could be in
      the current function, in the called function, or in a function called
      within the called function.

     Step Return - executes from the current execution point up to the line
      immediately following the line that called this function. If you issue a
      Step Return command from the main function, the program runs to
      completion.

 Note that execution may stop earlier than indicated above, if the debugger
 encounters a breakpoint or an exception.

 You can use combinations of step commands to step through multiple calls on a
 single line.

 Related Information

 Reference
 Stepping and Functions


ΓòÉΓòÉΓòÉ 1.4.2. Run a Program ΓòÉΓòÉΓòÉ

After you have set appropriate breakpoints in your program, you are ready to
issue the Run command. The debugger runs the program from the current line to
the first enabled breakpoint it encounters and a Source window displays the
current line. You can then examine the contents of storage, variables, the call
stack, or processor registers; step through your program; or issue the Run
command again to run to the next enabled breakpoint.

Related Information

Procedures
Set Breakpoints
Step through a Program
View Variables, Memory, Registers, and the Stack


ΓòÉΓòÉΓòÉ 1.4.3. Terminate a Debug Session ΓòÉΓòÉΓòÉ

To terminate a debug session and exit the debugger, do one of the following:

     Select File->Close debugger from any debugger window that has a File
      menu.

     Press F3 from any debugger window that is not a dialog

     Switch to the Session Control window and use your windowing system's
      technique for closing that window. For example, OS/2 and Windows
      operating systems, double-click on the upper left corner of the window or
      press Alt+F4.

 To terminate a debug session and start another one (local debugging only) do
 one of the following:

     If you want to start the same program executing again, select
      Run->Restart from a Source window or the Session Control window.

     Run the current program to completion, if this is feasible. A message
      window with the text 'Program has run to completion' appears. Click on
      OK. A Startup dialog then appears.

     Select File->Startup from a Source window or the Session Control window.

 The debugger locks the load modules for your program from write updates by the
 compiler until execution completes. If you want to recompile your program and
 debug it again, you should run the program to completion, exit the debugger,
 or switch to debugging a different program before recompiling.

 Related Information

 Procedures
 Halt Execution of a Debuggee Program


ΓòÉΓòÉΓòÉ 1.5. Debug Variable Contents and Memory ΓòÉΓòÉΓòÉ

Choose from among the following subtasks:

     Change the contents of storage

     View a location in storage

     Add expressions and variables to a monitor

     Open a new storage monitor

     View variables, memory, registers, and the stack

     Debug heap usage


ΓòÉΓòÉΓòÉ 1.5.1. Change the Contents of Storage, Variables, and Registers ΓòÉΓòÉΓòÉ

To change the contents of storage in a Storage monitor, do the following:

   1. Raise or open a Storage monitor (select Storage monitor from the Monitors
      menu of the Source or Session Control windows, or press Ctrl+G, or click
      on the  button)

   2. If the address whose contents you want to change is not shown, use the
      PageUp and PageDown keys to scroll to that address, or click on an entry
      in the address column and enter a new address

   3. Double-click on an entry in a data column in the monitor (or click on the
      entry and press Enter)

   4. Type a value that is valid for the shown representation

   5. Press Enter.

 To change the contents of a variable in a Local Variables, Program, Private,
 or Popup monitor, or a register in the Registers monitor, do the following:

   1. Raise or open the appropriate monitor (from the Monitors menu of a Source
      window or the Session Control window, or using the appropriate
      accelerator key or toolbar button)

   2. Double-click on the entry field that shows the contents of the variable
      or register you want to change

   3. Type a value that is valid for the current representation of that
      variable or register

   4. Press Enter.

 Related Information

 Reference
 Values that Are Valid for the Current Representation


ΓòÉΓòÉΓòÉ 1.5.1.1. Use the Registers Monitor ΓòÉΓòÉΓòÉ

Here are some of the common tasks you can perform from the Registers monitor:

     Change the contents of registers

     Change what kinds of registers are displayed

     Change the window layout between horizontal and vertical


ΓòÉΓòÉΓòÉ 1.5.1.1.1. View the Contents of Registers ΓòÉΓòÉΓòÉ

If you want to open a monitor showing the contents of all or most processor
registers, do the following:

   1. Raise a Source window or the Session Control window

   2. Select Monitors->Registers or click on the  pushbutton.

   3. A Registers Monitor displays the contents of processor registers for the
      current thread.

 Related Information

 Procedures
 Add Expressions and Variables to a Monitor
 Change the Contents of Registers
 Change Which Registers Are Displayed
 Use the Registers Monitor

 Concepts
 Introduction to the Registers Monitor


ΓòÉΓòÉΓòÉ 1.5.1.1.2. Change Which Registers Are Displayed ΓòÉΓòÉΓòÉ

You can choose what groups of registers are displayed in the Registers monitor
by selecting Options->Display style. In the dialog that appears, select what
items you want to display.

Related Information

Concepts
Introduction to the Registers Monitor

Procedures
Change the Contents of Registers
Change the Layout of the Registers Monitor
Display Floating-Point Register Contents
View the Contents of Registers

Reference
Registers Monitor Split Bars


ΓòÉΓòÉΓòÉ 1.5.1.1.2.1. Display Floating-Point Register Contents ΓòÉΓòÉΓòÉ

If you are debugging an Intel-based application and you step over a source line
containing floating-point arithmetic, you may find that the values of
floating-point registers in the Registers monitor are not displayed. Instead,
'Not used' appears beside each register. In fact, one or more of these
registers is being used during execution of the source line, but once you have
stepped over the source line, the register's contents have been written to a
variable and the register is no longer in use. If you want to step over a
floating-point statement and see a floating-point register's value before it is
written to the variable, do the following:

   1. Change from source view to mixed view (select View->Mixed).

   2. Locate the source line containing the floating-point instructions. Look
      for a disassembly instruction between this source line and the next that
      contains a floating-point store instruction (for example FSTP), and place
      a breakpoint on that line.

   3. Change back to source view.

   4. Now when you step over the source line containing the floating-point
      arithmetic, you must issue two Step Over commands for the line instead of
      one (because the first Step Over command stops at the breakpoint you set
      in the mixed view). After the second Step Over command, you should see
      the value of the floating point register as it was before it was stored.

 Related Information

 Procedures
 Change the Contents of Registers
 Change the Layout of the Registers Monitor
 Change Which Registers Are Displayed
 Use the Registers Monitor


ΓòÉΓòÉΓòÉ 1.5.1.1.3. Change the Contents of Registers ΓòÉΓòÉΓòÉ

Caution: Changing the contents of registers that affect program flow (for
example, registers used to manipulate the stack) can destabilize the program
you are debugging and may cause it to terminate abnormally.

You can change the contents of most registers in the Registers monitor as
follows:

   1. Either double-click on the current value of the register or move the
      cursor to that register and press Enter.

   2. Type in a new value, and press Enter.

 If updating of the register is allowed and your entry can be evaluated to a
 value the register supports, the register is updated.

 Note: On Intel platforms, you cannot change the contents of the CS (code
 segment) register, and you cannot enter values into floating-point registers
 when they display 'Not used' instead of a value.

  For flags, you can only enter values within the range supported by the flag,
 or expressions that evaluate within such a range. Flags usually only have two
 valid values: 0 and 1.

 Related Information

 Reference
 Valid Entries for Registers
 Expressions Supported


ΓòÉΓòÉΓòÉ 1.5.1.1.4. Change the Layout of the Registers Monitor ΓòÉΓòÉΓòÉ

The layout of the Registers monitor can be changed in a number of ways. You
can:

     Change the amount of space given to each group of registers using the
      Registers monitor split bars

     Change the following settings from the Options->Display style menu
      choice:

        -  Which groups of registers are displayed

        -  Whether register groups are displayed in columns or rows

        -  Whether group titles are displayed

        -  Whether split bar positions between groups are saved

 Related Information

 Procedures
 Change Which Registers Are Displayed

 Reference
 Registers Monitor Split Bars


ΓòÉΓòÉΓòÉ 1.5.2. Add Expressions and Variables to a Monitor ΓòÉΓòÉΓòÉ

From the Source window, you can add a variable or expression to a monitor, so
that you can keep track of how the variable's contents or the expression's
value changes during program execution. You can use any of the following
methods:

     Position the pointer over the variable, click mouse button 2 [note], and
      select the monitor you want from the popup menu.

     Highlight the variable or expression, then select Monitors->Monitor
      expression. A dialog opens containing the variable or expression; select
      a monitor from there.

     Select Monitors->Monitor expression. In the dialog, enter the variable or
      expression and choose a monitor.

     Double-click on a variable to add it to the Program monitor.

 Related Information

 Reference
 Expressions Supported


ΓòÉΓòÉΓòÉ 1.5.3. Open a New Storage Monitor ΓòÉΓòÉΓòÉ

You can bring up a new Storage monitor in a number of ways:

     Click on the  toolbar button from a Source window or the Session Control
      window.

     Select Monitors->Storage from a Source window or the Session Control
      window.

     Highlight an expression in a Source window, click mouse button 2 [note],
      and select Add to storage monitor from the popup menu.

     Select Monitors->Monitor expression from a Source window or the Session
      Control window, enter the expression you want to monitor, and select the
      Storage monitor radio button.

 A new storage monitor opens each time you do one of the above, even if you
 already opened another storage monitor for the same Source window, variable or
 expression.

 Related Information

 Procedures
 Open Other Debugger Windows
 Change the Storage Monitor Address Range


ΓòÉΓòÉΓòÉ 1.5.4. View Variables, Memory, Registers, and the Stack ΓòÉΓòÉΓòÉ

Follow one or more of the tasks below:

     Add a variable or expression to a monitor so you can view or change its
      contents

     View variable contents

     View storage contents

     View the contents of registers

     View the contents of the call stack


ΓòÉΓòÉΓòÉ 1.5.4.1. View Variable Contents ΓòÉΓòÉΓòÉ

To view the contents of a variable you have already added to a monitor, do the
following:

   1. Raise a window that contains a Windows menu (for example, a Source window
      or the Session Control window)

   2. Select the monitor you added the variable to from that Windows menu.

   3. If necessary, use the scroll bars or PageUp and PageDown keys to scroll
      the monitor until the variable is visible.

   4. If necessary, change the representation of the variable: select its
      contents, click on mouse button 2, and select Next representation from
      the popup menu.

 To view the contents of a variable you have not yet added to a monitor, add
 the variable to a monitor (see below).

 Related Information

 Procedures
 Add Expressions and Variables to a Monitor
 Debug Variable Contents and Memory


ΓòÉΓòÉΓòÉ 1.5.4.2. View a Location in Storage ΓòÉΓòÉΓòÉ

To view a particular location in storage (for example, the storage used by a
variable), either select Options->Monitor expression from the Storage monitor,
or open a new Storage monitor from a Source window or the Session Control
window, and specify an expression to monitor. See the Reference section below
for information on what types of expressions the debugger supports.

COBOL or PL/I: If a variable whose type is other than POINTER is specified, the
Storage monitor opens at the address of that variable. For variables of type
POINTER, the storage monitor opens at the address contained in the variable.

C++: To view the storage for a class object or a variable, specify the address
of the object or variable name by preceding the name with an ampersand (&).

Related Information

Reference
Expressions Supported

Procedures
Change the Contents of Storage, Variables, and Registers
Add Expressions and Variables to a Monitor
Change the Representation of Storage


ΓòÉΓòÉΓòÉ 1.5.4.2.1. Change the Storage Monitor Address Range ΓòÉΓòÉΓòÉ

You can change the address range you want displayed in a Storage monitor to a
specified address. Double-click on an entry in one of the address columns (for
example, the 'Flat' column), or move the cursor to that entry and press Enter;
then enter a new address. You can also scroll through the range using the
cursor keys (including Page Up and Page Down), or using the scrollbar.

If the debugger cannot determine the contents of storage at a particular
location, it displays the contents as a series of question marks (?). This can
occur when you display storage that your program does not own or when the
address range does not point to a valid storage area.

If you want to view the storage associated with a different variable, adding
that variable to a new Storage monitor is easier because the debugger
determines the variable's address in storage for you. You may want to close the
old Storage monitor first if its contents are no longer needed.

Related Information

Procedures
Add Expressions and Variables to a Monitor
Change the Contents of Storage, Variables, and Registers
Change the Representation of Storage
Open a New Storage Monitor
View a Location in Storage

Concepts
Introduction to the Storage Monitor


ΓòÉΓòÉΓòÉ 1.5.4.2.2. Change the Representation of Storage ΓòÉΓòÉΓòÉ

To change the representation of storage in the Storage monitor, do one of the
following:

     Select a representation from Options->Display style, OR

     Click on the appropriate display style toolbar button:   .

 The change in representation does not affect any other open storage monitors,
 only the one in which you make the change.

 Related Information

 Procedures
 Change the Contents of Storage, Variables, and Registers
 Change the Storage Monitor Address Range


ΓòÉΓòÉΓòÉ 1.5.5. Debug Heap Usage ΓòÉΓòÉΓòÉ

Note: You cannot debug heap usage when debugging COBOL or PL/I programs, or
when the DEBUG_LANG environment variable is set to COBOL or PL1.

If you suspect problems with heap usage in your program, you can pinpoint
likely causes of heap errors by following these steps:

   1. Compile your program with the /Tm option so that the debug versions of
      memory management functions are used.

   2. Run your program. Any errors detected by the debug memory management
      programs are written to standard error, with the source file and line
      number where the error was detected, and the source file and line number
      where the heap was last known to be uncorrupted. (You can also run your
      program within the debugger; in this case, the errors are shown in a
      popup window instead of on standard error.)

   3. To further isolate a heap corruption error, debug the program, set a
      breakpoint at the source file and line number where the heap was last
      known to be uncorrupted, and run the program.

   4. When execution stops at the breakpoint, enable the debugger's own heap
      checking functions by enabling Run->Check heap when stopping from a
      Source window or the Session Control window.

   5. Step through your code, or set frequent breakpoints and run it. Each time
      the debugger stops, it causes your application to call the heap checking
      functions. When heap corruption is detected, an error message displays in
      a popup menu.

   6. Each time you see a heap error message and are unable to pinpoint the
      exact location of the error, note the two line numbers provided, restart
      the program, set a breakpoint at the line where the heap was last found
      to be uncorrupted, and use step commands or breakpoints and the Run
      command to further narrow down the location of the error.

 Related Information

 Reference
 Heap Errors


ΓòÉΓòÉΓòÉ 1.6. Use the Call Stack Window ΓòÉΓòÉΓòÉ

You can display functions in the Call Stack window in two orders: the order in
which they were called, and the order in which they will return (in other
words, with the most recently called function on top or on the bottom). To
change the order, click on the Growth Direction button () or select Display
style and change the setting of the Growth direction group box.

To view the code for a function, position the pointer over the line for that
function, and do one of the following:

     Select the line and press Enter

     Double-click with mouse button 1

     Click mouse button 2 [note] and select View from the popup menu

 A Source window appears containing the source for the function. If this
 function is the current function, the current execution point is highlighted.
 Otherwise, the line that called the next innermost function on the call stack
 is highlighted.

 You can select what type of information is displayed in the Call Stack window
 by changing the display style. You can choose to display the function, source
 file, return address, and other information.

 Related Information

 Concepts
 Introduction to the Call Stack Window


ΓòÉΓòÉΓòÉ 1.6.1. View the Contents of the Call Stack ΓòÉΓòÉΓòÉ

You can view information for the active functions on a thread's stack. A
function is on the stack from the time it is called until after it returns.

To view stack information for functions, open or raise a Call Stack window in
one of the following ways:

     If a Call Stack monitor is already open, access it from the Windows menu
      of any debugger window that contains this menu.

     Select Monitors->Call stack from a Source or Session Control window, or
      press the Ctrl+K accelerator key, or click on the  toolbar button.

 Related Information

 Procedures
 Use the Call Stack Window

 Concepts
 Introduction to the Call Stack Window


ΓòÉΓòÉΓòÉ 1.7. Debug Logic and Program Flow ΓòÉΓòÉΓòÉ

To debug logic and program flow, you may need to perform the following
subtasks:

     Set, clear, enable, and disable breakpoints

     Step through, run, or halt a program

     Skip over sections of code using Jump to location commands

     View the contents of variables, memory, registers, and the stack.


ΓòÉΓòÉΓòÉ 1.7.1. Set, Clear, Enable, and Disable Breakpoints ΓòÉΓòÉΓòÉ

See the following subtasks:

     Set breakpoints

     Clear breakpoints

     Enable and disable breakpoints

     Modify breakpoint characteristics


ΓòÉΓòÉΓòÉ 1.7.1.1. Set Breakpoints ΓòÉΓòÉΓòÉ

You can set breakpoints from the following windows:

     Breakpoints List window

     Source window

     Session Control window (function breakpoints only)

 Related Information

 Procedures
 Set Multiple Breakpoints

 Concepts
 Types of Breakpoints
 Introduction to the Breakpoints List Window


ΓòÉΓòÉΓòÉ 1.7.1.1.1. Set a Line Breakpoint ΓòÉΓòÉΓòÉ

You can set a line breakpoint from a Source window or from the Breakpoints List
window.

There are three ways to set a line breakpoint from the Source window:

   1. Make sure the appropriate line is visible in the window (use the scroll
      bar or cursor keys to locate it), then double-click on the line number in
      the prefix area of the line.

   2. Type the line number in the source window. A Line number dialog opens up.
      The line number you entered is placed in the dialog entry field. Click on
      the the Breakpoint button.

   3. Select Breakpoints->Set line from the menu bar, and fill in appropriate
      fields in the resulting Line breakpoint dialog box as described below for
      the Breakpoints List window.

 To set a line breakpoint in a Breakpoints List window, do the following:

   1. Select Set->Line from the menu bar.

   2. In the resulting Line breakpoint dialog box, enter the line number and
      source file you want to place the breakpoint in.

   3. Enter other conditions for your breakpoint, such as the frequency, if you
      like.

 Related Information

 Procedures
 Set Breakpoints
 Set Breakpoints in the Breakpoints List Window
 Set and Clear Breakpoints from a Source Window

 Concepts
 Types of Breakpoints


ΓòÉΓòÉΓòÉ 1.7.1.1.2. Set Multiple Breakpoints ΓòÉΓòÉΓòÉ

You can set several breakpoints with the same optional parameters from a Type
Breakpoint dialog, where Type corresponds to the type of breakpoint (Line,
Function, Address, Storage change, Load occurrence). To do this, follow these
steps:

   1. From the breakpoint dialog, enter the information for the first
      breakpoint. Change any fields in the Optional Parameters section of the
      window, as desired.

   2. Click on Set. The settings are saved for the current breakpoint.

   3. For each additional breakpoint, enter only the changed information (for
      example, the new line number, new function name, new address), and again
      click on Set.

   4. After you have set the last breakpoint, click on Cancel to dismiss the
      dialog.

 Related Information

 Procedures
 Set Breakpoints


ΓòÉΓòÉΓòÉ 1.7.1.2. Delete Breakpoints ΓòÉΓòÉΓòÉ

To delete all breakpoints at once, select Edit->Delete all from the Breakpoints
List window. To delete individual breakpoints, position the pointer over the
desired breakpoint, click on mouse button 2, and select Delete.

When you delete a breakpoint, all information about it is lost. If you want to
temporarily deactivate a breakpoint and activate it later, you should disable
the breakpoint instead.

Related Information

Procedures
Enable and Disable Breakpoints


ΓòÉΓòÉΓòÉ 1.7.1.2.1. Delete All Breakpoints ΓòÉΓòÉΓòÉ

You can delete all breakpoints for your program from the Breakpoints List
window in three ways:

     Click on the  toolbar button

     Select Delete all from the Edit menu

     Position the pointer on a breakpoint in the list, click mouse button 2,
      and select Delete all from the popup menu.

 Once you have deleted all breakpoints, all information on them is lost. If you
 want to temporarily prevent all breakpoints from stopping execution, but you
 may need to activate them later, disable them instead, by selecting
 Edit->Disable all.

 Related Information

 Procedures
 Enable and Disable Breakpoints


ΓòÉΓòÉΓòÉ 1.7.1.3. Enable and Disable Breakpoints ΓòÉΓòÉΓòÉ

You can disable a breakpoint so that it does not stop execution, and then later
enable it again. The advantage of disabling a breakpoint instead of deleting it
is that it is easier to enable a breakpoint than to recreate it. The debugger
lets you:

     Enable breakpoints one at a time

     Disable breakpoints one at a time

     Enable all breakpoints at once

     Disable all breakpoints at once.

 Related Information

 Procedures
 Delete Breakpoints
 Modify Breakpoint Characteristics
 Set Breakpoints


ΓòÉΓòÉΓòÉ 1.7.1.4. Modify Breakpoint Characteristics ΓòÉΓòÉΓòÉ

You can change the following characteristics of a breakpoint:

     Which threads the breakpoint applies to

     How often the debugger should skip the breakpoint (the frequency)

     Whether to stop on the breakpoint only when a given expression is true

     Whether to defer the breakpoint (for use with DLLs)

 You can also change the Required parameters fields for a breakpoint, which
 amounts to deleting the existing breakpoint and setting a new one.

 To change a breakpoint's characteristics, select the breakpoint in the
 Breakpoints List window and choose Edit->Modify, or place your pointer over
 the breakpoint, click mouse button 2, and select Modify.

 A Type Breakpoint window opens, where Type corresponds to the type of
 breakpoint (Line, Function, Address, Storage change, Load occurrence), with
 the current settings for the breakpoint already placed in the window's fields.
 For information on individual fields within each window, see that window's
 help.

 Related Information

 Procedures
 Set a Deferred Breakpoint


ΓòÉΓòÉΓòÉ 1.7.2. Skip over Sections of Code ΓòÉΓòÉΓòÉ

You can change the current execution point in a debugging session to another
location in the current Source window, so that certain lines are executed
again, or are skipped over when they otherwise would not be. From within the
Source window containing the current execution point, do the following:

   1. Scroll to the line number you want to jump to, if it is not already
      visible.

   2. Issue the Jump to location command by doing one of the following:

          Click on the prefix area for the line, click mouse button 1, and
           select Jump to location from the popup menu

          Select the line, then select Run->Jump to location from the menu bar

          Select the line, then press the N key, which is the accelerator for
           the Jump to location command.

 Note that using Jump to location can cause unpredictable results if you jump
 outside the current function, jump over code that has side-effects (for
 example, calls to functions whose results are assigned to variables, or
 functions that change the contents of variables passed by reference), or jump
 into the middle of a block such as a for loop.


ΓòÉΓòÉΓòÉ 2. Concepts Help for Debugger ΓòÉΓòÉΓòÉ

 The Debugger Online Help is divided into four types of information:

     Procedures - how to perform a specific task or set of tasks

     Reference - technical information you may need to understand how to
      perform a task

     User Interface - context-sensitive help pages displayed when you press F1
      from within the debugger

     Concepts - overview information you may need to understand basic
      principles of debugging or components of the debugger interface

 Concepts help is organized hierarchically; see the following main topics:

     Main debugger windows

     Monitors

     Remote debugging


ΓòÉΓòÉΓòÉ 2.1. Main Debugger Windows ΓòÉΓòÉΓòÉ

You can get to help on the following debugger windows from here:

     Source Window

     Call Stack Window

     Breakpoint List Window

     Session Control Window

 See also the following main help pages:

     Dialogs

     Monitor Windows

     Other Help Topics


ΓòÉΓòÉΓòÉ 2.1.1. Introduction to the Source Window ΓòÉΓòÉΓòÉ

The Source window displays the source code for the program you are debugging.
If your program was compiled with debugging information, you have three choices
as to how to view it: by its source code, its disassembled machine code, or a
combination of the two.

You can either step through or run your program from the Source window. A step
command lets you step through your program, usually one line at a time. Step
commands are useful for monitoring logic flow, and for seeing how variables,
storage, registers, or the stack are affected by each line that you step
through. The Run command runs your program up to the next breakpoint, or until
an exception that is not handled occurs, or until the program ends.

Breakpoints are markers you place in your program to tell the debugger to stop
whenever execution reaches that point. For example, if a particular statement
in your program is causing problems, you could set a breakpoint on the line
containing the statement, then run your program. Execution stops at the
breakpoint, before the statement is executed, and you can check the contents of
variables, registers, storage, and the stack, then either step over the
statement to see how the problem arises, or jump over the statement to
temporarily circumvent the problem.

Related Information

Procedures
Run, Step Through, or Stop a Program
Set and Clear Breakpoints from a Source Window

Reference
When You Start Debugging
Problems Getting a Source or Mixed View
Prefix Area


ΓòÉΓòÉΓòÉ 2.1.1.1. Disassembly View ΓòÉΓòÉΓòÉ

In a disassembly view, the object code for an object used by your program is
disassembled into assembly language. For objects that were compiled with debug
information, you can switch between disassembly view and the other views
(source and mixed). For objects that were not compiled with debug information,
disassembly view is the only view available.

Related Information

Concepts
Source View
Mixed View


ΓòÉΓòÉΓòÉ 2.1.1.2. Mixed View ΓòÉΓòÉΓòÉ

A mixed view is a combination of a source view and a disassembly view. In this
view, the Source window displays each line of source code followed by the
resulting assembly language instructions. If the object file was made from
several source files, and Options->Window settings->Notebook is checked, the
mixed view is displayed in notebook format, with a tab for each source file
that is included in the object file.

Mixed views are available only for objects that were compiled with debug
information.

Related Information

Concepts
Source View
Disassembly View


ΓòÉΓòÉΓòÉ 2.1.1.3. Source View ΓòÉΓòÉΓòÉ

In a source view, the Source window displays the source code for an object file
within your program. If the object file was made from several source files, and
Options->Window settings->Notebook is checked, the source view is displayed in
notebook format, with a tab for each source file that is included in the object
file.

Source views are available only for components that were compiled with debug
information. For any file that can be viewed with a source view, all views
(source, disassembly, and mixed) are available.

Related Information

Concepts
Disassembly View
Mixed View


ΓòÉΓòÉΓòÉ 2.1.1.4. How Step Commands Work in Different Views ΓòÉΓòÉΓòÉ

In the Source window, the current view of your program affects how step
commands work. In a source view, they operate on the basis of lines of source
code (typically, one step per line of source code that contains executable
code). In a mixed view, the debugger treats source code lines as comments; in
both Mixed and Disassembly views, step commands operate on disassembly
instructions (typically, one step per line of disassembled code).

When you step from a function displayed in source view into a call to a
function that was compiled without debug information, the Source window for the
called function appears in disassembly view, and therefore step commands in
that window will operate on a disassembly-instruction basis.

Related Information

Reference
Stepping and Functions


ΓòÉΓòÉΓòÉ 2.1.2. Introduction to the Call Stack Window ΓòÉΓòÉΓòÉ

When one function calls another, information about the calling function is
placed on the stack for the executing thread. The debugger examines the stack
and the processor registers to determine all functions that have been called
for that thread, and lists these functions in the Call Stack window.

Each Call Stack window displays information for a single thread. The thread
number is indicated in the window title.

OS/2 debuggee only: The amount of free stack space remaining for the thread is
shown near the top of the window, in bytes.

Related Information

Procedures
Use the Call Stack Window


ΓòÉΓòÉΓòÉ 2.1.3. Introduction to the Breakpoints List Window ΓòÉΓòÉΓòÉ

Use the Breakpoints List window to view breakpoints for your program, change
their characteristics, delete them, or add new ones.

Related Information

Procedures
Set Breakpoints
Delete Breakpoints
Enable and Disable Breakpoints
Modify Breakpoint Characteristics
View Popup Choice

Reference
Breakpoints List Popup Menu


ΓòÉΓòÉΓòÉ 2.1.3.1. Types of Breakpoints ΓòÉΓòÉΓòÉ

The debugger supports the following types of breakpoints:

     Line breakpoints are triggered before the code at a particular line in a
      source file is executed.

     Function breakpoints are triggered when the function they apply to is
      reached.

     Address breakpoints are triggered before the disassembly instruction at a
      particular address is executed.

     Storage change breakpoints are triggered when the storage within a
      particular address range is written to. The range is typically a small
      power of 2 (for example, 4 bytes).

     Load occurrence breakpoints are triggered when a DLL is loaded into an
      application. This happens the first time a reference is made to a
      function within the DLL.

 Related Information

 Procedures
 Set Breakpoints


ΓòÉΓòÉΓòÉ 2.1.4. Introduction to the Session Control Window ΓòÉΓòÉΓòÉ

The Session Control window is the control window of the debugger, and is
displayed during the entire debugging session. It contains a status line that
indicates what the debugger is doing (for example, Ready).

The window is divided into two panes. The left pane, called the Threads pane,
shows the active threads for the program, while the right pane, called the
Components pane, shows the list of object files. You can resize these panes
with the mouse by dragging the split bar between them to the left or right.

Use the mouse or the cursor left and right keys to shift the focus between the
panes.

You can expand the items in these panes by clicking on the '+' to their left,
and you can collapse them by clicking on the '-'.

Related Information

Reference
Using the Threads Pane
Using the Components Pane


ΓòÉΓòÉΓòÉ 2.2. Monitors ΓòÉΓòÉΓòÉ

You can view help on the following debugger monitor windows:

     Registers Monitor

     Storage Monitor

     Monitor Expression Dialog

     Popup Monitor

     Private Monitor

     Program Monitor

     Local Variables Monitor

 Help is also available on the following monitor-related topics:

     Popup Menus for Private and Program Monitors

     Differences Between the Program and Private Monitors

 See also the following main help pages:

     Main Debugger Windows

     Dialogs

     Other Help Topics


ΓòÉΓòÉΓòÉ 2.2.1. Introduction to the Program Monitor ΓòÉΓòÉΓòÉ

You can monitor variables and expressions from Source windows in the Program
monitor. This monitor is not associated with any particular Source window, and
remains open until you close it directly or exit the debugger. Use it to
monitor global variables or variables you want to see at all times during your
debugging session.

You can open the Program monitor from a Source window by adding a variable or
expression to the program monitor.

From within the Program monitor, you can select one or more expressions or
variables, and access a popup menu to apply changes to them. For example, you
can delete an expression from the monitor, change its representation, or edit
its contents.

Expressions and variables that have a '+' on their left can be expanded, and
those with a '-' can be collapsed. Arrays and C++ class objects, for example,
are displayed by default in expanded format, with entries both for the array
and for elements within it. To collapse the list of elements, or to expand a
collapsed list, double-click on the '+' or '-', or place the cursor on that
line and press the Enter key.

C++ only: Pointers are displayed with a '>' on their left. You can change an
array or class object to pointer representation by dereferencing it. You can
display the value of the pointer, or the start of the memory it points to, by
choosing a different representation for it.

Related Information

Procedures
Add Expressions and Variables to a Monitor


ΓòÉΓòÉΓòÉ 2.2.2. Introduction to the Private Monitor ΓòÉΓòÉΓòÉ

You can monitor variables and expressions from a given Source window in a
Private monitor, which is associated with only that Source window. Private
monitors help you keep track of local variables and expressions in programs
with multiple compilation units. They are particularly useful in cases where
the number of variables or expressions is large, or where variables with the
same name appear in different compilation units.

You can open a Private monitor for a Source window by adding an expression or
variable to the Private monitor from that Source window.

From within a Private monitor, you can select one or more expressions or
variables, and access a popup menu to apply changes to them. For example, you
can delete an expression from the monitor, change its representation, or edit
its contents.

Expressions and variables that have a '+' on their left can be expanded, and
those with a '-' can be collapsed. Arrays and C++ class objects, for example,
are displayed by default in expanded format, with entries both for the array
and for elements within it. To collapse the list of elements, or to expand a
collapsed list, double-click on the '+' or '-', or place the cursor on that
line and press the Enter key.

C++ only: Pointers are displayed with a '>' on their left. You can change an
array or class object to pointer representation by dereferencing it. You can
display the value of the pointer, or the start of the memory it points to, by
choosing a different representation for it.

Related Information

Procedures
Add Expressions and Variables to a Monitor


ΓòÉΓòÉΓòÉ 2.2.3. Differences between Program and Private Monitors ΓòÉΓòÉΓòÉ

The Program and Private monitors are very similar, but have the following
differences:

     The Program monitor can be used to monitor all variables, while a Private
      monitor is associated with a single Source window.

     The Program monitor remains open at all times unless you close it or exit
      the debugger. A Private monitor closes whenever the Source window it is
      associated with closes, and is hidden whenever its Source window becomes
      inactive (for example, when a statement in that Source window returns
      control to code in another Source window).

     Because a Private monitor is associated with a specific Source window,
      whose focus is raised whenever you select the monitor, it does not have a
      Windows menu.

 Related Information

 Procedures
 Add Expressions and Variables to a Monitor
 Debug Variable Contents and Memory
 View Variable Contents


ΓòÉΓòÉΓòÉ 2.2.4. Introduction to the Local Variables Monitor ΓòÉΓòÉΓòÉ

Note: The Local Variables monitor is not available for debugging PL/I programs.

You can monitor variables within the current scope of a Source window from the
Local Variables monitor. This monitor is associated with a particular thread,
and closes automatically when that thread terminates. It is updated, after each
Step or Run command, to show what variables are currently in scope, and what
the contents of those variables are.

To open a Local Variables monitor for a given thread, highlight that thread in
the Threads pane of the Session Control window, or raise the Source window for
that thread; then choose Monitors->Local variables.

From within a Local Variables monitor, you can select one or more variables,
and access a popup menu to apply changes to them. For example, you can delete a
variable from the monitor, change its representation, or edit its contents.

Expressions and variables that have a '+' on their left can be expanded, and
those with a '-' can be collapsed. Arrays and C++ class objects, for example,
are displayed by default in expanded format, with entries both for the array
and for elements within it. To collapse the list of elements, or to expand a
collapsed list, double-click on the '+' or '-', or place the cursor on that
line and press the Enter key.

C++ only: Pointers are displayed with a '>' on their left. You can change an
array or class object to pointer representation by dereferencing it. You can
display the value of the pointer, or the start of the memory it points to, by
choosing a different representation for it.

Related Information

Reference
Private Monitor
Program Monitor
Popup Monitor


ΓòÉΓòÉΓòÉ 2.2.5. Introduction to the Registers Monitor ΓòÉΓòÉΓòÉ

The Registers monitor shows the contents of processor registers for a
particular thread in your program. If you are debugging multiple threads, you
can display a separate Registers monitor for each thread. Although all threads
share the same set of registers, the operating system saves the register
contents of each thread as the thread is suspended, and restores that thread's
processor contents when the thread resumes.

In the Registers monitor, floating-point registers are displayed either as
floating-point decimal numbers or as hexadecimal values. To change their
representation, go to the Source window or the Session Control window, select
Options->Debugger settings->Default data representation->System, and choose
Floating point or Hexadecimal.

If you are debugging an Intel-based application and you step over a source line
containing floating-point arithmetic, you may find that the values of
floating-point registers in the Registers monitor are not displayed. Instead,
'Not used' appears beside each register. See the help below for a solution.

Related Information

Procedures
Display Floating-Point Register Contents


ΓòÉΓòÉΓòÉ 2.2.6. Introduction to the Storage Monitor ΓòÉΓòÉΓòÉ

The Storage monitor lets you view and update the contents of storage areas used
by your program. You can do the following:

     Specify a variable, array, class object (C++ only), expression, or
      storage address to view. Note: You cannot monitor the storage represented
      by an expression when debugging PL/I programs.

     Change the address range to view

     Modify the contents of storage

     Change the representation the debugger uses to display storage, for
      example, from hexadecimal to floating-point

 You can open a new Storage monitor from a Source window or from the Session
 Control window.

 The title of each Storage monitor includes the variable name or address range
 whose contents the window displays, as well as the current representation for
 the window.

 Related Information

 Procedures
 View a Location in Storage
 Change the Storage Monitor Address Range
 Change the Contents of Storage, Variables, and Registers
 Change the Representation of Storage
 Open a New Storage Monitor


ΓòÉΓòÉΓòÉ 2.3. Expressions ΓòÉΓòÉΓòÉ

For information on what expressions you can enter in the Expression entry field
of the Monitor Expression dialog or the Monitor Expression in Storage dialog,
see the section on supported expressions for the language you are debugging:

     C++

     COBOL

     PL/I


ΓòÉΓòÉΓòÉ 2.4. Remote Debugging ΓòÉΓòÉΓòÉ

Remote debugging lets you debug programs that are running on one system, using
a VisualAge debugger running on another system.

Related Information

Procedures
Start the Debugger and the Remote Program

Reference
Why Use Remote Debugging
Supported Communications Protocols and Platforms


ΓòÉΓòÉΓòÉ 2.5. Stopping Thread ΓòÉΓòÉΓòÉ

A stopping thread is the thread that caused the program being debugged to stop.


ΓòÉΓòÉΓòÉ 2.6. Other Help Topics ΓòÉΓòÉΓòÉ

You can get to the following debugger help topics from here:

     Common Menu Choices

     Toolbar Buttons

     Expressions Supported

     Toolbar Short Cut Menu

     Postmortem Debugging

     Debug on Demand

     Environment Variables

     Search Order

     Child Process Debugging

     Debugging Threads

 See also the following main help pages:

     Main Debugger Windows

     Dialogs

     Monitor Windows

     Debugger Help Home Page


ΓòÉΓòÉΓòÉ 2.6.1. Record of Directories ΓòÉΓòÉΓòÉ

The record of directories is a cumulative list of all directories you have
entered in source path dialog boxes that opened when the debugger could not
locate a source file. This list is only cumulative for the duration of the
debugger session; when you exit the debugger, the list is not saved.

The debugger assumes that any directory in the record of directories may be on
either the debugger machine or the debuggee machine.


ΓòÉΓòÉΓòÉ 3. Reference Help for Debugger ΓòÉΓòÉΓòÉ

The Debugger Online Help is divided into four types of information:

     Procedures - how to perform a specific task or set of tasks

     Reference - technical information you may need to understand how to
      perform a task

     User Interface - context-sensitive help pages displayed when you press F1
      from within the debugger

     Concepts - overview information you may need to understand basic
      principles of debugging or components of the debugger interface

 Reference help is organized hierarchically; see the following main topics:

     When you start debugging

     Child process debugging

     Debugging threads

     Debug on demand

     Debugger options

     Compiler options and optimization

     Environment variables

     Expressions supported

     Problems Getting a Source or Mixed View

     Postmortem Debugging

     Supported Communications Protocols and Platforms

     Why Use Remote Debugging?


ΓòÉΓòÉΓòÉ 3.1. When You Start Debugging ΓòÉΓòÉΓòÉ

The first time you debug a program, the debugger raises the following windows:

     A Source window. This window contains the source code (or disassembly
      code, if the program was compiled without debug information) for the main
      function of your program.

     The Session Control window. Use this window to access other windows, to
      control the debugging of threads and functions, and to perform various
      debugger commands.

     When the program being debugged (the 'debuggee') is running locally on
      Windows and OS/2, the debugger also raises a Debug Application window,
      which is a text-mode window. This window is a text mode window, and is
      used for any console input and output your program may require. For
      programs using a graphical user interface (such as the User Interface
      classes of IBM OpenClass), the Debug Application window usually stays
      blank throughout the debugging session.

 The debugger behavior at startup depends upon the dominant language, as
 specified by the DEBUG_LANG environment variable.

 DEBUG_LANG=CPP The debugger runs up to the start of main. If you checked the
           Debug program initialization check box on the Startup dialog, the
           debugger starts at the first line of disassembly code in your
           program. Use this check box when you want to debug initialization
           code such as the constructors for class objects declared at global
           scope.

 DEBUG_LANG=COBOL or PL1 or PLI The debugger runs up to the first debuggable
           statement in the application. If no part of the application was
           compiled and linked with debug information, then the debugger does
           not stop the application (unless the application generates an
           exception), and a message box is displayed containing the text:
           'Program has run to completion. Executed code was not compiled with
           debugging information.'

 As you step through or run your program, the debugger may raise additional
 Source windows for other object files that are executed. If you exit the
 debugger, then debug the same program later, these other windows appear on
 reload, provided you saved program profile information.

 When you start debugging a program for the first time, no breakpoints are set
 and  no variables or expressions are being monitored. During the debug
 session, you may set breakpoints, or add variables or expressions to a local
 variables monitor. When you exit the debugger, breakpoints, local variables
 and expressions are saved in the program profile, and will be activated the
 next time you debug this program.


ΓòÉΓòÉΓòÉ 3.1.1. Stepping and Functions ΓòÉΓòÉΓòÉ

In a source code line that contains multiple calls, you can choose to step over
all the calls, or step through the calls individually. Given a complex C++ call
such as func1( func2(), func3() );, you can do the following:

     Step over the entire line with a single Step Over command.

     Step through each called function with a series of  Step Into commands.
      You can then step through the function, or, to return to the original
      statement so that you can step into the next function, issue a Step
      Return command.

     Step into each called function for which debug information is available,
      with a series of Step Debug commands. Each time you use Step Debug to
      step into such a function, you can then step through the function, or
      issue a Step Return command to return to the original statement.

 You can also use a combination of step commands and function breakpoints to
 more finely control which functions called from a given line are stepped into
 and which are stepped over.

 Related Information

 Procedures
 Set and Clear Breakpoints from a Source Window


ΓòÉΓòÉΓòÉ 3.1.2. C++ Compiler Options ΓòÉΓòÉΓòÉ

Compile your C++ programs with the  /Ti+ option (to generate debugging
information) if you want to be able to debug your program at the source code
statement level. You should also consider using the following options:

 Option    Purpose

 /Tm+      Enable debug memory management support. Use this option if you want
           to do heap debugging (using the Storage monitor and Check heap when
           stopping).

 /O-       Compiles your program with optimization off. This is the default.
           (Some optimizations reorder the execution sequence of your program,
           while others may eliminate expressions whose result is never used.
           You may find it confusing to debug a program compiled with
           optimization, because statements may execute in a nonsequential
           fashion or not at all.)

 /Oi-      Compiles your program with inlining off. This is the default.

 /DEbug    Use this option with the ilink command when linking objects that
           were compiled with debug information but are being separately
           linked. When you specify the /Ti+ option for a source file, the
           compiler passes the /DE linker option to the linker automatically.

 Related Information

 Procedures
 Invoke the Debugger
 Debug Heap Usage


ΓòÉΓòÉΓòÉ 3.1.3. COBOL Compiler Options on Intel Platforms ΓòÉΓòÉΓòÉ

Compile your programs with the -g option (to generate debugging information) if
you want to be able to debug your program at the source code statement level.
Specifying the -g option with cob2 causes the program to be compiled with the
TEST option and linked with the /DEBUG option, both of which are necessary for
debugging. Note that the TEST and OPTIMIZE compiler options are mutually
exclusive; if you use both, OPTIMIZE will be ignored.


ΓòÉΓòÉΓòÉ 3.1.4. Intel Options for PL/I Programs ΓòÉΓòÉΓòÉ

To use the debugger to debug a PL/I program, you must compile and link your
program with the following options:

 TEST      Compiles your program to produce an object file that includes line
           number and other information, in addition to the source code.

 /DEbug    Links your program to produce an executable file that includes line
           number information and a symbol table, in addition to the executable
           code.

 The following two compile-time options are recommended when you are using the
 debugger to debug PL/I programs, but are not required:

 NOOPTimize Debugging is easier if you compile your program with optimization
           off. NOOPT is the default.

 DEFAULT(NOINLINE) Compiles your program with inlining turned off. NOINLINE is
           the default.

 Related Information

 Procedures
 Invoke the Debugger


ΓòÉΓòÉΓòÉ 3.2. Debugging Threads ΓòÉΓòÉΓòÉ

 Note: The sections on debugging threads are intended primarily for users with
limited knowledge of developing multithreaded programs, in particular, those
whose programming experience is mainly with single-threaded environments such
as Windows 3.1.

Multithreaded programs may behave differently in the debugger than they do when
run normally. Because debugger features such as single-stepping and certain
kinds of breakpoints involve processing overhead, running a multithreaded
program within the debugger may affect the timing of thread switches. If you
are experiencing problems, you can use the Threads pane of the Session Control
window to enable or disable threads so that you can debug problems related to
thread timing.

The main problems you are likely to encounter in debugging multithreaded
programs are timing and deadlock problems. You should not assume that a timing
or deadlock problem that seems only to occur when your program is running
within the debugger will never occur outside of the debugger. It is far more
likely that the processing overhead of the debugger is merely increasing the
frequency with which coding problems lead to deadlocks or thread timing errors.

The following sections describe issues relating to debugging multithreaded
programs, and contain suggestions for ensuring that your multithreaded programs
are threadsafe both during debugging and in production use:

     Deadlocks and Timing Problems

     Windowing System Lockups

     Critical sections

     Race Conditions

     Threads and Source Language Statements

     Threads and C++ Class Members

     Threads and Load Occurrence Breakpoints

     Must Complete Sections

     OS/2 Thread-Related APIs


ΓòÉΓòÉΓòÉ 3.2.1. Deadlocks and Timing Problems ΓòÉΓòÉΓòÉ

Thread deadlocks can occur in a multithreaded program running inside the
debugger, even though they never seem to occur when the program runs outside
the debugger. Consider a program with two threads running, in which the threads
both request two mutex semaphores but in different orders:

THREAD 1                                  THREAD 2
Lots of code                              A bit of code, then request semaphore Y
Request semaphore X                       Request semaphore X
Lots of Code                              Release semaphores Y and X
Requests semaphore Y
Some code
Release sempahores X and Y

These two threads may deadlock. However, because the operating system may
timeslice your program and the threads within it in an unpredictable fashion,
such deadlocks may not become obvious until you try to debug the program. In
the example, you may find that when run outside the debugger, Thread 2 can
request and release both semaphores before Thread 1 has even finished its large
initial code section; both semaphores may already be released by Thread 2 by
the time they are requested by Thread 1. However, within the debugger, if you
are setting breakpoints, stepping through code, or otherwise slowing down one
thread compared to another, you may wind up finding the requests for the
semaphores clashing and thereby blocking each other. For example, if you step
through Thread 2, its short initial code section may take longer to execute
than the long initial code section of Thread 1:

Thread 1: Lots of code
     Thread 2: A bit of code,
,
     .
,
     .
Thread 1: Lots of code completes
     Thread 2: A bit of code completes
Thread 1: Request semaphore X (okay)
     Thread 2: Request semaphore Y (okay)
Thread 1: Lots of code, then request semaphore Y (waits)
     Thread 2: Request semaphore X (deadlock)

Because each thread is requesting a semaphore owned by the other thread, the
two threads lock up.

To avoid this kind of lockup, always request a group of semaphores in the same
order from every thread that uses them. It is also a good idea to release them
in the reverse order from the request order. For example:

THREAD 1                 THREAD 2
Lots of code             A bit of code
Request semaphore X      Request semaphore X (waits)
Lots of code             (still waiting)
Request semaphore Y      (still waiting)
Release semaphore Y      (still waiting)
Release semaphore X      (obtains semaphore X)
                         Request semaphore Y (okay)
...                      ...

Regardless of which thread completes first, there is no deadlock because
whichever thread requests X last will be forced to wait until X is freed, and X
will not be freed until the other thread no longer requires either semaphore.

The debugger may expose semaphore-related deadlocks that do not normally occur,
because of the following factors:

     When you step through a thread or run to a breakpoint within that thread,
      you inevitably affect the point at which thread swapping occurs

     The debugger inevitably intrudes on both the operating system and the
      debuggee application. The debugger needs to be informed of thread
      starting and stopping, exceptions, module loads, and so on, and its mere
      presence affects the dynamics of the operating system.

 Related Information

 Reference
 Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.2. Windowing System Lockups ΓòÉΓòÉΓòÉ

Multithreaded programs have a greater tendency than single-thread programs to
cause your windowing system to lock up, because of such problems as semaphore
deadlocks and live threads waiting for results from threads that have
inadvertently died. When the debugging of a multithreaded program hangs your
windowing system, you have no way of continuing to debug the faulty program,
because the debugger uses the windowing system as well.

To solve such problems, you can use the debugger's remote debug feature.
Install the debugger on both machines, start a remote debug server session on
the machine you want to run the program on, and run the debugger from the other
machine. If your program hangs the windowing system on its own machine (the
remote machine), you can still step through it because the windowing system on
your local machine is still operational. See Remote Debugging for further
information.

Related Information

Concepts
Remote Debugging

Reference
Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.3. Critical Sections ΓòÉΓòÉΓòÉ

The OS/2 and Windows operating systems support the use of critical sections to
mark particular sections of code that should never be timesliced out within a
multithreaded application. The purpose of these critical sections is to prevent
problems such as loss of data integrity (where two threads are simultaneously
reading and then writing to the same variable or file). You should avoid using
critical sections except under very limited circumstances. Critical sections
can cause deadlocks and major timing problems, because:

     They block every thread within your application, other than the thread
      containing the critical section, from doing anything. This prevents an
      efficient distribution of system resources to all threads.

     If you call a function within a critical section (explicitly through a
      call, or implicitly by using the C++ new, delete, or user-defined
      operators for a variable of class type, such as an IString object) the
      called function may request a semaphore that is already locked. This
      thread then locks, but because it is declared as a critical section, the
      thread that owns the semaphore can never be timesliced back in to release
      the semaphore. For example:


            Thread 1               Thread 2
               |             +_______|
               new-+         |     start critical section
                   |         |       |
              request sem A  |     new-+
                   |         |         |
                   +_________+      request sem A
                   |                   |
              release sem A         release sem A
                   |                   |
               ____+                 +-+
                                    end critical section

      In this example, Thread 1 calls the new operator, which requests
      semaphore A. The operating system timeslices it out while it owns
      semaphore A. Thread 2 gets timesliced in, declares a critical section,
      and calls new, which requests the same semaphore A (this semaphore is an
      operating system semaphore used to prevent two threads from
      simultaneously allocating storage). Because semaphore A is already owned
      by thread 1, thread 2 waits for the semaphore indefinitely. Thread 1 can
      never be timesliced back in to release semaphore A, because thread 2 is
      in a critical section; and thread 2 can never exit its critical section,
      because it is frozen waiting for semaphore A.

 Semaphores and critical sections provide some of the same functionality, but
 using only semaphores is a better programming practice and leads to more
 threadsafe programs. Avoid the use of critical sections in your programs
 wherever possible.

 Related Information

 Reference
 Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.4. Race Conditions ΓòÉΓòÉΓòÉ

 Note: The examples below assume the program in question was written in C++.

A race condition can occur in a multithreaded program when you do not use
semaphores. A race condition is a situation where two threads are 'racing'
towards use of the same variable or some other data structure. For example,
suppose Thread 1 contains the statement i=foo(i); and Thread 2 contains the
statement a=b=i;. If you do not use a semaphore to block one thread,
timeslicing could, in theory, result in either of the following sequences of
events, among others:

Sequence 1:
Thread 2: Load value of i into register
Thread 1: Load value of i into register
Thread 2: Store value of i in register to b
Thread 1: Call foo(i) using value of i in register
Thread 2: Store value of i in register to a
Thread 1: Store result of foo(i) to i
Sequence 2:
Thread 1: Load value of i into register
Thread 1: Call foo(i) using value of i in register
Thread 1: Store result of foo(i) to i
Thread 2: Load value of i into register
Thread 2: Store value of i in register to b
Thread 2: Store value of i in register to a

If i is an integer with a value of 3 before the sequences begin, and foo(x) is
an integer function that returns 3*x+1, the variables at the end of sequence 1
will be: a=1, b=1, i=10; the variables at the end of sequence 2 will be: a=10,
b=10, i=10.

A race condition can occur even when you do use semaphores. In such a case, it
may be an indication of incorrect program logic. Suppose, for example, that two
threads both assign a value to a variable, and that a third thread reads the
value of that variable:

Thread 1:         Thread 2:         Thread 3:
i=3;              i=4;              j=i;

Even if you request a semaphore before each assignment to i in threads 1 and 2,
and release the semaphore after the assignment, there is no way of predicting
whether j will be assigned the value 3 or 4 (or even the value of i before
Threads 1 and 2 assigned to it). In this example, the race condition is simply
poor programming logic.

You may want to use a race condition to determine which of two or more threads
completed a given task first. For example, if the statement in Thread 3 was:

if (i==3) cout << 'Thread 1 completed first' << endl;
else cout << 'Thread 2 completed first' << endl;

and you had protected each assignment to i with a semaphore, the statement in
Thread 3 would be reliable.

Remember to use semaphores not only on pointers to objects, but on the objects
themselves. If two pointers point to the same object and you only use
semaphores to lock the pointers, two different threads using different pointers
can access the same object simultaneously.

You can use a Storage change breakpoint to find race conditions such as those
shown above. By placing a Storage change breakpoint on the address of a
variable, you can find all statements that change the variable and make note of
the order in which different threads change it.

Race conditions are another example of a timing problem that may only occur
when you are debugging your program, because the debugger may affect the order
in which threads are accessing shared data.

Related Information

Reference
Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.5. Threads and Source Language Statements ΓòÉΓòÉΓòÉ

Note: The programming statements in this section assume the program in question
was written in C++.

Do not assume that a single source-language statement cannot be interrupted in
mid-statement by another thread. The statement: i++; might involve three
machine language instructions: loading a variable from storage into a register
(if it is not already in a register); incrementing the register contents; and
storing the result back to memory. If i is a double, or a pointer to struct,
for example, the increment itself may be broken up into several machine
language instructions. The thread may be interrupted at any instruction's
completion point by another thread that also uses or changes the same variable,
if you have not used a semaphore to lock during the increment.

Even if the assembly listing for a simple statement is a single instruction,
you should avoid relying on this fact to provide data integrity. An increment
of an integer variable requires a load, increment, and store; the load may have
occurred on an earlier use of the variable within the same thread, and the
store may occur some time later after another use of the variable. Thus the
increment statement may only have a single instruction associated with it in
the assembly listing, but another thread's modifying of that variable between
the load and increment, or the increment and store, affects the data integrity
of the variable.

Related Information

Reference
Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.6. Threads and C++ Class Members ΓòÉΓòÉΓòÉ

If you use the same C++ class in two different threads, you may have thread
problems such as the following:

     If the class contains static variables, you may have re-entrancy
      problems.

     If you are using the same instance from two separate threads, the
      instance may be accessed by both threads at once, resulting in a loss of
      data integrity.

 In both cases you need re-entrancy protection. For example, use a semaphore
 whenever you access the static variables or the common class instance.

 Related Information

 Reference
 Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.7. Threads and Load Occurrence Breakpoints ΓòÉΓòÉΓòÉ

If you set a load occurrence breakpoint for a DLL that has not been loaded, you
may find that, in a multithreaded program, the DLL never triggers the
breakpoint, even though it must have been loaded by a call to a function within
it. The usual cause of a load occurrence breakpoint not triggering is that you
associated the breakpoint with a particular thread.

To avoid this problem, choose 'every' to have the load occurrence breakpoint
trigger regardless of which thread first calls a function within it. The
debugger tells you which thread triggered the load.

C++ only: For all breakpoint types, you can specify a breakpoint at the same
location but with different conditions for different threads. For example, you
can set a breakpoint that is triggered in thread 1 when the variable a has the
value 3, and a breakpoint at the same location triggered in thread 2 when the
variable a has the value 4. Conditions on thread-specific breakpoints can be
useful for determining whether you have thread data integrity problems.

Related Information

Reference
Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.8. Must Complete Sections ΓòÉΓòÉΓòÉ

Note: This section applies only to C++ programs, it does not apply to COBOL or
PL/I programs.

In a program with static initialization and destruction, if you exit main() (or
call exit() from any other thread) before all threads have finished running,
those threads are killed, and static objects may not be properly released.
After all threads are destroyed, the static objects are destroyed; if the
destructors for these objects require a semaphore (for example, if the objects
are constructed with new), then the destructors hang while waiting for the
semaphore to be freed (it never is, because it has a status of 'Owner died')
The application itself then stays up (and does nothing) indefinitely. In OS/2
you can use DosEnterMustComplete() at the start of a thread and
DosExitMustComplete() at the end of it to prevent DosKill from killing your
thread before you have destructed objects.

Related Information

Reference
Debugging Threads


ΓòÉΓòÉΓòÉ 3.2.9. OS/2 Thread-Related APIs ΓòÉΓòÉΓòÉ

Avoid using the following OS/2 API's in multithreaded programs:

     DosSuspendThread: Do not suspend a thread that owns a semaphore, or you
      will prevent any thread needing that semaphore from continuing.

     DosKillThread: Do not kill a thread that owns a semaphore, or the
      semaphore will go into an error state 'Owner died'.

 In both cases you should notify the thread you want to kill or suspend, and
 have that thread do the killing or suspending itself after it has done any
 necessary cleanup.

 When you are using semaphores, always check the return code for
 DosGetSemaphore to make sure the owner hasn't died, or you may lock a thread
 waiting for a semaphore that will never be freed.

 Related Information

 Reference
 Debugging Threads


ΓòÉΓòÉΓòÉ 3.3. Child Process Debugging ΓòÉΓòÉΓòÉ

You can only debug child processes of a program running on OS/2.

See the following subtopics:

     Child Process Debugging on OS/2


ΓòÉΓòÉΓòÉ 3.3.1. Child Process Debugging on OS/2 ΓòÉΓòÉΓòÉ

In OS/2 programs that create child processes, you can debug either a child
process or the parent process, but not both. If you want to debug a child
process, you must specify this in the Startup dialog, which is displayed when
you invoke the debugger without parameters (simply type idbug at the command
shell) or when you choose File->Startup from the Session Control window or a
Source window.


ΓòÉΓòÉΓòÉ 3.4. Debugger Options ΓòÉΓòÉΓòÉ

The debugger supports the following options. These options should be specified
after the idbug command, but before the name of the program you want to debug.
For example, to debug the program myprog.exe using the /p- option, use the
following command line:

idbug /p- myprog.exe

 Option    Purpose

 /a process_id Attach to the already running process process_id. Note that you
           cannot attach to an already running process on OS/2.

 /c child_process_id Start debugging the specified child process of the program
           being debugged. This option only applies to debuggee programs
           running on OS/2, and is ignored on other platforms.

 /h or /?  Display help for the idbug command.

 /i        Start the debugger in the system initialization code that precedes
           the call to the main entry point for the program. (C++ only): This
           can be useful if you need to debug the constructors for static class
           objects.

 /p+       Use program profile information (this is the default). If the
           debugger has saved a profile containing information on window,
           breakpoint, and monitor settings from a previous debug session for
           this program, the profile is used to restore those settings.

 /p-       Do not use program profile information. The debugger ignores any
           program profile information, and opens the debugger in a default
           appearance with no breakpoints set and only the Session Control
           window and one Source window.

 Related Information

 Procedures
 Attach to a Process


ΓòÉΓòÉΓòÉ 3.4.1. Compiler Options and Optimization ΓòÉΓòÉΓòÉ

See the following topics for more information:

     C++ Compiler Options

     COBOL Compiler Options on Intel Platforms

     Debugging optimized code


ΓòÉΓòÉΓòÉ 3.5. Environment Variables ΓòÉΓòÉΓòÉ

The debugger uses the following environment variables. If you want to place
multiple entries in any of the variables that contain path names, separate the
entries with a semicolon.

     DEBUG_CASESENSITIVE

     DEBUG_LANG

     DEBUG_LOCAL_PATH

     DEBUG_NUMBEROFELEMENTS

     DEBUG_OVERRIDE

     DEBUG_PATH

     DEBUG_REMOTE_SEARCH_PATH

     DEBUG_TAB

     DEBUG_TABGRID

     DPATH

     INCLUDE

     LIBPATH (OS/2 only)

     HELP

     PATH

     SYSLIB

    

 Related Information

 Procedures
 Set Environment Variables for the Debugger


ΓòÉΓòÉΓòÉ 3.5.1. DEBUG_CASESENSITIVE Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_CASESENSITIVE environment variable, if set to a non-null value (for
example, 'yes', 1, 'true', etc.) tells the debugger to compare part names and
module names on a case sensitive basis. By default the debugger converts all
names to uppercase for comparison purposes. Note that this does not affect
filesystem accesses, which are case-insensitive regardless of the setting of
DEBUG_CASESENSITIVE.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.2. DEBUG_LANG Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_LANG environment variable sets the dominant language for a debugging
session. The setting of DEBUG_LANG determines the display style for windows,
dialogs, and menus throughout the debugging session, regardless of what the
current language is. For example, if DEBUG_LANG=COBOL and you step into a C++
function, the debugger's appearance continues to reflect a dominant language of
COBOL. If DEBUG_LANG is not set, the default language is C++. Available choices
are:

 CPP       The dominant language is C++.

 COBOL     The dominant language is COBOL. The VisualAge for COBOL product sets
           DEBUG_LANG to COBOL at installation.

 PL1 or PLI The dominant language is PL/I. The VisualAge for PL/I product sets
           DEBUG_LANG to PL1 at installation.

 The following aspects of debugger behavior are affected by the setting of
 DEBUG_LANG:

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  ΓöéValue of          ΓöéCPP               ΓöéPL1               ΓöéCOBOL             Γöé
  ΓöéDEBUG_LANG        Γöé                  Γöé                  Γöé                  Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé'Entry' vs.       ΓöéThe term          ΓöéThe term 'entry'  ΓöéThe term 'entry'  Γöé
  Γöé'Function' used inΓöé'function' is usedΓöéis used.          Γöéis used.          Γöé
  Γöédialogs and       Γöé                  Γöé                  Γöé                  Γöé
  Γöéwindows to        Γöé                  Γöé                  Γöé                  Γöé
  Γöéindicate a C++    Γöé                  Γöé                  Γöé                  Γöé
  Γöéfunction or a     Γöé                  Γöé                  Γöé                  Γöé
  ΓöéCOBOL or PL/I     Γöé                  Γöé                  Γöé                  Γöé
  Γöéentry point       Γöé                  Γöé                  Γöé                  Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéHeap checking     ΓöéYou can perform   ΓöéHeap checking is  ΓöéHeap checking is  Γöé
  Γöé                  Γöéheap checks using Γöénot available.    Γöénot available.    Γöé
  Γöé                  ΓöéRun->Check heap   Γöé                  Γöé                  Γöé
  Γöé                  Γöéwhen stopping     Γöé                  Γöé                  Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  ΓöéStartup           ΓöéStartup runs to   ΓöéStartup runs untilΓöéStartup runs untilΓöé
  Γöé                  Γöéthe first         Γöéthe first         Γöéthe first         Γöé
  Γöé                  Γöéstatement in main Γöédebuggable        Γöédebuggable        Γöé
  Γöé                  Γöéafter program     Γöéstatement in the  Γöéstatement in the  Γöé
  Γöé                  Γöéinitialization,   Γöéapplication.      Γöéapplication.      Γöé
  Γöé                  Γöéunless you chose  Γöé                  Γöé                  Γöé
  Γöé                  Γöéto debug program  Γöé                  Γöé                  Γöé
  Γöé                  Γöéinitialization.   Γöé                  Γöé                  Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

     Debugger settings, such as default fonts, changed when one dominant
      language is in effect are not applied to the debugger when the other
      dominant language is in effect

     Step commands in a source view may behave differently in certain
      situations.

 Related Information

 Reference
 Environment Variables


ΓòÉΓòÉΓòÉ 3.5.3. DEBUG_NUMBEROFELEMENTS Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_NUMBEROFELEMENTS environment variable can be set to an integer value,
to tell the debugger the maximum number of elements to display for an array,
structure, or object in a Program, Private, Local Variables, or Popup monitor.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.4. DEBUG_PATH Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_PATH environment variable is used to locate debug source files that
are not stored in the same path as the executable being debugged. For example,
if your debug binary is stored in F:\BUILDS\SANDDUNE\TEST but your source code
is stored in F:\SOURCE and F:\SOURCE\INCLUDE, you should set your DEBUG_PATH
variable as follows:

set DEBUG_PATH=F:\SOURCE;F:\SOURCE\INCLUDE

You can set the DEBUG_PATH environment variable on both client and server
systems.

The search order used to search for source files depends on the settings of
other environment variables as well.


ΓòÉΓòÉΓòÉ 3.5.5. DEBUG_LOCAL_PATH Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_LOCAL_PATH environment variable is used to locate executables and
DLLs on the debuggee machine. This environment variable is supported on Windows
95 and Windows NT only. For OS/2, LIBPATH and PATH provide equivalent
functionality.

Related Information

Reference
Environment Variables
Search Order


ΓòÉΓòÉΓòÉ 3.5.6. DEBUG_OVERRIDE Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_OVERRIDE environment variable takes precedence over DEBUG_PATH. If
you set your DEBUG_PATH variable in your system settings, but you want to
temporarily add another path that takes precedence over DEBUG_PATH, set
DEBUG_OVERRIDE. To restore DEBUG_PATH as the path used to locate executables
and DLLs, clear DEBUG_OVERRIDE, for example by using:

set DEBUG_OVERRIDE=

Related Information

Reference
DEBUG_PATH Environment Variable
Search Order
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.7. DEBUG_REMOTE_SEARCH_PATH Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_REMOTE_SEARCH_PATH environment variable is used to search specified
paths on the remote host for a requested source file.

Related Information

Reference
Environment Variables
Search Order


ΓòÉΓòÉΓòÉ 3.5.8. DEBUG_TAB Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_TAB environment variable affects how the debugger expands tab
characters in a source or mixed view within a Source window, when DEBUG_TABGRID
is set to 0 (or is not set). The value for this variable is an integer,
indicating the number of spaces to convert a tab character into.Unlike
DEBUG_TABGRID, DEBUG_TAB does not cause the debugger to place tabbed
information in specific columns; it simply results in each tab in the displayed
files being converted to the indicated number of spaces.

Related Information

Reference
DEBUG_TABGRID Environment Variable


ΓòÉΓòÉΓòÉ 3.5.9. DEBUG_TABGRID Environment Variable ΓòÉΓòÉΓòÉ

The DEBUG_TABGRID environment variable affects how the debugger uses tab
characters to align tabs to columns in a source or mixed view within a Source
window. The value of this variable is an integer indicating the starting
position and frequency of the tab. For example, if you set DEBUG_TABGRID=6, the
debugger sets tab stops at 6, 12, 18, 24, and so on. If DEBUG_TABGRID is set to
a nonzero value, the setting of DEBUG_TAB has no effect.

Related Information

Reference
Environment Variables
DEBUG_TAB Environment Variable


ΓòÉΓòÉΓòÉ 3.5.10. INCLUDE Environment Variable ΓòÉΓòÉΓòÉ

The INCLUDE environment variable is used by both the compiler and the debugger.
It specifies the path the compiler and debugger use to locate C++ include files
(files included in your source code with the #include directive.)

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.11. LIBPATH Environment Variable (OS/2 Only) ΓòÉΓòÉΓòÉ

The LIBPATH environment variable tells the debugger where to look for debugger
DLLs on the workstation. The LIBPATH environment variable must be set from
within CONFIG.SYS; you cannot set it using the SET command.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.12. SYSLIB Environment Variable ΓòÉΓòÉΓòÉ

The SYSLIB environment variable is used to locate COBOL copyfiles and PL/I
include files. It has the same effect, for COBOL or PL/I programs, as the
INCLUDE environment variable has for C++ programs.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.13. Other Environment Variables ΓòÉΓòÉΓòÉ

The debugger also uses the following standard environment variables on the
Windows or OS/2 workstation. These variables all contain one or more directory
names separated by semicolons:

PATH

The PATH environment variable is used to locate the debugger executable  and
the executable programs to be debugged, as well as any other executables being
run on the workstation. On Windows platforms the PATH environment variable is
also used to locate DLLs.

DPATH

The DPATH environment variable is used to locate message files, which the
debugger needs to display messages and the text of menus and dialogs.

HELP

The HELP environment variable is used to locate the online help files for the
debugger.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.5.14. Search Order ΓòÉΓòÉΓòÉ

The debugger uses a different search order for finding source files, depending
on whether you are debugging locally or remotely. It searches through each
location in the lists below until it finds a file that matches the requested
name.

Local debugging: The debugger searches for source files in:

   1. The executable directory

   2. The current directory

   3. The record of directories

   4. Paths in the DEBUG_PATH environment variable

 Remote debugging: The debugger searches for source files in the above
 directories on the debuggee machine, then in:

   1. The current directory of the debugger machine

   2. The record of directories on the debugger machine

   3. Paths in the DEBUG_PATH environment variable on the debugger machine

 If the source file cannot be located in any of the above directories, a dialog
 box opens requesting the path name for the source file. The path name you
 enter is searched for, first on the debuggee machine, then on the debugger
 machine. This path name is also added to the record of directories to be used
 in future searches.

 Related Information

 Concepts
 Record of Directories


ΓòÉΓòÉΓòÉ 3.6. Expressions Supported ΓòÉΓòÉΓòÉ

The expressions you can enter in an expression entry field (for example, in a
Monitor Expression dialog or a Set breakpoint dialog) are different for each
language the debugger supports. See the following for more information:

     Supported C++ expressions

     Supported COBOL expressions

     Supported PL/I expressions

 Related Information

 Concepts
 Expressions


ΓòÉΓòÉΓòÉ 3.6.1. COBOL Expressions Supported ΓòÉΓòÉΓòÉ

You can enter the following types of COBOL expressions in an expression entry
field:

Variable: A variable used in your program. The following can be specified with
COBOL variables:

     Group qualification (for example, A OF B OF C)

     Table subscripting (for example, A(1, 2, 3)) Note that only constants can
      be specified for array indices (no variables or operators).

     Reference modification (for example, A(1:2)) Note that reference
      modification is not allowed for group names. Also, only constants can be
      specified for the reference modification begin and length values (no
      variables or operators).

 Notes

   1. COBOL condition names cannot be specified.

   2. Operators (for example, A + B) are not allowed.

   3. The value displayed for COBOL index names and data items is the actual
      value in storage. For example, if INM is an index name for a
      one-dimensional table whose elements are two bytes wide and INM is set to
      reference the third element in the table, the value shown by the debugger
      (i.e., the value in storage) would be 4.

 Constant: The constant can be one of the following types:

     Fixed or floating-point constant

     A string constant, enclosed in double or single quotation marks (for
      example, 'string' or 'string')

     Hexadecimal constant (for example, X'0041014D'). Note that the number of
      bytes represented by the hexadecimal constant must be equal to the number
      of bytes of the corresponding variable in assignment or comparison.

 Note: In a COBOL constant, the period is always used as the decimal point
 (i.e., the DECIMAL-POINT IS COMMA clause is ignored by the debugger). COBOL
 figurative constants are not supported by the debugger.

 Register: Any of the processor registers that can be displayed in the
 Registers Monitor. In the case of conflicting names, program variable names
 take precedence over register names.

 Expressions Supported in Conditional Breakpoints

 Expressions supported by the expression conditions in conditional breakpoints
 are further limited in the following ways:

     Only the relation condition is supported, with the following operators:
      >, <, =, >=, <=, NOT >, NOT <, NOT =

     The left operand must be a variable and the right operand must be a
      constant. For example, var1 > 5 is valid, while 5 < var1 and var1 > var2
      are not.

     The hexadecimal constant is allowed only with POINTER variables.

     Nonnumeric and external floating point variables must be compared with a
      nonnumeric literal.

     Zoned decimal variables must be compared with a numeric constant.

     Complex conditions and group comparisons are not allowed.

     Comparison is locale-based, independent of any COLLSEQ compile option or
      collating sequence specification within the program.


ΓòÉΓòÉΓòÉ 3.6.2. C++ Expressions Supported ΓòÉΓòÉΓòÉ

The expression language that is supported by the debugger for C++ programs is a
subset of the C/C++ language. You can only monitor expressions with:

     A supported operand type

     A supported operator

     A supported typecasting operation


ΓòÉΓòÉΓòÉ 3.6.2.1. C++ Supported Data Types ΓòÉΓòÉΓòÉ

You can monitor an expression that uses the following typecasting operations
only:

     8-bit signed byte

     8-bit unsigned byte

     16-bit signed integer

     16-bit unsigned integer

     32-bit signed integer

     32-bit unsigned integer

     Single-precision floating-point floating-point

     Double-precision floating-point floating-point

     Pointers

     User-defined types

 These data types include int, short, char and so on.


ΓòÉΓòÉΓòÉ 3.6.2.2. C++ Supported Expression Operands ΓòÉΓòÉΓòÉ

You can monitor an expression that uses the following types of operands only:

 Operand   Definition

 Variable  A variable used in your program.

 Constant  The constant can be one of the following types:

               Fixed or floating-point constant within the ranges supported by
                the system the debuggee program is running on.

               A string constant, enclosed in double quotation marks (for
                example, 'mystring')

               A character constant, enclosed in single quote marks (for
                example, 'x')

 Register  Any of the processor registers that can be displayed in the
           Registers Monitor. In the case of conflicting names, program
           variable names take precedence over register names. For conversions
           that are done automatically when the registers display in mixed-mode
           expressions, general-purpose registers are treated as unsigned
           arithmetic items with a length appropriate to the register.For
           example, on Intel platforms EAX is 32-bits, AX is 16-bits, and AL is
           8-bits.

 If you monitor an enumerated variable, a comment appears to the right of the
 value. If the value of the variable matches one of the enumerated types, the
 comment contains the name of the first enumerated type that matches the value
 of the variable. If the length of the enumerated name does not fit in the
 monitor, the contents appear as an empty entry field.

 The comment (empty or not) lets you distinguish between a valid enumerated
 value and an invalid value. An invalid value does not have a comment to its
 right.

 You cannot update an enumerated variable by entering an enumerated type. You
 must enter a value or expression. If the value is a valid enumerated value,
 the comment to the right of it is updated.

 Bit fields are supported for C/C++ compiled code only. You can display and
 update bit fields, but you cannot use them in expressions. You cannot look at
 variables that have been defined using the #define preprocessor directive.


ΓòÉΓòÉΓòÉ 3.6.2.3. C++ Supported Expression Operators ΓòÉΓòÉΓòÉ

You can monitor an expression that uses the following operators only:

 Operator  Coded as

 Global scope resolution ::a

 Class or namespace scope resolution a::b

 Subscripting a[b]

 Member selection a.b or a->b

 Size      sizeof a or sizeof (type)

 Logical not !a

 Ones complement ~a

 Unary minus -a

 Unary plus +a

 Dereference *a

 Type cast (type) a

 Multiply  a * b

 Divide    a / b

 Modulo    a % b

 Add       a + b

 Subtract  a - b

 Left shift a << b

 Right shift a >> b

 Less than a < b

 Greater than a > b

 Less than or equal to a <= b

 Greater than or equal to a >= b

 Equal     a == b

 Not equal a != b

 Bitwise AND a & b

 Bitwise OR a | b

 Bitwise exclusive OR a ^ b

 Logical AND a && b

 Logical OR a || b


ΓòÉΓòÉΓòÉ 3.6.3. Supported PL/I Expressions ΓòÉΓòÉΓòÉ

The expression language that is supported by the debugger for PL/I programs is
a subset of the PL/I language. You can monitor only expressions with:

     A supported operand type

     A supported operator


ΓòÉΓòÉΓòÉ 3.6.3.1. Supported PL/I Operand Types ΓòÉΓòÉΓòÉ

You can monitor an expression that uses the following types of operands only:

 variable  A variable used in your program

 constant  The constant can be one of the following types:

     Fixed or floating point constant within the ranges supported by the
      debuggee processor

     A character constant, enclosed in single or double quotation marks

     A X (hex) character constant, enclosed in single or double quotation
      marks and followed immediately by the letter X

     A bit constant, enclosed in single or double quotation marks and followed
      immediately by the letter B

     A B4 (hex) bit constant, enclosed in single or double quotation marks and
      followed immediately by B4

     A graphic constant, enclosed in single or double quotation marks and
      followed immediately by the letter G

     A GX (hex) graphic constant, enclosed in single or double quotation marks
      and followed immediately by GX

 Builtin functions The debugger supports many PL/I builtin functions, as shown
           below. Functions are listed by category.

 Mathematical

  Acos            Gamma
  Asin            Log
  Atan            Loggamma
  Atand           Log10
  Atanh           Log2
  Cos             Sin
  Cosd            Sind
  Cosh            Sinh
  Cotan           Sqrt
  Cotand          Tan
  Erf             Tand
  Erfc            Tanh
  Exp

 Integer Manipulation

  Iand            Isll
  Ieor            Isrl
  Inot            Lower2
  Ior             Raise2

 String Handling

  Index           Searchr
  Length(1)       Tally
  Maxlength(1)    Verify
  Search          Verifyr

 Array handling

  Dimension  Lbound
  Hbound

 Miscellaneous

  Addr            Offsetsubtract
  Binaryvalue     Offsetvalue
  Hex             Pointer
  Heximage        Pointeradd
  Null            Pointerdiff
  Offset          Pointersubtract
  Offsetadd       Pointervalue
  Offsetdiff      Sysnull

 Note

 (1) Only for strings

 Only variables with supported storage classes can be accessed by the debugger.
 The following list indicates the storage classes that are supported:

  Automatic      Defined
  Based           Static
  Controlled      Parameter

 If based variables are used with REFER, only the variables up to the first
 REFER are known.

 A defined variable is supported if it is a character variable with constant
 position that is defined on a base variable w/o subscripts.

 The following are not supported by the debugger:

     Local variables option

     Variables declared within a package, but outside any contained level-1
      procedure

     Conditional entry breakpoints

     Program control data (except pointer and offset)

     String repetition factors

     User function references

     Type functions

 Related Information

 Reference
 Supported PL/I Operators


ΓòÉΓòÉΓòÉ 3.6.3.2. Supported PL/I Operators ΓòÉΓòÉΓòÉ

Arithmetic Operators

+  -  *  /

The plus sign and the minus sign can appear as prefix operators or as infix
operators. All other arithmetic operators can appear only as infix operators.

Bit Operators

╨║  &  |

The not/exclusive-or symbol (╨║) can be used as a prefix or infix operator. The
and (&) symbol and the or (|) symbol can be used as infix operators only.

Comparison Operators

<  ╨║<  <=  =  ╨║=  ╨║>  >=  >

The result of a comparison operation is always a bit string of length 1. The
value is '1'B if the relationship is true, or '0'B if the relationship is
false.

Concatenation Operators

||

Different types of operations can be combined within the same operational
expression. Any combination can be used.

See the PL/I Language Reference Manual for a complete description of expression
operators.

Related Information

Reference
Supported PL/I Operand Types


ΓòÉΓòÉΓòÉ 3.6.4. Values that Are Valid for the Current Representation ΓòÉΓòÉΓòÉ

When you are entering a value in an entry field such as a register in the
Registers monitor, a column of storage in the Storage monitor, or the contents
of a variable in another monitor, the debugger checks that the value you enter
is valid for the current representation of that column or entry field.

A value is valid for the current representation if it contains only the
characters used for that representation, and does not exceed the length of the
variable or register involved. For example, if you want to change the contents
of storage, and the Content style setting for a particular Storage monitor is
32-bit integer, the value you enter must be a valid 32-bit integer, not a
floating-point value or other value.Or, if you want to change the contents of a
character string and the current representation is as a text string, you must
enter a new string in double quotes, and the length of the string must not
exceed the declared array size.

Related Information

Reference
Expressions Supported

Procedures
Change the Contents of Storage, Variables, and Registers


ΓòÉΓòÉΓòÉ 3.6.5. Valid Addresses and Expressions ΓòÉΓòÉΓòÉ

Here are some examples of addresses or expressions you can enter in the Address
or expression field of the Set Storage Change dialog:

 MyVariable (C++) : The address pointed to by MyVariable, if such a variable
           exists in your program, and if its value is a valid storage address
           (for example, if the variable is a pointer to another variable or to
           an offset within an array).

 MyVariable (COBOL or PL/I) If MyVariable is of type POINTER, the contents of
           the variable are used as the address; for other variables, the
           address of the variable is used.

 &MyVariable (C++) The storage of the variable MyVariable.

 A1FCC     The hex address A1FCC, unless you have a variable declared as A1FCC,
           in which case it is treated the same as MyVariable above.

 0xA1FCC   The hex address A1FCC.

 RegisterName The name of a processor register on the system the debuggee
           program is running on. If the expression evaluates to a processor
           register, that register's contents are used in place of the register
           name.

 X'000A1FCC' (COBOL) The hex address A1FCC. Note that if you use this syntax,
           you must specify an even number of hex digits. For the above value
           you could specify 0xA1FCC or X'0A1FCC', but not X'A1FCC'.

 '000A1FCC'X (PL/I) The hex address A1FCC. Note that if you use this syntax,
           you must specify 8 hex digits. For the above value you could specify
           0xA1FCC or '000A1FCC'X, but not 'A1FCC'X'.

 Related Information

 Reference
 Expressions Supported


ΓòÉΓòÉΓòÉ 3.7. Problems Getting a Source or Mixed View ΓòÉΓòÉΓòÉ

If you are in the disassembly view of a section of code, you may find that you
cannot obtain a source or mixed view of your code (either through the View menu
or when you click on the Source View icon). There are several likely reasons
for such problems. Click on links in the list below for proposed solutions:

     The code you are debugging was not compiled with debug information,
      because the debugger is finding a different version of the executable
      than the one you compiled with debug information.

     The code you are debugging was not compiled with debug information,
      because it is not code you wrote, but code in a DLL or other object that
      your program uses.

     The code you are debugging was compiled with debug information, but the
      debugger cannot locate the source code. If you try to switch to a source
      or mixed view in this situation, a dialog opens so that you can enter the
      path of the source file. If you select Cancel, the view remains a
      disassembly view.

 Related Information

 Reference
 Debugger Is Using a Different Executable Version
 Debugger Cannot Find Source Code
 Debugger Cannot Find Source Code
 Environment Variables
 Source Views for Code You Did Not Write


ΓòÉΓòÉΓòÉ 3.7.1. Debugger Cannot Find Source Code ΓòÉΓòÉΓòÉ

In the Source window, you may not be able to obtain a source view of an object,
even though the code was compiled with debug information, if the debugger
cannot find the source files for it. When you start debugging such a program,
or when execution lands in a part of the program that was compiled with debug
information but the debugger cannot find the source code for it, the debugger
normally opens a Source Filename dialog in which you can enter the location and
name of the source file. If you choose Cancel when this dialog appears, the
debugger displays a disassembly view of the code, because it has no source code
to display. If the source file has been moved or renamed, select View->Change
text file, and enter the correct path and name in the Change text file dialog.
(The debugger searches the workstation for source files using a search path
based on environment variables, which you can set before starting your debug
session. If you anticipate frequently having your source files in a different
directory from your executables, you should set these environment variables.)

If you are debugging remotely, the debugger searches for the files in the path
you specify, first on the workstation where the program being debugged is
running, then on the workstation where the debugger user interface is running.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 3.7.2. Debugger Is Using a Different Executable Version ΓòÉΓòÉΓòÉ

In the Source window, you may not be able to obtain a source view of an object
if the debugger is finding a different version of the executable than the one
you created with debug information. Set the Show module path check box in the
Options->Window Settings->Display Style dialog of the Session Control window,
so that full pathnames are displayed in the components pane of the Session
Control window. Check that the modules listed are in the correct location. If
they are not, you can exit the debugger, remove or rename the executable or DLL
in the incorrect path so that the one in the correct path is accessed, and
start debugging again. (For example, if there is an obsolete version of your
executable in one directory, and an updated version in another, and the
obsolete directory's entry in PATH precedes that of the updated directory,
remove the executable from the obsolete directory.)

You can also specify an absolute path to the version you know was compiled with
debug information, when you invoke the debugger or in the Startup dialog. To
bring up the Startup dialog, choose File->Startup from within the Source or
Session Control window, or start the debugger with no parameters.


ΓòÉΓòÉΓòÉ 3.7.3. Source Views for Code You Did Not Write ΓòÉΓòÉΓòÉ

In the Source window, you may not be able to obtain a source view of an object
if the current code being executed is not part of your program. (For example,
you may have halted execution while in a DLL that does not contain debug
information.) Check the object name that appears at the top of the Source
window. If you do not recognize this name as an object of your own executable,
you are probably debugging system code used by, but not compiled with, your
program. If you have access to the source code for this object, you could
recompile it with debug information so that you can obtain a source view of it.


ΓòÉΓòÉΓòÉ 3.8. Supported Communications Protocols and Platforms ΓòÉΓòÉΓòÉ

The debugger supports the TCP/IP protocol to establish the communications link
between the debugger and a debuggee program running on different systems.


ΓòÉΓòÉΓòÉ 3.9. Heap Errors ΓòÉΓòÉΓòÉ

Note: You cannot debug heap usage when debugging COBOL or PL/I programs, or
when the DEBUG_LANG environment variable is set to COBOL or PL1.

Heap errors can occur when your code inadvertently overwrites control
information that the memory management functions use to control heap usage.
Each block of allocated storage within a heap consists of a data area, which
starts at the address returned by the allocating function, as well as a control
area adjacent to the data area, which is needed by the memory management
functions to free the storage properly when you deallocate the storage. If you
overwrite a control structure in the heap (for example, by writing to elements
outside the allocated bounds of an array, or by copying a string into too small
a block of allocated storage), the control information is corrupted and may
cause incorrect program behavior even if the data areas of other allocated
blocks are not overwritten.

You should consider the following points when you are trying to locate heap
errors:

Finding heap errors outside the debugger

To detect heap errors, you can compile your program to use the heap-checking
versions of memory management functions (use the /Tm option). When you run a
program compiled with this option, each call to a memory management function
causes a heap check to be performed on the default heap. This heap check
involves checking the control structures for each allocated block of storage
within the heap, and ensuring that none were overwritten. If an error is
encountered, the program terminates and information is written to standard
error including the address where heap corruption occurred, the source file and
line number at which a valid heap state was last detected, and the source file
and line number at which the memory error was detected.

Heap checking for default and other heaps

Heap checking is only enabled for the default heap used by each executable. If
the debug versions of the memory management functions do not report heap
corruption and you still suspect a problem, you may be using additional heaps
and corrupting them. You can debug usage of nondefault heaps by adding calls to
the _uheapchk C Library function to your source code. See your compiler
documentation for more information.

Pinpointing heap errors within the debugger

You can pinpoint the cause of a heap error from within the debugger, provided
the heap causing the error is known to be the default heap, by continually
narrowing down the gap between the last line at which the heap was valid, and
the first line at which corruption occurred. From within the Source window, use
a combination of run commands, step commands, line and function breakpoints,
and the Check heap when stopping setting on the Run menu, to narrow the scope
of your search.

Check heap when stopping may expose other coding errors

For semantically incorrect programs, Check heap when stopping is intrusive in
that it may cause different results where a program is incorrectly accessing
data on the stack. This is because Check heap when stopping causes the process
and thread being debugged to call a heap check function each time execution
stops, and this heap check function affects the safe area of the stack by
overwriting part of that area with its stack frame. For example, if a called
function returns the address of a local variable, that local variable's
contents will be accessible from the calling function, and will not change, as
long as the stack frame used by the called function is not overwritten by a
subsequent call. However, if you issue a Step return command from the called
function while Check heap when stopping is enabled, the heap checking function
is called immediately on return from the called function, and the storage
pointed to by the returned pointer may overwritten by the stack frame of the
heap checking function.

Check heap when stopping affects performance

Heap checking within the debugger has a high overhead cost for step commands,
because the heap is checked after each step. If you are stepping through large
sections of code, or frequently stopping at breakpoints, and you find debug
performance too slow, try turning on Check heap when stopping only in those
areas you suspect are causing heap errors.

Related Information

Procedures
Debug Heap Usage


ΓòÉΓòÉΓòÉ 3.9.1. Notes on Check Heap when Stopping ΓòÉΓòÉΓòÉ

Note: Heap checking is unavailable when the dominant language is COBOL or PL/I
(that is, when the environment variable DEBUG_LANG is set to COBOL or PL1).

     For the Check heap when stopping choice to work, you have to compile your
      application using the VisualAge for C++ /Tm+ compiler option.

     If you enable the Check heap when stopping choice and run your
      application to termination, and the application contains a heap error,
      the heap check is not made. To check the heap just before termination,
      set a breakpoint on the last line of your application.

     (OS/2 only): If you are debugging a multiple thread program and a thread
      stops while running in compiler memory management code that is holding a
      memory semaphore, the heap check will not be performed.

     (OS/2 only): If the stopping thread is running in 16-bit code, the heap
      check will not be performed.


ΓòÉΓòÉΓòÉ 3.10. Postmortem Debugging ΓòÉΓòÉΓòÉ

 Postmortem debugging is supported in the OS/2 environment through the ITRAPPER
program. It is not available on Windows.

Related Information

Reference
Postmortem Debugging on OS/2
Limitations During Postmortem Debugging
Postmortem Debugging Overview


ΓòÉΓòÉΓòÉ 3.10.1. Postmortem Debugging on OS/2 ΓòÉΓòÉΓòÉ

Note: Postmortem debugging is supported in the OS/2 environment through the
ITRAPPER program. It is not available on Windows.

Use the debugger's postmortem debugging capabilities to debug failing programs
that are already in production. Postmortem debugging is only useful when a
program fails by trapping or by throwing an OS/2 exception, and your
development site cannot easily reproduce the failure. When a trap or exception
occurs in a production version of your program, relevant information such as
process and thread IDs, register and memory contents, can be saved to a dump
file, and this dump file can then be sent to you for debugging.

Related Information

Procedures
Debug Dump Files
Obtain a Dump File

Reference
Postmortem Debugging Overview


ΓòÉΓòÉΓòÉ 3.10.2. Limitations During Postmortem Debugging ΓòÉΓòÉΓòÉ

Once you have started debugging a dump file, you can use a subset of debugger
features to examine registers, storage (if available), and code for the
executable that caused the trap. You can access only the following debugger
monitors:

     Registers monitor

     Storage monitor

     Call Stack monitor

     Local Variables monitor

 You cannot change the contents of items in these monitors (for example,
 registers in the registers monitor). Where the core file does not contain
 appropriate information, question marks or messages such as 'expression
 evaluation failed' may appear in place of data. For example, if stack
 information was not saved, local variable values may not be displayed, even
 though the names of those variables are.

 The following debugger commands are disabled, and icons for them are hidden or
 greyed out, when you are debugging a dump file:

     Run and stop commands

     Step commands

     Commands to set, clear, disable, enable, or delete breakpoints.


ΓòÉΓòÉΓòÉ 3.10.3. Postmortem Debugging Overview ΓòÉΓòÉΓòÉ

Note: This section applies only to OS/2 local debugging.

Postmortem debugging is intended to help you isolate the causes of
unanticipated traps or OS/2 exceptions, in programs that are already in
production or widespread use. The stages of the postmortem debugging process
are:

   1. You ship the ITRAPPER utility along with your application.

   2. After the end user has experienced a trap or unanticipated OS/2
      exception, or in anticipation of such a problem, they reload the
      application under ITRAPPER. This utility has no effect on the running
      application. However, if the application traps or throws an unhandled
      exception, ITRAPPER takes control and writes relevant information to a
      dump file, using compression algorithms to minimize the dump file size.
      If the failure causing the trap was an OS/2 exception, the program
      continues running. If the cause was a trap, the program terminates. A
      separate dump file is created for each exception or trap. The end user
      ships you the dump files created by ITRAPPER.

   3. You debug the dump file instead of a live object file. Because the dump
      file contains information about the state of the application at the time
      of the trap or exception, and is not a live object file, only a subset of
      debugger features are available. For example, you can view memory and
      register contents, but you cannot step or run the program or set
      breakpoints.


ΓòÉΓòÉΓòÉ 3.10.4. Start ITRAPPER ΓòÉΓòÉΓòÉ

Note: post-mortem debugging and the ITRAPPER program are only available on
OS/2.

Use the ITRAPPER utility to obtain a dump file when a program traps. If the
program has already trapped and was not started as a child process of the
ITRAPPER utility, you must restart the program under ITRAPPER and try to
duplicate the trap.

ITRAPPER is started with a simple command line interface:

[d:][path]ITRAPPER [/p parameter_file debuggee [debuggee_parameters]]

where:

 [d:][path] Is the path to the location of the ITRAPPER.EXE file, if this
           location is not in the user's PATH environment variable

 /p        is an optional parameter indicating that a trapper parameter file
           has been specified. (ITRAPPER also accepts /P, -p, or -P for this
           parameter.) The name of the parameter file follows.

 debuggee  is the program to be run under ITRAPPER

 debuggee_parameters are the normal parameters for the program to be run under
           ITRAPPER.

 Related Information

 Reference
 Trapper Parameter File


ΓòÉΓòÉΓòÉ 3.10.5. Trapper Parameter File ΓòÉΓòÉΓòÉ

Note: post-mortem debugging and the ITRAPPER program are only available on
OS/2.

You can specify an optional parameter file to control ITRAPPER behavior. This
file should be shipped with your product and the ITRAPPER.EXE utility. This
file is an ASCII file. Blank lines and comment lines (lines beginning with an
asterisk '*') are allowed. Parameter lines are of the form:

KEYWORD value

Keywords are not case-sensitive, and only the first three characters of a
keyword are necessary. Valid keywords are listed below. Click on a keyword for
information on its purpose and the arguments it takes:

     OnException | OffException

     OutputPath | Path

     DumpNumber | Number

     TraceChild

     UserExit

     LogFile


ΓòÉΓòÉΓòÉ 3.10.5.1. DumpNumber | Number ΓòÉΓòÉΓòÉ

 ITRAPPER keyword, values: DumpNumber | Number nn [WRAP|NOWRAP]

These two keywords are interchangeable and control the extensions of dump
files. These keywords take as arguments a number nn from 1 to 99, and an
optional WRAP or NOWRAP argument: The extension of each dump file will be the
character @ followed by a number between 1 and the value specified for nn. At
each new dump, ITRAPPER adds 1 to the number of the most recent dump, and dumps
to that file. If the number of the current dump is the same as the value nn.
ITRAPPER wraps back to 1, unless NOWRAP is set, in which case ITRAPPER does not
create a dump file.


ΓòÉΓòÉΓòÉ 3.10.5.2. LogFile ΓòÉΓòÉΓòÉ

ITRAPPER keyword, values: LogFile LOGFILE_NAME

Use the LogFile parameter to specify a log file, to which ITRAPPER will write
textual information at the start and end of each dump. By default, no log file
is created.


ΓòÉΓòÉΓòÉ 3.10.5.3. OnException | OffException ΓòÉΓòÉΓòÉ

ITRAPPER keyword, values: OnException | OffExceptionexception_list

These two keywords control which OS/2 exceptions will cause ITRAPPER to create
a dump file. See the exception list for the names of exceptions you can
specify, and their default ITRAPPER settings.


ΓòÉΓòÉΓòÉ 3.10.5.4. OutputPath | Path ΓòÉΓòÉΓòÉ

ITRAPPER keyword, values: OutputPath | Path logfilepath

These two keywords are interchangeable and control the path where the dump and
log files are to be placed. If this parameter is not specified, ITRAPPER checks
for a TMP environment variable and uses that directory if found. Otherwise it
uses the current directory.


ΓòÉΓòÉΓòÉ 3.10.5.5. TraceChild ΓòÉΓòÉΓòÉ

ITRAPPER keyword, values: TraceChild [ ON | OFF]

This parameter controls whether ITRAPPER can detect exceptions in the children
of the program being traced. By default this parameter is on, and all
descendant processes are monitored for exceptions. You only need to turn it off
if you are running ITRAPPER against a program that uses the DosDebug() API,
because ITRAPPER will cause such programs to malfunction if TraceChild is on.


ΓòÉΓòÉΓòÉ 3.10.5.6. UserExit ΓòÉΓòÉΓòÉ

ITRAPPER keyword, values: UserExit DLL_NAME

Use the UserExit parameter to specify a user exit DLL to be called at the start
and end of each dump. The DLL may export either or both of the functions listed
below. The functions are called by ordinal, and the actual function names are
irrelevant.

Ordinal 1:

void _System startdump(const char* exename, unsigned long PID);

This function, if you provide it, is called at the start of the process dump.
Use it to add additional process logging and control. The function parameters
are:

 exename   The fully qualified name of the executable that has trapped

 PID       The process ID of the executable that has trapped

 Ordinal 2:

  void _System enddump(unsigned long PID);

 This function, if you provide it, is called at the end of the process dump.
 Use it to add additional process logging and control. The function parameter,
 PID, is the process ID of the executable that has trapped.


ΓòÉΓòÉΓòÉ 3.11. Debug on Demand ΓòÉΓòÉΓòÉ

Note: Debug on Demand is available only on Windows NT and Windows 95, and only
for local debugging. It is not available for debugging PL/I programs.

Debug on Demand enables you to open a debugging session whenever an unhandled
exception or other unrecoverable error occurs in your application. The debugger
starts and attaches to your application at the point of fault. This can save
you time for two reasons: you do not have to recreate errors, and your
application can run at full speed without interference from the debugger until
the exception is encountered.

Debug on demand can be started for any application that fails while it is
running, even if the application does not contain debug information. VisualAge
for COBOL can start debug on demand for any failing application that was
started with the TRAP(OFF) runtime option (see the COBOL Programming Guide for
more information). With debug on demand, you can even find and fix a problem in
your application and let the application continue running.

To enable this feature, type the following at a command shell:

idod path_name

where path_name is the path where the debugger is installed, for example
e:\ibmcobw\bin.

To disable Debug on demand, type the following at a command shell:

idod /u


ΓòÉΓòÉΓòÉ 3.12. Why Use Remote Debugging ΓòÉΓòÉΓòÉ

You might want to use remote debugging for the following reasons:

     The program you are debugging is running on another user's system, and is
      behaving differently on that system than on your own. You can use the
      remote debug feature to debug this program on the other system, from your
      system. The user on the system running that program interacts with the
      program as usual (except where breakpoints or step commands introduce
      delays). You interact with the debugger, but not with the I/O of the
      program being debugged.

     It is easier to debug an application that uses graphics or has a GUI when
      you keep the debugger user interface separate from the application's GUI.
      Your interaction (or another user's interaction) with the application
      occurs on the remote system, while your interaction with the debugger
      occurs on the local system.

     The program you are debugging was compiled for a platform that the
      debugger user interface does not run on. You can use the remote debug
      feature to take advantage of the debugger user interface while debugging
      the remote application

 Related Information

 Procedures
 Start the Debugger and the Remote Program

 Concepts
 Remote Debugging


ΓòÉΓòÉΓòÉ 3.13. Single and Multiple Session Debugging ΓòÉΓòÉΓòÉ

The remote debug driver for workstation-to-workstation debugging (irmtdbg) runs
on the remote workstation, and waits for requests from a debugger user
interface on another workstation to start an application for debugging. irmtdbg
executes in single session mode by default. In this mode, when you close the
debugger (for example, by pressing F3), the remote debug driver will also exit.

In multiple session mode, when you close the debugger, the remote debug driver
does not terminate; instead, it re-initializes itself and waits for a new
connection. If you use this mode, you must terminate the remote debug driver
from the remote machine. For example, on OS/2 and Windows, terminate the
driver's process or use Ctrl-C or Ctrl-Break.


ΓòÉΓòÉΓòÉ 3.14. More Information on Recursion ΓòÉΓòÉΓòÉ

Recursion does not have to involve a function calling itself directly; for
example: func1 calls func2 calls func3 calls func1. After the call to func3,
each time you step into one of these functions, the entry for that call shows a
recursion count one higher than the previous entry for that call.

You can use the recursion value to detect unintentionally recursive calls.

The debugger can keep track of all calls, whether they are done using a
function or pointer to function, or, for C++, a virtual function.


ΓòÉΓòÉΓòÉ 3.15. Valid Entries for Registers ΓòÉΓòÉΓòÉ

If the value you enter consists entirely of valid hexadecimal characters, it is
treated as a hexadecimal value unless it is also the name of a variable that is
currently in scope. For example, suppose you have a variable feedbeef, and you
enter 'feedbeef' as a register value. If the variablefeedbeef can be
represented as a hex value, that hex value is used. Otherwise, the debugger
uses the hex value 'feedbeef'. To force the debugger to use a hex value rather
than the contents of a variable, precede the hex value with '0x' (for example,
'0xfeedbeef').  In COBOL, you can also use 'X'feedbeef''.In PL/I, you can also
use ''feedbeef'X'.

For C++, you can also enter a segmented address, or an expression. Numbers used
in the expression are treated as decimal unless explicitly preceded with '0x'.

Related Information

Reference
Expressions Supported


ΓòÉΓòÉΓòÉ 3.16. Registers Monitor Split Bars ΓòÉΓòÉΓòÉ

You can change the amount of space given to each group of registers in the
Registers monitor, as follows:

   1. Place the pointer on the split bar (a division between two panes of the
      window). The pointer's shape changes to an icon with two arrows.

   2. Click and hold mouse button 1.

   3. Drag the mouse up or down (for register groups displayed in rows) or left
      or right (for register groups displayed in columns) until you reach the
      desired size for the pane.

   4. Release the mouse button.

 To save the position of the split bars, select Options->Display style and
 click on the Save Split Bar Positions check box.


ΓòÉΓòÉΓòÉ 3.17. Notes on Debugging Optimized Code ΓòÉΓòÉΓòÉ

When you debug optimized code, information in debugger panes may lead you to
suspect logic problems that do not actually exist. You should bear in mind the
points below.

Values in some monitors may not be current

Do not rely on monitors such as the Local Variables or Popup monitors to show
the current values of variables. Numeric and char values may be kept in
processor registers, as may pointers to other types of variables such as
strings and class objects. In the optimized program, these values and pointers
are not always written out to memory; in some cases, they may be discarded
because they are not needed.

Static and external variables are not always current

Static or external variables can be monitored at function entry and exit
points. Within an optimized function, their values may be optimized out of
existence.

Register and Storage monitors are always current

The register and storage monitors are correct. Unlike monitors that show actual
variables, such as the Local Variables or Popup monitors, the Register and
Storage Monitors are always up-to-date as of the last time execution stopped.

Source statements may be optimized away

Use the disassembly view of your program to see whether source statements whose
result you were relying on have been optimized away (via dead code elimination,
where code that performs no useful work is removed). You may find, for example,
that an assignment to a variable in your source code does not result in any
disassembly code being produced; this may indicate that the variable's value is
never used after the assignment.

Related Information

Procedures
Debug Optimized Code


ΓòÉΓòÉΓòÉ 3.18. Limitations when Debugging Visual C++ Programs ΓòÉΓòÉΓòÉ

Note: This section applies only to programs being debugged on Windows 95 or
Windows NT.

You can debug C and C++ programs compiled with the Microsoft Visual C++
compiler, provided you have compiled and linked your program with the
appropriate options. The following limitations apply when debugging such
programs:

Enumerated types: Enumeration member name information for enumerated types in C
programs compiled with Visual C++ is not shown in monitors that display
variable contents, such as the Local Variables monitor. This information is
available for C++ programs, however. The following shows a code fragment with
enumerated types, and the values displayed in the Local Variables monitor of
the debugger:

typedef enum { One=1, Two, Three} TypeX;
TypeX a=One;
TypeX b=Two;
TypeX c=Three;

If the program is compiled as a C program with Visual C++:

a: 1
b: 2
c: 3

If the program is compiled as a C or C++ program with VisualAge C++, or a C++
program with Visual C++

a: 1 /* One */
b: 2 /* Two */
c: 3 /* Three */

Constants: A statement such as const int i = 42; in a Visual C++ program does
not generate any debug information for the variable i. Therefore the debugger
does not display any value for it. The IBM Visual Age C++ compiler does
generate information for this symbol.

Namespaces: You cannot debug Visual C++ namespaces because the Visual C++
compiler does not generate the necessary debug information for namespaces in
the executable.

Related Information

Procedures
Debug a Microsoft Visual C++ Program


ΓòÉΓòÉΓòÉ 3.19. When to Use the Process List Dialog ΓòÉΓòÉΓòÉ

Note: The Process List dialog, menu choice, and pushbutton are only available
on platforms that support process debugging (Windows 95, Windows NT).

If you close the debugger after attaching to a process on Windows NT, the
process terminates.

You can use the Process List dialog to attach the debugger to an already
running program where an error or failure has occurred. There are two main
reasons for attaching the debugger to an already running process:

     You anticipate a problem at a particular point in your program, and you
      do not want to step through the program or set breakpoints. In this
      situation, you can run your program, and at a program pause shortly
      before the anticipated failure (for example, while the program is waiting
      for keyboard input), you attach to the process. You can then provide the
      input, and debug from that point on.

     You are developing or maintaining a program that hangs sporadically, and
      you want to find out why it is hanging. In this situation, you can attach
      the debugger to the hung process, and look for infinite loops or other
      problems that might be causing your program to hang.

 On Windows NT and Windows 95, you can also use the Debug on Demand feature to
 invoke the debugger when an application running on your system throws an
 exception that is not handled.

 On OS/2 (local debugging only), you can also use postmortem debugging to debug
 a dump file containing information on the state of an application when it
 trapped.

 Related Information

 Reference
 Debug on Demand
 Postmortem Debugging on OS/2


ΓòÉΓòÉΓòÉ 3.20. Call Statement Example for COBOL ΓòÉΓòÉΓòÉ

Given the following::

.
.
.
PROGRAM-ID. MAINPRG.
.
.
.
CALL 'PROG1'.
.
.
.

If you step into PROG1 and display the Call Stack window, the call statement
shown for MAINPRG is the line number where PROG1 was called. The entry with the
highest entry number in the Call Stack window has no Call Statement value
because it has not itself called any routine.


ΓòÉΓòÉΓòÉ 3.21. Call Statement Example for C++ ΓòÉΓòÉΓòÉ

Given the following source code:

void func1() {/* ... */}
void main() {
  func1();
}

If you step into func1 and display the Call Stack window, the call statement
shown for main is the line number where func1 was called from. The function
with the highest entry number in the Call Stack window has no Call Statement
entry because it has not itself called any function.


ΓòÉΓòÉΓòÉ 3.22. Jump to Location -- COBOL Example ΓòÉΓòÉΓòÉ

In the example below, assume that line 61 is the current line and that you
selected line 62. If you issue a Jump to Location command and then a Step Into
command, line 65 will become the current line. However, if you issue a Run to
Location command instead of the Jump to Location command, line 63 will become
the current line.

59           MOVE 13 TO VAR2.
60           MOVE 12 TO VAR1.
61           MOVE 12 TO VAR2.
62           IF VAR1 = VAR2 THEN
63               CALL 'PROG1'
64           ELSE
65               CALL 'PROG2'
66           END-IF.


ΓòÉΓòÉΓòÉ 3.23. Jump to Location -- C++ Example ΓòÉΓòÉΓòÉ

In the example below, if you have stepped over the assignment to var2, and you
select the if line and issue a Jump to Location command followed by two Step
Into commands, execution stops at the first line of func2 instead of func1:

//...
var1=11;
var2=12;  // just stepped over this statement
var1=12;
if (var1==var2) func1();
else func2();


ΓòÉΓòÉΓòÉ 3.24. Jump to Location -- PL/I Example ΓòÉΓòÉΓòÉ

In the example below, assume that line 61 is the current line and that you
selected line 62. If you issue a Jump to Location command and then a Step Into
command, line 65 will become the current line. However, if you issue a Run to
Location command instead, line 63 will become the current line.

59 VAR2 = 13;
60 VAR1 = 12;
61 VAR2 = 12;
62 IF VAR1 = VAR2 THEN
63 CALL PROG1;
64 ELSE
65 CALL PROG2;


ΓòÉΓòÉΓòÉ 4. User Interface Help for Debugger ΓòÉΓòÉΓòÉ

 The Debugger Online Help is divided into four types of information:

     Procedures - how to perform a specific task or set of tasks

     Reference - technical information you may need to understand how to
      perform a task

     User Interface - context-sensitive help pages displayed when you press F1
      from within the debugger

     Concepts - overview information you may need to understand basic
      principles of debugging or components of the debugger interface

 The main topics for User Interface help are listed below:

     Source window

     Call Stack monitor

     Registers monitor

     Storage monitor

     Breakpoint List window

     Session Control window

     Popup Monitor

     Private Monitor

     Program Monitor

     Popup Menu for Private and Program Monitors

     Local Variables Monitor

     Dialogs

     Toolbar Buttons, Shortcut Keys, and Common Menu Items


ΓòÉΓòÉΓòÉ 4.1. Source Window ΓòÉΓòÉΓòÉ

The Source window displays the source code for the program you are debugging.
You can perform most debugger actions from the Source window. For more details
see:

     Introduction to the Source window

     How to use the Source window

     Menus, buttons, shortcut keys


ΓòÉΓòÉΓòÉ 4.1.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Source window provides the following menu bar menus, popup menus, toolbar
buttons, and shortcut keys:

     Menu bar menus:

        -  File

        -  View

        -  Breakpoints

        -  Monitors

        -  Run

        -  Options

        -  Windows

        -  Help

        -  Project

     Prefix area popup menu and code area popup menu

     Toolbar buttons:       Project button

     Shortcut keys:

        -  [Ctrl+B->Session Control]

        -  [Ctrl+E->Registers]

        -  [Ctrl+G->Storage]

        -  [Ctrl+K->Call Stack]

        -  [Ctrl+R->Run]

        -  [Ctrl+V-> Local variables]

        -  [Ctrl+X-> Breakpoint list]


ΓòÉΓòÉΓòÉ 4.1.1.1. File Menu ΓòÉΓòÉΓòÉ

Use the File menu of the Source window to open a new source file, find a
function or the current execution point, switch to debugging a different
program or process, or exit the debugger. The File menu contains the following
choices:

     Open New Source

     Find Function

     Where is Execution Point -- [Ctrl+P]

     Startup

     Process List

     Close Debugger -- [F3]


ΓòÉΓòÉΓòÉ 4.1.1.2. View Menu ΓòÉΓòÉΓòÉ

Use the View menu of the Source window to locate a text string, scroll through
the view, switch to a different view, or view a different source file. The View
menu contains the following choices:

     Find -- [Ctrl+F]

     Find Next -- [Ctrl+N]

     Scroll to Line Number

     Select Include (not available for COBOL)

     Change Text File

     Source

     Disassembly

     Mixed


ΓòÉΓòÉΓòÉ 4.1.1.2.1. Find ΓòÉΓòÉΓòÉ

Select View->Find or press Ctrl+F to locate a string of text in the Source
Window. Enter the string in the Find dialog. The debugger searches forward from
the current highlighted word or line to the end of the file, then wraps to the
beginning and searches up to the highlighted word or line. If the string is
found, it is highlighted. Otherwise the message Text not found is displayed.

If you want to search for only exact case matches to the search string, click
on the Case sensitive check box.

Once you have entered a string in the Find dialog, you can repeat the find
operation by selecting View->Find Next or by pressing Ctrl+N.


ΓòÉΓòÉΓòÉ 4.1.1.2.2. Find Next ΓòÉΓòÉΓòÉ

Select View->Find Next or press Ctrl+N to find the next string that matches the
search string you specified using View->Find or Ctrl+F.

If you have not yet specified a string to search for, this choice is not
available.


ΓòÉΓòÉΓòÉ 4.1.1.2.3. Scroll to Line Number ΓòÉΓòÉΓòÉ

Select View->Scroll to Line Number to move to another line in the source file.
This action only affects what you see; it does not change what line will be
executed next.

A dialog opens where you enter a line number to scroll to. You can then either
click on OK to scroll to that line, or you can select Breakpoint if you want to
set a breakpoint at the line number.

Once you have scrolled to a line number, you can select Run to locationor Jump
to location to runor jump to that line.

You can also open the Scroll to Line Number dialog by typing a line number
directly from within the Source window. The dialog opens and the number you
typed is placed in the line number entry field.

Scroll to Line Number is accessible only from the source view of a Source
window.


ΓòÉΓòÉΓòÉ 4.1.1.2.4. Select Include ΓòÉΓòÉΓòÉ

Select View->Select Include to display a list of the source files included in
your program. You can select a file from this list to view. You can also access
these files from the notebook tabs in the Source window (unless you have
disabled the Source as Notebook check box in the Source window options).


ΓòÉΓòÉΓòÉ 4.1.1.2.5. Change Text File ΓòÉΓòÉΓòÉ

Select View->Change text file to view a different source file. Sometimes the
debugger locates the wrong source file for your program. Change Text File lets
you specify the correct source file and directory  for the source file.

In the dialog that appears, enter the path and name of the source file you
want, or select File List to navigate through your directories and choose a
file from that list.

Note: Change Text File does not open a new Source window or change the
executable being debugged. If you enter the wrong source file, you may still be
able to set breakpoints, issue step commands, and see the debugger moving the
current line. However, the debugger's behavior is related to the current object
file, not to the current source file, and so this behavior may seem out of sync
with the source file. If you want to debug a different object file within the
same program, do not use this menu item; select File->Open New Source instead.
To stop debugging one program and start debugging another, choose
File->Startup.


ΓòÉΓòÉΓòÉ 4.1.1.2.6. Source ΓòÉΓòÉΓòÉ

Select View->Source to switch to a source view of the current object. In this
view, the object is displayed in notebook format, with a tab for each source
included by the current object, unless you have disabled the notebook format
from Options->Window settings.

Related Information

Concepts
Source View


ΓòÉΓòÉΓòÉ 4.1.1.2.7. Disassembly ΓòÉΓòÉΓòÉ

Select View->Disassembly to switch to a disassembly view of the current object.
In this view, the disassembly code appears without reference to what source
file the code originated in.

Related Information

Concepts
Disassembly View


ΓòÉΓòÉΓòÉ 4.1.1.2.8. Mixed ΓòÉΓòÉΓòÉ

Select View->Mixed to switch to a mixed view of the current object. In this
view, the object is display in notebook format, with a tab for each source file
included by the current object.

Related Information

Concepts
Mixed View


ΓòÉΓòÉΓòÉ 4.1.1.3. Breakpoints Menu ΓòÉΓòÉΓòÉ

Use the Breakpoints menu of the Source window to set and delete breakpoints. It
contains the following choices:

     Set line

     Set entry

     Set address

     Set storage change

     Set load occurrence

     List -- [Ctrl+X]

     Toggle at current line -- space bar

     Delete All - delete all breakpoints

 You can also set, delete, enable, and disable breakpoints in the prefix area
 of the source view.

 Related Information

 Procedures
 Delete All Breakpoints


ΓòÉΓòÉΓòÉ 4.1.1.3.1. List ΓòÉΓòÉΓòÉ

Select Breakpoints->List, or press Ctrl+X from a Source window or the Session
Control window, to open the Breakpoints List window. This window lists
information on all breakpoints, and lets you enable, disable, set, and delete
breakpoints.


ΓòÉΓòÉΓòÉ 4.1.1.3.2. Toggle at Current Line ΓòÉΓòÉΓòÉ

Select Breakpoints->Toggle at current line to set a breakpoint at the current
line. If there is already a breakpoint at the current line, this action clears
it.

Other ways to toggle a breakpoint are to double-click on the line number or to
select the line number and press the space bar.


ΓòÉΓòÉΓòÉ 4.1.1.4. Monitors Menu ΓòÉΓòÉΓòÉ

Use the Monitors menu to display one of the debugger monitors. Monitors keep
track of the contents of the call stack, registers, storage, and variables, and
are updated after each step command or encountered breakpoint.

In the Source window, the Monitors menu also includes the Monitor Expression
choice, which lets you enter a variable or expression to monitor.

You can access the following windows from the Monitors menu:

     Call stack

     Registers

     Storage

     Local Variables


ΓòÉΓòÉΓòÉ 4.1.1.5. Run Menu ΓòÉΓòÉΓòÉ

A subset of the following menu choices appears on the Run menu of the Source
and Session Control windows:

     Step over -- [O]

     Step into -- [I]

     Step debug -- [D]

     Step return -- [T]

     Run -- [R] or [Ctrl+R]

     Halt -- [SysRq]

     Restart

     Run to Location -- [L]

     Jump to Location -- [N]

     Hide Debugger on Run

     Check Heap When Stopping (not available for COBOL or PL/I programs)

     Thread Enabled

 The help for each debugger window contains appropriate links to the menu
 choices it supports.


ΓòÉΓòÉΓòÉ 4.1.1.6. Prefix Area Popup Menu ΓòÉΓòÉΓòÉ

When you click mouse button 2 [note] in the prefix area of an executable line
in a Source window, a popup menu appears with some or all of the following
choices:

     Run to location -- run to this line

     Jump to location -- jump to this line

     Set line breakpoint -- set a breakpoint at this line

     Clear breakpoint -- clear the breakpoint at the current line

     Set breakpoint -- set a breakpoint at the current line

     Disable breakpoint -- disable the breakpoint at the current line

     Enable breakpoint -- enable the disabled breakpoint at the current line

 Executable lines are shown in blue in the prefix area, while non-executable
 lines (such as comment lines) are shown in black.


ΓòÉΓòÉΓòÉ 4.1.1.7. Code Area Popup Menu ΓòÉΓòÉΓòÉ

When you click mouse button 2 [note] while your pointer is over text in the
source code area of a Source window, a popup menu appears with the choices
shown below. The first four choices are used to add the highlighted item to the
indicated type of monitor:

     Popup expression

     Add to private monitor

     Add to program monitor

     Add to storage monitor

     Copy -- copy the highlighted item into the system clipboard

     Find -- find the next occurrence of the highlighted item

     Find entry -- find an entry point that matches the highlighted item

     Set entry breakpoint -- set a breakpoint at the entry that matches the
      highlighted item

 For the last two choices, if the selected text corresponds to an overloaded
 C++ function (one that is implemented with two or more distinct signatures),
 an Overloaded dialog opens so that you can select which function signature
 corresponds to the function you selected.


ΓòÉΓòÉΓòÉ 4.1.1.8. Toolbar Buttons and Shortcut Keys ΓòÉΓòÉΓòÉ

The Source window provides the following toolbar buttons and shortcut keys:

     [O] -- Step over

     [I] -- Step into

     [D] -- Step debug

     [T] -- Step return

     [R] -- Run

     [SysRq] -- Halt

     -- Change views

     -- Monitor expression

     -- Call stack monitor

     -- Registers monitor

     -- Storage monitor

     [Ctrl+X] -- Breakpoints list

     EDIT_BMP -- Edit source

     [Ctrl+B] -- Session Control window


ΓòÉΓòÉΓòÉ 4.1.1.8.1. Change View ΓòÉΓòÉΓòÉ

Button:

Click on the Change View toolbar button in a Source window to switch between
available views for the current object. If the object was compiled with debug
information on, Change View cycles you through Source, Disassembly, and Mixed
views in that order.

Related Information

Concepts
Source View
Disassembly View
Mixed View


ΓòÉΓòÉΓòÉ 4.1.2. Prefix Area ΓòÉΓòÉΓòÉ

The prefix area of the Source window is the leftmost column in the main area of
the window. In a source view, the values in the prefix area correspond to the
line numbers in the current source file. In a disassembly view, they correspond
to the hexadecimal addresses of machine language instructions. In a mixed view,
both line numbers and hex addresses are shown.

You can use the prefix area in the following ways:

     To get a bearing on where you are in your file, by using line numbers as
      references.

     To set and clear breakpoints. Double-click mouse button 1 on a value in
      the prefix area, or press the space bar while the cursor is in the prefix
      area. This toggles between setting and removing a breakpoint.

     To run or jump to a line. Click mouse button 2 [note] over the line's
      prefix area, and select either Run to location  or Jump to location from
      the popup menu.

 Breakpoints are indicated in the prefix area by reverse red highlighting.


ΓòÉΓòÉΓòÉ 4.2. Call Stack Window ΓòÉΓòÉΓòÉ

You can use the Call Stack window to view a list of active functions for a
thread, and to raise a Source window to view the code for any of these
functions. To display the window, select Monitors->Call stack or click on the
pushbutton in the Source window or the Session Control window.

Call Stack window Menus, buttons, and shortcut keys

Related Information

Procedures
Use the Call Stack Window

Concepts
Introduction to the Call Stack Window


ΓòÉΓòÉΓòÉ 4.2.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Call Stack window provides the following menus, buttons, and shortcut keys:

     A popup menu with one item, View

     File Options Windows Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]


ΓòÉΓòÉΓòÉ 4.2.1.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Call Stack window contains only one choice, Close
Debugger.


ΓòÉΓòÉΓòÉ 4.2.1.2. Options Menu ΓòÉΓòÉΓòÉ

The Options menu of the Call Stack window contains the following choices:

     Fonts

     Display style

     Restore defaults

     Tool buttons

     Hover help

     Infoarea


ΓòÉΓòÉΓòÉ 4.2.1.2.1. Display Style ΓòÉΓòÉΓòÉ

Select Options->Display style to specify what information you want displayed in
the Call Stack window, and to specify the growth direction for the window.

In the dialog that appears, you can select from the following items (not
necessarily in the order shown here):

     Entry No Function

     Source

     Return Address

     Recursion

     Stack frame pointer (this appears as a register name)

 Click on an entry from the list above for help about it.

 To select an item in the dialog, position the pointer over it and click mouse
 button 1, or press the space bar. (Clicking or pressing again deselects a
 selected item.) Selected items appear white on a gray background. To cancel
 changes you have made to the window without closing the window, click on
 Reset. To restore the debugger defaults, click on Defaults. You can move
 through the list by using either the mouse and slide bar or the cursor keys.


ΓòÉΓòÉΓòÉ 4.2.1.3. View ΓòÉΓòÉΓòÉ

Position the pointer over a function in the Call Stack window, click mouse
button 2, and select View from the popup menu. A Source window that contains
the source code for the function is opened or raised.


ΓòÉΓòÉΓòÉ 4.2.1.4. Growth Direction ΓòÉΓòÉΓòÉ

You can change the order in which functions on the call stack are displayed in
the Call Stack window -- with the most recent entry at the top, or at the
bottom. You can have the window display the most recently called routine at the
top, and the outermost calling routine (usually the main program) at the
bottom. If you click on the  button, the order is reversed.

To change the default growth direction, select Options->Display style and
choose the appropriate growth direction from the dialog.


ΓòÉΓòÉΓòÉ 4.2.1.5. Growth Direction Push button ΓòÉΓòÉΓòÉ

Button:  Menu: Options->Display style (from Call Stack window)

The Growth direction command changes the order in which functions on the call
stack are displayed (whether the most recently called function appears at the
top or bottom). See Growth Direction for more information.


ΓòÉΓòÉΓòÉ 4.2.2. Source ΓòÉΓòÉΓòÉ

The Source item in the Call Stack window lists the name of the source file (or
object file) for each active function in the current thread.

Select Source from the Options->Display style dialog for the Call Stack window
if you want a column showing  source file names to be displayed. Source file
names are displayed by default.


ΓòÉΓòÉΓòÉ 4.2.3. View Popup Choice ΓòÉΓòÉΓòÉ

Use the View choice on the Breakpoints List window's popup menu to raise the
focus of the Source window containing a  line, address, or function breakpoint:

   1. Select the breakpoint in the Breakpoints List window

   2. Click mouse button 2

   3. Select View from the breakpoint popup menu

 You can also raise the focus of the Source window by double-clicking on the
 breakpoint with mouse button 1.

 The line containing the breakpoint is displayed in a Source window, with its
 prefix area selected. If you want to alter the breakpoint, position the
 pointer on that line, click mouse button 2 [note], and select an item from the
 popup menu.


ΓòÉΓòÉΓòÉ 4.2.4. Compile Date/Time ΓòÉΓòÉΓòÉ

The Compile Date/Time item in the Call Stack window shows the date and time the
function was compiled.

Select Compile Date/Time from the Options->Display style dialog for the Call
Stack window if you want a column showing compilation time stamps to be
displayed.


ΓòÉΓòÉΓòÉ 4.2.5. Entry No ΓòÉΓòÉΓòÉ

The Entry No (entry number) item in the Call Stack window is a column of
numbers that indicate the order of functions. The function with the highest
number is the currently executing function; the one with the next highest
number is its caller. Depending on the growth direction of the Call Stack
window, entry numbers appear in descending or ascending order. The smallest
entry number is always 1.

Select Entry No from the Options->Display style dialog for the Call Stack
window if you want a column showing entry numbers to be displayed.


ΓòÉΓòÉΓòÉ 4.2.6. Function ΓòÉΓòÉΓòÉ

The Function item in the Call Stack window lists the name of each active
function in the current thread, or, where the name is not available, the
function's address. To view the source for that function, you can:

     Double-click on its name

     Select its line and press Enter

     Position the pointer over it, click on mouse button 2, and select View
      from the popup menu

 Select Function from the Options->Display style dialog for the Call Stack
 window if you want a column showing function names to be displayed. This
 column is displayed by default.


ΓòÉΓòÉΓòÉ 4.2.7. Recursion ΓòÉΓòÉΓòÉ

The Recursion item in the Call Stack window shows the number of times a
function has been called and has not yet returned. For example, when a function
recursefunc calls itself and you step into recursefunc, the debugger adds a new
recursefunc entry to the Call Stack window. The recursion count for the new
entry is one greater than for the previous recursefunc entry.

Select Recursion from the Options->Display style dialog for the Call Stack
window if you want a column showing recursion values to be displayed.

Related Information

Reference
More Information on Recursion


ΓòÉΓòÉΓòÉ 4.2.8. Return Address ΓòÉΓòÉΓòÉ

The Return address item in the Call Stack window shows the hexadecimal address
of the instruction that execution will return to, provided the indicated
function has called another function and that called function has not yet
returned.


ΓòÉΓòÉΓòÉ 4.2.9. Stack Frame Pointers ΓòÉΓòÉΓòÉ

These entries in the Call Stack window are typically the names of processor
registers for the processor on which the program being debugged is executing.
The available registers are those generally associated with the stack. For
example, on Intel processors, the stack pointer (ESP) and base pointer (EBP)
are used, respectively, to keep track of the current function's stack frame and
the calling function's stack frame.

From the Options->Display style dialog for the Call Stack window, select the
processor registers whose contents you want displayed.


ΓòÉΓòÉΓòÉ 4.2.10. Size ΓòÉΓòÉΓòÉ

The  Size item in the Call Stack window is the size, in bytes, of the stack
frame for the called function. A function's stack frame includes the address to
return to when the function completes, a pointer to the previous function's
stack frame, and any local variables or arrays declared in the calling
function. Given that the return address and previous function pointer are
fixed-size components of a stack frame, the stack frame size provides an
indication of how much local data is declared by the function.

In C++, because the heap, not the stack frame, contains the storage for
dynamically allocated local variables, only the pointers to such variables take
up stack frame space.

Select Size from the Options->Display style dialog for the Call Stack window if
you want a column showing the size of the stack frame.


ΓòÉΓòÉΓòÉ 4.3. Registers Monitor ΓòÉΓòÉΓòÉ

Use the Registers monitor to view or modify the contents of the registers
monitored for your program. The debugger displays a separate Registers monitor
for each thread. See the following topics for more information:

     Introduction

     How to use the Registers monitor

     Menus, buttons, and shortcut keys


ΓòÉΓòÉΓòÉ 4.3.1. Menus, Buttons, Shortcut Keys ΓòÉΓòÉΓòÉ

The Registers monitor provides the following menus, buttons, and shortcut keys:

     File Options Windows Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]


ΓòÉΓòÉΓòÉ 4.3.1.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Registers monitor contains only one choice, Close
Debugger.


ΓòÉΓòÉΓòÉ 4.3.1.2. Options Menu ΓòÉΓòÉΓòÉ

The Options menu of the Registers monitor contains the following choices:

     Fonts

     Display style

     Restore defaults

     Tool buttons

     Hover help

     Infoarea


ΓòÉΓòÉΓòÉ 4.3.1.2.1. Display Style ΓòÉΓòÉΓòÉ

Use the Display Style dialog to customize how the information in your Registers
monitor is displayed. You can choose what groups of registers are displayed in
the window, whether groups are laid out in columns (vertical orientation) or
rows (horizontal orientation), whether or not the name of each group appears
above its column or row, and whether the positions of split bars between rows
or columns are saved.

This dialog has the following group boxes and check boxes:

 Groups    Use this selection list to choose the groups of registers you want
           to display. (Available groups are dependent on the processor on
           which the application being debugged is running.) To select an item,
           position the pointer over it and click mouse button 1 or press the
           space bar. Repeating this action deselects the item. Selected items
           appear white on a gray background.

           You can move through the list by using the mouse and slide bar, or
           by using the cursor up and down keys.

 Orientation Select Vertical if you want each group of registers to display in
           its own column, or select Horizontal if you want it to display in
           its own row. (A row can have multiple lines.)

 Column titles Select this check box if you want the title of each group of
           registers to appear above its group.

 Save split bars Select this check box if you want to save the positions of
           split bars between rows or columns of registers, from one debugging
           session of your program to the next.

 To cancel changes you have made without closing the dialog, click on Reset. To
 restore the debugger defaults, click on Defaults.


ΓòÉΓòÉΓòÉ 4.4. Storage Monitor ΓòÉΓòÉΓòÉ

Use the Storage monitor to view and update the contents of storage areas used
by your program.

See the following topics for more information:

     Introduction to the Storage monitor

     Menus, buttons, and shortcut keys


ΓòÉΓòÉΓòÉ 4.4.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Storage monitor provides the following menus, buttons, and shortcut keys:

     File Options Windows Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]


ΓòÉΓòÉΓòÉ 4.4.1.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Storage monitor contains only one choice, Close Debugger.


ΓòÉΓòÉΓòÉ 4.4.1.2. Options Menu ΓòÉΓòÉΓòÉ

The Options menu of the Storage monitor contains the following choices:

     Fonts

     Display style

     Monitor expression

     Restore defaults

     Tool buttons

     Hover help

     Infoarea


ΓòÉΓòÉΓòÉ 4.4.1.2.1. Display Style ΓòÉΓòÉΓòÉ

Use the Display style dialog to specify what information is shown in the
Storage monitor, what addressing scheme is used, how many columns of bytes are
displayed on each line, and whether column titles are shown.

To choose the desired style from the Content Style list, scroll through the
list using the cursor keys, or position the pointer over the item you want;
then click mouse button 1. To cancel changes you have made without closing the
dialog, click on Reset. To restore the debugger defaults, click on Defaults.

For information on the other items in the Display style dialog, click on the
links below:

     Address style

     Columns per line

     Column titles


ΓòÉΓòÉΓòÉ 4.4.1.2.1.1. Address Style ΓòÉΓòÉΓòÉ

For debuggee programs running on Intel processors, you can select an address
style of either flat, segmented (shown as '16:16'), or combined (shown as 'Flat
and 16:16').


ΓòÉΓòÉΓòÉ 4.4.1.2.1.2. Columns per Line ΓòÉΓòÉΓòÉ

Enter a number, or use the arrows beside this field, to specify the number of
Columns per line of storage you want displayed. The size of a single column is
based on the content style you select. For example, if you select Hex and
character, a column is a single byte; if you select 16-bit integer, a column is
two bytes.


ΓòÉΓòÉΓòÉ 4.4.1.2.1.3. Column Titles ΓòÉΓòÉΓòÉ

Select this check box if you want a title line to appear above the storage area
of the Storage monitor. When you choose Column Titles, the Storage monitor
displays the address style (flat or segmented) above the column showing
addresses, and displays the offset of the displayed range above the column
showing storage contents.


ΓòÉΓòÉΓòÉ 4.4.1.2.1.4. Display String Literals in ASCII or EBCDIC ΓòÉΓòÉΓòÉ

You can view string literals in the Storage monitor in either ASCII or EBCDIC.
The default is ASCII for workstation applications. To change the default
representation, select Options->Display style and choose the appropriate
representation:

     HEX and EBCDIC

     HEX and ASCII


ΓòÉΓòÉΓòÉ 4.4.1.2.2. Monitor Expression in Storage ΓòÉΓòÉΓòÉ

Select Options->Monitor Expression from the Storage monitor to enter the
variable or expression you want to monitor.

The storage monitor is updated to show the requested storage address and
contents. This saves you from having to scroll up and down through the
monitor's storage pane if you know what storage you want to look at.

For COBOLand PL/I, if a variable is added to the storage monitor, the storage
monitor opens at the address of that variable. If the variable is of type
POINTER, it opens at the address specified by the contents of that variable.

For C++, given the code:

int x=12;
int *y=&x;

to view the storage for x, you can enter either &x or y.

Note: For C++, if you enter the name of a variable that is not a pointer, or an
expression that is not related to pointers, the debugger shows storage
beginning at the address corresponding to the value of the variable or
expression. This storage may not have any connection to the variable itself or
to the program you are debugging. Normally you would only use variables or
expressions that evaluate to an address (for example, pointers, array names, or
expressions containing pointers).

Select the Enabled monitor check box if the expression you are entering
evaluates to a dynamically changing address and you want the Storage monitor to
show the storage for that changing address. For instance, if you enter a
pointer as part of the expression, and the address contained in that pointer
changes dynamically, the Storage monitor will display a different location in
storage each time the pointer changes.

Related Information

Concepts
Expressions


ΓòÉΓòÉΓòÉ 4.4.1.3. Single-Precision Floating-Point Pushbutton ΓòÉΓòÉΓòÉ

Button:  Menu: Select Options->Display style from the Storage monitor, then
select Single-precision floating-point float from the Content style list.

This causes storage in the Storage monitor to be displayed as a series of
single-precision floating-point numbers. Each number begins on a four-byte
boundary.


ΓòÉΓòÉΓòÉ 4.4.1.4. Double-Precision Floating-Point Pushbutton ΓòÉΓòÉΓòÉ

Button:  Menu: Select Options->Display style from the Storage monitor, then
select Double-precision floating-point float from the Content style list.

This causes storage in the Storage monitor to be displayed as a series of
double-precision floating-point numbers. Each number begins on an eight-byte
boundary.


ΓòÉΓòÉΓòÉ 4.4.1.5. 32-Bit Unsigned Pushbutton ΓòÉΓòÉΓòÉ

Button:  Menu: Select Options->Display style (from the Storage monitor), then
select 32-bit unsigned integer from the Content style list.

This causes storage in the Storage monitor to be displayed as a series of
32-bit unsigned integers. Each number begins on a four-byte boundary.


ΓòÉΓòÉΓòÉ 4.4.1.6. 32-bit Signed Pushbutton ΓòÉΓòÉΓòÉ

Button:  Menu: Select Options->Display style (from Storage monitor) then select
32-bit signed integer from the Content style list.

This causes storage in the Storage monitor to be displayed as a series of
32-bit signed integers. Each number begins on a four-byte boundary.


ΓòÉΓòÉΓòÉ 4.4.1.7. Character Pushbutton ΓòÉΓòÉΓòÉ

Button:  Menu: Select Options->Display style (from the Storage monitor) then
select Character from the Content style list.

This causes storage in the Storage monitor to be displayed as a series of
characters. Alphanumeric characters and some punctuation characters are
displayed normally; other characters are shown only as small dots. To view the
value of a nondisplayed character, change to Hex and character display style
and look for the character's hexadecimal value.


ΓòÉΓòÉΓòÉ 4.4.1.8. Hex and Character Push button ΓòÉΓòÉΓòÉ

Button:  Menu: Select Options->Display style from the Storage monitor, then
select Hex and character from the Content style list.

This causes storage in the Storage monitor to be displayed in columns of
hexadecimal data, followed by a single column of characters. In the character
section, alphanumeric characters and punctuation characters are displayed
normally; other characters are shown only as small dots.

When storage is displayed in hex and character data, the characters can be in
either ASCII or EBCDIC format depending on the platform the debugger is running
on. See Display String Literals in ASCII or EBCDIC for information on how to
change the default character set.


ΓòÉΓòÉΓòÉ 4.5. Breakpoints List Window ΓòÉΓòÉΓòÉ

Use the Breakpoints List window to set, delete, enable, disable, or modify the
characteristics of  breakpoints. See the following topics for more information:

     Introduction to the Breakpoints List window

     Menus, buttons, and shortcut keys


ΓòÉΓòÉΓòÉ 4.5.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Breakpoint List window provides the following menus, buttons, and shortcut
keys:

     File Edit Set Options Windows Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]

 It also provides a popup menu.


ΓòÉΓòÉΓòÉ 4.5.1.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Breakpoints List window contains only one choice, Close
Debugger.


ΓòÉΓòÉΓòÉ 4.5.1.2. Edit Menu ΓòÉΓòÉΓòÉ

Use the Edit menu of the Breakpoint List window to delete, change, disable, or
enable breakpoints that have already been set. This menu contains the following
choices:

     Delete

     Disable (shown only when the highlighted breakpoint is enabled)

     Enable (shown only when the highlighted breakpoint is disabled)

     Modify

     Delete all

     Disable all

     Enable all


ΓòÉΓòÉΓòÉ 4.5.1.2.1. Disable ΓòÉΓòÉΓòÉ

To disable the currently selected breakpoint, choose Edit->Disable from the
Breakpoints List window, or place the pointer over the breakpoint you want to
disable. Then click on mouse button 2, and select Disable. (The breakpoint must
be enabled for this menu choice to be shown.)

When you disable a breakpoint, it does not stop execution when the program is
run. You can later enable it by selecting Edit->Enable from the Breakpoints
List window, or by clicking mouse button 2 on it and selecting Enable from the
popup menu. You can also enable all disabled breakpoints by selecting
Edit->Enable all.

Related Information

Procedures
Enable and Disable Breakpoints


ΓòÉΓòÉΓòÉ 4.5.1.2.2. Enable ΓòÉΓòÉΓòÉ

To enable the currently selected breakpoint, choose Edit->Enable from the
Breakpoints List window, or place the pointer over the breakpoint, click mouse
button 2, and select Enable. (The breakpoint must be disabled for this menu
choice to be shown.)

Disabled breakpoints are remembered by the debugger but do not cause execution
to stop when the program runs. When you enable a disabled breakpoint, the
debugger stops program execution whenever the breakpoint is encountered.

Related Information

Procedures
Enable and Disable Breakpoints


ΓòÉΓòÉΓòÉ 4.5.1.2.3. Modify ΓòÉΓòÉΓòÉ

Select Edit->Modify from the Breakpoints List window to modify settings for the
selected breakpoint (for example, the frequency with which it causes execution
to stop, or what threads it applies to). After you have made the desired
changes, click on OK.

If you click on Set instead, the changes are applied and the dialog stays open.
Subsequent changes you make within the dialog are applied to the same
breakpoint.

Related Information

Procedures
Modify Breakpoint Characteristics


ΓòÉΓòÉΓòÉ 4.5.1.2.4. Delete all ΓòÉΓòÉΓòÉ

Choose Edit->Delete all from the Breakpoints List menu bar to delete all
breakpoints in the monitor.

Note: If you want to temporarily disable all breakpoints and then later
re-enable them, use Edit->Disable all instead.


ΓòÉΓòÉΓòÉ 4.5.1.2.5. Disable All ΓòÉΓòÉΓòÉ

Choose Edit->Disable all from the Breakpoints List window to disable all
breakpoints. When you disable breakpoints, the debugger remembers where they
are set, but does not use them to stop execution when the program is run. You
can later enable them all by selecting Edit->Enable all. You can enable
individual breakpoints by clicking with mouse button 2 on each breakpoint you
want to enable, and selecting Enable from the popup menu.


ΓòÉΓòÉΓòÉ 4.5.1.2.6. Enable All ΓòÉΓòÉΓòÉ

Choose Edit->Enable all from the Breakpoints List window to enable all
breakpoints that have been disabled.


ΓòÉΓòÉΓòÉ 4.5.1.3. Set Menu ΓòÉΓòÉΓòÉ

Use the Set menu of the Breakpoint List window to set various kinds of
breakpoints through a dialog. This menu contains the following choices:

     Set line

     Set entry

     Set address

     Set storage change

     Set load occurrence


ΓòÉΓòÉΓòÉ 4.5.1.3.1. Set Line ΓòÉΓòÉΓòÉ

Select Set->Set Line, or select Line breakpoint from the prefix area popup
menu, to set a line breakpoint at a particular line number. In the dialog that
appears, you can specify what executable and source file you want to set the
breakpoint in. If the source code consists of several files (that is, if one or
more files include other files) you can select which source file the breakpoint
should be set in from the Include File pulldown list.

Type a line number in the Line entry field. The breakpoint is set on that line
number.

More information is available on the following entry field items:

     Thread

     Defer breakpoint

     Frequency

     Expression


ΓòÉΓòÉΓòÉ 4.5.1.3.2. Set Function ΓòÉΓòÉΓòÉ

Select Set->Set Function to set a breakpoint at the start of a function. Select
Set->Set Entry to set a breakpoint at an entry point. In the dialog that
appears, type the name of the function in the Function entry field, or select
the List button and click on the function you want. You can also specify what
executable and source file you want to set the breakpoint in. If the source
code consists of several files (that is, if one or more files include other
files) select which source file to set the breakpoint in from the Include File
pulldown list.

More information is available on the following entry field items:

     Thread

     Defer breakpoint

     Frequency

     Expression

 If the function you specified is an overloaded C++ function (your program
 contains two or more functions with the same name but different signatures),
 an Overloaded dialog appears, displaying a list of the overloads of the
 function. Choose the desired one from the list.


ΓòÉΓòÉΓòÉ 4.5.1.3.3. Set Address ΓòÉΓòÉΓòÉ

Use the Set Address choice to set a breakpoint at a specific address. When the
instruction at the specified address is executed, the program will stop.

When you click on Set Address, an Address Breakpoint dialog opens. In the
Address or Expression entry field, you can type the address, or an expression
that evaluates to a valid execution address.

A valid execution address is the beginning address of a machine language
instruction. For  Intel 32-bit code, you must enter the address in flat format.
For 16-bit code (debuggee on OS/2 only), you can enter it in either flat or
segmented format.

For example, to set an address breakpoint for the address 0x000A1FCC, type
0X000A1FCC or A1FCC. In a PL/I program you can also enter the address in the
form '000A1FCC'X.In a COBOL program you can also enter the address in the form
X'000A1FCC'. Note that the PL/I and COBOL specific syntaxes both require an
even number of hexadecimal digits. To set the segmented address 0x0060:1F7C,
type 0X0060:1F7C or 60:1F7C.

COBOL and PL/I: You can also specify a POINTER variable instead of a
hexadecimal constant to specify an address.

C++: Expressions that evaluate to an address are C++ expressions such as:

     An expression containing an address, an addition or subtraction operator,
      and a value. For example: A1FCC+17.

     A pointer-to-function that points to a valid execution address. For
      example, after you have stepped over the assignment to ptf1 in the
      following program:

                 void howdy() { printf('Hello there\n'); }
                 void main() {
                   void (*ptf1) ();
                   ptf1=howdy;
                   // ...
                 }

      you could enter ptf1 as the expression, and the breakpoint would be set
      on entry to the function howdy(). (Before you have stepped over the
      assignment, ptf1 does not point to a valid function and so you could not
      use it in an address expression here.)

 More information is available on the following entry field items:

     Thread

     Frequency

     Expression

 Related Information

 Reference
 Expressions Supported


ΓòÉΓòÉΓòÉ 4.5.1.3.4. Set Storage Change ΓòÉΓòÉΓòÉ

Use the Set storage change choice to cause execution to stop whenever storage
at a specific address is written to. Execution stops even if the value written
to storage is the value that was already present at that address. You can set
up to four breakpoints.

Caution: If you set a storage change breakpoint for an address that is on the
call stack, be sure to remove the breakpoint before leaving the routine
associated with it. Otherwise, when you return from the routine, the routine's
stack frame will be removed from the stack, but the breakpoint will still be
active. Any other routine that gets loaded on the stack will then contain the
breakpoint.

In the Address or Expression entry field, you can type the address or a
variable name or expression that evaluates to a valid address.

C++: You can also enter the address of a variable, by preceding the variable
name with an ampersand (for example, &myVariable).

COBOLand PL/I: For POINTER variables, the contents of the variable are used as
the address. For all other variables, the address of the variable is used.

Note: If you type FEEDBEEF in the Address or expression entry field, and there
is a variable named FEEDBEEF, the debugger will interpret the entry as the
variable FEEDBEEF, not the hex value FEEDBEEF.

More information is available on the following fields:

     Bytes to monitor

     Thread

     Frequency

 Related Information

 Reference
 Expressions Supported
 Valid Addresses and Expressions


ΓòÉΓòÉΓòÉ 4.5.1.3.4.1. Bytes to Monitor ΓòÉΓòÉΓòÉ

Select a value from Bytes to Monitor on the Storage Change Breakpoint dialog to
tell the debugger the number of bytes you want it to monitor. The valid range
depends on the operating system the debuggee is running on.

On Intel platforms, you can choose 1, 2, or 4 bytes. The 2-byte range must be
aligned on a word boundary, and the 4-byte range must be aligned on a
double-word boundary.


ΓòÉΓòÉΓòÉ 4.5.1.3.4.2. Set Load Occurrence ΓòÉΓòÉΓòÉ

Select Set Load Occurrence to set a breakpoint that will stop execution when
the DLL you specify has been loaded.  In the Load Occurrence Breakpoint dialog,
type the name of the DLL in the DLL File Name entry field. Execution stops when
the DLL is loaded.

For information on other fields in this dialog, see the following:

     Thread

     Frequency (From/To/Every)


ΓòÉΓòÉΓòÉ 4.5.1.4. Options Menu ΓòÉΓòÉΓòÉ

The Options menu of the Breakpoints List window contains the following choices:

     Fonts

     Display style

     Sort

     Restore defaults

     Tool buttons

     Hover help

     Infoarea


ΓòÉΓòÉΓòÉ 4.5.1.4.1. Display Style ΓòÉΓòÉΓòÉ

You can change the way items in the Breakpoint List window are displayed by
selecting Options->Display style, then selecting those items you want from the
Select Items list in the Display Style dialog.

The Select Items list in the Display Style dialog contains the following items:

 Type      The type of breakpoint, for example, Line or Address

 Executable The name of the executable file the breakpoint applies to

 Source    The name of the compilation unit the breakpoint applies to

 File      The source file

 Function  The function containing the breakpoint

 Line      The source code line containing the breakpoint

 Address   The address of the breakpoint

 State     Whether the breakpoint is enabled or disabled

 Status    Whether the breakpoint is active or deferred (a deferred breakpoint
           is a breakpoint set in a DLL that has not yet been loaded)

 Thread    What threads the breakpoint applies to

 Expression An optional expression that must evaluate to true for the
           breakpoint to cause execution to stop.

 From      The first encounter of the breakpoint that causes execution to stop.
           For example, if this value is set to 5, each run command could, if
           no other breakpoints are encountered and the program does not
           terminate, pass over the breakpoint four times before stopping the
           fifth time.

 To        The last encounter of the breakpoint that causes execution to stop.

 Every     The frequency at which encounters of the breakpoint cause execution
           to stop. For example, if Every is set to 2, the breakpoint causes
           execution to stop every other time the breakpoint is encountered.

 If you select the Reset pushbutton any changes you have made in the Display
 Style dialog are discarded, and the dialog is refreshed to show the display
 style in effect when you opened the dialog. If you select Default the default
 items are displayed in the Breakpoint List window.


ΓòÉΓòÉΓòÉ 4.5.1.4.2. Sort ΓòÉΓòÉΓòÉ

You can change the order of items in the Breakpoint List window by selecting
Options->Sort, then selecting the item you want the debugger to sort on from
the Select Item list in the Sort dialog. By default, breakpoints are sorted by
line number.


ΓòÉΓòÉΓòÉ 4.5.1.5. Defer Breakpoint ΓòÉΓòÉΓòÉ

Select the Defer breakpoint check box from within the Line Breakpoint dialog if
you want to set a line breakpoint in a DLL that is not currently loaded.

When a DLL in which you have set a deferred breakpoint is loaded, the
breakpoint state changes from deferred to active. When the DLL is freed, the
breakpoint state changes back to deferred.

If you enter an incorrect source, file, or line number, the debugger will be
unable to activate the breakpoint when the DLL is loaded, and the breakpoint
will remain in the deferred state.

Note: You cannot set a deferred breakpoint in a preloaded DLL, but you can set
one in a program that has some preloaded DLLs and some dynamically loaded ones.

Related Information

Procedures
Set a Deferred Breakpoint


ΓòÉΓòÉΓòÉ 4.5.2. Thread ΓòÉΓòÉΓòÉ

The Thread pulldown list in a Set breakpoint or Modify breakpoint dialog lets
you choose what threads to activate the breakpoint in. To select a thread ID
from the list, select the List button, then highlight the thread where you want
to set the breakpoint.


ΓòÉΓòÉΓòÉ 4.5.3. Defer Breakpoint ΓòÉΓòÉΓòÉ

Select the Defer breakpoint check box if you want to set a function breakpoint
in a DLL that is not currently loaded.

If you set a deferred function breakpoint on a C++ function, and that function
is overloaded, the debugger sets the breakpoint in all of the overloaded
functions when the DLL is loaded.

When a DLL in which you have set a deferred breakpoint is loaded, the
breakpoint state changes from deferred to active. When the DLL is freed, the
breakpoint state changes back to deferred.

If you enter an incorrect source, file, or function, the debugger will be
unable to activate the breakpoint when the DLL is loaded, and the breakpoint
will remain in the deferred state.

Note: You cannot set a deferred breakpoint in a preloaded DLL, but you can set
one in a program that has some preloaded DLLs and some dynamically loaded ones.


ΓòÉΓòÉΓòÉ 4.5.4. Frequency ΓòÉΓòÉΓòÉ

Use the Frequency fields to tell the debugger when to stop on a breakpoint and
when to skip it. The debugger keeps track of how many times each breakpoint is
encountered. The fields in this section tell the debugger on which encounter of
a breakpoint the debugger should first stop, how often it should stop, and on
which encounter the debugger should no longer stop.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéEntry field                           ΓöéPurpose                              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéFrom                                  ΓöéEnter the first breakpoint encounter Γöé
Γöé                                      Γöéyou want the debugger to stop on. ForΓöé
Γöé                                      Γöéexample, if you want the debugger to Γöé
Γöé                                      Γöéskip over the breakpoint the first   Γöé
Γöé                                      Γöéfive times it is encountered, enter  Γöé
Γöé                                      Γöé'6'.                                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéTo                                    ΓöéEnter the last breakpoint encounter  Γöé
Γöé                                      Γöéyou want the debugger to stop on. ForΓöé
Γöé                                      Γöéexample, if you want it to start     Γöé
Γöé                                      Γöéignoring the breakpoint after the    Γöé
Γöé                                      Γöé20th encounter, enter '20'. To have  Γöé
Γöé                                      Γöéit always stop on the breakpoint,    Γöé
Γöé                                      Γöéenter 'Infinity'.                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéEvery                                 ΓöéEnter the frequency with which you   Γöé
Γöé                                      Γöéwant the debugger to stop on this    Γöé
Γöé                                      Γöébreakpoint. For example, if you want Γöé
Γöé                                      Γöéit to stop on only one out of every  Γöé
Γöé                                      Γöéfour it encounters, enter '4'.       Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 4.5.5. Expression ΓòÉΓòÉΓòÉ

If you are setting a line breakpoint, address breakpoint or function breakpoint
in a C++ program,  or a line or address breakpoint in a COBOL or PL/I program,
you can type an expression into the Expression entry field in a Set breakpoint
or Modify breakpoint dialog. The execution of the program stops at the
breakpoint only if the condition specified in this field tests true.

For example, if you are debugging a C++ program you could type the following:

(i==1) || (j==k) && (k!=5)

For a COBOL or PL/I program, you could type the following:

myvar = 'abc'

Note: Variables in a conditional expression that is associated with a function
breakpoint are limited to any static or global variables known to the called
function when the function is called. The expression cannot contain local or
automatic variables.

Related Information

Reference
Expressions Supported


ΓòÉΓòÉΓòÉ 4.5.6. Breakpoints List Popup Menu ΓòÉΓòÉΓòÉ

In the Breakpoints List window, if your pointer is on a line containing
breakpoint information and you click on mouse button 2, a popup menu appears
with the following choices that affect breakpoints:

     View

     Delete - deletes the selected breakpoint

     Enable (if breakpoint is currently disabled)

     Disable (if breakpoint is currently enabled)

     Modify (not supported on OS/390) - opens a dialog that lets you change
      the breakpoint

     Delete all - deletes all the breakpoints

 Related Information

 Procedures
 Delete Breakpoints
 Modify Breakpoint Characteristics
 Delete All Breakpoints


ΓòÉΓòÉΓòÉ 4.6. Session Control Window ΓòÉΓòÉΓòÉ

The Session Control window is open throughout the debugging session. It shows
the current status of the debugger, and gives you a number of ways to access
other windows or perform common functions. See the following topics for more
information:

     Introduction to the Session Control window

     Menus, buttons, and shortcut keys


ΓòÉΓòÉΓòÉ 4.6.1. Using the Components Pane ΓòÉΓòÉΓòÉ

You can expand any item in the Components pane that has a '+' beside it. The
following list shows what items you can expand, and what items appear when you
do:

 Item with + Expands to

 Executable or DLL Object files used to form the executable or DLL

 Object file Source files used to compile the object file, if more than one
           source file was used. Otherwise, the object file item expands to the
           functions defined in the source file.

 Source file (C++ only): File-scope functions and class member functions
           defined within each source file. C++ class member functions are not
           shown.

 To shift the focus within the Session Control window between the Threads and
 Components panes, use the pointer or the cursor left and right keys. To move
 between items in the list, use the mouse or the cursor up and down keys. To
 expand or collapse items in the list, use the + and - keys.

 To open or raise the focus of the Source window for an object file, source
 file, or function, double-click on the item, or highlight it and press Enter.

 To access the popup menu for a function, select that function and click on
 mouse button 2 . This menu lets you set a breakpoint on the function or view
 its source code.


ΓòÉΓòÉΓòÉ 4.6.2. Using the Threads Pane ΓòÉΓòÉΓòÉ

When you expand a thread in the Threads pane, the following information is
displayed:

     Whether the thread is runable or blocked

     Whether the thread is enabled or disabled

     The thread's priority.

 To move between items in the list, use the mouse or the cursor up and down
 keys. To expand or collapse items in the list, use the + and - keys.

 To open or raise the focus of the Source window for a thread, press the Enter
 key while the thread is highlighted, or double-click on it.

 To access a popup menu for a highlighted thread, click mouse button 2. This
 menu lets you disable or enable the thread, access monitors specific to it, or
 jump to the execution point in the Source window for the thread.

 To enable a disabled thread or disable an enabled one, select the thread, then
 choose Run->Thread enabled. This toggles the current enablement for that
 thread. If the thread is enabled, a checkmark appears beside Thread enabled.

 Note: In the Source window, the current execution line is reverse-highlighted
 in black. When a thread becomes disabled, the current execution line for that
 thread's Source Window changes to gray.

 For guidance on designing and debugging multithreaded programs, see Debugging
 Threads.


ΓòÉΓòÉΓòÉ 4.6.3. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Session Control window provides the following menus, buttons, and shortcut
keys:

     File Breakpoints Monitors Run Options Windows Help

   

     [Ctrl+E->Registers] [Ctrl+G->Storage] [Ctrl+K->Call Stack]
      [Ctrl+P->Source] [Ctrl+R->Run] [Ctrl+V->Local variables] [Ctrl+X->
      Breakpoint list]

 The Session Control window also has a popup menu.


ΓòÉΓòÉΓòÉ 4.6.3.1. Shortcut Keys ΓòÉΓòÉΓòÉ

The Session Control window provides the following shortcut keys:

     [Ctrl+E->Registers]

     [Ctrl+G->Storage]

     [Ctrl+K->Call Stack]

     [Ctrl+P->Source]

     [Ctrl+R->Run]

     [Ctrl+V->Local variables]

     [Ctrl+X-> Breakpoint list]

     [Ctrl+Y-> Process list] (Windows only)


ΓòÉΓòÉΓòÉ 4.6.3.2. Breakpoints Menu ΓòÉΓòÉΓòÉ

Use the Breakpoints menu to set and delete breakpoints. It contains the
following choices:

     Set line

     Set function

     Set address

     Set storage change

     Set load occurrence

     List -- [Ctrl+X]

     Delete All - Deletes all breakpoints

 Related Information

 Procedures
 Delete All Breakpoints


ΓòÉΓòÉΓòÉ 4.6.3.3. Options Menu ΓòÉΓòÉΓòÉ

The Options menu in the Session Control window lets you change settings for the
window and for the debugger itself. It contains the following choices:

     Window settings

     Debugger settings


ΓòÉΓòÉΓòÉ 4.6.3.3.1. Display Style ΓòÉΓòÉΓòÉ

Select Options->Window settings->Display style to specify what you want
displayed in the Session Control window. The dialog contains the following
check boxes:

 Check box Effect when checked

 Show all components All components are displayed (when this choice is not
           checked, only components with debug information are displayed)

 Show module path The path name is displayed

 Sort components Components are sorted in alphabetical order

 Sort threads Threads are sorted in numerical order

 Show status line A status line is displayed, showing the current state of the
           debugger (for example, Executing)


ΓòÉΓòÉΓòÉ 4.6.3.3.2. Window Settings ΓòÉΓòÉΓòÉ

Select the Window settings cascading choices from the Session Control window
Options menu to modify these settings:

 Fonts     Lets you change the font for the Session Control window.

 Display style Opens a Display Style dialog where you can specify how
           information in the Session Control window should appear.

 Restore defaults Resets all settings for the Session Control window to their
           original values.

 Tool buttons Displays or hides the toolbar buttons for the window.

 Hover help Enables or disables hover help, which provides brief descriptions
           of menu choices and toolbar buttons when your pointing device passes
           over them.

 Infoarea  Enables or disables the window's information area, which provides
           longer textual descriptions of menu choices and toolbar buttons when
           your pointing device passes over them.


ΓòÉΓòÉΓòÉ 4.6.3.3.3. Set Breakpoints at Entry Points ΓòÉΓòÉΓòÉ

Select the Set breakpoints at entry points  check box in the Debugger
Properties dialog of the Session Control window to automatically set a
breakpoint at each function.


ΓòÉΓòÉΓòÉ 4.6.3.4. Threads/Components Popup Menu ΓòÉΓòÉΓòÉ

Popup menus are available for both the Threads pane and the Components pane of
the Session Control window.

In the Threads pane, when you highlight the main entry for a thread and click
mouse button 2, the popup menu displays a subset of the following choices:

     Execution point -- opens or raises a Source window showing the next line
      to be executed in the thread

     Enable -- changes a disabled thread's state to enabled, so that it can
      run (shown only for disabled threads)

     Disable -- changes an enabled thread's state to disabled, to prevent it
      from running (shown only for enabled threads)

     Registers -- opens or raises a Registers monitor for that thread

     Call Stack -- opens or raises a Call Stack window for that thread

     Local variables -- opens or raises a Local Variables window for that
      thread

 In the Components pane, if you click mouse button 2 over a function, the popup
 menu contains the following choices:

     View -- open or raise a Source window for the file or function

     Set function breakpoint -- set a breakpoint at the start of this
      function, for the current thread only

     Set breakpoint every -- set a breakpoint at the start of the function,
      for all threads

 If you click mouse button 2 over an object file, the popup menu contains only
 the View choice.


ΓòÉΓòÉΓòÉ 4.6.3.5. Source ΓòÉΓòÉΓòÉ

Menu: Windows->Source from the Session Control window Keystroke: Ctrl+P

Opens or raises a Source window. When you use Ctrl+P to access a source window,
the source window raised or opened contains the contents of the active thread
and function. When you use the Windows menu and more than one Source window is
currently open, a Source choice is available for each open Source window.


ΓòÉΓòÉΓòÉ 4.7. Monitor Expression Dialog ΓòÉΓòÉΓòÉ

Use the Monitor Expression dialog to add a variable or expression to one of the
following monitors, which are listed in the dialog within a radio button group
box:

     Popup

     Private

     Program

     Storage

 The current context is shown in an information group box. This is the context
 (file, line number, etc.) that the debugger uses in evaluating the expression
 you enter.

 Type in an expression, and either click on OK or Monitor. OK closes the
 dialog, while Monitor leaves the dialog open so that you can add more
 expressions.

 If the expression you want to add is already in your source code, you can
 place that expression in the Expression entry field in the Monitor Expression
 dialog as follows: highlight it with the mouse, then select Monitor->Monitor
 expression or click on the  toolbar button.

 See Expressions Supported for more information on what types of expressions
 the debugger supports.

 Related Information

 Concepts
 Expressions


ΓòÉΓòÉΓòÉ 4.7.1. Current Context ΓòÉΓòÉΓòÉ

The context group box on the right side of the Monitor Expression dialog shows
the current execution point in your program: the file name, line number, type
of view, and thread number.

If you have tried to add an expression to a monitor and the debugger issues the
error message 'Expression validation failed', you may have included
out-of-scope variables or constants in your expression. If you are familiar
with the structure of your program, the Context group box may help you
determine if scoping problems are the cause of the error.

See Expressions Supported for information on what types of expressions the
debugger supports.


ΓòÉΓòÉΓòÉ 4.8. Popup Monitor ΓòÉΓòÉΓòÉ

A Popup monitor displays a variable or expression you select for monitoring.
This monitor is associated with a specific Source window and closes when the
associated window closes. Each time you add a variable or expression to a Popup
monitor, a new Popup monitor opens. The contents of each Popup monitor are
updated after each Step or Run command (except for disabled variables or
expressions within such windows).

You can do the following from a Popup monitor:

     Access a popup menu using mouse button 2

     Change the contents of a variable

 The Popup monitor has the following menu items on its titlebar menu:

     File

     Options

     Help

 Related Information

 Procedures
 Add Expressions and Variables to a Monitor


ΓòÉΓòÉΓòÉ 4.8.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Popup monitor contains only one choice, Close Debugger.


ΓòÉΓòÉΓòÉ 4.8.2. Popup Menu for the Popup Monitor ΓòÉΓòÉΓòÉ

To access a popup menu from within a Popup window, place the pointer over a
monitored variable or expression, and click mouse button 2. Depending on the
variable or expression you selected, the popup menu provides a subset of the
following choices:

     Edit

     Next representation

     Change font

     Dereference  (not available for COBOLor PL/I)

     Delete

     Enable

     Disable


ΓòÉΓòÉΓòÉ 4.8.2.1. Change Font ΓòÉΓòÉΓòÉ

Choose Change font from the popup menu in a Popup monitor to change the font
used within that particular monitor. Choose the desired font from the Font
Selection dialog that appears.


ΓòÉΓòÉΓòÉ 4.9. Private Monitor ΓòÉΓòÉΓòÉ

Use a Private monitor to monitor variables or expressions from a given Source
window. Each Source window can have its own Private monitor. This monitor is
similar to the Program monitor.

See the following for more information:

     Introduction to the Private Monitor

     Monitor popup menu

     Menus, buttons, and shortcut keys

 Related Information

 Concepts
 Differences between Program and Private Monitors


ΓòÉΓòÉΓòÉ 4.9.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Private monitor provides the following menus, buttons, and shortcut keys:

     Edit Options Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]

 The Private monitor also has a popup menu. To access it, place the pointer
 within the content area of the window and click mouse button 2.


ΓòÉΓòÉΓòÉ 4.9.1.1. Edit Menu ΓòÉΓòÉΓòÉ

The Edit menu of both the Program monitor and Private monitor contains the
following choices:

     Delete

     Delete all

     Select all

     Deselect all

     Enable

     Disable

     Other elements

     Representation


ΓòÉΓòÉΓòÉ 4.9.1.1.1. Delete ΓòÉΓòÉΓòÉ

Select Edit->Delete from the monitor menu bar, or Delete from a monitor popup
menu, to delete the selected variables or expressions from the monitor.

To delete all expressions, select Edit->Delete all.


ΓòÉΓòÉΓòÉ 4.9.1.1.2. Delete All ΓòÉΓòÉΓòÉ

Choose Edit->Delete all from the monitor menu bar to delete all expressions and
variables in the monitor.

Note: If you delete an expression or variable and then later decide that you
want to monitor it, you must add it again from the Source window.


ΓòÉΓòÉΓòÉ 4.9.1.1.3. Disable ΓòÉΓòÉΓòÉ

Select Edit->Disable from the monitor menu bar, or Disable from the monitor
popup menu, to prevent the displayed contents of the selected variables or
expressions from being updated when they change.


ΓòÉΓòÉΓòÉ 4.9.1.1.4. Enable ΓòÉΓòÉΓòÉ

Select Edit->Enable from the monitor menu bar to have the debugger refresh the
displayed contents of the selected variables or expressions whenever they
change. Variables and expressions are enabled by default, so this choice is
only available if a variable or expression has been disabled.


ΓòÉΓòÉΓòÉ 4.9.1.1.5. Other Elements ΓòÉΓòÉΓòÉ

If an array, structure, or C++ class object in a monitor contains more than 50
elements, only 50 elements are displayed at a time. By default, the first 50
elements are displayed. To display a different range of elements, select
Edit->Other elements (or select Other elements from the monitor popup menu),
and enter the number of the first element to display.

You can change the default maximum of 50 elements to a different maximum by
setting the DEBUG_NUMBEROFELEMENTS environment variable on the local
workstation before starting the debugger.

In a C++ class object, elements are listed in declaration order, regardless of
their access specifier (private, protected or public).

The 50-element limit applies to each level within an array or a C++ class
object. For example, if a C++ class contains 100 member variables and the first
variable is a 60-element array, the debugger displays the name of the array
only (with a '+' to its left so that you can expand it) and the next 49
elements of the C++ class object. When you expand the array, the debugger
displays the first 50 elements of the array, and the next 49 elements of the
C++ class object. To view more elements of the array, position the pointer on
the array name and select Other elements. To view more elements of the C++
class object, position the pointer on the object name and select Other
elements.


ΓòÉΓòÉΓòÉ 4.9.1.1.6. Representation, Next Representation ΓòÉΓòÉΓòÉ

Select Edit->Representation, or Next representation from the monitor popup
menu, to change the representation of monitor contents.

Edit->Representation:

The available representations for the selected variable or element are shown in
a cascading menu. For example, for a 32-bit signed integer, the available
representations are decimal and hexadecimal.

Next representation (from the monitor popup menu, or from the  toolbar button):

The next representation of the selected variable or element is shown. The
debugger cycles through available representations in the same order as would be
shown in the Edit->Representation cascading menu list for the selected item.


ΓòÉΓòÉΓòÉ 4.9.2. Options Menu ΓòÉΓòÉΓòÉ

The Options menu of the Private and Program monitors contains the following
choices:

     Fonts

     Restore defaults

     Show enablement

     Show context

     Tool buttons

     Hover help

     Infoarea


ΓòÉΓòÉΓòÉ 4.9.2.1. Show Enablement ΓòÉΓòÉΓòÉ

You can disable a variable or expression within a monitor so that its displayed
contents are not updated when the variable or expression changes. Later you can
enable the variable or expression so that its contents are updated. Select
Options->Show enablement if you want the current enablement of each variable or
expression to be shown. A column appears that shows either 'Enabled' or
'Disabled' for each entry in the monitor.


ΓòÉΓòÉΓòÉ 4.9.2.2. Show Context ΓòÉΓòÉΓòÉ

Select Options->Show context from a monitor window to display the following
information in separate columns for each object or array:

      The source file name where the object or array is declared

     The line number

     The thread number

     The variable or expression name

 This information is only shown once for each object or array.


ΓòÉΓòÉΓòÉ 4.10. Program Monitor ΓòÉΓòÉΓòÉ

Use the Program monitor to collect variables or expressions that you want to
monitor. This monitor is not associated with any specific Source window, and is
always displayed unless you specifically close it. It is similar to the Private
monitor.

See the following for more information:

     Introduction to the Program monitor

     Monitor popup menu

     Menus, buttons, and shortcut keys

 Related Information

 Concepts
 Differences between Program and Private Monitors


ΓòÉΓòÉΓòÉ 4.10.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Program monitor provides the following menus, buttons, and shortcut keys:

     File Edit Options Windows Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]

 The Program monitor also has a popup menu. To access it, position the pointer
 in the content area of the window and click mouse button 2.


ΓòÉΓòÉΓòÉ 4.10.1.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Program monitor contains only one choice, Close Debugger.


ΓòÉΓòÉΓòÉ 4.11. Popup Menu for Private and Program Monitors ΓòÉΓòÉΓòÉ

When you select a variable or element in the Program monitor or a Private
monitor, and click mouse button 2, a popup menu appears with a subset of the
following choices:

     Edit

     Delete

     Disable

     Dereference (not available for COBOLor PL/I)

     Next representation

     Other elements


ΓòÉΓòÉΓòÉ 4.11.1. Edit Contents ΓòÉΓòÉΓòÉ

To edit the contents of a variable in a monitor, do one of the following:

     Select the line containing the variable, click mouse button 2, and select
      Edit from the popup menu

     Double-click on the content of the variable

     Use the cursor keys or the mouse to highlight the line containing the
      variable, and press Enter.

 Then enter a new value and press Enter. This value must be valid for the type
 of variable.

 Related Information

 Procedures
 Change the Contents of Storage, Variables, and Registers


ΓòÉΓòÉΓòÉ 4.11.2. Dereference ΓòÉΓòÉΓòÉ

Note: The Dereference choice is not available for COBOLor PL/I programs.

Choose Dereference from the popup menu in a Program, Private, or Local
Variables monitor to show the storage contents of the selected pointer
variable.

This choice is available only when the variable you have selected is a pointer,
or is an array or object name displayed in pointer representation (with a '>'
to its left). To change an array or object to pointer representation, choose
Edit->Representation from the menu bar, or Next representation from the popup
menu.


ΓòÉΓòÉΓòÉ 4.12. Local Variables Monitor ΓòÉΓòÉΓòÉ

Note: The Local Variables monitor is not available for debugging PL/I programs.

Use the Local Variables monitor to view all local variables that are currently
in scope. The Source window for each thread of your program has its own Local
Variables monitor.

See the following for more information:

     Introduction to the Local Variables monitor

     Local Variables popup menu

     Menus, buttons, and shortcut keys


ΓòÉΓòÉΓòÉ 4.12.1. Menus, Buttons, and Shortcut Keys ΓòÉΓòÉΓòÉ

The Local Variables monitor provides the following menus, buttons, and shortcut
keys:

     File Edit Options Windows Help

   

     [Ctrl+B->Session Control] [Ctrl+R->Run]

 The Local Variables monitor also has a popup menu. To access it, position the
 pointer in the content area of the monitor and click mouse button 2.


ΓòÉΓòÉΓòÉ 4.12.1.1. File Menu ΓòÉΓòÉΓòÉ

The File menu of the Local Variables monitor contains only one choice, Close
Debugger.


ΓòÉΓòÉΓòÉ 4.12.1.2. Edit Menu ΓòÉΓòÉΓòÉ

The Edit menu of the Local Variables monitor contains the following choices:

     Delete

     Select all

     Deselect all

     Other elements

     Representation


ΓòÉΓòÉΓòÉ 4.12.1.3. Options Menu ΓòÉΓòÉΓòÉ

The Options menu of the Local Variables monitor contains the following choices:

     Fonts

     Restore defaults

     Show context

     Tool buttons

     Hover help

     Infoarea


ΓòÉΓòÉΓòÉ 4.12.2. Popup Menu for the Local Variables Monitor ΓòÉΓòÉΓòÉ

When you select a variable or element in a Local Variables monitor and click
mouse button 2, a popup menu appears with a subset of the following choices:

     Edit

     Dereference (not available for COBOL)

     Delete

     Next representation

     Other elements


ΓòÉΓòÉΓòÉ 4.13. Debugger Dialogs ΓòÉΓòÉΓòÉ

You can get to help on the following debugger dialogs from here:

     Source List Dialog

     Exception Dialog

     Overloaded Dialog

     Source Filename Dialog

     Monitor Expression Dialog

     Post-Mortem Information Dialog

     Exception Filtering Dialog

     Startup Dialog

 See also the following main help pages:

     Main Debugger Windows

     Monitor Windows

     Other Help Topics

     Debugger Help Home Page


ΓòÉΓòÉΓòÉ 4.13.1. Debugger Properties Dialog ΓòÉΓòÉΓòÉ

Use the Debugger Properties dialog to define:

     Whether to keep displaying, minimize, or discard a Source window from
      which control has just passed

     Whether multiple views can be displayed.

     Whether clicking on mouse button 2 will perform a step command or bring
      up a popup menu.

 This dialog contains the following group boxes:

     Display at stop

     Old source disposition

     Settings

     Mouse button 2 behavior


ΓòÉΓòÉΓòÉ 4.13.1.1. Display at stop Group Box ΓòÉΓòÉΓòÉ

The Display at stop group box lets you control how many Source windows are
displayed at once, and how many Source windows the Old source disposition
setting applies to. The choices are:

 Only stopping thread Keeps, minimizes, or discards all views that are not the
           stopping thread.

 All threads Keeps, minimizes, or discards the views for old components within
           each thread.

 For example, if you select Only stopping thread, the Old source disposition
 applies to all the Source windows except the current view of the stopping
 thread. If you select All threads, the Old source disposition applies only to
 the Source windows for the components from which execution has just left
 within a thread.


ΓòÉΓòÉΓòÉ 4.13.1.2. Old source disposition Group Box ΓòÉΓòÉΓòÉ

The Old source disposition group box lets you control the behavior of Source
windows from which control has just passed. The choices are:

 Keep      Leaves old Source windows open

 Minimize  Changes old Source windows into icons

 Discard   Closes old Source windows

 Note: The setting of the Display at Stop group box affects what Source windows
 the Old source disposition choices apply to.


ΓòÉΓòÉΓòÉ 4.13.1.3. Settings Group Box ΓòÉΓòÉΓòÉ

The Settings group box contains the following:

     The Multiple views check box, which you can select to display more than
      one Source window for a particular object. If the check box is enabled,
      when you open a new window for an object, the first window stays open and
      is overlaid by the second one. If the check box is disabled, the first
      window is closed when a second window is opened. The default is not to
      display multiple Source windows.

     The Set breakpoints at entry points check box. If this check box is
      enabled, the debugger will set breakpoints at all functions for programs
      that were compiled and linked with debug information.


ΓòÉΓòÉΓòÉ 4.13.1.4. Mouse button 2 behavior Group Box ΓòÉΓòÉΓòÉ

The behavior of mouse button 2 within the Source window depends on the Mouse
button 2 behavior group box in the Debugger properties dialog (accessed from
the Source or Session Control windows through Options->Debugger
settings->Debugger properties).

Select one of the following check boxes to determine how mouse button 2 will
behave in the Source window.

 Popup menus Displays a popup menu, where one is available; otherwise does
           nothing.

 Step always Performs a step command.

 Popup menus and step in white space Displays a popup menu, when the pointer is
           over certain text (for example, a variable or a line number in the
           prefix area), and performs a step command when the pointer is over
           white space or over text for which no popup menu is available.

 C++ example:.If Popup menus and step in white space is checked, and you click
 mouse button 2 on the C++ source line int myVar=18;, a popup menu appears if
 the pointer is over int, myVar, or 18, and a step command is performed if the
 pointer is on white space or the = or ; symbols.

 COBOL example: If Popup menus and step in white space is checked, and you
 click mouse button 2 on the COBOL line MOVE 18 TO MYVAR., a popup menu appears
 if the pointer is over MOVE, 18, TO, or MYVAR, and a step command is performed
 if the pointer is on white space or the period.

 PL/I example: If Popup menus and step in white space is checked, and you click
 mouse button 2 on the PL/I source line MYVAR = 18;, a popup menu appears if
 the pointer is over MYVAR or 18, and a step command is performed if the
 pointer is on white space or the = or ; symbols.


ΓòÉΓòÉΓòÉ 4.13.2. Exception Dialog ΓòÉΓòÉΓòÉ

The Exception dialog is displayed whenever an exception is raised that matches
the exception category you specified in the Exception Filtering dialog. The
line where the exception occurred is highlighted in a Source window.

This dialog gives you three choices:

 Examine/Retry  Lets you investigate the cause of the exception and, if
           desired, retry executing the line that caused the original
           exception. The debugger begins with this line and attempts to
           continue.

 Step exception The debugger steps into the first registered exception handler
           (tracked by the operating system). Execution stops at the first
           executable line of code in that exception.

 Run exception The debugger runs the exception handler that is registered to
           handle the type of exception that was encountered.

 OS/2: For details on OS/2 exception definitions, see the Control Program
 Programming Reference (S10G-6263). The Software exception is not listed in
 this document, since this is a user-defined OS/2 exception generated by the
 DosRaiseException call.


ΓòÉΓòÉΓòÉ 4.13.3. Exception Filtering Dialog ΓòÉΓòÉΓòÉ

In the Exception Filtering dialog, select the exceptions you want the debugger
to recognize.

If an exception you selected is encountered during execution, the Exception
dialog opens. Exceptions you did not select are ignored when they occur.

If an exception is encountered during execution, and that exception is in an
exception category you selected, the Exception dialog opens. Otherwise the
exception is ignored.

OS/2: For details on OS/2 exception definitions, see the Control Program
Programming Reference (S10G-6263). The Software exception is not listed in this
document, since this is a user-defined OS/2 exception generated by the
DosRaiseException call.


ΓòÉΓòÉΓòÉ 4.13.4. Find Function Dialog ΓòÉΓòÉΓòÉ

To use the Find Function dialog:

   1. In the Function entry field, type the name of the function you want to
      locate. An error message appears if a matching function was not found.

   2. If you want to search only files that contain debugging information,
      enable the Debugging information only check box.

   3. If you want to search for the string exactly as typed, select the Case
      sensitive check box. Do not select it if you want to search for both
      uppercase and lowercase matches to the string.

   4. Select OK.

 If you specified a C++ function and the debugger finds more than one overload
 of the function you specified, an Overloaded dialog opens, listing the
 overloads of that function. Select the desired overload from that list.


ΓòÉΓòÉΓòÉ 4.13.5. Monitor Properties Dialog ΓòÉΓòÉΓòÉ

Use the Monitor Properties dialog to select the settings for monitoring
variables or expressions. You can set one check box in each of the following
group boxes (click on the Group box name for more information):

 Group box Purpose

 Monitor Location The window into which the variable or expression being
           monitored is placed.

 Popup Duration For a popup expression window, determines how long the monitors
           are displayed.


ΓòÉΓòÉΓòÉ 4.13.5.1. Monitor Location ΓòÉΓòÉΓòÉ

Choose one of the following radio buttons to determine which monitor will open
when you select a variable or expression to monitor.

     Popup monitor

     Private monitor

     Program monitor

     Storage monitor


ΓòÉΓòÉΓòÉ 4.13.5.2. Popup Duration ΓòÉΓòÉΓòÉ

If you selected Popup in the Monitor Location group box, select one of the
following radio buttons to specify at what point the popup expression window is
closed.

 Step/run  The monitor closes when the next step or run command is executed.

 New source The monitor closes when execution stops in a new source.

 Permanent The monitor is associated with a specific Source window, and is
           closed when that Source window is closed.


ΓòÉΓòÉΓòÉ 4.13.6. Open New Source Dialog ΓòÉΓòÉΓòÉ

Use the Open New Source dialog to open another Source window containing a new
executable or DLL for the program you are already debugging.

You may find it easier to open a new Source window by expanding components in
the Components pane of the Session Control window until you find the
compilation unit you want. The Open New Source dialog is useful for opening a
source view for a source file when you are unsure of the file name of the
executable that was created from that source file.

If you know the name of the source file, turn on the All executables check box
and type in the source file name, then select OK.

If you do not know the name of the source file, leave the Source field blank,
and turn off the All executables check box. You can then select an executable
from the Executable pulldown list.  If you want to view only those executables
compiled and linked with debug information, turn on the Debugging information
only check box.

Once you have chosen an executable, click on OK (or press Enter) and a Source
List dialog displays with a list of the compilation units for that executable.
From this Source List dialog, select the compilation unit you want to open a
Source window for.

Related Information

Reference
Environment Variables


ΓòÉΓòÉΓòÉ 4.13.7. Overloaded Dialog ΓòÉΓòÉΓòÉ

When you specify a C++ function in a debugger entry field (for example, when
you are setting a function breakpoint), and the debugger finds more than one
overload of that function, an Overloaded dialog appears, containing a list of
all functions with the name you specified. Choose the function from the
displayed list that matches the function you wanted.

A signature is the combination of return type and argument types that
distinguish a C++ function from other functions of the same name.


ΓòÉΓòÉΓòÉ 4.13.8. Postmortem Information Dialog ΓòÉΓòÉΓòÉ

Note: This dialog is only available on OS/2.

The Postmortem Information dialog opens when you select a postmortem dump file
to debug and you click on Postmortem info.

This dialog provides the following information about the dump file you are
using:

     The level of operating system that was running when the dump file was
      created

     A list of all executables and dynamic load libraries (DLLs) that were
      used by the program that caused the dump file to be created

     For each listed executable or DLL, whether is available ('found') on the
      machine you are doing the postmortem debugging from

     For each executable or DLL that is found, whether the version found on
      your system matches the version in the dump file.

 If the comment for an executable or DLL indicates that it was not found on
 your system, you will not have access to debug information for that module, so
 you cannot debug source code or view the contents of variables used in that
 module.

 If the comment indicates that the executable or DLL was found but did not
 match, the debug information in that module is of questionable value, because
 variables, code, or  entry points may be at different addresses within the
 module on your machine and on the machine where the dump occurred.

 Related Information

 Reference
 Postmortem Debugging


ΓòÉΓòÉΓòÉ 4.13.9. Source List Dialog ΓòÉΓòÉΓòÉ

The Source List dialog opens if you select an executable in the Open New Source
dialog but do not specify a new source file to open.

The lefthand pane contains the names of executable files, and the righthand
pane shows corresponding compile units. Select a compile unit from the list,
and either click on OK or press Enter.

You can resize the panes by dragging the split bar between them to the left or
right.


ΓòÉΓòÉΓòÉ 4.13.10. Source Filename Dialog ΓòÉΓòÉΓòÉ

The Source Filename dialog is displayed when you try to debug a component that
contains debugging data for which the source code cannot be located. To respond
to this dialog, do one of the following:

     If the source file is located in another directory on the system, type in
      the path name and select OK.

     If you do not have the source file for this component, select Cancel. A
      Source window in disassembly view opens for this component.


ΓòÉΓòÉΓòÉ 4.13.11. Startup Dialog ΓòÉΓòÉΓòÉ

Note: The Startup dialog is available for debugging both local and remote
client code, but for remote client code no list of remote executables is
available from the Browse pushbutton.

Use the Startup dialog to start debugging a program. This dialog opens when you
select File->Startup from a Source or Session Control window, or when you start
the debugger without specifying the name of a program to debug.

You can enter the name of an executable , or, for OS/2 only, a dump file, in
the Program entry field; select a recently debugged file from the pulldown list
on that field; or choose a file from a file selection dialog by clicking on the
Browse/File list button (after you have selected a file, you are returned to
the Startup dialog).

Once you have entered the necessary information, select OK or press Enter to
start the debugging session.

For information on other entry fields and check boxes on the Startup dialog,
click on the appropriate items below.

     Parameters

     Debug program initialization

     Use program profile

     Debug child processes, Child names, and Child List (OS/2 local debugging
      only)

     Process list (Windows 95, Windows NT)


ΓòÉΓòÉΓòÉ 4.13.11.1. Parameters ΓòÉΓòÉΓòÉ

Use the Parameters entry field in the Startup dialog to specify parameters for
your program. For example, if your program is designed to read a file name and
the /xyz option from the parameter list, in that order, enter:

filename /xyz

For local debug sessions, you can also specify parameters for your program when
you invoke the debugger from the operating system command line or a batch,
command,  or similar file.

Related Information

Procedures
Invoke the Debugger


ΓòÉΓòÉΓòÉ 4.13.11.2. Debug Program Initialization ΓòÉΓòÉΓòÉ

Click on the Debug program initialization check box in the Startup dialog if
you want to debug code that executes before the main function is called. The
principal reason you might want to do this is if you are debugging C++ code and
you want to debug the constructors for your globally declared C++ class objects
(because such objects are constructed before main is entered).


ΓòÉΓòÉΓòÉ 4.13.11.3. Use Program Profile ΓòÉΓòÉΓòÉ

The Use program profile check box in the Startup dialog lets you specify
whether the window sizes, positions, fonts, and breakpoints for your program
are to be saved when you exit the debugger or switch to another program. If you
check this check box, then the next time you load that program, the windows and
breakpoints are restored to match their previous configuration for that program
to save debugger window settings and breakpoints when debugging a program more
than once.

This check box is turned on by default. Turn it off if you do not want this
information to be saved. When the check box is off, the debugger windows start
up with their default appearance, and no breakpoints are initially set.

Note: If you add or delete lines in your source file, recompile it, and then
debug the program again with a saved program profile, line breakpoints may no
longer match the code they were initially set for, as line breakpoint
information is saved by line number, not by the content of the line.


ΓòÉΓòÉΓòÉ 4.13.11.4. Process List Push button ΓòÉΓòÉΓòÉ

The Process list button on the Startup dialog (Windows 95, Windows NT, and AIX
only) opens a Process list dialog. You can then select an already running
process to debug, instead of an executable. The Process list dialog is also
accessible from the File menu of the Source and Session Control windows.


ΓòÉΓòÉΓòÉ 4.13.11.5. Select Child Process (OS/2) ΓòÉΓòÉΓòÉ

Note: Debugging child processes is only supported on OS/2.

Use the Select Child Processes dialog to browse through your file system and
select a child process to debug. The default file extension to search for (and
the only valid one for a child process) is .EXE. Choose the executable or
executables that your program invokes as child processes.

You can select several executables, provided they all reside in the same
directory.

To select several executables with the mouse, click on the first executable
name in the File list. For additional executables, hold down the Shift key and
click on each additional executable.

To select several executables with keystrokes, tab to the File list. Use the
cursor keys to move up or down the list, and press the space bar to select each
executable you want to add.


ΓòÉΓòÉΓòÉ 4.13.11.6. Debug Child Processes (OS/2) ΓòÉΓòÉΓòÉ

Click on the Debug child processes check box in the Startup dialog if you want
to debug child processes that are started by a parent program. When you enable
this check box, the Child process(es) entry field becomes active.

When you select Debug child processes, the debugger does not stop in the main
function of the program, and does not stop at any breakpoints set in your
program. Instead, execution proceeds until the first invocation of a child
process whose name you identified in the Child process(es) entry field.

In the Child process(es) entry field, you can type the name of the executable
file for the child process you want to debug. If you do not know the child
process executable name, click on the File List pushbutton to open the Open
dialog. From this dialog, you can browse your file system for the executable
that gets invoked as a child process of your program.


ΓòÉΓòÉΓòÉ 4.14. Toolbar Buttons, Shortcut Keys, and Common Menu Items ΓòÉΓòÉΓòÉ

Each window of the debugger provides a subset of the following toolbar buttons,
shortcut keys, and menu choices:

     Toolbar buttons:

     Shortcut keys: [Ctrl+B] -->Raise Session Control window [Ctrl+R] -->Run
      (The Source window and Session Control window have their own specialized
      sets of shortcut keys.)

     Menu choices:

      File Edit Monitors Run Options Windows Help Project


ΓòÉΓòÉΓòÉ 4.14.1. Toolbar Buttons ΓòÉΓòÉΓòÉ

Toolbar buttons let you quickly access a wide range of commands and windows
from the Source and Session Control windows, and a lesser range from other
windows. These buttons are displayed when the Tool buttons item is set from a
window's Options menu (or from a menu beneath Options). The following toolbar
buttons are available:


ΓòÉΓòÉΓòÉ 4.14.1.1. Call Stack Button ΓòÉΓòÉΓòÉ

Click on the  button to open or raise a Call Stack window containing the
contents of the call stack for the current thread. This is the same as
selecting Monitors->Call Stack or typing Ctrl+K.


ΓòÉΓòÉΓòÉ 4.14.1.2. Delete All Button ΓòÉΓòÉΓòÉ

Click on the  button to delete all breakpoints in a breakpoint list, or to
delete all variables and expressions in a monitor.


ΓòÉΓòÉΓòÉ 4.14.1.3. Delete Button ΓòÉΓòÉΓòÉ

Click on the  button to delete the selected breakpoint in a breakpoint list, or
to delete the selected variable or expression in a monitor.


ΓòÉΓòÉΓòÉ 4.14.1.4. Session Control Button ΓòÉΓòÉΓòÉ

Click on the  button to bring the Session Control window into focus.


ΓòÉΓòÉΓòÉ 4.14.1.5. Edit Button ΓòÉΓòÉΓòÉ

Note: This button is only supported for versions of the debugger installed with
an IBM VisualAge product, and is only shown if the debugger was invoked from a
WorkFrame project.

Click on the  button to open or raise an editor window containing the current
source file.


ΓòÉΓòÉΓòÉ 4.14.1.6. Monitor Expression Button ΓòÉΓòÉΓòÉ

Click on the  button from the Source window to add a variable or expression to
one of the debugger monitors. In the Monitor expression dialog that opens,
enter a variable or expression to monitor.

If you highlight a variable or expression before you press the Monitor
expression button, that variable or expression is automatically placed in the
Monitor expression dialog.

See Expressions Supported for information on what types of expressions the
debugger supports.


ΓòÉΓòÉΓòÉ 4.14.1.7. Project Button ΓòÉΓòÉΓòÉ

Note: This button is only supported for versions of the debugger installed with
an IBM VisualAge product, and is only shown if the debugger was invoked from a
WorkFrame project.

Click on the Project button to open or raise the WorkFrame.


ΓòÉΓòÉΓòÉ 4.14.1.8. Registers Button ΓòÉΓòÉΓòÉ

Click on the  button to open or raise a Registers monitor containing the
contents of processor registers for the current thread. This is the same as
selecting Monitors->Registers or typing Ctrl+E.


ΓòÉΓòÉΓòÉ 4.14.1.9. Storage Button ΓòÉΓòÉΓòÉ

Click on the  button to open or raise a Storage monitor, which you can use to
display storage used by your program. This is the same as selecting
Monitors->Storage or typing Ctrl+G.


ΓòÉΓòÉΓòÉ 4.14.1.10. Breakpoints Button ΓòÉΓòÉΓòÉ

Click on the  button to open or raise the Breakpoints list window, which you
can use to view, set, clear, disable, or enable breakpoints. This is the same
as selecting Breakpoints->List or typing Ctrl+X.


ΓòÉΓòÉΓòÉ 4.14.2. Common Menu Choices ΓòÉΓòÉΓòÉ

A subset of the following menus appears on many debugger windows:

     File

     Edit

     Options -- you can view help for a short list of common options, or a
      complete list of all available options

     Monitors

     Run

     Windows

     Help

 The help for each debugger window contains appropriate links to the menus it
 supports.


ΓòÉΓòÉΓòÉ 4.14.2.1. File Menu ΓòÉΓòÉΓòÉ

A subset of the following menu choices appears on the File menu of many
debugger windows:

     Open new source

     Locate function

     Where is execution point -- [Ctrl+P]

     Startup

     Process list window

     Close debugger -- [F3]

 The help for each debugger window contains appropriate links to the File menu
 choices it supports.


ΓòÉΓòÉΓòÉ 4.14.2.1.1. Open New Source ΓòÉΓòÉΓòÉ

Note: The Open new module choice on the File menu is available only on the
Source and Session Control windows.

Select this choice when you want to view a source file that is associated with
your application, but is not currently shown in a Source window. The Open New
Source dialog displays.

Note: Open new source does not change the program being debugged. The source
file you select must be one that is used by the program you are currently
debugging. If instead you want to switch to debugging a different program,
select Startup from the File menu.


ΓòÉΓòÉΓòÉ 4.14.2.1.2. Where is Execution Point ΓòÉΓòÉΓòÉ

Select Where is execution point from the File menu to view the next line to be
executed. If the file containing that line is already in a Source window, that
Source window has its focus raised; otherwise, a new Source window opens. The
next line to be executed is highlighted and has the cursor on it.


ΓòÉΓòÉΓòÉ 4.14.2.1.3. Startup ΓòÉΓòÉΓòÉ

Select Startup from the File menu to open a Startup dialog.


ΓòÉΓòÉΓòÉ 4.14.2.1.4. Process List (Windows NT and Windows 95 Only) ΓòÉΓòÉΓòÉ

Note: The Process List dialog, menu choice, and pushbutton are only available
on platforms that support process debugging (Windows 95, Windows NT).

Select Process List on the File menu, or the Process List pushbutton in the
Startup dialog, to open a Process List dialog. This dialog lets you attach to a
specific process that you want to debug.

To select a process to debug:

   1. Type the full path name of the process you want to debug in the Process
      path entry field.

      The debugger requires this path to locate the executable for the process
      so that it can load the debugging information contained in the
      executable. If you do not specify a process path, you can only see the
      disassembly view in the Source window for the process.

   2. Double-click on the process, or select the process you want to debug from
      the list, then press Enter or select the Attach push button.

 Note: In Windows 95 and Windows NT, if you are currently debugging a process,
 that process is terminated when a new process is attached. When you exit the
 debugger, any attached process is also terminated. Do not attach to operating
 system processes, or to the debugger's own process. Attaching to such
 processes can cause unpredictable results.

 Use program profile Check Box

 Select the Use program profile check box to start the debugging session with
 program profile information. If the executable associated with the process you
 attach to was previously debugged, its program profile is used to determine
 window positions and sizes.

 Push Buttons

 Attach    Attaches the process you selected so that you can begin debugging
           it.

 Refresh   Refreshes the list, removing processes that have terminated, and
           adding ones that started since the Process List dialog opened or
           since the last refresh.

 Related Information

 Reference
 When to Use the Process List Dialog


ΓòÉΓòÉΓòÉ 4.14.2.1.5. Close Debugger ΓòÉΓòÉΓòÉ

Select Close debugger from the File menu to end the program you are debugging
and exit the debugger.

When you close the debugger, the window positions, sizes, and other settings
such as breakpoints are saved in a program profile. This profile is used the
next time you debug that program, to establish startup settings for the new
debug session.

Note: If you attached the debugger to an already running process, closing the
debugger also terminates the process.


ΓòÉΓòÉΓòÉ 4.14.2.2. Edit Menu ΓòÉΓòÉΓòÉ

A subset of the following menu choices appears on the Edit menu of many
debugger windows:

     Delete

     Select all

     Deselect all

 The help for each debugger window contains appropriate links to the menu
 choices it supports.


ΓòÉΓòÉΓòÉ 4.14.2.2.1. Delete ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [Delete] Menu: Edit->Delete (from Breakpoints List
window, and Program, Private, and Local Variables monitors)

Delete deletes the highlighted item or items in the current window. In a
Monitor window, the selected expressions or variables are deleted. In a
Breakpoint List window, the selected breakpoint is deleted (you can only select
one breakpoint at a time).

Note: When you delete a breakpoint, all information on it is lost. If you need
to temporarily prevent a breakpoint from stopping execution but you want to be
able to easily activate it later, you should disable it instead, by selecting
Edit->Disable.

Related Information

Procedures
Enable and Disable Breakpoints


ΓòÉΓòÉΓòÉ 4.14.2.2.2. Select All ΓòÉΓòÉΓòÉ

Select Edit->Select all from a Program or Private monitor to select all the
variables and expressions shown in the monitor. You can then individually
deselect certain variables, and use one of the available Edit menu choices to
delete, enable, or disable the remaining selected variables.


ΓòÉΓòÉΓòÉ 4.14.2.2.3. Deselect All ΓòÉΓòÉΓòÉ

Select Edit->Deselect all from a monitor to deselect all selected variables and
expressions shown in the monitor.


ΓòÉΓòÉΓòÉ 4.14.2.3. Options Menu ΓòÉΓòÉΓòÉ

The following Options menu choices are shared by several debugger windows:

 Fonts     Lets you change the font for the current window.

 Restore defaults Resets all settings for this window to the debugger defaults
           for the window.

 Tool buttons Determines whether the toolbar buttons are displayed in the
           window.

 Hover help Enables or disables hover help, which provides brief descriptions
           of menu choices and toolbar buttons when the pointer is placed over
           them.

 Infoarea  Enables or disables the window's information area, which provides
           longer textual descriptions of menu choices and toolbar buttons when
           the pointer is placed over them.


ΓòÉΓòÉΓòÉ 4.14.2.4. Monitors Menu ΓòÉΓòÉΓòÉ

A subset of the following menu choices appears on the Monitors menu of the
Source and Session Control windows:

     Monitor expression

     Call Stack

     Registers

     Storage

     Local variables

 The help for each debugger window contains appropriate links to the menu
 choices it supports.


ΓòÉΓòÉΓòÉ 4.14.2.4.1. Monitor Expression ΓòÉΓòÉΓòÉ

Select Monitors->Monitor expression to open a Monitor expression dialog. Here,
you can enter a variable or expression to monitor, and select what monitor to
display it in.


ΓòÉΓòÉΓòÉ 4.14.2.4.2. Call Stack ΓòÉΓòÉΓòÉ

Select Monitors->Call Stack to open a Call Stack window for the current thread.
Here, you can view the contents of the call stack to determine what calls are
currently in progress.


ΓòÉΓòÉΓòÉ 4.14.2.4.3. Registers ΓòÉΓòÉΓòÉ

Select Monitors->Registers to open a Registers monitor. Here, you can view or
alter the contents of registers for the processor of the machine that the
program being debugged is running on.


ΓòÉΓòÉΓòÉ 4.14.2.4.4. Storage ΓòÉΓòÉΓòÉ

Select Monitors->Storage to open a Storage monitor. Here, you can view or alter
the contents of storage used by your program.


ΓòÉΓòÉΓòÉ 4.14.2.4.5. Local Variables ΓòÉΓòÉΓòÉ

Select Monitors->Local variables to open a Local Variables monitor. Here, you
can view or alter the contents of variables that are currently in scope for a
given thread. When you select this choice from a Source window, the Local
Variables monitor uses the thread for that Source window. When you select it
from the Session Control window, the Local Variables monitor uses the currently
highlighted thread in the Threads pane.


ΓòÉΓòÉΓòÉ 4.14.2.5. Run Menu ΓòÉΓòÉΓòÉ

Use the Run menu to perform step commands, run your program, restart the
debugging session, hide debugger windows, enable heap check, and enable or
disable threads. It contains the following choices:

     Step over -- [O]

     Step into -- [I]

     Step debug -- [D]

     Step return -- [T]

     Run -- [R]

     Halt -- [SysRq]

     Restart

     Run to location -- [L]

     Jump to location -- [N]

     Hide debugger on Run

     Check heap when stopping (not available for COBOL or PL/I programs)

     Thread enabled

 Shortcut keys (shown above in brackets) and toolbar buttons are available for
 many of the Run menu choices. See the help panels for these choices for more
 information.


ΓòÉΓòÉΓòÉ 4.14.2.5.1. Hide Debugger on Run ΓòÉΓòÉΓòÉ

Select Run->Hide debugger on Run to hide the debugger windows when your program
is running. This option does not affect the windows when you are stepping
through your program.


ΓòÉΓòÉΓòÉ 4.14.2.5.2. Check Heap When Stopping ΓòÉΓòÉΓòÉ

Note: This choice is disabled, and heap checking is unavailable, when the
dominant language is COBOL or PL/I (that is, when the environment variable
DEBUG_LANG is set to COBOL or to PL1).

Select Run->Check heap when stopping to check all memory blocks allocated or
freed by the runtime memory management functions. This makes sure that
overwriting has not occurred outside the bounds of allocated blocks, and that
free memory blocks have not been overwritten.

If Check heap when stopping is enabled, the heap is checked each time the
program stops. For example, the heap check is performed at each breakpoint or
after each step command. If a heap error is detected, your application
terminates. The Termination dialog displays showing the source line number
where the application stopped and the heap check was performed.

Related Information

Reference
Notes on Check Heap when Stopping


ΓòÉΓòÉΓòÉ 4.14.2.5.3. Thread Enabled ΓòÉΓòÉΓòÉ

Select Run->Thread enabled to allow the thread that is highlighted in the
Threads box of the Session Control window to execute when the program runs.
When threads are enabled, a check mark is displayed beside the Thread enabled
choice. This is the default setting.

When threads are not enabled, no check mark is displayed and the highlighted
thread is not executed when the program is run.


ΓòÉΓòÉΓòÉ 4.14.2.5.4. Restart ΓòÉΓòÉΓòÉ

Select Run->Restart to start the debugging session again. Restart closes all
debugger windows except the Session Control window, and then restarts your
debugging session.

If you want to debug a different program, use File->Startup instead.


ΓòÉΓòÉΓòÉ 4.14.2.6. Project ΓòÉΓòÉΓòÉ

The Project menu is available when you have loaded the debugger from a
Workframe project. Use it to perform project-related tasks. The list of choices
depends upon the type of project, the platform, and the language. See the
WorkFrame online help for further information on the choices.


ΓòÉΓòÉΓòÉ 4.14.2.7. Options Menu ΓòÉΓòÉΓòÉ

Use the Options menu to change the appearance and behavior of the debugger. You
can change settings for the particular window from which you access the menu,
and settings for the debugger itself. This menu contains the following choices:

     Window settings

     Debugger settings


ΓòÉΓòÉΓòÉ 4.14.2.7.1. Window Settings ΓòÉΓòÉΓòÉ

Select the Window settings cascading choices to modify these settings for the
window from which you access the Options menu:

 Colors    (Source window only) Lets you change the colors used in the Source
           window.

 Fonts     (Source window only) Lets you change the font for the Source window.
           Only fixed-pitch fonts are available.

 Display style Opens a dialog where you can specify how information in this
           window should appear. Additional help is available for the Session
           Control window.

 Monitor expression (Storage monitor only) Opens a Monitor Expression in
           Storage dialog, where you can enter an expression for monitoring in
           storage.

 Restore defaults Resets all settings for this window to their original values.

 Notebook  (Source window only) Displays source files within the Source window
           in a notebook format.

 Tool buttons Displays or hides the toolbar buttons for the window.

 Hover help Enables or disables hover help, which provides brief descriptions
           of menu choices and toolbar buttons when your pointing device passes
           over them.

 Infoarea  Enables or disables the window's information area, which provides
           longer textual descriptions of menu choices and toolbar buttons when
           your pointing device passes over them.


ΓòÉΓòÉΓòÉ 4.14.2.7.2. Debugger Settings ΓòÉΓòÉΓòÉ

Select the Debugger settings cascading choices to modify debugger settings:

     Debugger properties

     Monitor properties

     PM debugging mode (OS/2 only)

     Default data representation

     Program profiles

     Exception filtering

     Save debugger window positions

     Global font change

     Enable window cascading

     Display tool buttons -- shows the toolbar buttons at the top of each
      window

     Display hover help -- displays a help bubble, when one is available, near
      the pointer when you move the pointer over a tool button

     Display infoarea -- displays a line of help, when one is available, at
      the bottom of the window when you move the pointer to a new area of the
      window.

     Place tool buttons on title bar -- places the tool buttons for each
      window on its title bar rather than below the menu bar. This choice is
      only supported when the debugger's user interface is running under OS/2.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.1. Default Data Representation ΓòÉΓòÉΓòÉ

Select Options->Debugger settings->Default data representation to specify how
you want your data represented in the monitors. A cascading menu appears with
choices for 'system' and for the languages supported by the debugger.

System: You can select either floating point or hexadecimal. This setting
affects only the representation used for floating point registers in the
Registers monitor.

Language-specific representations: For each language supported by the debugger,
a cascading menu choice appears from the Default data representation menu. The
dialog for the language you select contains a group box for each data type that
is supported by the debugger's expression evaluator for that language. You can
change the default representation for a data type by clicking on the
appropriate radio button within that data type's group box.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.2. Program Profiles ΓòÉΓòÉΓòÉ

Select Options->Debugger settings->Program profiles to specify where you want
the debugger program profiles stored, what profile information to save, or what
profiles to delete. This menu has three choices:

 Select information Select the types of information to save in the program
           profile. If Save profile information is checked, your changes to
           this list will be saved for future debugging sessions. If it is not
           checked, your changes will only affect profiles saved until you exit
           this session of the debugger.

 Delete program profiles A dialog opens with a list of program profiles. Select
           those profiles you want to delete, and click on OK. Profile
           filenames are similar to their associated program filenames,but have
           an extension that contains the character '@'.

 Change location Change the location of the files that hold the debugger
           settings. Enter the new path for program profiles in the Change
           location dialog.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.3. Exception Filtering ΓòÉΓòÉΓòÉ

Select Options->Debugger settings->Exception filtering to open the Exception
Filtering dialog. Select the exceptions that you want the debugger to
recognize.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.4. Exception List ΓòÉΓòÉΓòÉ

The following table shows the named exceptions that ITRAPPER can trap on. You
can also specify up to 8 additional exception numbers in decimal, octal, or
hex, where each such number is specified in a form suitable for input to the
stroul() function of the C library.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéException Name                        ΓöéDefault State                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_DATATYPE_MISALIGNMENT            ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_BREAKPOINT                       ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_SINGLE_STEP                      ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_ACCESS_VIOLATION                 ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_ILLEGAL_INSTRUCTION              ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_FLOAT_DENORMAL_OPERAND           ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_DIVIDE_BY_ZERO                   ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_FLOAT_INEXACT_RESULT             ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_FLOAT_INVALID_OPERATION          ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_FLOAT_OVERFLOW                   ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_FLOAT_STACK_CHECK                ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_FLOAT_UNDERFLOW                  ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_INTEGER_DIVIDE_BY_ZERO           ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_INTEGER_OVERFLOW                 ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_PRIVILEGED_INSTRUCTION           ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_IN_PAGE_ERROR                    ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_NONCONTINUABLE_EXCEPTION         ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_INVALID_DISPOSITION              ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_INVALID_LOCK_SEQUENCE            ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_ARRAY_BOUNDS_EXCEEDED            ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_B1NPX_ERRATA_02                  ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_BAD_STACK                        ΓöéOn                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_GUARD_PAGE_VIOLATION             ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_UNABLE_TO_GROW_STACK             ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_PROCESS_TERMINATE                ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_ASYNC_PROCESS_TERMINATE          ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_UNWIND                           ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_INVALID_UNWIND_TARGET            ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_SIGNAL                           ΓöéOff                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéXCPT_C++                              ΓöéOff                                  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 4.14.2.7.2.5. Save Debugger Window Positions ΓòÉΓòÉΓòÉ

Select Options->Debugger Settings->Save debugger window positions to save the
position and size of each debugger window that is currently open, so that these
settings are used the next time you start the debugger.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.6. Global Font Change ΓòÉΓòÉΓòÉ

Select Debugger Settings->Global font change to change the font in all debugger
windows. (The font you choose affects all debugger windows except Source
windows.)


ΓòÉΓòÉΓòÉ 4.14.2.7.2.7. Enable Window Cascading ΓòÉΓòÉΓòÉ

Select Debugger Settings->Enable window cascading to display newly opened
debugger windows offset to the right of and below previous windows, so that you
can see the titles of previous windows.

If this choice is disabled, successive windows will overlay earlier ones.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.8. PM Debugging Mode (OS/2 Only) ΓòÉΓòÉΓòÉ

Note: Available on OS/2 local debugging only.

Use the PM Debugging Mode dialog to set the debugging mode to asynchronous or
synchronous, and to control the interaction between the program windows and PM,
while the application has stopped executing.

     Debugging Mode group box

        -  Synchronous radio button

        -  Asynchronous radio button

     Program Windows group box

        -  No painting

        -  Color invalid areas

        -  Restore

        -  Repaint

     Invalid Area Color

 Related Information

 Procedures
 Debug PM Applications


ΓòÉΓòÉΓòÉ 4.14.2.7.2.9. Synchronous ΓòÉΓòÉΓòÉ

Synchronous radio button in PM debugging mode dialog

Note: This section applies to OS/2 only.

When the debugger is operating in synchronous mode, the messages that are
passed between PM applications are answered by their target applications in the
order that they were created. The messages that are passed within the debugger
take priority over any other messages that are passed in the system. When the
program being debugged is stopped and the debugger is in synchronous mode,
other PM applications are locked, leaving the debugger free to operate. In
synchronous mode, you will not be able to use any other PM applications that
are running.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.10. Asynchronous ΓòÉΓòÉΓòÉ

Asynchronous radio button in PM debugging mode dialog

Note: This section applies to OS/2 only.

When the debugger is operating in asynchronous mode and the program you are
debugging is stopped, the debugger responds immediately to messages that have
been sent to the program being debugged on this program's behalf. The debugger
answers the messages with a simple default response, freeing up other processes
to operate while the debugger has control. When you are running the debugger in
asynchronous mode, other PM applications running in the system are not blocked
when the program being debugged stops.

Caution: Do not operate the debugger in asynchronous mode if the PM application
that you are debugging requires the appropriate response to its messages. For
example, a dynamic data exchange (DDE) message would require the appropriate
response.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.11. Color Invalid Areas ΓòÉΓòÉΓòÉ

Color invalid areas radio button in PM debugging mode dialog

The Color invalid areas option works only in asynchronous mode. This option
paints the invalid areas in a solid fill color. You can change the color by
selecting a different one from the Invalid area color combination box.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.12. Invalid Area Color ΓòÉΓòÉΓòÉ

Invalid area color selection list in PM debugging mode dialog

Select the color that is to be used to repaint the invalid area of an
application window. Depending on the original color of the application window,
certain colors will be more appropriate for repainting. The color you choose is
used when you select the Color invalid areas, Restore, or Repaint options.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.13. No Painting ΓòÉΓòÉΓòÉ

No painting radio button in PM debugging mode dialog

None of the invalid areas of the window are repainted.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.14. Repaint ΓòÉΓòÉΓòÉ

Repaint radio button in PM debugging mode dialog

The Repaint option restores the application window with the last available
image. The image you can regain consists of the last available image when a
step or run command ended, minus any parts of the window that were covered when
that command ended. The parts of the window that were covered are filled with
the solid color you chose from the Invalid area color combination box. The
Repaint option differs from the Restore option. It interrupts the normal
debugging process of the window as follows:

     The program windows will not receive any screen interaction messages
      while the application is stopped. For example, the application will not
      receive any of the WM_MOUSEMOVE or WM_PAINT messages that were generated
      while the application was stopped.

     An extra WM_PAINT message is generated for the program windows when
      execution resumes.

      Note: The program windows might not process the WM_PAINT message
      depending on where the breakpoints are set or on which step or run
      command was selected.


ΓòÉΓòÉΓòÉ 4.14.2.7.2.15. Restore ΓòÉΓòÉΓòÉ

Restore radio button in PM debugging mode dialog

The Restore option works only in asynchronous mode. It restores the application
window with the last available image of the window. The image that you can
regain consists of the last available image when a step or run command ended,
minus any parts of the window that were covered when that command ended. The
parts of the window that were covered are filled with the solid color you chose
from the Invalid area color combination box.


ΓòÉΓòÉΓòÉ 4.14.2.7.3. Windows Menu ΓòÉΓòÉΓòÉ

The Windows menu lists the currently open debugger windows, including Source
windows, monitors, the Breakpoints List window, and the Session Control window.
To switch to a different window, select this menu from any window where the
option is available, and click on the window you want to go to.

When you minimize the debugger, some of its windows may not be on the list of
windows displayed by the operating system. To access a minimized window not on
the window list, select the Session Control window, then use the Windows menu
to access the window you want.


ΓòÉΓòÉΓòÉ 4.14.2.7.4. Help ΓòÉΓòÉΓòÉ

The Help menu provides help for the current window and for other help on the
debugger.  The following choices are available:

     Help index -- displays a list of index entries within the help file.

     General help -- displays high-level help for the current window.

     Using help -- displays help on how to access and use help features of the
      debugger.

     How do I -- displays task-oriented help for common debugger tasks.

     Product information -- displays the logo screen for the debugger.

 If you want to search for a string within a help file, click on Search from
 the help window, enter the search string in the entry field, select All
 sections, and click on Search.


ΓòÉΓòÉΓòÉ 4.14.3. Step Into ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [I] Menu: Run->Step into (from Source window)

The Step Into command executes the current line in the program. If the current
line is a call, execution halts at the first statement in the called function,
or, if debug information is not available for that function, at the first
disassembly instruction in the called function.


ΓòÉΓòÉΓòÉ 4.14.4. Step Over ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [O] Menu: Run->Step over (from Source window)

The Step Over command executes the current line in the program. If the current
line is a call, execution stops at the line following the call.

If you step over a function that contains a breakpoint, execution stops at the
breakpoint.


ΓòÉΓòÉΓòÉ 4.14.5. Step Debug ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [D] Menu: Run->Step debug (from Source window)

The Step Debug command executes the current line in the program. If the current
line is a call, and debug information is available for any function called
before the return to the current function, execution halts at the first
statement for which debug information is available. If no debug information is
available, execution halts after the call.

For example, if A calls B and A is compiled without debug information, while B
is compiled with debug information, after a Step Debug from a call to A,
execution will stop at the first executable statement of B.

C++ only: If the current line contains a complex call (for example
p->memberFunc1()->memberFunc2().memberFunc3(func1(), func2())), the debugger
examines each call (and any calls beneath it) for functions containing debug
information, and steps into the first such function.The order in which it
examines the calls is based on the order of the calls in the assembly code,
which is not necessarily the order in which the calls appear in the source
code. If you want to do a step debug into a particular function with debug
information in a complex call, switch to mixed view, select the assembly code
line containing the call to the function you want to debug, do a run to
location, and then do a Step Debug into the function.

Note: Because of the more complex analysis the debugger must do to check for
debuggable code during a Step Debug command, the performance of Step Debug may
be slower than that of the Step Over command. Certain high-level COBOL
statements, such as the Report Writer's GENERATE may be particularly slow using
Step Debug. In such cases you can achieve much improved performance by using
Run to location from the line containing the next executable statement.


ΓòÉΓòÉΓòÉ 4.14.6. Step Return ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [T] Menu: Run->Step return (from Source window)

The Step Return command executes the code up to and including the return
statement of the current function. Execution halts at the line following the
call to the current function.


ΓòÉΓòÉΓòÉ 4.14.7. Run ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [R] from Source/Session Control windows, [Ctrl+R] from
other windows Menu: Run->Run (from Source/Session Control windows)

Run executes the program. The debugger starts executing where it last stopped
(for example, at a breakpoint) or, if you have not yet run the program in this
session, at the beginning of the program. When you select Run, execution
continues until one of the following occurs:

     You select Halt

     The debugger encounters a breakpoint

     An exception is encountered that is not handled

     The program terminates

     You close the debugger

 Related Information

 Procedures
 Run a Program


ΓòÉΓòÉΓòÉ 4.14.8. Halt ΓòÉΓòÉΓòÉ

Button:  Shortcut key: [SysRq] Menu: Run->Halt (from Source/Session Control
windows)

Halt, which is available only while the program is running, stops execution
immediately. The Source window is updated with the current line set to the next
line to be executed.  If you issued the halt while the debugger was executing a
section of code without debug information, the Source window displays the
current context in disassembly mode. Otherwise it displays the current context
in the most recently used view (source, mixed, or disassembly).


ΓòÉΓòÉΓòÉ 4.14.9. Jump to Location ΓòÉΓòÉΓòÉ

Shortcut key: [N] Menu: Run->Jump to location (from Source/Session Control
windows)

Jump to location makes the currently highlighted line in the Source window the
current line, without executing any code. You can view an example in C++ COBOL
or PL/I to see how Jump to location works.

Caution: When you jump to a location, you may alter the flow of your program in
ways that make it difficult to continue debugging later in the same session:

     The stack can become corrupted if you jump to a location outside the
      current function.

     Some compilers optimize register usage in ways that can corrupt variables
      or program flow when you use Jump to Location. For example, if the
      compiler keeps track of register contents and can determine that a
      register contains the value 1 at the start of a statement that
      initializes an integer variable to 1, it may simply copy that register's
      contents to the variable. If you step over the statement that involved
      setting the register to 1, the variable may not contain the expected
      contents.

 After you have done the debugging for which you needed to alter the program
 flow, you may want to restart your program, to ensure that program flow is not
 arbitrarily or unexpectedly altered by code you jumped over.


ΓòÉΓòÉΓòÉ 4.14.10. Run to Location ΓòÉΓòÉΓòÉ

Shortcut key: [L] Menu: Run->Run to location (from Source/Session Control
windows)

Run to location executes the program up to the currently highlighted line in
the Source window. The debugger starts executing where it last stopped (for
example, after a breakpoint) or, if you have not yet run the program in this
session, at the beginning of the program. When you select Run to location,
execution continues until one of the following occurs:

     Execution reaches the location (the line) you selected in the Source
      window

     You select Halt

     The debugger encounters a breakpoint

     An exception is encountered that is not handled

     The program terminates

     You close the debugger


ΓòÉΓòÉΓòÉ 4.14.11. Session Control ΓòÉΓòÉΓòÉ

Button:  Menu: Windows->Session Control Keystroke: Control-B

Use this button, menu selection, or shortcut key to raise the Session Control
window.


ΓòÉΓòÉΓòÉ 4.14.12. Local Variables ΓòÉΓòÉΓòÉ

Menu: Monitors->Local variables Keystroke: Ctrl+V

Opens or raises a Local Variables window, which displays the names and contents
of variables that are in scope within the current thread or function.


ΓòÉΓòÉΓòÉ 4.14.13. Delete ΓòÉΓòÉΓòÉ

Select Edit->Delete from a Local Variables monitor, or Delete from a monitor
popup menu, to delete the selected expressions from the monitor.

To delete all expressions, select Edit->Select all, then Edit->Delete.


ΓòÉΓòÉΓòÉ <hidden> Run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Session Control Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete All Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Session Control Window ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Open New Source ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Where is Execution Point ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Startup ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Find Function Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Line ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Function ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Address ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Storage Change ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Load Occurrence ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete all ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitors Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Call Stack Window ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Registers Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Storage Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Local Variables Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Run Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Halt ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Restart ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Hide Debugger on Run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Check Heap When Stopping ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Thread Enabled ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Debugger Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Debugger Properties Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Properties Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> PM Debugging Mode (OS/2 Only) ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Default Data Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Exception Filtering ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Save Debugger Window Positions ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Global Font Change ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Enable Window Cascading ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Threads/Components Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Source Window ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Open New Source ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Where is Execution Point ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Startup ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Find Function Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> View Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Find ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Find Next ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Scroll to Line Number ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Select Include ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Change Text File ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Line ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Function ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Address ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Storage Change ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Load Occurrence ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Toggle at Current Line ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete all ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Prefix Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Prefix Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitors Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Expression Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Call Stack Window ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Registers Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Storage Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Local Variables Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Run Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Over ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Into ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Debug ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Return ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Halt ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Restart ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Run to Location ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Jump to Location ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Hide Debugger on Run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Check Heap When Stopping ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Thread Enabled ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Debugger Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Debugger Properties Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Properties Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> PM Debugging Mode (OS/2 Only) ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Default Data Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Exception Filtering ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Save Debugger Window Positions ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Global Font Change ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Enable Window Cascading ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Source ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Disassembly ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Mixed ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Prefix Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Prefix Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Code Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints List Window ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Edit Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Disable ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Modify ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete all ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Disable All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Enable All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Line ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Function ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Address ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Storage Change ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Load Occurrence ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Sort ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> View ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Modify ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete all ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Call Stack Window ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> View Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Private Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Edit Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Select All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Deselect All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Enable ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Disable ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Other Elements ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Representation, Next Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Representation, Next Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Representation, Next Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Show Context ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Show Enablement ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Edit Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Select All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Deselect All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Enable ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Disable ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Other Elements ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Representation, Next Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Show Context ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Show Enablement ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Local Variables Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Edit Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Select All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Deselect All ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Other Elements ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Representation, Next Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Show Context ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Show Enablement ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Popup Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Disable ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Edit Contents ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Dereference ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Representation, Next Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Other Elements ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Registers Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Storage Monitor ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> File Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Close Debugger ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Expression in Storage ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Options Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Windows Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Help ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Postmortem Information Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Default Data Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Default Data Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Shortcut Keys ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Line ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Function ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Address ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Storage Change ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Set Load Occurrence ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Default Data Representation ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Exception Filtering Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Exception Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Find Function Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Expression Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Properties Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Open New Source Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Overloaded Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Overloaded Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> PM Debugging Mode (OS/2 Only) ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Process List (Windows NT and Windows 95 Only) ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Program Profiles ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Change Text File ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Window Settings ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Source Filename Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Debugger Properties Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Scroll to Line Number ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Find ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Select Include ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Expression in Storage ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Display Style ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Startup Dialog ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Other Elements ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Prefix Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Prefix Area Popup Menu ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Into ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Over ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Debug ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Step Return ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Call Stack Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Registers Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Storage Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Session Control Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Monitor Expression Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Breakpoints Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Growth Direction Push button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete Button ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ <hidden> Delete all ΓòÉΓòÉΓòÉ