Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
magesh23586 wrote:
2. SORTED, NOSEQCK ==> I think sorted is sufficient, if we mention sorted alone, do the dfsort will perform a sequence check ?
DFSORT is not known for having statements merely for decorative purposes.
Your concern with performance will come down to the number of records on F1. If F1 is greater than 20% of the number of records on F2 I'd expect the JOINKEYS to be faster, generally. If F1 has one record, the process will be horribly slower.
The "tipping point" will be somewhere in between, and only you can identify that by running volume tests where the data is representative of what is expected in production.
DFSORT does no "keyed read" of a KSDS. With one record on F1, your entire KSDS will be read.
The DYNALLOC and FILSZ and AVGRLEN are ignored as you used SORTED keyword which makes Joinkeys read the VSAM file with a COPY operation. Remove them. I am not even sure as to why you need to read the VSAM Cluster as Variable when your key is always present and you don't need any other data. Read it TYPE=F and adjust the positions on the JOINKEYS accordingly. Since you don't need any data apart from the key, Just use INREC BUILD=(1,12) in JNFxCNTL which will only build the Key to match. Your INCLUDE condition gets executed before the INREC.
As Bill Mentioned always code for Positive condition rather than negative condition.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
For a comparison, why don't you use OPTION COPY/SORT FIELDS=COPY to copy your KSDS to a "flat" file. Then run your step with that flat file. As well as CPU, pay attention to the I-O counts, VSAM vs flat.
Remember, if the number of records you are processing is "small" in relation to the size of the KSDS, your client is not going to be impressed vs a programming language with a direct read.