Welcome to the forums! You should probably be able to achieve this with whichever sort product is available at your site (DFSORT, Syncsort,..).
Search the DFSORT forum here for examples on how to "remove duplicate"s or creating "trailer count"s.
Try something and get back if you face any issues. Someone would be here to help. Good luck!
Also make sure you include all the relevant information, RECFM, LRECL, field positions of your actual data, sort order of the input data (if any), sort order of the output (if it matters). Post code/sample data using "Code" tags.
Even accepting the 4.4 comparison for C'COUNT' as a typo, you don't want to use HEADER and COUNT, for your tests, as there is absolutely nothing to stop these giving you a "false hit" if they happen to occur in at that position in a name.
There are clearly indicators for the header and trailer which give no possibility of a false hit. There is also, clearly, a "reference number" which should be used for the sort/deduplication, even if that is not sufficient (no indication) there is no reason to includ the "05" or the blank following it or only a selected part of the name field.
WHEN=GROUP with BEGIN for "01", END for "99". Sort field after the ID to contain X'00' for header, X'FF' for trailer.
To suggest using COUNT, you can't chop off the extension in OUTREC.
A sequence, with RESTART for the ID extension and an IFTHEN=(WHEN=(logcicalespression) on OUTREC would allow a JFY with SHIFT=LEFT for the format of count shown.
Yes, Arun, that looks good. I got confused with the END because the trailer was being treated as a separate group by Rohit :-)
I'd rearrange the order of the IFTHENs, so that the data-one is treated first, it'll avoid a lot of tests for when the header/trailer when most of the records will be data. Multiple IFTHEN=(WHEN=(logicalexpression) are like an EVALUATE in COBOL, so cease the processing of that construct as soon as there is a "hit". That behaviour can be modified, when needed (for two entirely independent operations on the same record) by using HIT=NEXT.
Arun's code drops duplicates and produces correct counts. Even if you've already dropped the duplicates without telling us (wasting time) the code will still work even if there are no duplicates to drop. Note: I've not tested it either, but it looks good.
I'd rearrange the order of the IFTHENs, so that the data-one is treated first, it'll avoid a lot of tests for when the header/trailer when most of the records will be data
I thought about this while posting to OVERLAY the 'key' in the INIT for all the records since we have more detail records and then to check for header and trailer in the subsequent IFTHENs, but was too lazy especially when I cant test anything now (and for the next 2 weeks ).
Or even better as you pointed out, is to make it 3 mutually exclusive IFTHEN conditions in the order of data>>header>>trailer to avoid 'rework' on header and trailer records.