Choosing a method or methods for starting z/OS Debugger

Table 1 indicates that there are several different methods to start z/OS® Debugger for each type of program. In this topic, you will read about the circumstances in which each applicable method works for each type of program. Then you can select which method would work best for your site. After you complete this topic, you will have selected the methods that work best for your programs.

Table 1. Methods for specifying the TEST runtime options and the subsystems that support these methods.
  TSO JES batch UNIX System Services1 CICS® Db2® Db2 stored procedures (PROGRAM TYPE=MAIN) Db2 stored procedures (PROGRAM TYPE=SUB) IMS TM IMS batch IMS BTS
Use the DFSBXITA user exit               X X X
Use the DTCN transaction       X            
Use the Db2 catalog           X3 X      
From within a program by coding a call to CEETEST, __ctest(), or PLITEST X X X X X X X X X X
Through CEEUOPT or CEEROPT X X X X2 X2 X2,3   X X X
Use the CEEOPTS DD statement in JCL or CEEOPTS allocation in TSO X X X   X       X X
Use the parameters on the EXEC statement when you start your program   X                
Use the parameters on the RUN statement when you start your program         X          
Use the parameters on the CALL statement when you start your program X                  
Through the EQASET transaction4               X4    
Through the EQANMDBG program5 X5 X5             X5 X5
Use the EQAD3CXT user exit routine   X       X X6 X X X
Note:
  1. Go programs only run under UNIX System Services, with the following limitations:
    • __ctest() might not work as expected when cgo is in use.
    • CEEOPTS allocation cannot be used.
  2. You cannot use CEEROPT to specify TEST runtime options.
  3. The Db2 catalog method always takes precedence over CEEUOPT.
  4. This method is only for non-Language Environment® assembler programs.
  5. This method is only for non-Language Environment programs.
  6. EQAD3CXT supports Db2 stored procedures PROGRAM TYPE=SUB if you set the RRTN_SW flag as x'01'.

For each subsystem, Table 1 shows that you can choose from several different methods of specifying the TEST runtime options. The following list can help you select the method that best applies to your situation, ordered by flexibility and convenience:

For TSO programs
  • For programs that start in Language Environment, specify the TEST runtime options using the CEEOPTS allocation in TSO for the most flexible method of specifying the runtime options.
  • Specify the TEST runtime options using the parameters on the CALL statement if you have a small number of runtime options or need to invoke EQANMDBG for a non-Language Environment program.
  • If you specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST, you will have to recompile your program every time you want to change the options.
For JES batch programs
  • For programs that start in Language Environment, specify the TEST runtime options using the CEEOPTS DD statement in your JCL for the most flexible method of specifying runtime options.
  • Specify the TEST runtime options using the parameters on the EXEC statement option if you have a small number of runtime options or need to invoke EQANMDBG for a non-Language Environment program.
  • If you specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST, you will have to recompile your program every time you want to change the options.
For UNIX System Services programs
  • Specify the TEST runtime options by setting the _CEE_RUNOPTS environment variable.
  • If you specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST, you will have to recompile your program every time you want to change the options.
For CICS programs
  • Specify the TEST runtime options using the DTCN transaction to create and store a profile that contains the TEST runtime options.
  • If you specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST, you will have to recompile your program every time you want to change the options.
For Db2 programs
  • Specify the TEST runtime options using the CEEOPTS DD statement in JCL or CEEOPTS allocation in TSO for the most flexible method of specifying runtime options.
  • Specify the TEST runtime options using the parameters on the RUN statement option if you have a small number of runtime options.
  • If you specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST, you will have to recompile your program every time you want to change the options.
For Db2 stored procedures that have the PROGRAM TYPE of MAIN
  • Specify the TEST runtime options using the Language Environment EQAD3CXT user exit routine. You can run the stored procedure with your own set of suboptions. Another user can run or debug the stored procedure with a separate set of suboptions. Therefore, multiple users can run or debug the stored procedure at the same time.
  • If the exit routine is not available at your site, specify the TEST runtime options using the Db2 catalog. However, you are limited to specifying one specific set of suboptions, which means that every user that runs or debugs that stored procedure uses the same set of suboptions.

If you implement both methods, the Language Environment exit routine takes precedence over the Db2 catalog.

For Db2 stored procedures that have the PROGRAM TYPE of SUB
  • For programs defined as PROGRAM TYPE=SUB, specify the TEST runtime options using the Language Environment EQAD3CXT exit routine. You can run or debug the Db2 stored procedure with your own set of suboptions, while another user can run or debug the Db2 stored procedure with a separate set of suboptions.
  • If the exit routine is not available at your site, specify the TEST runtime options using the Db2 catalog. You are limited to specifying one set of suboptions, which means that every user that runs or debugs that stored procedure uses the same set of suboptions.

If you implement both methods, the Language Environment exit routine takes precedence over the Db2 catalog.

For programs invoked by any other method, specify the TEST runtime options using the Db2 catalog. You are limited to specifying one set of suboptions, which means that every user that runs or debugs that stored procedure uses the same set of suboptions.

For IMS TM programs
  • Specify the TEST runtime options using the Language Environment EQAD3CXT user exit routine.
  • If your program is a non-Language Environment program, issue the EQASET transaction to setup your debugging preference.
  • If the EQAD3CXT user exit routine is not available at your site, specify the TEST runtime options using the DFSBXITA user exit routine.
  • If the EQAD3CXT or DFSBXITA user exit routines are not available at your site, specify the TEST runtime options using CEEUOPT or CEEROPT.
  • If none of the previous options is available at your site, specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST. However, you will have to recompile your program every time you want to change the options.
For IMS batch programs
  • For programs that start in Language Environment, specify the TEST runtime options using the CEEOPTS allocation in JCL because this method can be the most flexible method.
  • Specify the TEST runtime options using the EQAD3CXT user exit routine.
  • If your program is a non-Language Environment program, use the EQANMDBG program to start your debugging session.
  • If the EQAD3CXT user exit routine is not available at your site, specify the TEST runtime options using the DFSBXITA user exit routine; however, you must specify PROGRAM rather than TRANSACTION.
  • If the EQAD3CXT or DFSBXITA user exit routines are not available at your site, specify the TEST runtime options using CEEUOPT or CEEROPT.
  • If none of the previous options is available at your site, specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST. However, you will have to recompile your program every time you want to change the options.
For IMS BTS programs
  • For programs that start in Language Environment, specify the TEST runtime options using the CEEOPTS allocation in JCL because this method can be the most flexible method.
  • Specify the TEST runtime options using the EQAD3CXT user exit routine.
  • If your program is a non-Language Environment program, use the EQANIAFE application front-end program to start your debug session. For more information, see Debugging non-Language Environment IMS BTS programs.
  • If the EQAD3CXT user exit routine is not available at your site, specify the TEST runtime options using the DFSBXITA user exit routine.
  • If the EQAD3CXT or DFSBXITA user exit routines are not available at your site, specify the TEST runtime options using CEEUOPT or CEEROPT.
  • If none of the previous options is available at your site, specify the TEST runtime options by coding a call to CEETEST, __ctest(), or PLITEST. However, you will have to recompile your program every time you want to change the options.

After you have identified the method or methods you will use to start z/OS Debugger, see Planning your debug session to determine the next task you must complete.