Performance tuning for Easytrieve batch begins with a honest question: is the job waiting on disk, burning CPU in arithmetic loops, or spending hours in sort work datasets? A million-record payroll extract with tight BUFNO on twelve input files is I/O-bound until buffers increase—yet raising BUFNO on thirty files simultaneously can exhaust below-the-line storage on AMODE31 programs per Broadcom knowledge articles. A control-break report with complex BEFORE-LINE logic on every detail may be CPU-bound even when I/O is healthy. A presort SELECT on half the master file before SORT is sort-bound when work datasets spill to slower volumes. Easytrieve adds product-specific knobs—VFM for VIRTUAL files, WORKFSPA for report work files, PARM WORK for sort work dataset policy—on top of generic mainframe discipline of measuring before changing. This overview maps the performance chapter topics—file buffering, sort optimization, memory, large datasets, report tuning, CPU and I/O—into a beginner workflow: baseline measurement, bottleneck classification, targeted changes, regression compare, and production hardening without debug overhead.
Capture elapsed time, EXCP counts, and CPU seconds from SMF type 30 or job accounting on representative production input volume—not ten-record test files. Re-run after each change on same input to compare. Document LPAR load; Tuesday night contention differs from Sunday test. Single change per experiment isolates cause—simultaneous BUFNO bump plus SORT WORK change plus logic rewrite confounds analysis.
| Topic | Primary levers | Typical bottleneck |
|---|---|---|
| File buffering | BUFNO FILE/JCL/options, BLKSIZE | Sequential read/write I/O |
| Sort optimization | SORT keys, WORK PARM, SORTWK JCL | Sort work space and passes |
| Memory | REGION, AMODE31, BUFNO total, VFM | Abends or paging |
| Large datasets | Streaming design, presort, split jobs | Elapsed window exceed |
| Report tuning | WORKFSPA, control breaks, LINE work | Report work file I/O |
| CPU | Per-record logic, lookups, DISPLAY | CPU seconds high vs I/O |
| I/O | Buffering, dataset placement, VSAM CI | EXCP and wait high |
Multiple sequential passes over same large file—JOB read, SORT, second JOB read—multiply EXCP. Mitigations: combine passes in one activity where logic allows, increase BUFNO on input after testing, match BLKSIZE to LRECL multiples, place datasets on appropriate storage class. VSAM sequential browse uses AMP and CI size—not BUFNO. See file buffering and I/O optimization pages.
Internal SORT on wide records with many keys consumes work space. Presort SELECT reducing record count before SORT helps. PARM WORK controls dynamic sort work datasets versus JCL SORTWK. Insufficient work space forces multi-pass sort—dramatic elapsed increase. SORTMSG diagnostics explain allocation failures.
Programs building many VIRTUAL intermediate files stress Virtual File Manager. VFMSPAC options table and PARM VFM FILE parameter influence allocation and contention when EZTVFM pack busy. Consolidate passes or use explicit work files in JCL when VFM thrashes.
12345FILE STAGE1 VIRTUAL SEQUENTIAL KEY-FIELD 1 10 A AMOUNT 11 5 P 2 * Many VIRTUAL files in one job—monitor VFM and elapsed
Control reports with breaks and multiple LINE types write work files. WORKFSPA options and PARM WORKFILE override cylinder allocation per report work file—undersized causes extend or abend on large breaks. Report tuning page covers LINE and CONTROL interaction with work file growth.
Per-record DISPLAY, uncached table searches, redundant date calls, complex IF on every detail when subset would suffice—CPU adds up without extra I/O. Move invariant work to INIT procedure. Use indexed table lookup patterns for repeated reference data. Remove DEBUG FLOW from production load module.
Test with production-scale row counts periodically—ten-row test hides quadratic algorithms. Production JCL should omit debug PARM and limit DISPLAY. Compare compile summary to ensure DEBUG options not accidentally embedded in load from dev compile proc.
Performance is making the homework finish faster. Sometimes you are slow because you walk to the file cabinet too often—that is I/O; bigger armfuls (buffers) help. Sometimes you sort too many papers—that is sort; sort less first. Sometimes you redo math on every line when once at start enough—that is CPU. Measure which part is slow before guessing the fix.
1. Easytrieve batch jobs often bottleneck first on:
2. BUFNO on FILE affects:
3. VIRTUAL files use:
4. Before tuning BUFNO on twenty files you should:
5. Performance tuning starts with: