Date conversion in DFSORT means changing a date field from one format to another—for example from MMDDYYYY to YYYYMMDD, or from Julian (YYYYDDD) to Gregorian (YYYYMMDD). You do this in INREC or OUTREC using format codes (Y2T, Y4T, Y2W, Y4W) and conversion operators (TOGREG, TOJUL). Converting in INREC is important when you need to sort by the converted date or filter on it with INCLUDE/OMIT, because INREC runs before the sort. For report headers you can also use DATE= to insert the current (run) date without converting an input field. This page gives an overview of when and where to convert dates, why YYYYMMDD is useful for sorting, and how date conversion fits with the rest of the Date & Time section (Julian dates, Gregorian formats, date arithmetic). For the full INREC/OUTREC conversion syntax and examples, see Date conversions (INREC); for run date in headers, see Headers/trailers (reports).
Mainframe data often stores dates in many different forms: YYYYMMDD (8 bytes), MMDDYYYY, DDMMYYYY, YYYYDDD (Julian), or YYMMDD with a 2-digit year. To sort by date or to filter (e.g. "records from 2023 onward"), you need a consistent format—and ideally one where character order matches date order. YYYYMMDD has that property: when you sort the field as character ascending, earlier dates come first. Formats like MMDDYYYY do not: "12311999" sorts after "01012000" even though December 31, 1999 is before January 1, 2000. So a common goal of date conversion is to produce a YYYYMMDD (or ccyymmdd) field that you can then use in SORT FIELDS= or INCLUDE/OMIT. Another goal is to display dates in a report in a readable form (e.g. with slashes or hyphens), which you might do in OUTREC or in a header with DATE=.
INREC runs before the sort and before INCLUDE/OMIT. So any field you build or convert in INREC is part of the record that the sort and filter see. Use INREC when:
OUTREC runs after the sort. The sort and INCLUDE/OMIT have already run on the original (or INREC-built) record. Use OUTREC when you only need the converted date in the final output—for example, to display a date in a different format in a report—and you do not need to sort or filter by it. The same conversion syntax (format codes and TOGREG/TOJUL) works in both INREC and OUTREC; the difference is timing and whether the sort/filter see the new value.
Gregorian format is the usual calendar date: year, month, day (e.g. YYYYMMDD or MMDDYYYY). Julian format is year plus day-of-year: DDD is 001–366 (e.g. 2024366 for the last day of 2024). DFSORT can convert between them: TOGREG=Y4T produces Gregorian with 4-digit year first (e.g. ccyymmdd); TOJUL=Y4T produces Julian (ccyyddd). You specify the source format (Y2T, Y4W, etc.) so the input bytes are interpreted correctly, then the conversion operator produces the target format. For more on Julian dates and formats, see Julian dates and Gregorian formats.
The source format tells DFSORT how the input date is arranged:
| Code | Meaning |
|---|---|
| Y2T | 2-digit year first (e.g. yymmdd, yyddd). |
| Y2W | 2-digit year last (e.g. mmddyy, dddyy). |
| Y4T | 4-digit year first (e.g. ccyymmdd, ccyyddd). |
| Y4W | 4-digit year last (e.g. mmddccyy, dddccyy). |
Use the code that matches your data. Then add TOGREG=Y4T (or similar) to convert to Gregorian, or TOJUL=Y4T for Julian. Full syntax and examples are in Date conversions (INREC).
For report output you often want the run date (the date the job ran) in the header, not a date from the data. In HEADER1= or HEADER2= you use the DATE= keyword with a format. Example (syntax is product-dependent):
1HEADER1=(1:'SALES REPORT', 25:'Run date: ',DATE=(MD4-), 50:'Time: ',TIME)
DATE= inserts the current date in the format you specify (e.g. MD4 for MM/DD/YYYY, MD4- for MM-DD-YYYY, Y4T for YYYYMMDD). This is not conversion of an input field—it is the system date at run time. See your DFSORT manual for supported date and time formats in headers and trailers.
When you convert a date to YYYYMMDD (ccyymmdd) and place it at a fixed position (e.g. 1–8 after INREC), sorting that field as CH,A (character ascending) gives chronological order. That is because the string "20230101" is less than "20231231", and "20221231" is less than "20230101". So one practical pattern is: convert all dates to YYYYMMDD in INREC, put that field at the start (or another known position), then SORT FIELDS=(1,8,CH,A) and optionally INCLUDE/OMIT on that field. No need for a numeric date sort key—character sort on YYYYMMDD is correct.
When the source uses a 2-digit year (Y2T or Y2W), DFSORT uses a century window to interpret yy (e.g. 40–99 → 1940–1999, 00–39 → 2000–2039). So 25 might become 2025 and 99 might become 1999. If your data has years outside that window, the converted date can have the wrong century. Prefer 4-digit year source (Y4T, Y4W) when the data has it; otherwise check your product for century-window options. See Date conversions (INREC) and Century windowing for details.
Imagine dates written two ways: "12-25-2024" (month-day-year) and "2024-12-25" (year-month-day). If we sort the first kind by the written order, December 25 would not sort next to other December dates—we would have to look at the month and year in a tricky way. If we change every date to year-month-day first, then when we sort the lines, the oldest dates come first and the newest last. Date conversion is changing the date into that "year first" form (or another form we want). We do it before sorting (in INREC) so the sort sees the nice form and can order everything correctly.
1. When should you convert a date in INREC rather than OUTREC?
2. What is the main advantage of YYYYMMDD (or ccyymmdd) for sorting?
3. Where do you get the current date (run date) in a DFSORT report header?
4. What is the difference between Gregorian and Julian date formats in DFSORT?
5. Why might 2-digit year formats (Y2T, Y2W) be risky?