A batch job can run the same COBOL load module with different Language Environment options. One run may produce a clean dump for support. Another may start a debugger. A third may save vector registers for a condition handler that almost no program in the shop uses. Those choices affect support, diagnostics, and sometimes elapsed time.
What this COBOL run-time performance post covers
This page covers three options from the old post: TEST, TRAP, and VCTRSAVE. The goal is not to switch every option to the fastest-looking value. The goal is to know what each option does, where it is set, and what to check before changing a production job.
Runtime options versus compiler options
Compiler options are chosen when the program is compiled. Runtime options are chosen when the program runs under Language Environment. A production issue can involve both. For example, the TEST compiler option controls debug data in the program object or separate debug files, while the Language Environment TEST runtime option controls when a debugging tool takes control.
If you need the deeper compiler discussion, see COBOL TEST compiler option. This page stays with the run-time side and the production support tradeoffs.
Quick reference
| Option | What it controls | Production note |
|---|---|---|
TEST |
When a debug tool can take control of the application. | Use only when the job or region is meant to be debugged. |
TRAP |
How Language Environment handles abends and program checks. | IBM guidance generally favors TRAP(ON) for normal application runs. |
VCTRSAVE |
Whether vector state is saved for user condition handlers. | Keep it off unless a real condition handler needs vector state. |
TEST runtime option
The Language Environment TEST runtime option controls the conditions under which a debugging tool can take control. It belongs in a controlled test or debug setup, not as a casual setting in a high-volume production batch stream.
Debug readiness can add cost in two places. The program may be compiled with debug data, and the run may include runtime options that let a debugger start. When the job is performance-sensitive, confirm both the compile listing and the runtime options report before blaming COBOL logic.
What to check
- Does the compile listing show
TESTorNOTEST? - Does the runtime options report show a Language Environment
TESTsetting? - Is this a production job, a QA run, or a one-time debug run?
- Is the program also compiled with
OPT,TEST,EJPD, or related debug suboptions?
TRAP runtime option
TRAP controls whether Language Environment intercepts abends and program interrupts. With TRAP(ON), Language Environment can handle conditions, produce useful diagnostic output, and close resources in a controlled way. IBM warns that TRAP(OFF) can lead to unexpected results.
This is a supportability setting as much as a performance setting. Switching it off to chase a small timing gain can make the next S0C7, S0C4, or arithmetic overflow harder to diagnose. In many shops, TRAP(ON) is the normal setting unless the systems programming team has a specific reason to do otherwise.
Safe production rule
Do not change TRAP alone because one job ran slowly. Capture the current options, look at CPU and elapsed time, check the abend and dump requirements, and involve the team that owns the Language Environment defaults.
VCTRSAVE runtime option
VCTRSAVE controls whether vector state is saved and restored when user condition handlers are called. If the application does not use that function, saving extra state can add needless work around condition handling.
IBM-supplied defaults commonly show VCTRSAVE(OFF). That is a sensible setting for many ordinary COBOL batch programs. Turn it on only when the application, a called routine, or a user-written condition handler really needs the vector environment preserved.
How to see the options used by a job
Do not rely only on a standard sheet from ten years ago. Check what the current job actually used. Language Environment can report runtime options with RPTOPTS(ON), and COBOL runtime-specific options can also be reported depending on the COBOL level and site setup.
//STEP1 EXEC PGM=PAYMAIN,
// PARM='RPTOPTS(ON),TRAP(ON)'
//STEPLIB DD DSN=PAYROLL.LOADLIB,DISP=SHR
//SYSOUT DD SYSOUT=*
//CEEDUMP DD SYSOUT=*Your site may set options through PARM=, CEEOPTS, IGZOPTS, runtime option modules, or region defaults. If two places set the same option, the final report is the evidence to use.
When performance tuning is the wrong first move
These options can matter, but a slow job is often slow for a simpler reason: too many file reads, bad sort placement, missing Db2 statistics, repeated dynamic calls, or avoidable table scans. Runtime options should be checked after you know where the time is going.
For related COBOL tuning topics, read COBOL performance tuning tips, COBOL DYNAM compiler option, and COBOL RENT compiler option.
Production checklist
- Capture elapsed time and CPU time before any option change.
- Save the compile listing for the program being tested.
- Run with
RPTOPTS(ON)in a controlled test job if allowed. - Confirm whether
TESTis needed for the current run. - Keep
TRAP(ON)unless your site has a documented exception. - Keep
VCTRSAVE(OFF)unless vector state must be saved for condition handlers. - Record the final setting in the job documentation or change ticket.
Common mistakes
Confusing compile TEST with runtime TEST
A program can be compiled one way and run another way. Check both sides before deciding why debug behavior or timing changed.
Turning off TRAP without a dump plan
The next abend may lose the diagnostic path that support depends on. Do not trade away problem determination unless the site standard clearly permits it.
Changing options without a baseline
If you do not have CPU, elapsed time, input volume, and the current options report, you cannot tell whether the change helped.
Related COBOL posts
- COBOL Run-Time Performance Part 1
- COBOL TEST Compiler Option
- COBOL DYNAM Compiler Option
- COBOL RENT Compiler Option
- COBOL SSRANGE Compiler Option
- COBOL ARITH Compiler Option
FAQ
Should TEST be used in production COBOL jobs?
Use it only when the run is meant for debugging or when your site standard requires specific debug data. For normal high-volume production work, confirm that debug settings are intentional.
Is TRAP(ON) slower?
For many applications, TRAP(ON) is kept because the diagnostic value matters. Do not switch to TRAP(OFF) without testing and a clear dump-handling reason.
When is VCTRSAVE(ON) needed?
It is needed when user condition handlers depend on the vector environment. Ordinary COBOL batch programs often do not need it.
How do I confirm the active runtime options?
Use a controlled run with option reporting such as RPTOPTS(ON), if your site allows it, and review the Language Environment options report in the job output.
