Problem:

IBM TXSeries starts one or more Application Server processes when a region starts.  An Application Server process runs in the background and listens for requests, then invokes COBOL programs to fulfil requests.  Other applications such as NTT DATA’s Unikix, FIS (formerly Sungard) Ellucian Banner, and Systems & Software's enQuesta are also designed using Application Server processes that invoke COBOL programs.  It is difficult to use the Visual COBOL for Eclipse debugger to debug COBOL programs invoked by these Application Server processes.

Solution:

This article includes a COBOL module and instructions to make this type of debugging more practical.

The Eclipse debugger can be started in different ways, controlled by the debug configuration.  

The Attach to Process debug configuration is not practical in these cases because the debugger would need to attach to one of the Application Server processes responsible for invoking COBOL programs, but more than one Application Server process might be running (especially when the application is handling a heavy work load), and a person cannot predict which Application Server process will invoke a particular COBOL program.  Even if only one Application Server process were running, attaching the debugger to it would attempt to debug every program that it happened to invoke, instead of targeting a particular program.

The Wait for Application Attachment debug configuration is difficult to use because:

1) The "directory" Matching Option would sit and wait for a COBOL process to start in a particular directory, but one or more Application Server processes responsible for invoking COBOL programs are already running, and the directory-matching option cannot match COBOL processes already running. 

2) The "session identifier" Matching Option requires the application developer to edit the COBOL program and insert a call to CBL_DEBUG_START specifying a "program identifier" parameter.  This would require editing each of the (possibly hundreds) of COBOL programs and adding calls to CBL_DEBUG_START.  It is not possible to add a COPY statement to each program specifying a copybook containing the call to CBL_DEBUG_START, because each program must specify a unique "program identifier" parameter.

To make debugging more practical, this article has an attached COBOL program named CallCDS.cbl.  This COBOL program determines the name of its calling (parent) program, then calls CBL_DEBUG_START specifying the name of its calling program as the unique program identifier.  In this way, application developers do not need to modify each of their hundreds of COBOL modules inserting unique calls to CBL_DEBUG_START.

Here are the steps for using this approach:

(1) Change the build script or makefile or project that compiles COBOL programs for debugging, and add a new compiler directive: INITCALL"CallCDS", then recompile the programs for debugging.  The INITCALL compiler directive causes the Compiler to insert a CALL as though the CALL were located at the beginning of the PROCEDURE DIVISION.  In this case, every program will CALL "CallCDS" before executing the rest of the procedural code.

(2) Compile CallCDS.cbl to debuggable .gnt, for example using this command line:

cob -ug CallCDS.cbl

As an alternative you could compile CallCDS.cbl to another dynamically-loadable form such as .int or .so, but it must be compiled as debuggable.  Make sure to compile CallCDS.cbl using the same bitmode as the application programs.  For example, if the application programs are compiled in 32-bit mode, make sure to compile CallCDS.cbl also in 32-bit mode.

(3) If the application has a "loadlib" or "bin" location, where compiled application programs are placed, copy CallCDS.gnt and CallCDS.idy to the loadlib or bin location so they can be found at run-time.  If the source code for CallCDS.cbl is not already in the same directory as the application source code, copy CallCDS.cbl to the directory containing the application source code, so the source can be found at run-time.

(4) In the case of TXSeries, stop and re-start the region.

From then on, to debug a particular COBOL program:

(1) Create a wait-for-attach debug configuration in Eclipse specifying a program-id match of the name of the intended program, then run the debug configuration -- the debugger will wait for the intended program.  You need not specify a main or top-level program; you could specify any program of interest, for example a subprogram.  Debugging will begin when the flow of control enters that program.

(2) Invoke the intended program.  For example in TXSeries, use a 3270 terminal emulator and enter a transaction that would cause the intended program to be invoked, or in other applications, submit a request that would cause the intended program to be invoked.  When the flow of control enters that program, the debugger will attach.  The debugger will stop inside the CallCDS module.  Press "Step" or "Step Into" (F5) to continue debugging the intended program.
                                                              
CallCDS calls CBL_DEBUG_START with parameters: flag 1 and timeout 0000.  This means: if a debugger is waiting for that program, begin debugging, and if no debugger is waiting, carry on running.  This allows programs to run normally if no debugger is waiting for them.  You can compile all application programs using the INITCALL"CallCDS" compiler directive, so they are ready to be debugged, and so they will run normally when not being debugged.

On Linux/UNIX, the "cobdebugremote" process (started by Eclipse wait-for-attach debug configurations), uses disk files in /tmp or in the location specified by the TMPDIR environment variable, for inter-process communication to match the intended program. One reason remote debugging might fail is if the application has a different TMPDIR environment variable than the cobdebugremote process.  To diagnose these problems, examine the environment of each process and look for TMPDIR settings.  

On Linux you can examine a running process using a "strings" command while logged in as root (<pid> means process ID):

strings /proc/<pid>/environ | more

For example to search for TMPDIR:

strings /proc/<pid>/environ | grep -i tmp

On Solaris, the equivalent command is:
    pargs -e <pid>

On AIX, the equivalent command is:
    pargs or ps eww <pid>

Use the above commands on the <pid> of an Application Server process, and also on the <pid> of a cobdebugremote process started by Eclipse.  If either process has TMPDIR set in its environment, the other must also have TMPDIR set to the same value, otherwise wait-for-attach debugging will not attach.

Full article: https://portal.microfocus.com/s/article/KM000002463