Chapter 32: Key Takeaways - Performance Tuning for COBOL Programs

Chapter Summary

Performance tuning is the discipline of making COBOL programs execute faster, consume fewer resources, and complete within their allocated batch windows or response time targets. This chapter brought together knowledge from every preceding chapter -- language features, file handling, database access, transaction processing, and the z/OS environment -- to show how each layer contributes to overall performance and how each can be optimized. Performance tuning on the mainframe is not about clever tricks; it is a systematic process of measurement, analysis, and targeted improvement that requires understanding the entire execution stack from COBOL source code through the compiler, runtime, operating system, and hardware.

The chapter began with compiler options that directly affect generated code performance. Options like OPTIMIZE (levels 0, 1, and 2), TRUNC (STD, OPT, BIN), NUMPROC (NOPFD, PFD, MIG), ARITH (COMPAT, EXTEND), and SSRANGE influence how the compiler translates COBOL statements into machine instructions. We explored how OPTIMIZE(2) enables aggressive instruction scheduling, dead code elimination, and register allocation optimizations that can reduce CPU consumption by 10-20% compared to unoptimized code. The trade-off is that optimized code is harder to debug, so development builds typically use OPTIMIZE(0) with TEST, while production builds use OPTIMIZE(2) without TEST.

I/O optimization received extensive coverage because I/O is typically the dominant cost in batch COBOL programs. Strategies include choosing optimal block sizes (or letting the system choose with BLKSIZE=0), buffering (BUFNO for QSAM, BUFNI/BUFND for VSAM), sequential access method selection (QSAM versus BSAM), and VSAM free space and control interval tuning. For DB2 programs, we examined SQL optimization through proper predicate coding, index utilization, EXPLAIN analysis, host variable matching, and the avoidance of stage 2 predicates. CICS performance tuning covered COMMAREA sizing, BMS map efficiency, pseudo-conversational design, and the minimization of CICS API calls. Memory layout optimization addressed the placement of frequently accessed data items, the use of COMP and COMP-3 for arithmetic, and the avoidance of unnecessary data moves. The chapter concluded with monitoring tools -- SMF records, Strobe, IBM Application Performance Analyzer, and RMF -- that provide the measurements needed to identify performance bottlenecks and verify the effectiveness of optimizations.

