0 IDENTIFIER FROM CALLING PROGRAM IS 0001
0 JOBNAME: TTYAGMK1 , STEPNAME: STEP020
0 BLOCKSET TECHNIQUE IN CONTROL
0 BLOCKSET SORT TECHNIQUE SELECTED
0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
0 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 06:30 ON THU JA
E XSUM IS NOT SUPPORTED - USE ICETOOL SELECT IF APPROPRIATE
0 END OF STATEMENTS FROM CTL1CNTL - PARAMETER LIST STATEMENTS FOLLOW
C5-K62149 C6-K90026 C7-K58148 C8-K67572 E7-K70685
END OF DFSORT
I appreciate your enthusiasm to help but you need to understand the order of processing. You already have the data sorted on the key and hence your job worked even though you are using INREC to number the duplicates. Run your job with the following data and see how you get incorrect results.
You can do either do another pass to get the desired results or alternatively there is a trick to get the desired results in the same pass even if there is nothing to identify the header and trailer.
Please provide us the DCB properties of the input file. Do you have anything to identify the header and trailer? If there is then we just need to slightly modify hailashwin's solution. If not then I will show you the trick to get it done in 1 pass.
There is a "pre-sort" which is simply 0 for header, 5 for data, and 9 for trailer, then the actual sort on the key.
The "first" record is INCLUDED by using WHEN=GROUP, with KEYBEGIN and PUSHing a sequence number for the group.
A similar approach to ICETOOL's SELECT "works", as in my single test-run gives the same results, but since the manual specifies that the high-order sort key should be any and all ON values, in the order specified on the SELECT which can be followed by additional keys, I'd not rely on it working.