Input record File1
C~S~NN~YYYY~ZZZZZ
where I need select 4 columns
(3,1 -5,2 -8,4 -13,5)
Because in input record file 2 has 12 columns that too it is a KSDS key
SNNYYYYZZZZZ =>
Code:
ICE143I 0 BLOCKSET COPY TECHNIQUE SELECTED
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
ICE000I 1 - CONTROL STATEMENTS FOR
11:12 ON TUE NOV
* CONTROL STATEMENTS FOR JOINKEYS APPLICATION
JOINKEYS FILE=F1,FIELDS=(3,1,A,5,2,A,8,4,A,13,5,A)
JOINKEYS FILE=F2,FIELDS=(1,12,A),TYPE=V
JOIN UNPAIRED,F1,ONLY
REFORMAT FIELDS=(F1:1,1354)
* CONTROL STATEMENTS FOR MAIN TASK (JOINED RECORDS)
SORT FIELDS=COPY
ICE405A 0 JOINKEYS STATEMENTS HAD MISMATCH IN NUMBER, LENGTH OR ORDER OF KEYS
ICE751I 0 C5-K51706 C6-K51706 C7-K51706 E7-K51706
ICE052I 3 END OF DFSORT
Code:
//SYSIN DD *
* CONTROL STATEMENTS FOR JOINKEYS APPLICATION
JOINKEYS FILE=F1,FIELDS=(3,1,A,5,2,A,8,4,A,13,5,A)
JOINKEYS FILE=F2,FIELDS=(1,12,A),TYPE=V
JOIN UNPAIRED,F1,ONLY
REFORMAT FIELDS=(F1:1,1354)
* CONTROL STATEMENTS FOR MAIN TASK (JOINED RECORDS)
SORT FIELDS=COPY
//JNF2CNTL DD *
OMIT COND=(450,1,CH,EQ,C'N')
/*
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
magesh23586 wrote:
Thanks, I got the error, But Please advice how to compare a delimited record with normal record.
i.e
C~S~NN~YYYY~ZZZZZ File 1
SNNYYYYZZZZZ File 2
Think about it, Magesh-kun. The key fields in file 1 are (3,1,5,2,8,4,13,5), yes? So assuming that the characters correspond between files 1 and 2, the join keys (which need not actually have anything to do with the VSAM key) are (1,1,2,2,4,4,8,5), yes? Same number of keys, each with the same length.
Wow, Its worked out... thanks Kolusu and dick scherrer.
Code:
//SYSIN DD *
* CONTROL STATEMENTS FOR JOINKEYS APPLICATION
JOINKEYS FILE=F1,FIELDS=(3,1,A,5,2,A,8,4,A,13,5,A)
JOINKEYS FILE=F2,FIELDS=(1,1,A,2,2,A,4,4,A,8,5,A),TYPE=V
JOIN UNPAIRED,F1,ONLY
REFORMAT FIELDS=(F1:1,1354)
* CONTROL STATEMENTS FOR MAIN TASK (JOINED RECORDS)
SORT FIELDS=COPY
//JNF2CNTL DD *
OMIT COND=(450,1,CH,EQ,C'N')
/*
But please advice on performance, Is there any way to provide or tell DFSort , "this a vsam key which I am trying to fetch". I mean like in File aid we use "Key next" to find a key record in vsam.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Please explain why you find the performance unsatisfactory. Recall that not including the SORTED keyword on the JOINKEYS statements informs DFSORT that the records are not physically ordered by join key.
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
When the inclusion of this job causes the elapsed time of your nightly processing to threatened to overflow the batch window, and every less efficient job has been optimized, then it will be time to look at this one. Recall that half a day ago, it was not running at all, and therefore was taking an infinite amount of time to find and process those records.
The mindless drive for "performance" (probably driven by greedy thugs of bosses wanting every rupee that passes through their hands to stick there) is one of the most puzzling and unlovely things about outsourcing
The requirement was cobol... I suggested dfsort to my boss and he told to client, dfsort is more efficient...:(clients are all 20 to 25 exp in mainframes...and they are all cobol fans...they can easily measure it and may challenge cobol is efficent
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Well, we're at an impasse here. If we worked in the same shop, I could knock out a program in an hour or so that, whilst not up to production standards, was good enough for "happy path" performance comparisons, but I don't have your data and you -- without insult -- don't have my ability and experience as a programmer.
If you're seriously sweating over performance, the only thing I can think of would be to do a straight unload of the VSAM data set, and then use that unload in the JOINKEYS step, but with less than 2,500 records, I think the overload of an extra step will swallow any performance gain in the second step. The DFSORT performance maven -- I forgot his name, he's only posted a couple-three times on this board -- might be called in, but it again wouldn't surprise me if he said that this was too small a process with which to bother.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
Compared to random read in Cobol...
I suspect the sort process will outperform the COBOL process. If you want to verify, make sure the comparison runs are high volume rather than low volume.
2400+ is Not very many records.
If it looks like the COBOL process performs as well, there should be an identifiable reason.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Akatsukami wrote:
The DFSORT performance maven -- I forgot his name, he's only posted a couple-three times on this board -- might be called in, but it again wouldn't surprise me if he said that this was too small a process with which to bother.
Dave Betten is DFSORT performance expert, however there is not much he can do in this case as it is an issue of bad programming.
The COBOL program is reading a Keyed Sequential Data Set and the keys are already in the SORTED order, however the sample Joinkyes Job OP has shown is SORTING the ENTIRE KSDS file once again on the key which is a huge waste or resource and CPU time.
People demand fully optimized solutions and they don't seem to put in minimum effort to read upon the JOINKEYS documentation and on top if it they think that their time is much more valuable than our time.
magesh23586 wrote:
The requirement was cobol... I suggested dfsort to my boss and he told to client, dfsort is more efficient...:(clients are all 20 to 25 exp in mainframes...and they are all cobol fans...they can easily measure it and may challenge cobol is efficent
I applaud your audacity to challenge your seniors when you are still a newbie in DFSORT. *Sigh* Read up the documentation of Joinkeys and pay attention to the keyword SORTED and understand what it does.
Added following things into the code, which has come up with significance performance improvement.
1. FILSZ specified
2. SORTED, NOSEQCK ==> I think sorted is sufficient, if we mention sorted alone, do the dfsort will perform a sequence check ?
3. AVGLEN specified.
Here is the updated code.
Code:
* CONTROL STATEMENTS FOR JOINKEYS APPLICATION
JOINKEYS FILE=F1,FIELDS=(3,1,A,5,2,A,8,4,A,13,5,A)
JOINKEYS FILE=F2,FIELDS=(1,1,A,2,2,A,4,4,A,8,5,A),SORTED,
TYPE=V,NOSEQCK
JOIN UNPAIRED,F1,ONLY
REFORMAT FIELDS=(F1:1,1354)
* CONTROL STATEMENTS FOR MAIN TASK (JOINED RECORDS)
SORT FIELDS=COPY
//JNF2CNTL DD *
OMIT COND=(450,1,CH,EQ,C'N')
OPTION DYNALLOC(,16),FILSZ=E5000000,AVGRLEN=450
/*
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.