Key Concepts

  • OPTIMIZE Compiler Option: Controls the level of code optimization. OPTIMIZE(0) generates straightforward code; OPTIMIZE(1) performs basic optimizations; OPTIMIZE(2) enables aggressive optimizations including cross-statement analysis, dead code elimination, and register reuse that significantly reduce CPU consumption.
  • TRUNC Compiler Option: Controls how binary (COMP) fields are truncated. TRUNC(OPT) generates the most efficient code by assuming the programmer manages values correctly. TRUNC(STD) truncates to the PIC size, adding overhead. TRUNC(BIN) treats binary fields as full binary values regardless of PIC.
  • Block Size Optimization: Larger block sizes reduce the number of physical I/O operations. For QSAM files, system-determined block size (BLKSIZE=0) typically selects the half-track value, which is optimal for most workloads. For VSAM, the control interval size (CISZ) serves a similar role.
  • BUFNO/BUFNI/BUFND: Buffer allocation parameters that control how many I/O buffers are allocated. More buffers reduce physical I/O by keeping frequently accessed data in memory. For sequential files, BUFNO=5 or higher reduces wait time. For VSAM, BUFNI (index) and BUFND (data) should be tuned based on access patterns.
  • DB2 SQL Optimization: Writing efficient SQL involves ensuring predicates are indexable (stage 1), avoiding implicit data type conversions, using BETWEEN instead of >= and <= combinations where appropriate, selecting only needed columns, and using FETCH FIRST n ROWS ONLY for bounded queries.
  • EXPLAIN Analysis: The DB2 EXPLAIN facility reveals the access path chosen by the optimizer for each SQL statement, showing which indexes are used, the join method, sort operations, and estimated cost. EXPLAIN is the primary tool for diagnosing and improving SQL performance.
  • CICS Pseudo-Conversational Efficiency: Pseudo-conversational design frees resources between user interactions, but the cost of re-establishing state on each RECEIVE must be minimized. Efficient COMMAREA management, minimal BMS map I/O, and cached lookup tables reduce the overhead of pseudo-conversational transactions.
  • Numeric Data Type Selection: COMP-3 (packed decimal) is most efficient for fields used in arithmetic with DISPLAY fields. COMP (binary) is most efficient for subscripts, indexes, and fields used in comparisons. DISPLAY numeric is least efficient for arithmetic and should be used only for fields that are displayed or printed without conversion.
  • Memory Alignment and Slack Bytes: The COBOL compiler inserts slack bytes to align binary (COMP) and floating-point fields on halfword, fullword, or doubleword boundaries. Grouping fields of similar types together minimizes slack bytes and reduces working storage size.
  • Batch Commit Frequency: For batch programs updating DB2, the commit interval affects both performance and recoverability. Committing every 500-1000 rows is a common starting point. Too frequent commits waste CPU on commit overhead; too infrequent commits consume excessive log space and hold locks too long.
  • PERFORM versus GO TO: While structured programming favors PERFORM, excessively deep PERFORM nesting or PERFORMs with many sections can generate suboptimal branch instructions. In performance-critical loops, flat inline code sometimes outperforms deeply nested PERFORMs, though readability must be considered.
  • SMF and RMF Monitoring: System Management Facility (SMF) records provide detailed job-level and step-level resource consumption data (CPU time, I/O counts, elapsed time). Resource Measurement Facility (RMF) provides system-level performance data. Together, they provide the metrics needed for performance analysis.
  • Application Performance Analyzer (APA): IBM's APA tool (formerly Strobe) provides statement-level CPU profiling for COBOL programs, showing exactly which paragraphs and statements consume the most CPU. This is the primary tool for identifying "hot spots" in COBOL code.
  • Efficient String Operations: STRING and UNSTRING operations are relatively expensive. For high-volume processing, reference modification (WS-FIELD(start:length)) is faster than STRING for simple extractions, and INSPECT TALLYING/REPLACING is optimized for single-character operations.

Common Pitfalls

  1. Optimizing without measuring first. The most common performance tuning mistake is optimizing the wrong thing. Always measure with SMF, APA, or EXPLAIN before changing code. The bottleneck is rarely where developers assume it is.
  2. Using OPTIMIZE(2) during development and debugging. OPTIMIZE(2) rearranges and eliminates code, making it extremely difficult to correlate abend offsets and debugger breakpoints with source lines. Use OPTIMIZE(0) with TEST for development; switch to OPTIMIZE(2) without TEST for production.
  3. Performing arithmetic on DISPLAY numeric fields in tight loops. Each arithmetic operation on a DISPLAY numeric field requires conversion to packed decimal, computation, and conversion back. Defining loop counters and accumulators as COMP or COMP-3 eliminates these conversions.
  4. Coding inefficient DB2 predicates that force table scans. Predicates with leading wildcards (LIKE '%VALUE'), functions on columns (YEAR(DATE_COL) = 2025), or mismatched data types prevent DB2 from using indexes, resulting in full table scans that can be orders of magnitude slower than indexed access.
  5. Opening and closing files repeatedly within a loop. Each OPEN and CLOSE involves operating system overhead. Files should be opened once at program start and closed once at program end, not opened and closed for each logical operation.
  6. Using COMPUTE for simple increments. ADD 1 TO WS-COUNTER generates a single machine instruction, while COMPUTE WS-COUNTER = WS-COUNTER + 1 may generate less optimal code depending on the compiler version and optimization level. For simple operations, use the dedicated arithmetic verbs.
  7. Not using BINARY or COMP for VSAM RRDS keys and subscripts. Subscripts and relative record numbers used in table lookups and RRDS access should be COMP (binary) to avoid repeated decimal-to-binary conversions that occur on every access.
  8. Ignoring VSAM buffer tuning. Default buffer allocation (typically 2 data buffers and 1 index buffer) is rarely optimal. Increasing BUFND for sequential access or BUFNI for random access can reduce physical I/O dramatically, especially for batch programs processing entire VSAM files.

