Reports are why many shops keep Easytrieve: control breaks, masks, and titles in dozens of lines instead of hundreds of COBOL print routines. At high volume, the report engine becomes a CPU and spool factory—every detail line runs LINE expressions, masks format amounts, and CONTROL fields trigger break procedures. Broadcom documents WORKFILE, dedicated report FILE parameters, and careful sort design as primary tuning tools. This page teaches beginners how report spool is built, where time is spent, and which REPORT statement choices multiply work unnecessarily.
JOB or PRINT activities feed rows into the report processor. For each detail line, Easytrieve evaluates LINE fields, applies masks, checks CONTROL break levels, and may invoke BEFORE-LINE or AFTER-BREAK procedures. Intermediate results sit in VFM unless WORKFILE or REPORT FILE parameters redirect spool to disk. Large reports therefore hit both CPU (formatting) and memory (spool). Tuning targets either fewer rows, cheaper formatting per row, or better spool placement.
On batch z/OS, coding WORKFILE on PARM or on individual REPORT statements tells Easytrieve to use sequential work files for report intermediates. WORKFSPA sets cylinder space for dynamic allocations. Alternatively, FILE on the REPORT statement names a dedicated work dataset. Broadcom states this improves performance for large reports compared with VFM-only processing. In programs with three heavy reports, give each report its own work file rather than forcing one overflow pack to serve all spool.
1234567891011121314PARM WORKFILE FILE SALES FB(150 15000) %SALES JOB INPUT SALES PRINT SUMMARY PRINT DETAIL * REPORT SUMMARY WORKFILE CONTROL REGION LINE REGION TOTAL-AMT * REPORT DETAIL WORKFILE SEQUENCE STORE LINE STORE ITEM AMT
SEQUENCE sorts report spool for one report—slimmer than sorting full master files but still sort work. If SUMMARY and DETAIL reports both SEQUENCE on STORE within the same program, you may pay twice for similar ordering. When input can be presorted once—via SORT activity or external JCL—both reports may omit SEQUENCE if keys align. Compare CPU in test; identical keys do not guarantee stable order among equals unless tie-break keys match your sort product behavior.
CONTROL fields should match business hierarchy—region before store, not the reverse unless reports require it. Each break level fires procedures and totals. Avoid expensive PERFORM chains in AFTER-BREAK for levels that fire thousands of times. Move one-time calculations to derived fields populated in JOB before PRINT. Use BREAK-LEVEL tests to limit logic to relevant levels only.
Simple LINE fields referencing file columns are cheapest. Nested expressions, repeated SUBSTR chains, and conditional masks on every detail line multiply CPU. TITLE and HEADING lines run less often than detail but long heading stacks still add I/O. Prefer consistent LINESIZE aligned with printer definitions rather than arbitrary widths that force padding work. Review whether every mask digit justifies its cost on million-row extracts.
| Lever | Action | Typical impact |
|---|---|---|
| SELECT before PRINT | Filter JOB input | Fewer detail lines |
| WORKFILE | Disk spool per report | Lower VFM/EZTVFM stress |
| Shared presort | One SORT feeds reports | Lower sort CPU |
| Simplify LINE | Reduce per-row expressions | Lower format CPU |
| Break alignment | Match keys to sort order | Fewer break events |
Performance articles describe EZTVFM as a single overflow area that multiple VFM-heavy reports can fight over. Symptoms include elongated elapsed time on the third report even when the first two finish quickly. Mitigation: WORKFILE or explicit FILE on each REPORT, stagger heavy reports into separate job steps, or split programs. Operations may also place EZTVFM on faster DASD or VIO per site standards.
Extended reporting printers support fonts and positioning beyond basic line printers. Mixed fonts on one line can make COL placement approximate when metrics differ. For performance-sensitive batch, keep layouts simple unless extended features are mandatory. Defaults for SPACE, LINESIZE, and printer DD often come from the site options table—not from your program source alone.
A report is like printing a yearbook for every student. WORKFILE is using a separate stack of paper for each chapter so one huge chapter does not bury the others. SEQUENCE is sorting names before printing—if two chapters need the same order, sort once instead of twice. Short lines with simple words print faster than fancy decorations on every page.
1. Multiple large REPORT activities in one program often benefit from:
2. SEQUENCE inside REPORT compared with one shared SORT activity:
3. WORKFILE on REPORT directs intermediate report data to:
4. Complex MASK and many LINE items primarily affect:
5. Filtering rows before REPORT processing saves time because:
Printing an unfiltered million-row master with multiple SEQUENCE sorts and no WORKFILE in a memory-constrained region. The fix is usually filter-first, shared sort, and dedicated work files—not more TITLE lines.
NOPAGE changes paging behavior for reports. It is not a universal speedup—use it when report layout allows and documentation for your release supports the option. Measure rather than assume.
Breaks add logic at level changes—subtotals, headings, and footing. Necessary breaks should use minimal work in AFTER-BREAK procedures. Misaligned BREAK fields force extra break events and inflate CPU.
Yes. Extended printer definitions and font metrics affect COL positioning and spool construction. Site printer set modules define defaults—heavy mixed-font lines cost more than simple uniform lines.
Yes, when safe. Report tuning appears only at scale. Use masked test data that matches layout and row counts representative of production.