Set debugger options

WTSupported in traditional Synergy on Windows


USupported on UNIX
VSupported on OpenVMS
SET option



One of the following options:

BREAK breakpoint



Set the DBGSRC environment variable to the specified path.


Set the default mode for the STEP command to step over a routine.


Set the default mode for the STEP command to step into an external subroutine. (default)


Break when a STOP statement is executed (after any destructors have been executed).


Do not break when a STOP statement is executed. (default)


Break whenever a program traps an error.

TRAP IGNORE error[,...]

Break whenever a program traps an error but ignore the specified error numbers or exception class names.


Do not break when an error is trapped. (default)


Allow the debugger to use characters that are typed ahead in the application. (default)


Prevent the debugger from using characters that are typed ahead in the application.


Set a program breakpoint when uninitialized stack records and ^M memory is accessed.


Turn on debugger messages when uninitialized stack records and ^M memory is accessed.


Turn off uninitialized memory debugger messages and program breaking.

VIEW count

Set the default number of source lines that will be displayed immediately preceding and following the current line when the VIEW debugger command is specified without the optional count value. The default count for the VIEW command is 4.




The SET command lets you customize debugger behavior by setting various debugger options.

The DBGSRC environment variable is appended to the beginning of source filenames before source files are opened in the debugger if the file cannot be found through the path to the file defined at compile time. It tells the debugger where the source file is located. You can either set DBGSRC in the environment, before you begin your debugging session, or you can set it with the SET command. If you set DBGSRC with the SET command, it overrides any DBGSRC path that you set previously at the environment level. If you are debugging remotely, make sure path is accessible from the server.

Detection for INITIALIZED ON or INITIALIZED BREAK occurs on assignment and IF tests.

STEP INTO only applies to external subroutines, not functions. (To step into a function, you need to either set a breakpoint or use the GO command to go to that function name.)


If the default step mode is STEP OVER, the debugger steps into any external subroutine that has a function as one of its arguments.

If you don’t set TRAP ON, when an error is trapped, the program begins executing at the ONERROR label, without any warning that program control has changed. Setting TRAP ON causes the program to break when an error is trapped, and you get a message that tells you where the error occurred and what line will be executed next.

SET TRAP IGNORE implies that TRAP ON is set but disables debug interruption if an error or exception in the specified list occurs, where error[,...] is one or more runtime error numbers or fully qualified exception class names, separated by commas (or spaces). Any SET TRAP command (ON, OFF, or IGNORE) releases any previous error trap list.

The SET UNINITIALIZED debugger feature is designed to help track down random problems at runtime due to variables in ^M and stack records not being initialized before use. Both %MEM_PROC(DM_ALLOC…) and stack records are random value unless preinitialized. When SET UNINITIALIZED debugger options are set, %MEM_PROC memory is initialized to a series of 0xFA bytes, and stack memory is set to a series of 0xFB bytes. When an IF test or assignment statement is encountered, the data is scanned for a series of four or more FA or FB bytes, and the appropriate action is taken if found. It is possible for false positives to occur if integer fields that happen to have exactly the same values are used.

When the break occurs, the line reported is the next line that would be executed after the error statement, and this is the module where the uninitialized data is detected. In many cases, this is not the module defining the data, but the module using the data, which was most likely passed in via arguments. For example, many times a UI Toolkit list processing routine uses stack data passed in several levels up the call stack via the user data argument. However, this is a bug in the user code, not a bug in Toolkit.


The example below sets the default STEP mode to STEP OVER. If no arguments are specified on the STEP command, STEP steps over a routine.


The following example causes the runtime to break on any trapped error or exception except errors 1, 40, 53, 64, 511, and Myclass.Myexception.

SET TRAP IGNORE 1,40,53,64,511, "Myclass.Myexception"