Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If you have to go to two steps, and then a third step to give you a single sorted output files, I'd put my money on the ICETOOL approach being quite a bit more effective.
You might be able to do the OUTREC processing on one step, if the records are identifiable to the particular input dataset, but I don't know if you can select the sort key to be different, so your output will not be the same.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
The two sorts that you are doing are different. They are the same up to a point, then with the second file the list of key fields is longer. You are also sorting on PD vs CH. If you do either both on CH or both on PD you will get different order for your output. I can't tell you whether that difference is significant.
If you could use the same sort key for both datasets (remembering they are concatenated) and you can identify which dataset the current record is from then you would be able to do it in a single sort step.
I guess you have to try it and look at the output.
I still don't get the performance angle that you are looking at. If you do the above so you can see whether it works for your data, and then post answer plus volumes, I'm sure you can get some very professional answers to explain the timings, but it would help to know the reason you want to make the change.
prasun dhara,
In your CTL1CNTL you are using BUILD to create output record of 189 bytes but then you are forcing LRECL to be 186... You need to change this so that output record is 186 bytes and is in sync with your JCL or probably don't use LRECL in JCL and let DFSort decide LRECL based on your sort card.
Regardless, you are using 154X'41', did you mean 154X'40'?
Code:
OUTREC BUILD=(3,8,25,4,11,23,154X'41')
Also for the 2 control cards, first you show 25 through 4 bytes as being sorted as CH and in the second card the same is sorted as being PD but then you select this field in the same output file. This doesn't seem correct.
From the performance point of view, please provide LRECL for both the input files. If LRECL is same for both the files, do they both use the same layout?
I have just tested and comapred the CPU time for 2 step DFSORT and 1 step ICETOOL method for our Test input file and found ICETOOL step is taking 6% less CPU.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Quote:
I have just tested and comapred the CPU time for 2 step DFSORT and 1 step ICETOOL method for our Test input file and found ICETOOL step is taking 6% less CPU.
Another totally meaningless statement made by someone who does not understand what they are attempting to do. When you say "CPU time" -- do you mean TCB time? SRB time? combined TCB and SRB time? Did you look at the SMF data to get actual CPU usage, or are you using the numbers provided on the job listing? How much time are you talking about, any way? 6% of 1000 CPU seconds would be very different than 6% of 1 CPU seconds! From a system performance standpiont, you'd want to look at EXCP counts as well -- dropping CPU usage by 6% but having EXCP go up 600% might not work well in a site that is using a lot of channel capacity already.
This percentage is calculated based on the "Total CPU time" displayed in the Job listing/Job log.
Entire job listing is not possible to post here.So, please let me know what are the values I should post so that performance issues can be discussed clearly.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Entire job listing is not possible to post here
Well, then how about sending it to me offline (yaeger@us.ibm.com)?
Quote:
So, please let me know what are the values I should post so that performance issues can be discussed clearly
Well, you can start by posting the SOURCE for your jobs (that is, complete JCL) as well as information about the files used (RECFM, LRECL, BLKSIZE, DSORG, number of records). That way, we can recreate what you did and see if it holds up.
