Rational Developer for System z
Enterprise COBOL for z/OS, Version 4.1, Programming Guide


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
ARITH(EXTEND)

(see ARITH)

To increase the maximum number of digits allowed for decimal numbers In general, none ARITH(EXTEND) causes some degradation in performance for all decimal data types due to larger intermediate results. The amount of degradation that you experience depends directly on the amount of decimal data that you use.
AWO To get optimum use of buffer and device space Can result in performance savings, because this option results in fewer calls to data management services to handle input and output In general, none When you use AWO, the APPLY WRITE-ONLY clause is in effect for all files in the program that are physical sequential with V-mode records.
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. In general, 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 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 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 when direct work files are used for the sort work files. Not all sorts are eligible for this option.
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(MIG) and NUMPROC(NOPFD). When you use NUMPROC(PFD), the compiler assumes that the data has the correct sign and bypasses the sign "fix-up" process. Because not all external data files contain the proper sign for COMP-3 or DISPLAY signed numeric data, NUMPROC(PFD) might not be applicable for all programs. For performance-sensitive applications, NUMPROC(PFD) is recommended.
OPTIMIZE(STD)

(see OPTIMIZE)

To optimize generated code for better performance Generally results in more efficient runtime code Longer compile time: OPTIMIZE requires more processing time for compiles than NOOPTIMIZE. NOOPTIMIZE is generally used during program development when frequent compiles are needed; it also allows for symbolic debugging. For production runs, OPTIMIZE is recommended.
OPTIMIZE(FULL)

(see OPTIMIZE)

To optimize generated code for better performance and also optimize the DATA DIVISION Generally results in more efficient runtime code and less storage usage Longer compile time: OPTIMIZE requires more processing time for compiles than NOOPTIMIZE. OPT(FULL) 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.
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  
RMODE(ANY)

(see RMODE)

To let the program be loaded anywhere RMODE(ANY) with NORENT lets the program and its WORKING-STORAGE be located above the 16-MB line, relieving storage below the line. In general, none  
NOSSRANGE

(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. None 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. You can turn off SSRANGE at run time by using the CHECK(OFF) runtime option. For performance-sensitive applications, NOSSRANGE is recommended.
TEST(NOHOOK) or NOTEST

(see TEST)

To avoid the additional object code that is needed to take full advantage of Debug Tool, use TEST(NOHOOK) or NOTEST. With TEST(NOHOOK), you can also use the SEP suboption to further reduce the size of your object code. Because TEST(HOOK) generates additional code, it can cause significant performance degradation when used in a production environment. None TEST without the suboption NOHOOK forces compiler option NOOPT into effect. For production runs, using NOTEST or TEST(NOHOOK) with or without the SEP suboption is recommended. This results in overlay hooks rather than compiled-in hooks.

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(NOHOOK) with or without the SEP suboption.

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. This is true for a threaded or a 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, though its performance was improved in COBOL for OS/390 & VM V2R2. TRUNC(STD) conforms to Standard COBOL 85, 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.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)