CPU seconds drive mainframe software charges and batch window length. Easytrieve hides much complexity behind automatic file handling and report formatting, but that automation still executes machine instructions on every row. Broadcom's efficiency guidance focuses on data types in hot paths, array indexing, sort discipline, and intelligent table access. This page translates those recommendations into actionable habits for developers maintaining legacy reports and new extracts alike—without premature micro-optimization of cold code paths.
Start with job accounting: SMF records or scheduler reports showing CPU versus wait. If CPU is high with low wait, suspect sort, arithmetic loops, or report formatting. If wait dominates, tune I/O first. Easytrieve does not ship a developer profiler in every installation, so use structured experiments—disable one REPORT, halve input with SELECT, or replace SEQUENCE with presorted input—and compare CPU deltas.
Mainframe binary packed fields (type B or P in definitions) align with hardware decimal instructions. Zoned decimal (type Z) suits display-friendly files but costs more when used in tight ADD and MULT loops. Define file fields to match source data, but convert to binary working storage for accumulators touched millions of times. Avoid repeated MOVE between zoned and packed in inner loops—convert once per row in BEFORE-LINE or JOB logic.
12345678FILE SALES FB(80 800) AMOUNT-Z 40 7 Z 2 %SALES WS-TOTAL W 9 P 2 JOB INPUT SALES MOVE AMOUNT-Z TO WS-AMOUNT-P ADD WS-AMOUNT-P TO WS-TOTAL PRINT SALESRPT
When processing OCCURS tables or byte arrays, indexes (computed once) beat subscripts (converted internally each reference) in CPU-sensitive loops. Subscripts remain readable for small utilities; hot paths in payroll tax arrays or rate tables benefit from index variables updated explicitly in DO loops. Balance readability with measured cost.
Broadcom best practices recommend keeping masters presorted and avoiding redundant sorts during execution. Merge presorted updates in the same order as the master. Use one SORT activity to feed multiple PRINT statements when keys match. Filter with SELECT before SORT so the sort product compares fewer records. For installation sort, FASTSRT may reduce I/O wait inside sort when supported—coordinate with operations rather than coding it in application source.
Large TABLE scans are O(n) per lookup. Indexed TABLE files where SEARCH ARG equals the key compile toward keyed READ semantics—far cheaper at scale. When lookups exceed a few thousand entries, evaluate VSAM KSDS instead of TABLE entirely. CPU and memory improve together.
| Tactic | CPU effect | Note |
|---|---|---|
| Binary accumulators | Lower per arithmetic op | Convert at row boundary |
| Index in loops | Lower array access | Hot paths only |
| SELECT filter | Fewer ops overall | Validate business rules |
| One shared sort | Avoid duplicate sort | Match keys exactly |
| Keyed SEARCH | Avoid table scan | Requires indexed TABLE |
Copy-pasted PROC blocks drift over years—one copy gains an extra SORT or DISPLAY during a panic fix. Central macros for FILE layouts and standard totals reduce accidental CPU regressions during maintenance even though macro expansion itself is not a runtime optimization. Code review checklists should flag new SORT, SEQUENCE, and DISPLAY in production branches.
DEBUG FLDCHK, FLOW, and verbose LIST options add CPU and storage during test. Remove them from production PARM profiles. ABEXIT SNAP is for diagnosis, not steady-state schedules. Production should follow site defaults unless operations approves exceptions.
CPU is how hard the computer thinks. Sorting a whole toy box every time you need one color is exhausting—that is SEQUENCE on already messy data. Counting with fast finger tricks (binary math) beats counting on slow sticky notes (zoned fields) when you add thousands of numbers. Ask the computer to do less work by giving it fewer toys and sorting once.
1. For heavily used calculations Broadcom recommends:
2. Indexes compared with subscripts in array loops:
3. Sorting during Easytrieve execution:
4. FASTSRT site option affects:
5. SEARCH on an indexed TABLE file when ARG equals the key:
Sort and report formatting dominate many jobs: SORT/SEQUENCE compare-merge, LINE and mask evaluation per row, and control-break processing. I/O waits show as elapsed time but sort and format work show as CPU.
Only if arithmetic on that field is a proven hotspot. Profile with representative data first. Converting all fields blindly adds conversion overhead at I/O boundaries without benefit.
Macros reduce maintenance and duplicate compile size; they do not magically shrink runtime CPU. They help organizations avoid copy-paste drift that leads to accidental extra SORT or DISPLAY statements.
Fewer input rows mean fewer sort comparisons, LINE formats, and break evaluations—CPU drops roughly with row reduction when the expensive steps are per-row.
No. Compile-and-go adds compile CPU every run. Link-edit load modules remove repeated compile cost in production.