Comparison of methods for starting z/OS Debugger under CICS

There are several different mechanisms available to start z/OS® Debugger under CICS®. Each mechanism has a different advantage and are listed below:

• DTCN is a full-screen CICS transaction that z/OS Debugger provides. By using DTCN, you can create a profile that contains a pattern of CICS resource names that identify a task that you want to debug. You can dynamically change any Language Environment® TEST or NOTEST runtime option that your application was originally link-edited with. You can also use DTCN to dynamically change any other Language Environment runtime options that are not specific to z/OS Debugger which are defined in your CICS installation except the STACK option.

  To learn how to set up profiles by using DTCN, see Preparing a CICS program.

• Language Environment CEEUOPT module link-edited into your application, containing an appropriate TEST option, which tells Language Environment to start z/OS Debugger every time the application is run.

  This mechanism can be useful during initial testing of new code when you will want to run z/OS Debugger frequently.

• A compiler directive within the application, such as #pragma runopts(test) (for C and C++) or CALL CEETEST.

  These directives can be useful when you need to run multiple debug sessions for a piece of code that is deep inside a multiple enclave or multiple CU application. The application runs without z/OS Debugger until it encounters the directive, at which time z/OS Debugger is started at the precise point that you specify. With CALL CEETEST, you can even make the invocation of z/OS Debugger conditional, depending on variables that the application can test.

If your program uses several of these methods, the order of precedence is determined by Language Environment. For more information about the order of precedence for Language Environment run-time options, see z/OS Language Environment Programming Guide.