Performance-related compiler options
In the table below you can see a description of the purpose of each option, its performance advantages and disadvantages, and usage notes where applicable.
Compiler option | Purpose | Performance advantages | Performance disadvantages | Usage notes |
---|---|---|---|---|
AFP(NOVOLATILE) (see AFP) |
To control the compiler usage of the Additional Floating Point (AFP) registers that are provided by z/Architecture processors | AFP(NOVOLATILE) lets the compiler
generate more efficient code sequences for programs with floating
point operations. |
None | Poorly behaved assembler code
might not adhere to the standard calling convention and might fail
to correctly preserve values in Floating Point registers. With AFP(NOVOLATILE) ,
COBOL programs can safely call such routines. |
ARCH (see ARCH) |
To specify the machine architecture for which the executable program instructions are to be generated | If you specify a higher ARCH level,
the machine generates code that uses newer and faster instructions
instead of the sequences of common instructions. |
None | Your application might abend if it runs on a
processor with an architecture level lower than that specified for
the ARCH option. |
ARITH(EXTEND) (see ARITH) |
To increase the maximum number of digits allowed for decimal numbers | None | ARITH(EXTEND) causes some degradation in performance
for all decimal data types because of larger intermediate results. |
The amount of degradation that you experience depends directly on the amount of decimal data that you use. |
AWO (see AWO) |
To get optimum use of buffer and device space for QSAM files | Can result in performance savings, because this option results in fewer calls to data management services to handle input and output | None | If you use AWO , the APPLY WRITE-ONLY clause
is in effect for all QSAM files in the program that have V-mode records. |
BLOCK0 (see BLOCK0) |
To take advantage of system-determined block size for QSAM output files | Can result in enhanced processing speed and minimized storage requirements for QSAM output files | None | If you use BLOCK0 , a BLOCK CONTAINS
0 clause is activated for all QSAM files in the program that
specify neither BLOCK CONTAINS nor RECORDING
MODE U in the file description entry. |
DATA(31) (see DATA) |
To have DFSMS allocate QSAM buffers above the 16 MB line (by
using the RENT and DATA(31) compiler
options) |
Because extended-format QSAM data sets can require many buffers, allocating the buffers in unrestricted storage avoids virtual storage constraint problems. | None | On a z/OS® system with
DFSMS, if your application processes striped extended-format QSAM
data sets, use the RENT and DATA(31) compiler
options to have the input-output buffers for your QSAM files allocated
from storage above the 16 MB line. |
DYNAM (see DYNAM) |
To have subprograms (called through the CALL statement)
dynamically loaded at run time |
Subprograms are easier to maintain, because the application does not have to be link-edited again if a subprogram is changed. | There is a slight performance penalty, because the call must go through a Language Environment® routine. | To free virtual storage that is no longer needed, issue the CANCEL statement. |
FASTSRT (see FASTSRT) |
To specify that the IBM DFSORT product (or equivalent) will handle all of the input and output | Eliminates the overhead of returning to Enterprise COBOL after each record is processed. | None | FASTSRT is recommended if direct work files
are used for the sort work files. Not all sorts are eligible for this
option. |
HGPR (see HGPR) |
To control the compiler usage of the 64-bit registers provided by z/Architecture processors. | If you specify HGPR(NOPRESERVE) ,
the compiler omits preserving the high-halves of the 64-bit GPRs that
a program is using, which improves performance. |
None | If your program modifies and does not save the
high-halves of the registers, but calling programs depend on the unchanged
values, the application might give incorrect results. Exception: It does not apply
if the caller of this program is Enterprise COBOL, Enterprise PL/I or z/OS XL C/C++ programs.
|
![]() INLINE (see INLINE) ![]() |
![]() ![]() |
![]() INLINE allows
the compiler to decide whether to inline procedures referenced by
PERFORM statements. This typically improves performance when the application
contains commonly occurring and often-executed procedures. ![]() |
![]() INLINE usually
increases the size of the module. For commonly occurring but rarely
executed procedures, you can use the >>INLINE OFF directive to prevent
the compiler from inlining that procedure and increasing the module
size. ![]() |
![]() INLINE compiler
option to indicate that a procedure should be considered eligible
for inlining, but the decision whether to inline a procedure in a
specific PERFORM statement or not is made by the compiler.![]() |
![]() INITCHECK (see INITCHECK) ![]() |
![]() ![]() |
![]() ![]() |
![]() INITCHECK option
might increase compile time and memory consumption.![]() |
![]() INITCHECK analyses
occur at compile time only. The INITCHECK option
has no effect on the behavior or performance of the program after
it has been compiled.![]() |
MAXPCF (see MAXPCF) |
To reduce optimization in programs that require excessive compilation time or excessive storage requirements because of large sizes or complexity. | None | If you specify |
None |
![]() NUMCHECK (see NUMCHECK) ![]() |
![]() ![]() |
![]() ![]() |
![]() NUMCHECK is
much slower than NONUMCHECK , depending on how many
zoned decimal (numeric USAGE DISPLAY) data items, packed decimal (COMP-3)
data items, and binary data items are used in a COBOL program.![]() |
![]() ![]() |
NUMPROC(PFD) (see NUMPROC) |
To have invalid sign processing bypassed for numeric operations | Generates significantly more efficient code for numeric comparisons | For most references to COMP-3 and DISPLAY numeric
data items, NUMPROC(PFD) inhibits extra code from
being generated to "fix up" signs. This extra code might also inhibit
some other types of optimizations. The extra code is generated with NUMPROC(NOPFD) . |
If you use NUMPROC(PFD) ,
the compiler assumes and requires that all decimal items contain the
preferred sign values and bypasses the sign "fix-up" process. However,
because not all external data files contain the proper signs for COMP-3 or DISPLAY numeric
data, and programs might use REDEFINES , group moves,
or parameter passing in ways that do not ensure preferred signs, the NUMPROC(PFD) might
not be appropriate for many programs. |
OPTIMIZE(0|1|2) (see OPTIMIZE) |
To optimize generated code for better performance | Generally results in more efficient runtime code | Longer compile time: OPTIMIZE(1|2) requires
more processing time for compiles than OPTIMIZE(0) . |
OPTIMIZE(0) is generally used
during program development when frequent compiles are needed; it also
allows for symbolic debugging. For production runs, OPTIMIZE(1|2) is
recommended. |
STGOPT (see STGOPT) |
To optimize storage allocation in DATA DIVISION | Generally results in less storage usage | None | STGOPT deletes unused data items,
which might be undesirable in the case of time stamps or data items
that are used only as markers for dump reading. |
![]() PARMCHECK (see PARMCHECK) ![]() |
![]() ![]() |
![]() ![]() |
![]() PARMCHECK will cause the compiler
to generate slower code for programs with CALL statements. NOPARMCHECK should
be in effect for good performance.![]() |
![]() ![]() |
RENT (see RENT) |
To generate a reentrant program | Enables the program to be placed in shared storage (LPA/ELPA) for faster execution | Generates additional code to ensure that the program is reentrant | None |
RMODE(ANY) (see RMODE) |
To let the program be loaded anywhere | None | None | None |
SSRANGE (see SSRANGE) |
To verify that all table references and reference modification expressions are in proper bounds | SSRANGE generates additional code for verifying
table references. Using NOSSRANGE causes that code
not to be generated. |
With SSRANGE specified, checks
for valid ranges do affect compiler performance. |
In general, if
you need to verify the table references only a few times instead of
at every reference, coding your own checks might be faster than using SSRANGE . For
performance-sensitive applications, NOSSRANGE is
recommended. |
TEST (see TEST) |
To get full debugging capability when using Debug Tool and to get a symbolic
dump of the data items in CEEDUMP . You can also get
a symbolic dump of the data items in CEEDUMP with NOTEST(DWARF) . |
None | Some reduction in optimization
occurs when the TEST option is used. More
reduction in optimization occurs when the EJPD suboption
of TEST is used. |
For production runs, using NOTEST or TEST(NOEJPD) is recommended. If
during a production run, you want a symbolic dump of the data items
in a formatted dump if the program abends, compile using |
THREAD (see THREAD) |
To enable programs for execution in a Language Environment enclave that has multiple POSIX threads or PL/I tasks | None | There is a slight performance penalty because of the overhead of serialization logic. | A slight performance penalty occurs in either a threaded or nonthreaded environment. |
TRUNC(OPT) (see TRUNC) |
To avoid having code generated to truncate the receiving fields of arithmetic operations | Does not generate extra code and generally improves performance | Both TRUNC(BIN) and TRUNC(STD) generate
extra code whenever a BINARY data item is changed. TRUNC(BIN) is
usually the slowest of these options. |
TRUNC(STD) conforms to the 85 COBOL Standard, but TRUNC(BIN) and TRUNC(OPT) do
not. With TRUNC(OPT) , the compiler assumes that the
data conforms to the PICTURE and USAGE specifications. TRUNC(OPT) is
recommended where possible. |