COBOL TEST Compiler Option: Debug Builds on z/OS

A COBOL abend in test is much easier to fix when the debugger can show the failing statement and variable names. The TEST compiler option tells Enterprise COBOL to create debug information for tools such as IBM z/OS Debugger. NOTEST is the normal choice when a release build does not need that debug data.

Build with debug data.

What is the COBOL TEST compiler option?

TEST controls the debug information produced by the COBOL compiler. IBM describes it as the option used to create the information needed to debug a program, including where that information is placed.

The exact suboptions depend on the compiler level. Enterprise COBOL 6.2 and later support modern combinations such as TEST(SEPARATE,SOURCE,EJPD) and NOTEST(DWARF,SOURCE). Older compilers used other forms, so always check the compile listing for the actual options in effect.

TEST vs NOTEST

Option	Meaning	Typical use
TEST	Produces debug data for source-level debugging.	Unit test, system test, problem recreation, and controlled support builds.
NOTEST	Does not request full source-level debug support.	Normal production builds when source debugging is not required.

Common TEST suboptions

SOURCE and NOSOURCE

SOURCE keeps source information available for the debugger. Use it when a developer needs to step through COBOL statements rather than only inspect offsets or dumps.

SEPARATE and NOSEPARATE

SEPARATE can place debug information outside the main program object for supported compiler levels. That can reduce object size while keeping source-level debugging available, but the separate debug file must be cataloged and available during the debug session.

DWARF and NODWARF

Modern Enterprise COBOL can use DWARF debug information. IBM notes that newer NOTEST combinations can still include DWARF data for tools that use it, depending on the compiler level and selected suboptions.

EJPD and NOEJPD

EJPD supports some debugger actions such as predictable variable changes and certain jump commands when used with selected optimization options. It can affect generated code, so use it only when the debug scenario needs it.

Example compile options

This example shows the intent, not a site standard. Your compile PROC might pass options through a symbolic parameter such as PARM.COBOL.

//COBOL  EXEC PGM=IGYCRCTL,
//             PARM='TEST(SEPARATE,SOURCE,EJPD),LIST,MAP,XREF'
//SYSIN  DD  DSN=DEV.COBOL.SOURCE(ACCT001),DISP=SHR
//SYSLIN DD  DSN=&&OBJ,DISP=(MOD,PASS),UNIT=SYSDA,
//             SPACE=(CYL,(1,1))

For a normal release build, the same site might use NOTEST with the other production compiler options approved by the build team.

When to use TEST

• Use TEST when a developer must debug statement-by-statement in a controlled test environment.
• Use it when a recurring abend needs source lines and variable names to shorten the investigation.
• Use it for support builds only when the debug data is stored and secured according to site rules.
• Use NOTEST when the program is being built for a normal production release and debug data is not required.

Production checks

Do not move a debug build to production just because it passed a test cycle. Check the compile listing, binder listing, load library, and deployment package. If your release process stores debug files separately, confirm they are not lost before a support team needs them.

For online programs, confirm the runtime and debugger setup with the CICS, IMS, or batch support team. A compile option alone does not make every runtime debugging scenario available.

Common mistakes

Assuming TEST is active from the PROC name

A PROC named COBTEST can still pass NOTEST after symbolic substitution. Read the compiler listing to see the final option set.

Losing the separate debug file

If the build uses a separate debug file, keep it cataloged, backed up, and tied to the exact program object. A mismatched debug file can waste hours during an abend call.

Mixing old and new compiler guidance

Enterprise COBOL V3, V4, V5, and V6 do not all use the same TEST suboption rules. Use the documentation for the compiler level shown in the compile listing.

Review checklist

• Confirm the compiler version and maintenance level.
• Check whether the build uses TEST or NOTEST.
• Check whether SOURCE, SEPARATE, DWARF, or EJPD is needed.
• Confirm the debug file location when SEPARATE is used.
• Keep debug data under the same access controls as source and load modules.
• Rebuild after changing compiler options; do not rely on an old load module.

Related Mainframe Forum guides

For nearby topics, read COBOL program compilation process, COBOL SSRANGE compiler option, COBOL RENT compiler option, COBOL ARITH compiler option, COBOL DYNAM compiler option, and COBOL file status.

External references

IBM documents choosing TEST and NOTEST suboptions, compiling with Enterprise COBOL, and compiler option changes in Enterprise COBOL 5 and 6.

FAQ

What does TEST do in COBOL?

TEST tells the compiler to produce debug information that can be used by source-level debugging tools.

Should TEST be used in production?

Usually no. Use production compiler options approved by your build team. Keep TEST for controlled debug and support builds unless your site standard says otherwise.

What is TEST(SEPARATE)?

TEST(SEPARATE) stores supported debug information separately from the main program object, depending on the compiler level and selected suboptions.

What should I check first when debugging does not work?

Read the compile listing. Confirm the compiler version, final TEST or NOTEST option, source suboption, and debug file location.