Sort optimization is the art of paying for ordering once—not three times because three REPORT sections each coded SEQUENCE on the same keys, not twice because a nightly extract is sorted in DFSORT and again inside Easytrieve, and not on rows that SELECT would have discarded before the first compare. Easytrieve invokes the system sort product; CPU and work data set pressure scale with record count and key width. Beginners optimize too late—tweaking SORTWK cylinders while feeding millions of unfiltered rows. This page teaches volume reduction BEFORE SELECT, single SORT feeding multiple JOB activities, SIZE and WORK parameters when record count is unknown, presorted JCL extracts for shared consumers, tie-break keys for stable order, internal versus external sort selection, and a production checklist aligned with Broadcom performance guidance.
The cheapest sort is the one that never sees rejected rows. Use JOB INPUT with IF and SELECT patterns, BEFORE SELECT on SORT when supported, or upstream extraction jobs that filter status codes before Easytrieve runs. Every removed row skips compare-merge I/O. Document filter predicates—optimization without audit trail confuses operations when counts drop.
12345678SORT NAME ORDERED INPUT PAYFILE USING PAY-KEY EMP-KEY BEFORE SELECT IF STATUS NE 'A' SKIP END-IF END-SELECT
| Pattern | Sort passes | When to use |
|---|---|---|
| SORT once then multiple JOB PRINT | One | Same keys, multiple reports |
| SEQUENCE per REPORT | One per REPORT | Avoid for identical keys |
| DFSORT JCL presort | Zero inside Easytrieve | Shared extract many programs |
| Already sorted input | Zero if monotonic | Upstream warehouse order guaranteed |
Sort shortest effective key that preserves business order—packed keys narrower than character when collating rules allow. Multi-key sorts list major key first; unnecessary trailing keys add compare cost. Add tie-break key—employee number after department—when equal keys must be deterministic across runs. Broadcom documents that equal-key order depends on sort product; do not rely on accidental order for regression tests.
When SORT input is not produced by a prior Easytrieve activity in the same run, SIZE supplies estimated record count so the sort utility allocates adequate work space—undersized work data sets cause spills and multipass merges that inflate elapsed time. WORK names sort work DDs per installation standards; coordinate SORTWK space with storage team. Test with peak month-end volume, not Tuesday sample.
SORT activity is external sort integration—appropriate for large sequential files. Internal sort paths suit smaller volumes per release thresholds. Wrong choice shows as long CPU in step or excessive work data set allocation. External presort in JCL when file exceeds comfortable in-step limits or when multiple programs consume same order.
1234567891011//PRESORT EXEC PGM=SORT //SORTIN DD DSN=RAW.PAYROLL,DISP=SHR //SORTOUT DD DSN=SORTED.PAYROLL,DISP=(,CATLG,DELETE), // SPACE=(CYL,(500,50)),UNIT=SYSDA //SYSIN DD * SORT FIELDS=(1,5,CH,A,10,8,PD,A) /* //EZT EXEC PGM=EZTPA00,... //INPUT DD DSN=SORTED.PAYROLL,DISP=SHR * Easytrieve JOB reads presorted — omit SORT activity
Report CONTROL fields must match sort key order major-to-minor. Optimizing sort without aligning CONTROL produces wrong subtotals without sort error message—worse than abend. SEQUENCE on REPORT documents expected order but does not replace physical sort.
PARM SORT(MSG(ALL)) helps test failures; it does not speed production. Remove after validating keys and work space. Runtime SORT messages wrapped in SYSPRINT point to key length mismatch or missing SORTWK—fix structure, not message suppression.
Sorting is lining up kids by height. Optimization is not inviting kids who are absent (filter first), lining up once for three photos (one SORT), and asking the gym teacher who already lined up the class (DFSORT presort) instead of shuffling again. If two kids are the same height, pick a second rule—like shirt color—so everyone stands in the same order tomorrow.
1. Best sort optimization often starts with:
2. One shared SORT before multiple PRINT reports:
3. SIZE on SORT is needed when:
4. JCL DFSORT presort helps when:
5. Equal keys without tie-break field: