BillMeany wrote:The suggestion to use the INREC statement to check the date is valid. If I understand the way DFSORT processes data, the INCLUDE processing phase occurs before the INREC phase. If I use the INREC statement to detect the bad dates, then I would need to pass the output from the INREC to another pass with the INCLUDE. Certainly a doable approach, but I pay the cost of another pass through the data. Was hoping for a neat trick to catch the bad dates in the INCLUDE processing.
I appreciate the information.
NOT really. You don't need another pass to eliminate the bad date records . You can use an INCLUDE on OUTFIL and filter the records. It also gives you an option to write all the bad date records into another file.
try this job
//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
2010000 - INVALID DAY OF YEAR
0000021 - INVALID YEAR
2009366 - INVALID DAY OF YEAR FOR NON LEAP
2008366 - VALID DAY OF YEAR FOR LEAP YEAR
2010060 - MARCH 1ST FOR NON LEAP YEAR
2008060 - FEB 29TH FOR NON LEAP YEAR
//GOOD DD SYSOUT=*
//BAD DD SYSOUT=*
//SYSIN DD *