Sorting in Easytrieve is not one single mechanism. Operations teams talk about internal sort when ordering happens inside the report generator's own processing cycle—without standing up a separate JCL sort step or declaring a full-file SORT activity that hands records to DFSORT through prescreen exits. The flagship internal pattern is REPORT SEQUENCE: after PRINT spools detail lines to a temporary work file, Easytrieve sorts only the fields that report needs, then TITLE and LINE formatting read the sorted spool. On CICS and non-mainframe deployments, Broadcom documents a sort packaged with the product rather than your site's installation sort program—another internal path distinct from z/OS E15/E35 external sort. Beginners who treat every sort as SORT USING are surprised when a program with no SORT activity still produces ordered pages because SEQUENCE ran invisibly after PRINT. This page explains internal sort scope, spool work files, VIRTUAL declarations, how SEQUENCE keys relate to CONTROL breaks, packaged sort environments, limits compared with external SORT, and decision rules for when internal ordering is enough versus when you must sort the whole input file first.
| Term | Mechanism | Typical use |
|---|---|---|
| Internal sort | REPORT SEQUENCE; packaged Easytrieve sort on CICS/non-z/OS | One report needs print order; spool-only reorder |
| External sort | SORT activity on z/OS calling installation DFSORT/Syncsort via E15/E35 | Whole file reorder for JOB, writes, or multiple reports |
External sort is covered in the companion external sort tutorial. Internal sort does not mean in-memory quicksort written in PROC code—it means the product-owned report spool pipeline or bundled sort module handles ordering without you coding a separate SORT TO dataset activity for that purpose. Both paths consume CPU; internal sort often processes fewer bytes per record because spool layouts omit fields you never PRINT.
Declare SEQUENCE on the REPORT statement with the same key fields you would use in USING on a SORT line—region, branch, pay amount, and so on. Minor keys follow major keys left to right. Append D immediately after a key name for descending order on that key only; other keys remain ascending unless they also carry D. When JOB logic executes PRINT for that report, Easytrieve copies selected fields to an internal work file, invokes sort on those spool records, then drives page building from sorted output. CONTROL break headers align with SEQUENCE keys when you list the same fields on CONTROL—if you CONTROL REGION BRANCH but SEQUENCE only REGION, branch subtotals may fire at wrong boundaries.
1234REPORT RPT1 SEQUENCE (REGION, BRANCH D, EMP-NAME) CONTROL REGION BRANCH TITLE 'PAYROLL BY REGION AND BRANCH' LINE REGION BRANCH EMP-NAME GROSS-PAY
REGION sorts ascending, BRANCH descending within each region, EMP-NAME ascending within each branch group. No SORT activity appears in the program—ordering is internal to RPT1. JOB may still read input in arrival sequence while the printed report shows sorted detail. That split is valid when file order does not matter for GET logic but readability does matter on paper.
Internal sort depends on temporary sequential files Easytrieve allocates for spool and merge. You rarely name these explicitly for SEQUENCE—the product manages report work files. When you chain activities manually, FILE SORTWRK VIRTUAL COPY input-layout creates scratch space the Virtual File Manager holds in memory or on spill datasets until CLOSE or job end. VIRTUAL MEMORY favors smaller extracts; VIRTUAL DISK spills to work DDs when row counts exceed memory policy. RETAIN keeps a VIRTUAL file across activities in one execution pass so a second JOB can read intermediate results without rewriting JCL. Internal SEQUENCE work files are typically shorter than full input records because only PRINT-selected fields enter the spool.
Broadcom states z/OS batch invokes the installation sort program. CICS Easytrieve and non-mainframe editions use the sort packaged with the product. From your source code perspective SEQUENCE and SORT syntax look the same, but operations cannot tune DFSORT control cards for those internal invocations the way a standalone sort step allows. Capacity planning for online Easytrieve programs that SEQUENCE large extracts must account for region and sort work inside the transaction or batch region hosting the product—not a separate sort job step on the JES queue.
| Syntax | Effect | Compared to USING on SORT |
|---|---|---|
| KEY | Ascending order for that key | Same as USING without D |
| KEY D | Descending for that key only | Same D suffix rules as USING |
| (KEY1, KEY2) | Major-to-minor composite sort | Identical key ordering concept |
Field definitions must be fixed length for keys—varying length, K-type, or M-type fields are invalid sort keys and fail at compile time. OFFSET and length on FILE DEFINE must match the bytes SEQUENCE compares; a one-byte slip shifts department codes into wrong sort buckets.
When two or more reports need the same keys, or JOB must detect FIRST-DUP after ordering, external SORT once before JOB usually beats multiple internal SEQUENCE passes on identical keys—see sort performance tutorial for CPU comparisons.
12345678910JOB INPUT PERSNL NAME PAY-RUN PRINT RPT1 * * Internal path for RPT1 only: * PRINT -> spool work file -> SEQUENCE sort -> format TITLE/LINE * REPORT RPT1 SEQUENCE (DEPT, EMP-NAME) CONTROL DEPT TITLE 'EMPLOYEE LISTING BY DEPARTMENT' LINE DEPT EMP-NAME SALARY
PERSNL records are read in whatever order the extract arrived. Each PRINT adds spool rows. Before formatting, internal sort orders spool by DEPT then EMP-NAME. CONTROL DEPT prints department headers when DEPT changes on sorted spool. Without SEQUENCE, headers would appear whenever a new department happened to appear in random input—a classic beginner failure mode.
| Symptom | Likely fix |
|---|---|
| CONTROL fires every line | Add SEQUENCE on same keys as CONTROL |
| Report sorted, file not | Expected for SEQUENCE-only; add SORT if JOB needs order |
| Wrong descending groups | Place D immediately after the key that should descend |
| Compile error on SEQUENCE key | Remove varying-length or invalid key field types |
| Three reports, triple sort cost | One external SORT plus shared ordered input |
You are putting on a school play. The class list on the teacher's desk is in random order because kids signed up as they walked in. Internal sort is like sorting only the index cards of kids who are actually in the play, right before you read their names on stage—you do not reorder the whole class list in the office filing cabinet. You shuffle the small stack of performer cards alphabetically, then read from that stack. External sort would be the secretary reordering every student file in the cabinet before the play starts. If only the stage needs order, sorting the performer cards is enough. If the nurse and the librarian also need the whole school in alphabetical order, the secretary should sort the cabinet once instead of three people each sorting their own smaller stacks.
1. Which Easytrieve feature is the classic internal sort for one report?
2. On CICS or non-mainframe Easytrieve, the sort utility is typically:
3. SEQUENCE sorts which records?
4. Internal sort work files are often declared as:
5. When is internal SEQUENCE a better fit than external SORT?