In a COPY only operation there is no need to reformat the input record to reduce the amount of data being carried around in intermediate (e.g. SORTWKxx) files. Hence, in this case, not only is the use of INREC not MORE efficient, it is, in fact, LESS efficient, since it requires additional data manipulation.

But, If INREC processing WOULD have made it more efficient ( e.g. if a sort were required and the original input file had an LRECL of 600 ), then, since the three fields (1,4,5,9,14,4) are contiguous, it would have been more efficient to simply state

INREC BUILD=(1,17)

By coding the BUILD with just ONE (contiguous) field instead of three, the work of building the intermediate record would be reduced ( just one move per input record instead of three ).

Note: In a previous thread I asked if DFSORT was coded such that contiguous fields (of the same data type) were automatically consolidated during INREC/OUTREC processing and I was NOT told that it DID include such logic, so I am left to assume that it does NOT include such logic. As always, I welcome correction/enlightenment.

Note: In a previous thread I asked if DFSORT was coded such that contiguous fields (of the same data type) were automatically consolidated during INREC/OUTREC processing and I was NOT told that it DID include such logic, so I am left to assume that it does NOT include such logic. As always, I welcome correction/enlightenment.

I don't know which previous thread you're referring to or what was said about what, but ...

Except for the RDW which is treated specially, DFSORT will consolidate contiguous fields. 1,17 and 1,4,5,9,14,4 would be treated the same internally.

Note: The post you refer to was made well before I joined this site, BUT the fault remains mine for not SEARCHing to see if any post related to consolidation of fields had been made by anyone connected with DFSORT before my arrival here. A valuable lesson, for which I thank you.

I must add, however, that when I raised the same question earlier this month, there was no response either way. That's why I felt it necessary to post the caveat.

Note: In a previous thread I asked if DFSORT was coded such that contiguous fields (of the same data type) were automatically consolidated during INREC/OUTREC processing and I was NOT told that it DID include such logic, so I am left to assume that it does NOT include such logic. As always, I welcome correction/enlightenment.

I don't know which previous thread you're referring to or what was said about what, but ...

By combining fields ( i.e. coding 1,39 instead of 1,4,5,4,9,4,13,18,31,9 ) you will reduce the number of data moves required during the refomatting process ( unless the DFSORT developers put in code to test for, and consolidate same )

As I said, there was no response either confirming that DFSORT did perform consolidation or did not do so.

As I said, there was no response either confirming that DFSORT did perform consolidation or did not do so.

Quote:

so I am left to assume that it does NOT include such logic.

When somebody chooses NOT to confirm or deny something, it's not safe to assume the answer is one thing or another.

The complete answer is really more complicated than just "yes" or "no". It depends on the situation. There's lots of code in DFSORT for lots of different situations. The DFSORT code is proprietary and we do not discuss it for the most part. Please don't think that because the DFSORT developers here (Kolusu and myself) can't reveal everything, that you are necessarily correct in assumptions that we don't discuss.

When it comes to performance, it almost always "depends". And all one can give is general guidelines. There will usually be exceptions.

The best advice anyone can give about sort performance questions is try it yourself in your own environment and come to conclusions based on your own criteria.