Quick Reference

      * EFFICIENT DATA DEFINITIONS
       01  WS-COUNTER        PIC S9(8)  COMP.
       01  WS-SUBSCRIPT       PIC S9(8)  COMP.
       01  WS-AMOUNT          PIC S9(9)V99 COMP-3.
       01  WS-FLAG            PIC X.
           88  PROCESS-DONE   VALUE 'Y'.

      * EFFICIENT TABLE DEFINITION
       01  WS-TABLE.
           05  WS-ENTRY OCCURS 1000 TIMES
               INDEXED BY WS-IDX.
               10  WS-KEY       PIC X(10).
               10  WS-VALUE     PIC S9(7)V99 COMP-3.

      * USE SEARCH ALL FOR SORTED TABLES
           SEARCH ALL WS-ENTRY
               AT END PERFORM KEY-NOT-FOUND
               WHEN WS-KEY(WS-IDX) = SEARCH-KEY
                   MOVE WS-VALUE(WS-IDX) TO OUTPUT-VAL
           END-SEARCH.

      * EFFICIENT STRING EXTRACTION (REFERENCE MOD)
           MOVE WS-RECORD(15:8) TO WS-DATE-FIELD.

      * AVOID UNNECESSARY MOVES IN LOOPS
           PERFORM VARYING WS-IDX FROM 1 BY 1
               UNTIL WS-IDX > TABLE-SIZE
               IF WS-KEY(WS-IDX) = SEARCH-KEY
                   SET PROCESS-DONE TO TRUE
               END-IF
           END-PERFORM.

KEY COMPILER OPTIONS FOR PERFORMANCE:
  OPTIMIZE(2)    - Maximum optimization
  TRUNC(OPT)     - Efficient binary truncation
  NUMPROC(PFD)   - Assume valid sign (fastest)
  SSRANGE        - Remove for production (saves CPU)
  TEST           - Remove for production (saves CPU)
  FASTSRT        - Use DFSORT for internal SORTs
  RENT           - Reentrant code (LPA eligible)

VSAM BUFFER TUNING (JCL):
  //VSAMFILE DD DSN=MY.VSAM.KSDS,DISP=SHR,
  //            AMP=('BUFND=10,BUFNI=5')

DB2 PERFORMANCE CHECKLIST:
  1. Run EXPLAIN for every SQL statement
  2. Ensure predicates are stage 1 (indexable)
  3. Match host variable types to column types
  4. Use FOR FETCH ONLY on read-only cursors
  5. Avoid SELECT * (name needed columns)
  6. Use OPTIMIZE FOR n ROWS on cursors
  7. Commit at appropriate intervals in batch
  8. Rebind packages after RUNSTATS

BATCH I/O OPTIMIZATION:
  - BLKSIZE=0 for system-optimal blocking
  - BUFNO=5+ for sequential QSAM files
  - Use FASTSRT compiler option with SORT verb
  - Release unused space: SPACE=(x,(p,s),RLSE)

What's Next

With the completion of this chapter on performance tuning, you have covered the full spectrum of mainframe environment skills needed to develop, deploy, and optimize COBOL programs in a z/OS environment. The chapters in this part -- JCL, batch processing, utilities, dataset management, security, and performance -- together provide the operational context that transforms a COBOL programmer into a complete mainframe application developer. The next part of the book moves into modern integration topics, exploring how COBOL programs connect with web services, APIs, and contemporary architectures while continuing to serve as the backbone of enterprise computing.