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.

Table 1. Performance-related compiler options
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.
Start of changeINLINE

(see INLINE)

End of change
Start of changeTo control the compiler usage of inlining procedures (paragraphs or sections) referenced by PERFORM statements in the source program.End of change Start of changeSpecifying 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. End of change Start of changeSpecifying 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. End of change Start of changeYou can use the 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.End of change
Start of changeINITCHECK

(see INITCHECK)

End of change
Start of changeTo have the compiler check for uninitialized data items and issue warning messages when they are used without being initialized.End of change Start of changeNoneEnd of change Start of changeUse of the INITCHECK option might increase compile time and memory consumption.End of change Start of changeAll of the 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.End of change
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 MAXPCF(n) and n is not zero, when the program complexity factor exceeds n, any specification of OPTIMIZE(1) or OPTIMIZE(2) is reset to OPTIMIZE(0), and a warning message is generated.

None
Start of changeNUMCHECK

(see NUMCHECK)

End of change
Start of changeTo have the compiler generate extra code to validate data items when they are used as sending data items.End of change Start of changeNoneEnd of change Start of changeNUMCHECK 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.End of change Start of changeNoneEnd of change
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.
Start of changePARMCHECK

(see PARMCHECK)

End of change
Start of changeTo have the compiler generate an extra data item following the last item in WORKING-STORAGE. This buffer data item is then used at run time to check whether a called subprogram corrupted data beyond the end of WORKING-STORAGE. End of change Start of changeNoneEnd of change Start of changePARMCHECK will cause the compiler to generate slower code for programs with CALL statements. NOPARMCHECK should be in effect for good performance.End of change Start of changeNoneEnd of change
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 TEST or with NOTEST(DWARF).

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.