Key sequencing is the rule DFSORT uses to decide the order of records when you have multiple sort keys. The primary key (the first 4-tuple in SORT FIELDS) has the highest priority: when comparing two records, DFSORT first compares the primary key. If one record has a smaller (or larger, for descending) primary key value, that record is ordered first—the secondary key is not looked at. Only when the primary key values are equal does DFSORT use the secondary key to break the tie. If the secondary key is also equal, it uses the tertiary key, and so on. So the order of keys in the list is the order of priority: first key wins unless tied, then second key breaks the tie, then third, etc. When all keys are equal, OPTION EQUALS preserves input order (stable sort); otherwise the order between those records is undefined. This page explains this tie-breaking logic in detail.
When DFSORT compares two records, it looks at the first (primary) key. If the primary key of record A is less than the primary key of record B (for ascending), A is placed before B and the comparison stops. If the primary keys are equal, DFSORT looks at the second (secondary) key. If the secondary key of A is less than that of B, A comes first. If the secondary keys are also equal, it looks at the third (tertiary) key, and so on. So the keys are used in strict order: primary first, then secondary only when primary is tied, then tertiary only when both primary and secondary are tied. This is the same as sorting a spreadsheet by Column A, then Column B, then Column C.
The order in which you list keys in SORT FIELDS is the priority order. If you put department first and date second, you get all department 10 together, then department 20, and within department 10 the records are ordered by date. If you put date first and department second, you get chronological order first, and within the same date you get department order. So think about which grouping you want at the outer level (primary) and which at the inner level (secondary). The first key "groups" the data; the second key orders within each group; the third orders within groups that tie on the first two.
If two records are equal on all specified keys, DFSORT still has to put one before the other. With OPTION EQUALS, the sort is stable: the record that appeared first in the input stays first in the output. With NOEQUALS, the order between such records is not guaranteed (implementation-dependent). So if you need a defined order when all keys are equal (e.g. preserve input sequence), use OPTION EQUALS.
SORT FIELDS=(1,10,CH,A,11,8,CH,A,19,4,PD,D): primary bytes 1–10 character ascending (e.g. customer), secondary bytes 11–18 character ascending (e.g. date), tertiary bytes 19–22 packed descending (e.g. amount). So records are grouped by customer; within customer by date; within same customer and date by amount (highest first).
1SORT FIELDS=(1,10,CH,A,11,8,CH,A,19,4,PD,D)
Key sequencing is like lining up "first by color, then by size." We look at color first: all red together, then blue. If two people have the same color, we look at size to see who goes first. If they have the same color and same size, we might keep the order they were standing (EQUALS) or the teacher picks (NOEQUALS). So the first rule is the most important; the second rule is only for ties.
1. When comparing two records, when does DFSORT use the secondary key?
2. What is the order of key priority in SORT FIELDS=(pos1,len1,fmt1,dir1,pos2,len2,fmt2,dir2)?
3. If two records are equal on all specified keys, what determines their order?
4. Can the primary key be descending and the secondary ascending?
5. What is the "primary" key?