When a DFSORT step runs, it writes messages to SYSOUT (or to the DD you specify with OPTION MSGDDN=). Knowing where to look and in what order messages appear makes it much easier to verify that the step used the right control statements and to find the cause of a failure. This page explains what SYSOUT is for a sort step, the typical message flow, how to locate the step output, how to find the first error message, and how completion and DEBUG output fit in.
In JCL, SYSOUT is the default output stream for a step—the place where the system and the program write the step listing and messages. For a DFSORT step, that same stream receives all ICE messages: the startup message (ICE000I), any parsing or option messages, record counts, completion statistics, and error messages. So when you look at the job output in the JES spool or your site's log viewer, you open the sort step's output; that output is (or includes) the step SYSOUT. The exact way you open it depends on your environment: some viewers show one dataset per DD, others combine step output into one listing. Either way, the DFSORT messages are in that step's output unless you redirected them with MSGDDN.
If you code OPTION MSGDDN=ddname in SYSIN, DFSORT sends its messages to the dataset (or SYSOUT) allocated to that DD name instead of the default. For example, OPTION MSGDDN=SORTMSG means you must have a DD statement in the same step with name SORTMSG (e.g. //SORTMSG DD SYSOUT=*, or //SORTMSG DD DSN=...). All ICE messages and any DEBUG output then go to that DD. Use this when you want messages in a separate file for audit, when you want to keep the main step SYSOUT small, or when your site routes different DDs to different output classes. When analyzing output, remember: if MSGDDN is used, the messages are not in the default step listing; they are in the dataset allocated to that DD.
Messages are written in the order they occur. So you typically see: (1) ICE000I at the very start, with the product identifier, version, date/time, and the control statements read from SYSIN; (2) any messages about option processing or control statement parsing; (3) messages during the run (e.g. records read, records written, or phase progress if the product prints them); (4) at the end, either a completion message (e.g. ICE201I or similar) with final statistics, or the first A-level (or E-level) error message if the step failed. Understanding this order helps you know where to look: top for "what was used," then scan for the first A or E for "why it failed."
| Phase | Example |
|---|---|
| Startup | ICE000I – product, version, control statements |
| Parsing/setup | Option or control-statement interpretation messages |
| Processing | Record counts, phase progress (if printed) |
| End | ICE201I or similar (statistics) or first A/E (error) |
In the JES spool, a job has multiple steps and each step can have multiple output datasets. The step listing is usually the primary SYSOUT for that step—often the one with a default output class (e.g. A). If your JCL does not explicitly assign SYSOUT to a DD, the step program's messages go to that default. When you open the job in SDSF, the job log, or your site's equivalent, locate the sort step (e.g. STEP1 or SORTSTEP). Open its output; the first or main listing there is where ICE000I and the rest of the DFSORT messages will be. If you used OPTION MSGDDN=xxx, open the output for the DD named xxx instead.
When the step completes with condition code 0, you still want to confirm that it did what you expected. Check ICE000I: do the echoed control statements match your SYSIN (or PROC)? Then look at the completion message (e.g. ICE201I): it usually reports how many records were read and how many were written. If you have INCLUDE/OMIT or OUTFIL with INCLUDE/OMIT, the written count may be less than the read count; that is normal. If you have multiple OUTFIL outputs, the completion message may break down counts per output. Verify that these numbers match your expectations (e.g. input file had 10,000 records, you expected 9,500 after OMIT, and the message says 9,500 written). If the numbers are off, the logic (filtering, keys, or data) may need investigation.
When the step fails (non-zero condition code or abend), open the same SYSOUT (or MSGDDN dataset). Read ICE000I first to confirm the control statements; sometimes the wrong SYSIN or a bad continuation is the cause. Then search for the first message whose ID ends with A or E (e.g. ICE001A, ICE046A). That message is usually the one that describes the failure: invalid keyword, field out of range, text in wrong column, sort capacity exceeded, or data exception. Read the message text; it often includes the keyword or value that caused the problem. Look up the message ID in the IBM DFSORT Messages, Codes and Diagnosis Guide (or your site's equivalent) for the official explanation, cause, and programmer response. If the step abended with a system code (e.g. S0C7), the last ICE messages before the dump may still point to the control statement or phase that led to the abend; use the debugging techniques tutorial to tie that together.
Completion or summary messages (the exact IDs depend on your DFSORT version) typically report: number of records read from the primary input (and from JOINKEYS inputs if applicable), number of records written to the primary output (SORTOUT) and to each OUTFIL if used, and sometimes elapsed or CPU time. Some products also print phase-by-phase counts or sizes. Use these numbers to validate that the step processed the expected volume and that filtering or multiple outputs behaved as intended. If you use STOPAFT or SKIPREC, the read count will reflect that; if you use INCLUDE/OMIT, the written count will reflect the filtered set.
When you add the DEBUG control statement, DFSORT produces additional diagnostic or trace lines. That output is written to the same destination as the other messages: default SYSOUT or the MSGDDN DD. So when you enable DEBUG, you will see more lines in the same listing—for example, parsed control statement details, record counts at intermediate stages, or sample record content. The exact format depends on your product and DEBUG options. When analyzing, treat DEBUG output as extra context between the normal messages; the first A or E message is still the primary indicator of failure. The tracing control statements tutorial goes deeper into using DEBUG and interpreting trace output.
The sort program writes a "diary" of what it did. That diary is in SYSOUT. First it says "here are the instructions I got" (ICE000I). Then it might say "I read this many cards and wrote that many." If something went wrong, it writes a line that says "ERROR" (the A or E message). So when you look at the diary, you look at the beginning to see the instructions, and you look for the first ERROR line to see what broke. If you told the program to write the diary in a different notebook (MSGDDN), you have to look in that notebook, not the usual one.
1. Where do DFSORT messages appear by default?
2. What is the typical order of messages in a DFSORT step SYSOUT?
3. You use OPTION MSGDDN=SORTMSG. Where do you look for DFSORT messages?
4. How do you quickly find why a DFSORT step failed when reading SYSOUT?
5. What do completion messages (e.g. ICE201I) typically tell you?