DFSORT (IBM) and Syncsort (Syncsort, Inc. / Precisely) are both mainframe sort/merge utilities, but they are different products with different syntax for many control statements and options. Basic sort key specification is often similar, but once you use INREC, OUTREC, date conversion, OUTFIL reports, JOINKEYS, or product-specific options, the exact keywords and formats can differ. This page summarizes the main syntax differences so you know what to check when migrating a job from one product to the other: SORT/MERGE, INREC/OUTREC, SUM, OUTFIL, JOINKEYS, date conversion, and message IDs. Always use the target product manual for the final conversion and test with a small dataset.
DFSORT and Syncsort were developed separately. They both implement sort, merge, copy, and reformatting, but the choice of statement names, keyword spellings, and option formats was made independently. So while many concepts map (e.g. "reformat before sort" exists in both), the exact syntax does not. When you migrate a job, you must translate each control statement to the target product's form; blind copy-paste of SYSIN often leads to errors or different behavior.
| Area | DFSORT (typical) | Syncsort (typical) |
|---|---|---|
| SORT / MERGE FIELDS | Position, length, format, A/D; EQUALS, NOEQUALS | Similar basics; option names may differ |
| INREC / OUTREC | BUILD, FIELDS, FINDREP, IFTHEN | Equivalent REFORMAT/BUILD; IFTHEN syntax may differ |
| Date conversion | DATE1, JFY, century keywords | Different keyword and format names |
| OUTFIL report | HEADER1/2, TRAILER1/2/3, COUNT=, LINES= | Report options and syntax can differ |
| JOINKEYS / join | JOINKEYS F1/F2, REFORMAT, JOIN UNPAIRED | Join feature and syntax may differ |
| Messages | ICE* | WER* |
Both products use a SORT or MERGE statement with FIELDS= specifying position, length, format, and A (ascending) or D (descending). Format codes (CH, BI, PD, ZD, etc.) are often similar. Options such as EQUALS (preserve order of equal keys) or NOEQUALS may have the same or different names (e.g. STABLE in some products). Collating sequence and alternate sequence (ALTSEQ) syntax can differ. When migrating, list every option on the SORT or MERGE statement and look up each in the target manual.
DFSORT uses INREC (reformat before sort) and OUTREC (reformat after sort) with BUILD= or FIELDS=, FINDREP=, and IFTHEN for conditional building. Syncsort has equivalent reformatting capability but may use different statement names (e.g. REFORMAT in a different context) or different keyword order. FINDREP (find/replace) and IFTHEN (conditional overlay or build) often have different syntax or nesting rules. When converting, map each BUILD segment and each IFTHEN clause to the target product's equivalent; test with a few records to ensure field positions and logic match.
Date conversion is a common source of difference. DFSORT uses keywords like DATE1=, JFY (Julian), and format codes (e.g. MD4, Y2Y) and century windowing options. Syncsort has its own date conversion keywords and format names. The same input format (e.g. YYMMDD) and output format (e.g. YYYYMMDD) may be specified differently. Look up "date conversion" or "date format" in the target manual and rewrite the conversion specification; verify with known dates (e.g. 991231 → 19991231).
Both products support SUM (or equivalent) for removing duplicates and optionally summing numeric fields. The key and FIELDS= specification are often similar. Overflow handling (e.g. when a sum exceeds the output field) can differ: DFSORT has options like VLSHRT, NOVLSHRT; Syncsort may use different names or behavior. Check overflow and MIN/MAX/AVG options in the target manual.
OUTFIL in DFSORT supports multiple outputs, BUILD, INCLUDE/OMIT, SPLIT, and report options (HEADER1, HEADER2, TRAILER1, TRAILER2, TRAILER3, SECTIONS, LINES=, COUNT=). Syncsort has similar capabilities but the exact keywords and the format of HEADER/TRAILER (e.g. position:value, DATE=, TIME=, PAGE) can differ. Report layout conversion often requires line-by-line mapping of each header and trailer line and the COUNT or total syntax.
DFSORT uses JOINKEYS F1= and JOINKEYS F2= with REFORMAT and JOIN UNPAIRED. Syncsort may have a different name for the join feature (e.g. JOIN) and different syntax for specifying the two files, the key, and the reformat layout. UNPAIRED options (ONLY, F, F,F, etc.) may be spelled or coded differently. When migrating a file comparison or join job, find the join chapter in the target manual and rewrite the entire join control block.
DFSORT messages typically start with ICE (e.g. ICE000I for informational, ICE001A for abend). Syncsort messages typically start with WER. When a step fails, the message ID tells you which product ran so you look up the explanation in the correct manual. When migrating, keep in mind that the same logical error may produce a different message and code in the other product.
DFSORT and Syncsort are like two brands of the same kind of toy: both can sort and change data, but the buttons have different names and some buttons only exist on one brand. When you move from one to the other, you have to read the new box (the manual) to find which button does what, and you cannot assume the old instructions work word-for-word. You try it with a little bit of data first to make sure the result is the same.
1. Why can you not always copy DFSORT control cards to a Syncsort step unchanged?
2. How do message IDs help when migrating between DFSORT and Syncsort?
3. What should you do before migrating a DFSORT job to Syncsort (or vice versa)?
4. Are SORT FIELDS and MERGE FIELDS syntax usually the same between DFSORT and Syncsort?
5. Where do the biggest syntax differences usually appear?