premise ... I an not a sort expert, but usually when You are able to get a result using <less> statements it might give some advantages
no reason to use more statements than needed
why not simplify the compare logic...
You are in an IF THEN / ELSE situation
if You check for HDR and TRL for equality, no reason to check also for inequality
checked with a simpler record/key setup, but the results are just the same
maddukurivasu, this looks like a good start from enrico. Any comment from you? Any answer to my earlier request?
The above still has 19:19,696 - a 696-byte move of data which is already there, as far as I can tell (and without any help from you). If you feel you have to do the build just to drop off the last two bytes of the record (don't know, because you haven't said), you could try this in place of the build.
That hasn't dealt with the record-length. So start with
If that is good for you, you will have removed two 700 byte moves per 5,000,000 records. That should be noticeable.
If you feel it still "too slow" have a look at your datasets: blocking; buffers; file types. Also consult your sort manual (we are assuming Syncsort from where you have posted) and look for information on performance/tuning and see if that covers anything you are doing.
So, this is good. Even if we cut the OUTREC processing by 90%, we won't notice :-)
I suspect a COPY would give very similar results, as you've probably not generated any "random" values for the keys, but it certainly serves our purpose. The OUTREC is not the problem, good spot Don and Gerry.
We need the JCL and the output messages. Also interesting to know how that 15-digit key is made up. Is it several things? If so, how many, and how much do the values vary?