When a DFSORT step fails or behaves unexpectedly, you need to know exactly what control statements were read and how they were parsed. Tracing control statements means using ICE000I (which echoes SYSIN) and optionally the DEBUG statement to see the parsed or internal form. This page covers how DFSORT reads SYSIN, the column rules that affect parsing (including continuation in column 72), how to use ICE000I and DEBUG to trace what was used, and common parsing errors and how to fix them.
DFSORT reads the SYSIN dataset (or in-stream data) once at the start of the step. It treats each line as a fixed-format record: specific columns have specific meanings. Content that is part of a control statement must appear in the allowed area (typically columns 8–71 for the main content). A non-blank character in column 72 means "this statement continues on the next line"; the next line is then appended logically to the current one before parsing. So the parser sees a stream of logical lines, each of which may have been built from one or more physical lines. Understanding these rules is essential when you trace: if something is in the wrong column, the parser may treat it as a new statement, truncate a keyword, or signal "TEXT BEGINS IN WRONG COLUMN."
Different DFSORT products and JCL conventions use slightly different column layouts; the following is a common one. Columns 1–6 are often used for sequence numbers (and may be ignored by the sort). Column 7 is sometimes used as an indicator (e.g. for continuation in some systems). The main content of a statement goes in columns 8–71. Column 72 is the continuation column: if any character there is non-blank, the next physical line is treated as part of the same statement. So when you write a long SORT FIELDS= or OUTFIL BUILD=, you break the line before column 72 and put a character (e.g. a comma or X) in column 72 of the first line; the next line should then start in the proper area (e.g. column 16 or as required) so the parser recognizes it as continuation and not a new statement.
| Columns | Use |
|---|---|
| 1–6 | Sequence number (optional); often left blank |
| 7 | Indicator (e.g. continuation; often blank for new statement) |
| 8–71 | Statement content; keywords and operands go here |
| 72 | Continuation: non-blank here means next line continues this statement |
The first message DFSORT prints is ICE000I. It includes the product and version and, importantly, the control statements as read from SYSIN. So the lines that appear after the header in ICE000I are exactly what the parser read—including any continuations as they were assembled. When you trace, open SYSOUT (or MSGDDN), find ICE000I, and compare those lines to the SYSIN you intended. If you used a PROC, the echoed lines are what the PROC (and any overrides) produced. If you concatenated datasets to SYSIN, the echo shows the combined content. So ICE000I answers: "What did this step actually use?" If the echo matches your expectations and the step still fails, the problem may be in the data or in a later phase; if the echo does not match, fix the SYSIN source or the PROC.
ICE000I shows the raw lines; it does not show the internal parsed form (e.g. how SORT FIELDS was expanded into key positions and formats). When you need that level of detail, add the DEBUG control statement to SYSIN. DEBUG tells DFSORT to produce additional diagnostic output. The exact format and content depend on your product and version: you may see parsed control statements, field lists, or record counts at various stages. Run the job and look at the same SYSOUT (or MSGDDN) for the extra lines. Use DEBUG only while diagnosing; remove it for production to avoid extra output and overhead. The DEBUG statement tutorial has more on syntax and options.
ICE001A "TEXT BEGINS IN WRONG COLUMN" is one of the most common. It usually means the parser saw text where it did not expect it. Typical causes: (1) A continuation line that did not have a non-blank in column 72 on the previous line, so the next line was treated as a new statement and its first character was in the "wrong" column. (2) A new statement that started past the allowed start column (e.g. past column 16). (3) Leading spaces or tabs that pushed keyword text into an invalid column. Fix by ensuring continuation is in column 72 and that each new statement starts in the correct columns; use the ICE000I echo to see exactly what was read. Another common error is an invalid or misspelled keyword (e.g. SORT FEILDS= instead of SORT FIELDS=); the message may be something like "INVALID KEYWORD" and the echoed line in ICE000I will show the typo.
To continue a long statement, end the first line with a non-blank in column 72 (e.g. a comma or the letter C). The next line should start in the continuation area (e.g. column 16). Wrong: putting the continuation character in column 71 or 73, or starting the next line in column 1 with a keyword—the parser may treat it as a new statement and fail.
12SORT FIELDS=(1,20,CH,A,21,8,PD,D),EQUALS X OPTION COPY
Here, the X in column 72 (approximate) marks continuation; the next line continues the SORT FIELDS. If the X were in column 71, the parser might not recognize continuation and could issue ICE001A or misinterpret OPTION COPY.
After a failure, verify in this order: (1) Open the step SYSOUT and find ICE000I. (2) Compare the echoed statements to your SYSIN (or PROC output). (3) If they match and you still need more detail, add DEBUG and re-run; then look at the DEBUG output for parsed form or field interpretation. (4) If they do not match, fix the SYSIN source (dataset, PROC, or in-stream data) so that the correct statements are supplied. (5) Pay special attention to any line that shows a truncated keyword or an unexpected keyword—that often indicates a continuation or column error. Once the echoed statements are correct and the step still fails, the cause is likely in the data (e.g. wrong format or position) or in the logic (e.g. wrong key); use the debugging techniques and SYSOUT analysis tutorials to narrow it down.
The sort program reads your instructions from a piece of paper (SYSIN). It has a rule: if there's a mark in a special box at the end of a line (column 72), the next line is still part of the same instruction. When it starts, it says "here are the instructions I read"—that's ICE000I. So you can check: did it read the right instructions? If you need to see exactly how it understood each line, you turn on DEBUG and it prints more details. If it says "something is in the wrong box," you fix the line so the mark is in the right box (column 72) or so the next line starts in the right place.
1. What does ICE000I show about control statements?
2. Where must a continuation character go for a continued control statement?
3. How does DEBUG help with tracing control statements?
4. You get ICE001A "TEXT BEGINS IN WRONG COLUMN." What should you check?
5. Why trace control statements when the step fails?