Please provide me the sort card for my below mentioned query.
The input file as following fields :
1. Provider ID, 9 bytes, alpha numeric
2. Province, 4 bytes, alpha numeric
3. License number , 9 bytes, numeric
4. Type code, 1 byte, alpha numeric.
This is a VB file.
Introduce a SORT step in the JCL which will format the input file so that the out has only the following fields
1. Provider ID, 9 bytes, alpha numeric
2. Province, 4 bytes, alpha numeric
The output is a FB file and ensure that it only has records where province is populated.
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.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
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 ...
Frank,
The previous thread I was referring to was:
Clarification on Sort Performance, and specifically the post I made on Thu Aug 19, 2010 at 8:46 am, in which I said (emphasis mine):
Ronald Burr wrote:
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.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
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.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Anuj,
The thread you referenced was about contiguous SORT fields, whereas Ronald was asking about contiguous INREC fields. So I deleted your post and addressed the question asked.
