You can use the debugger in two configurations, default or multiprocess. Use the default configuration to debug a program that normally runs (without the debugger) in only one process. Use the multiprocess configuration to debug a program that normally runs in more than one process. The configuration depends only on the definition of the logical name DBG$PROCESS, as indicated in the following table: DBG$PROCESS Definition: Configuration: DEFAULT or undefined Default MULTIPROCESS Multiprocess Note that the debugging configuration does not depend on whether the program runs in one or several processes. Rather, the current definition of DBG$PROCESS determines whether debuggable images running in different processes can be controlled from the same debugging session. Before starting the debugger, enter the DCL command SHOW LOGICAL DBG$PROCESS to determine the current definition of DBG$PROCESS and the resulting debugging configuration.
1 – Default Configuration
Use the default configuration to debug a program that normally runs (without the debugger) in only one process. This configuration is achieved when DBG$PROCESS is either undefined or has the definition DEFAULT. In the following example, the output of the SHOW LOGICAL command indicates that a default debugging configuration is in effect: $ SHOW LOGICAL DBG$PROCESS %SHOW-S-NOTRAN, no translation for logical name DBG$PROCESS If DBG$PROCESS has the value MULTIPROCESS, and you want to debug a program that runs in only one process, enter the following command: $ DEFINE DBG$PROCESS DEFAULT
2 – Multiprocess Configuration
Use the multiprocess configuration to debug a program that normally runs in more than one process. This configuration is achieved when DBG$PROCESS has the definition MULTIPROCESS, and it enables you to interact with several processes from one debugging session. Use the following command to establish a multiprocess debugging configuration: $ DEFINE/JOB DBG$PROCESS MULTIPROCESS As shown in this example, when defining DBG$PROCESS for a multiprocess configuration, use a job logical definition so that the definition applies to all processes in that job. An image can be connected to (and controlled by) an existing multiprocess debugging session only if the process running the image is in the same job as the process running the debugging session. Although all processes of a multiprocess configuration must be in the same job tree, they do not have to be related in a particular process/subprocess hierachy. Moreover, the program images running in separate processes do not have to communicate with each other.
3 – Examples
$ DEFINE/JOB DBG$PROCESS MULTIPROCESS $ DEBUG/KEEP Debugger Banner and Version Number DBG> RUN PROG1 %DEBUG-I-INITIAL, language is FORTRAN, module set to PROG1 %DEBUG-I-NOTATMAIN, type GO to get to start of main program predefined trace on activation at routine PROG1 in %PROCESS_ NUMBER 1 DBG_1> In this example, the DEFINE/JOB command establishes the multiprocess configuration and the debugger is then started. After the program PROG1 is brought under debugger control, the normal prompt changes to DBG_1>, indicating that this is a multiprocess debugging configuration and that execution is suspended in process 1 (the first process that was brought under debugger control). Process 1 is currently the visible process (the context for executing process-specific commands like STEP, EXAMINE, and so on). $ DEFINE DBG$PROCESS DEFAULT $ DEBUG/KEEP Debugger Banner and Version Number DBG> RUN FORMS %DEBUG-I-INITIAL, language is PASCAL, module set to FORMS DBG> In this example, the DEFINE command establishes the default configuration and the debugger is then started. After the program FORMS is brought under debugger control, the prompt remains DBG>, indicating that this is the default debugging configuration.
4 – Process Relationships
The debugger consists of two parts: A main debugger image (DEBUGSHR.EXE) that contains most of the debugger code and a smaller kernel debugger image (DEBUG.EXE). This separation reduces potential interference between the debugger and the program being debugged and also makes it possible to have a multiprocess debugging session. When you start the debugger, a process is created to run the main debugger. In a multiprocess debugging session, each program being debugged runs in a separate process. Each process that is running one or more images under debugger control is also running a local copy of the kernel debugger. The main debugger, running in its own process, communicates with the other processes through their kernel debuggers. Although all processes of a multiprocess session must be in the same job, they do not have to be related in a particular process/subprocess hierarchy. Moreover, the program images running in separate processes do not have to communicate with each other.