TEST
Use TEST
to produce object
code that enables debugging with problem determination tools such
as IBM® z/OS® Debugger and Fault Analyzer.
With TEST
, you can also enable the inclusion of symbolic
variables in the formatted dumps that are produced by Language Environment®.
Default is: NOTEST(NODWARF, NOSOURCE, NOSEPARATE)
whenNODWARF, NOSOURCE, NOSEPARATE
NOTEST
is specified with no suboptions
whenNOEJPD, DWARF, SOURCE, NOSEPARATE
TEST
is specified with no suboptions
Abbreviations are: None

NOSO
|SO
forSOURCE
|NOSOURCE
NOSEP
|SEP
forSEPARATE
|NOSEPARATE


DWARF
|NODWARF
- If
TEST(DWARF)
is in effect, completeDWARF
diagnostic information is included in the object program, or a separate debug file when theSEPARATE
suboption is in effect. This option enables the best usability for application failure analysis tools, such as CEEDUMP and IBM Fault Analyzer.
EJPD
|NOEJPD
EJPD
andNOEJPD
control enablement of the IBM z/OS Debugger commandsJUMPTO
andGOTO
in production debugging sessions.EJPD
andNOEJPD
only take effect if you specify theTEST
option and a non-zeroOPTIMIZE
level (OPTIMIZE(1)
orOPTIMIZE(2)
).
SOURCE
|NOSOURCE
- If you specify
SOURCE
, theDWARF
debugging information generated by the compiler includes the expanded source code.Note:SOURCE
is not allowed ifNODWARF
is specified.
|SEPARATE[(DSNAME|NODSNAME)]
NOSEPARATE
The default is
SEPARATE(NODSNAME)
whenSEPARATE
is specified with no suboptions.

Controlling module
size while retaining debugging capability:

DWARF
suboption of TEST
causes
the compiler to generate debug information tables that IBM z/OS Debugger uses to resolve data-names,
paragraph-names, and the like. This information can take a lot of
storage. You can choose either to compile this information into the
object program or to write it to the separate SYSDEBUG
data
set: - For smaller executables, use the
SEPARATE
suboption and keep the separate debugging files for use during IBM z/OS Debugger sessions. - To avoid having to manage separate debugging files, compile with
the
NOSEPARATE
suboption; note that this suboption results in larger object programs on DASD. The size when loaded into virtual storage is not increased by use of theNOSEPARATE
option.

If you invoke the COBOL
compiler from JCL or TSO and you specify
NOTEST|TEST(...,SEPARATE,...)
,
the DWARF debugging information is written to the data set that you
specify in the SYSDEBUG DD
statement. For details
about coding that statement and about the SYSDEBUG data set, see the
related information below about defining the debug data set and about
logical record length and block size.
When you invoke the COBOL compiler from the z/OS UNIX shell and you specify
NOTEST|TEST(...,SEPARATE,...)
,
the DWARF debugging information is written to file.dbg
in the current directory, where file is the name
of the COBOL source file.
Performance versus debugging capability:
You can control the amount of debugging capability that you get and the program performance, as follows:
- For the best performance, but with some restrictions on debugging,
compile using a non-zero
OPTIMIZE
level,STGOPT
andTEST(NOEJPD)
.- The IBM z/OS Debugger commands
JUMPTO
andGOTO
are not supported. However, you can still useJUMPTO
andGOTO
if you use theSET WARNING OFF
IBM z/OS Debugger command. In this scenario,JUMPTO
andGOTO
will have unpredictable results. - Except for the
DESCRIBE ATTRIBUTES
command, IBM z/OS Debugger commands cannot refer to any data item that was discarded from a program by theSTGOPT
option. - The IBM z/OS Debugger command
AT CALL
entry-name is not supported.
- The IBM z/OS Debugger commands
- For some reduction in program performance from the
production-debugging scenario above, but to enable predictable behavior
for the IBM z/OS Debugger commands
JUMPTO
andGOTO
, specify a non-zeroOPTIMIZE
level andTEST(EJPD)
.The restrictions above about referring to items discarded by the
STGOPT
option, and about theAT CALL
command also apply when you use a non-zeroOPTIMIZE
level andTEST(EJPD)
. - For slowest performance but maximum
debugging capability, specify
OPTIMIZE(0)
,NOSTGOPT
andTEST
.The
OPTIMIZE(0)
option causes the compiler to generate slower code, but all IBM z/OS Debugger commands are supported.
Language Environment:
The TEST
option specified
with any of its suboptions, and
NOTEST
with DWARF
,
can improve your formatted dumps from Language Environment by adding these two features
to the dumps:
- A line number that indicates the failing statement, rather than just an offset
- The values of the program variables
(if
DWARF
is in effect)
With
, the dump will have program variables and
the line number of the failing statement. With DWARF
,
the dump will not have program variables nor the line number of the
failing statement. NODWARF
Enterprise COBOL uses the Language Environment-provided dump services to produce dumps that are consistent in content and format with those that are produced by other Language Environment-conforming member languages.
Whether Language Environment produces a dump for unhandled
conditions depends on the setting of the runtime option TERMTHDACT
.
If you specify TERMTHDACT(DUMP)
, a dump is generated
when a condition of severity 2 or greater goes unhandled.
- IBM Developer for z Systems Enterprise Edition (included in IBM Application Delivery Foundation for z Systems)
- IBM Debug for z Systems (formerly IBM Debug Tool for z/OS)
IBM Developer for z Systems
Defining the debug data set (SYSDEBUG)
Using the debugger
Suppressing information in CEEDUMP processing
Generating a Language Environment dump with TERMTHDACT (Language Environment Debugging Guide)
Special considerations while using the TEST runtime option (Debug Tool User's Guide)
Logical record length and block size
cob2 input and output files
Conflicting compiler options
OPTIMIZE
TEST | NOTEST (Language Environment Programming Reference)