After you have completed the tasks in Planning your debug session, you can use the information you have collected to update the following processes:
For more information about how to update these processes, see the following topics:
This topic describes the changes you must make to your compilation, assembly, and linking process to implement the choices you made in Planning your debug session. If you are familiar with managing JCL and with your site's compilation or assembly process, see Compiling your program without using Debug Tool Utilities for instructions on the specific changes you need to make. If your site uses Debug Tool Utilities to manage these processes, see Compiling your program by using Debug Tool Utilities for instructions on how to use the Program Preparation option to update these processes.
Create or modify JCL so that it includes all the statements you need to compile or assemble your programs, then properly link any libraries. The following list describes the changes you need to make:
For each compiler, there might be additional updates you might need to make so that Debug Tool starts. The following list describes these updates:
| Programming language | Compiler suboption or assembler option | File you need to save |
|---|---|---|
| COBOL | ||
| SEPARATE | separate debug file | |
| any other | listing file | |
| NOTEST | listing file containing pseudo-assembler code | |
| non-Language Environment COBOL | ||
| EQALANGX | ||
| any other | listing file containing pseudo-assembler code | |
| PL/I | ||
| SEPARATE | separate debug file | |
| any other (pre-Enterprise PL/I) | listing file | |
| any other (Enterprise PL/I) | source file that was used as input to the compiler | |
| NOTEST | listing file containing pseudo-assembler code | |
| C/C++ | ||
| DEBUG(DWARF) | file created by this compiler option and source file | |
| TEST | source file that was used as input to the compiler | |
| NOTEST | listing file containing pseudo-assembler code | |
| assembler | ||
| ADATA | EQALANGX | |
| no debug information saved | listing file containing pseudo-assembler code | |
After you complete this task, see Update your library and promotion process.
Debug Tool Utilities provides several utilities than can help you compile your programs and start Debug Tool. The steps described in this topic apply to the following category of compilers and assemblers:
If you are using Debug Tool Utilities to prepare your program and start Debug Tool, read Appendix C. Examples: Preparing programs and modifying setup files with Debug Tool Utilities, which describes how to prepare a sample program and start Debug Tool by using Debug Tool Utilities. After you read the sample and understand how to use Debug Tool Utilities, do the following steps:
If the program source is a sequential data set and the DB2 precompiler is selected, make sure the DBRMLIB data set field in panel EQAPPC1B, EQAPPC2B, EQAPPC3B, EQAPPC4B, or EQAPPC5B is a partitioned data set with a member name. For example, DEBUG.TEST.DBRMLIB(PROG1).
Type in the backslash character ("/") in the Enter / to edit options and data set name patterns field, then press Enter.
After you complete this task, see Update your library and promotion process.
If you are compiling and launching Enterprise PL/I programs on an HFS file system, you must do one of the following:
By default, the Enterprise PL/I compiler stores the relative path and file names in the object file. When you start a debug session, if the source is not in the same location as where the program is launched, Debug Tool does not locate the source. To avoid this problem, specify the full path name for the source when you compile the program. For example, if you execute the following series of commands, Debug Tool does not find the source because it is located in another directory (/u/myid/mypgm):
cd /u/myid/mypgm pli -g "//TEST.LOAD(HELLO)" hello.pli
call TEST.LOAD(HELLO) 'test/'
Debug Tool does find the source if you change the compile command to:
pli -g "//TEST.LOAD(HELLO)" /u/myid/mypgm/hello.pli
The same restriction applies to programs that you compile to run in a CICS environment.
If you build your application using the c89 or c++, do the following steps:
cd /u/mike/app c89 -g -o "//PROJ.LOAD(FRED)" fred.c
FRED TEST ENVAR('PWD=/u/mike/app') / asis
If you are compiling and launching programs on an HFS file system, you must do one of the following:
By default, the C compiler stores the relative path and file names of the source files in the object file. When you start a debug session, if the source is not in the same location as where the program is launched, Debug Tool does not find the source. To avoid this problem, specify the full path name of the source when you compile the program. For example, if you execute the following series of commands, Debug Tool does not find the source because it is located in another directory (/u/myid/mypgm):
cd /u/myid/mypgm c89 -g -o "//TEST.LOAD(HELLO)" hello.c
call TEST.LOAD(HELLO) 'test/'
Debug Tool finds the source if you change the compile command to:
c89 -g -o "//TEST.LOAD(HELLO)" /u/myid/mypgm/hello.c
The same restriction applies to programs that you compile to run in a CICS environment.
If you are compiling and launching programs on an HFS file system, you must do one of the following:
By default, the C++ compiler stores the relative path and file names of the source files in the object file. When you start a debug session, if the source is not in the same location as where the program is launched, Debug Tool does not locate the source. To avoid this problem, specify the full path name of the source when you compile the program. For example, if you execute the following series of commands, Debug Tool does not find the source because it is located in another directory (/u/myid/mypgm):
cd /u/myid/mypgm c++ -g -o "//TEST.LOAD(HELLO)" hello.cpp
call TEST.LOAD(HELLO) 'test/'
Debug Tool finds the source if you change the compile command to:
c++ -g -o "//TEST.LOAD(HELLO)" /u/myid/mypgm/hello.cpp
The same restriction applies to programs that you compile to run in a CICS environment.
If you use a library to maintain your program and a promotion process to move programs through levels of quality and testing, you might have to update these processes to ensure that Debug Tool can find the files it needs to obtain information about your programs. For example, if your final production level does not have access to the same libraries as your development level, and you want to be able to debug programs that are in the final product level, you might need to update the environment in your final production level so that it can access to the following resources:
If your source code is being managed by a library system that requires the SUBSYS=ssss parameter when the data set is allocated, you need a custom version of the EQAOPTS options module that specifies the SUBSYS=ssss allocation parameter. This is required for the following types of programs:
This support is not available for CICS programs. See the Debug Tool Customization Guide for details.
In this topic, you will use the information you gathered after completing 2 and Choosing a method or methods for starting Debug Tool to write the TEST runtime options string, then save that string in the appropriate location.
You might have to write several different TEST runtime options strings. For example, the TEST runtime options string that you write for your CICS programs might not be the same TEST runtime options string you can use for your IMS™ programs. For this situation, you might want to use Table 12 to record the string you want to use for each type of program you are debugging.
| Test runtime options string (for example, TEST(ALL,,,MFI%SYSTEM01.TRMLU001:)) | |
|---|---|
| TSO |
|
| JES batch |
|
| UNIX System Services |
|
| CICS |
|
| DB2 |
|
| DB2 stored procedures (PROGRAM TYPE=MAIN) |
|
| DB2 stored procedures (PROGRAM TYPE=SUB) |
|
| IMS TM |
|
| IMS batch |
|
| IMS BTS |
|
If you are not familiar with the format of the TEST runtime option string, see the following topics:
After you have written the TEST runtime option strings, you need to save them in the appropriate location. Using the information you recorded in Table 10, review the following list, which directs you to the instructions on where and how to save the TEST runtime options strings: