COBOL - Performance Tuning
- Avoid repetitive uses of the INITIALIZE statement. INITIALIZE once and move it to a second like-sized 01 level, then move the second 01 level to the first to initialize the fields.
Here is one better way of INITIALIZATION of a record or group item.
INITIALIZE WS-RECORD
REPLACING ALPHANUMERIC DATA BY SPACES
NUMERIC DATA BY ZEROES. |
- Consider using an in-line PERFORM instead of a SEARCH when you have less than 20 elements in a table.
- In general, It is an advantage to use COMP for numeric data and COMP-3 for decimal data.
- Performance Considerations for Datatypes
- PACKED-DECIMAL (COMP-3): Use 15 or few digits in the PIC clause to avoid the use of library routines.
- Always code an odd number of digits!
- While performing arithmetic, always use the signed numeric fields.
» COBOL performs faster with signed fields than unsigned fields.
- Specify SYNC for BINARY items.
- Use signed data items with 8 or fewer digits – [S9(8)BINARY SYNC]
» 9 or more digits is slower
» 18 digits is slowest
- Avoid USAGE IS DISPLAY for numeric fields [ PIC S99].
- Performance Considerations for Constant and Variables
- Use PIC S9(8) BINARY fields for loop control variables.
- Initialize constants with a value clause and do not modify them or pass the by reference (Compile will optimize the constants).
- Performance Considerations for Tables
- Using variable-length tables is 5% slower than using a fixed-length table.
- Using a variable-length table that references the first complex ODO(Occurs Depending On)element is 7% slower than using a fixed-length table.
- Performance Considerations for Indexes and Subscripts
- Indexes are faster than subscripts.
- If you select subscripts, code S9(8) BINARY SYNC other Usage clauses like COMP,COMP-3 and DISPLAY results in lower performance.
- When referring to tables sequentially, having the leftmost subscript vary the most often can be 50% slower than having the rightmost subscript vary the most often.
- Binary search on table(using SEARCH ALL) is faster than Linear search(SEARCH).
- Performance Considerations for CALL Statement
- Call literal(Static call) faster than dynamic call literal.
Example:
CALL ‘PROGRAMA’ - Static call
|
is faster than
01 WS-PGM PIC X(08).
MOVE ‘PROGRAMA’ to WS-PGM.
CALL WS-PGM - Dynamic Call
|
- Nested calls are faster than static calls. Because When a COBOL program calls a nested program, the CALL is resolved by the compiler without any system intervention.
- IS INITIAL on PROGRAM-ID can be very penalizing in terms of time.
- Performance Considerations for QSAM files
- To allow the OS/390 operating system to optimize your block size code
- BLOCK CONTAINS 0 RECORDS on FD section of COBOL program
- And BLKSIZE = 0 on DCB in JCL
- When performing arithmetic, always use signed numeric fields. COBOL performs faster with signed fields than unsigned fields.
- When writing to variable length blocked sequential files, use the APPLY WRITE-ONLY clause for the file or use the AWO compiler option. This can reduce the number of calls to Data Management Services to handle the I/Os.
- If you use SEARCH in COBOL, it is better to use SEARCH ALL ( Binary Search).
- Using indexes to address a table is more efficient than using subscripts since the index already contains the displacement from the start of the table and does not have to be calculated at run-time.
- For loop control variables use binary data items.
Performance considerations for loop control variables (PIC S9(8)):
- using a decimal (COMP-3) is 320% slower than using binary (COMP)
- using a DISPLAY is 890% slower than using binary (COMP)
- If you are accessing the file sequentially, It s good to mention BLOCK CONTAINS 0 RECORDS on FD and BLKSIZE = 0 on DCB.
Also, Many compiler options do have a far reaching performance implications on the program during runtime, especially the ARITH, AWO, DYNAM, FASTSRT, NUMPROC, OPTIMIZE, RENT, SSRANGE, TEST, THREAD, and TRUNC options.
Below is the explanation for each of the compiler options mentioned above and how they impact the performance:-
ARITH - EXTEND or COMPAT :
The ARITH compiler option allows you to control the maximum number of digits allowed for numeric variables in your program.ARITH(EXTEND), the maximum number of digits is 31 - Slower. ARITH(COMPAT), the maximum number of digits is 18 - Faster.
AWO or NOAWO :
APPLY WRITE-ONLY processing for physical sequential files with VB format.
APPLY WRITE-ONLY , the file buffer is written to the output device when there is notenough space in the buffer for the next record.Without APPLY WRITE-ONLY, the file buffer is written to the output device when there is not enough space in the buffer for the maximum size record.
If the application has a large variation in the size of the records to be written, using APPLY WRITE-ONLY can result in a performance savings since this will generally result in fewer I/O calls.
NOAWO is the default.
DATA(24) or DATA(31) :
Specifies whether reentrant program data areas reside above or below the 16-MB line. With DATA(24) reentrant programs must reside below the 16-MB line. With DATA(31) reentrant programs can reside above the 16-MB line.
DATA(31) is the default.
DYNAM or NODYNAM :
DYNAM ,Changes the behavior of CALL literal statements to load subprograms dynamically at run time. Call path length is longer - slower NODYNAM ,CALL literal statements cause subprograms to be statically link-edited in the load module. Call path length is - faster
NODYNAM is the default.
FASTSRT or NOFASTSRT :
FASTSRT ,Specifies fast sorting by the IBM DFSORT licensed program. - FasterNOFASTSRT ,Specifies that Enterprise COBOL will do SORT or MERGE input/output. - Slower
NOFASTSRT is the default
NUMPROC - NOPFD, MIG, or PFD :
Handles packed/zoned decimal signs as follows:
NUMPROC(NOPFD), sign fix-up processing is done for all references to these numeric data items. NUMPROC(MIG), sign fix-up processing is done only for receiving fields (and not for sendingfields) of arithmetic and MOVE statements. NUMPROC(PFD), the compiler assumes that the data has the correct sign and bypasses this sign fix-up processing.
For performance sensitive applications, NUMPROC(PFD) is recommended when possible.
NUMPROC(NOPFD) is the default.
OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE :
Optimizes the object program. OPTIMIZE has the suboptions of (STD/FULL).
OPTIMIZE(FULL) provides improved runtime performance, over both the OS/VS COBOL and VS COBOL II OPTIMIZE option, because the compiler discards unused data items and does not generate code for any VALUE clauses for these data items.
NOOPTIMIZE is generally used while a program is being developed when frequent compiles arenecessary. NOOPTIMIZE also makes it easier to debug a program since code is not moved;
NOOPTIMIZE is the default.
RENT or NORENT :
Using the RENT compiler option causes the compiler to generate some additional code to ensure that the program is reentrant.
On the average, RENT was equivalent to NORENT.
RENT is the default.
RMODE - AUTO, 24, or ANY :
Allows NORENT programs to have RMODE(ANY).
When using NORENT, the RMODE option controls where the WORKING-STORAGE will reside.With RMODE(24), the WORKING-STORAGE will be below the 16 MB line. With RMODE(ANY), theWORKING-STORAGE can be above the 16 MB line.
RMODE(AUTO) is the default.
SSRANGE or NOSSRANGE :
SSRANGE - At run time, checks validity of subscript, index, and reference modification references. Its slower than NOSSRANGE.
NOSSRANGE is the default.
TEST or NOTEST :
TEST - Produces object code usable by Debug Tool for the product. It is slower than NOTEST.
NOTEST is the default.
THREAD or NOTHREAD :
THREAD -Enables a COBOL program for execution in a run unit with multiple POSIX threads or PL/I tasks. It is slower than NOTHREAD.
NOTHREAD is the default.
TRUNC - BIN, STD, or OPT :
Truncates final intermediate results.
TRUNC(STD) Truncates numeric fields according to PICTURE specification of the binary receiving field TRUNC(OPT) Truncates numeric fields in the most optimal way TRUNC(BIN) Truncates binary fields based on the storage they occupy
on an average performance analysis - TRUNC(OPT) > TRUNC(STD) > TRUNC(BIN)
TRUNC(STD) is the default.
If you have any doubts or queries related to this chapter, get them clarified from our Mainframe experts on ibmmainframer Community!