Easytrieve Sort Performance

Where CPU Time Goes During Sort

Compare operations dominate sort CPU: each record participates in multiple comparisons during merge passes. Wider keys and more keys increase compare cost per decision. I/O dominates elapsed time when work data sets exceed memory and the installation sort writes intermediate runs to SORTWK volumes. Easytrieve adds prescreen procedure overhead for every input record when BEFORE is coded—cheap IF tests on millions of rows still add up. REPORT SEQUENCE adds PRINT spool I/O before sort even begins. External SORT on full-width records moves more bytes than SEQUENCE on trimmed spool fields, but one full-file sort may still beat three SEQUENCE passes sorting overlapping key sets on the same run.

Cost Drivers Ranked for Beginners

One SORT Versus Multiple SEQUENCE

Consider a program with three reports: summary by region, detail by branch, and exception list by employee. If each REPORT declares SEQUENCE (REGION, BRANCH) on the same keys, Easytrieve may sort three spool files independently. If JOB already needs region-branch order for FIRST-DUP logic, a single SORT PERSNL TO SORTWRK USING (REGION, BRANCH) before JOB lets all three PRINT statements read ordered input—SEQUENCE may be omitted when print order matches file order. Exception report needing employee name as minor key might still need SEQUENCE (REGION, BRANCH, EMP-NAME) while others use sorted input only—a deliberate second sort with narrower spool. Document the choice in source comments so future maintainers do not add a fourth SEQUENCE blindly.

1
2
3
4
5
6
7
8
9
10
* Performance-friendly chain:
SORT PERSNL TO SORTWRK USING (REGION, BRANCH) SIZE 1200000
 
JOB INPUT SORTWRK NAME NIGHTLY
  PRINT RPT-SUMMARY
  PRINT RPT-DETAIL
  PRINT RPT-EXCEPTION
 
REPORT RPT-EXCEPTION SEQUENCE (REGION, BRANCH, EMP-NAME)
  * Only this report needs extra minor key on spool

SIZE and WORK Parameters

SIZE tells the sort utility how many records to plan for when Easytrieve cannot infer count from a prior activity output. Use production peak counts plus growth margin—not last Tuesday's small test file. SIZE too low risks sort failure or degraded multi-pass behavior; SIZE too high wastes virtual storage and work space reservations. WORK names an alternate work file for sort intermediate data when site standards require separating sort scratch from VIRTUAL TO output. Coordinate WORK DD with operations; developers name the FILE; JCL binds physical volumes.

BEFORE SELECT as Volume Reduction

1
2
3
4
5
6
7
8
SORT PERSNL TO SORTWRK USING (DEPT, EMP-NAME) BEFORE ACTIVE-ONLY
 
ACTIVE-ONLY. PROC
  IF STATUS NE 'A'
     EXIT
  END-IF
  SELECT
END-PROC

If thirty percent of rows are inactive status, prescreening removes them before compare operations—roughly thirty percent fewer sort records. Combine business filters in BEFORE rather than SORT then JOB DELETE patterns that still paid sort cost for dropped rows. Keep procedures tight: complex BEFORE logic on every row can rival sort savings if it triggers expensive field conversions per record.

JCL Pre-Sort Versus In-Program SORT

VIRTUAL MEMORY Versus DISK for Work Files

FILE SORTWRK VIRTUAL MEMORY favors keeping intermediate activity data in memory until policy forces spill. Medium nightly extracts often see better elapsed time than cataloged scratch data sets with heavy allocation. Million-row sorts exceed memory and spill regardless— plan DISK or installation SORTWK space. RETAIN on VIRTUAL extends lifetime across activities; forgotten RETAIN work files hold memory until job end—performance and region pressure continue after you no longer need the file.

Key Design for Cheaper Compares

• Use numeric keys when department codes are numeric—compare cost and clarity beat padded alphanumeric when definitions allow.
• Avoid sorting on long text fields when a short code exists—sort DEPT not DEPT-NAME when DEPT is the break key.
• Add tie-breaker keys only when business requires deterministic order among equals.
• Align CONTROL and USING/SEQUENCE keys so you do not sort twice for break detection fixes.
• Reject varying-length keys at compile time rather than runtime surprises.

Measurement and Regression Habits

1. Capture SMF or step-level CPU before and after removing an in-program SORT.
2. Compare elapsed time: JCL DFSORT step plus Easytrieve versus combined SORT activity.
3. Log record counts at extract creation; reconcile with SIZE yearly.
4. When adding a REPORT with SEQUENCE, ask whether existing SORT already supplies order.
5. Review duplicate SEQUENCE keys across REPORT blocks during code review.

Performance Anti-Patterns

Explain It Like I'm Five

Sorting is like organizing a huge pile of trading cards. The bigger the pile, the longer it takes. If you remove cards you do not want before organizing, the pile shrinks and you finish faster—that is BEFORE SELECT. If three friends each reorganize the same pile their own way, you do triple work—that is three SEQUENCE on the same keys. If one friend organizes the pile once and everyone shares the neat stack—that is one SORT. If the pile is so big it does not fit on the table, you need extra side tables—that is SORTWK work space. Smart kids measure how long sorting took last time before adding another sort just because a new game wants cards in a slightly different order.

Exercises

1. Given 2M rows and three SEQUENCE (REGION, BRANCH), estimate relative CPU versus one SORT.
2. Write BEFORE that drops two status codes and calculate sort savings at forty percent volume.
3. Draft a memo recommending JCL DFSORT for a shared payroll extract—three bullet points.
4. List five SIZE update triggers for operations calendar.
5. Refactor a design: remove redundant SEQUENCE when SORT already orders input.
6. Identify widest key in a sample FILE define and propose a shorter alternative.