|
|
| Author |
Message |
vijikesavan
Active User
Joined: 04 Oct 2006
Posts: 109
Location: NJ, USA
|
|
|
|
Hi,
I have a sort job which is using maximum CPU time and we are looking for tuning options. THe sort card is given below. Can someone explain me 1) What is the use of OPTIONSIZE,MODS etc...the portion highlighted in RED below
Is there is any way I can modify this sort card to have much better performance?
OPTION SIZE=E15000000,DSPSIZE=0,CINV,
NOEQUALS,NOVERIFY,NOWRKSEC,COBEXIT=COB2,
EFS=NONE,MAINSIZE=128M,DYNALLOC=(SYSDA,32)
SORT FIELDS=(11,9,A,27,7,A),FORMAT=CH
SUM FIELDS=(34,8,PD,42,8,PD,50,8,PD)
MODS E35=(NSM015B,1024,STEPLIB,C)
END
Pls help.
Thanks,
Viji |
|
| Back to top |
|
 |
References
|
 Posted: Wed Apr 04, 2007 11:29 pm Post subject: Re: What is the use of OPTIONSIZE,MODS in SORT CARD |
|
|
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4401
Location: San Jose, CA
|
|
|
|
If you're using DFSORT, you can look up all of the control statements and options yourself in "z/OS DFSORT Application Programming Guide" which you can access from:
www.ibm.com/servers/storage/support/software/sort/mvs/srtmpub.html
You're using a COBOL E35 exit that somebody in your site supplied. That could possibly be a CPU hog depending on what it's doing and how it's coded.
SIZE=E15000000 gives DFSORT an estimate of the number of records to be sorted. If DFSORT is accessing the input file directly, it can determine the number of input records and the estimate will be ignored. If DFSORT is not accessing the input file directly, and this value does not give a good estimate of the number of records, then it should be changed to give a good estimate. |
|
| Back to top |
|
|
vijikesavan
Active User
Joined: 04 Oct 2006
Posts: 109
Location: NJ, USA
|
|
|
|
Thanks for the reply Frank.
yes it exits to a cobol program. The cobol program just divides 2 amount fields by 100.
Not sure why they are doing this division in COBOL program.
The cobol pgm just checks for non-numeric and non-zero value before doing the division by 100. I feel I can replace that in DFSORT itself.
Please post me with your suggestions if you have any.
Thanks,
Viji |
|
| Back to top |
|
|
Alain Benveniste
Active User
Joined: 14 Feb 2005
Posts: 89
|
|
|
|
Dfsort is able to add, sub, mul, div or mod.
Alain |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4401
Location: San Jose, CA
|
|
|
|
| Quote: |
| The cobol pgm just checks for non-numeric and non-zero value before doing the division by 100. |
Depending on what exactly the COBOL E35 is checking for and computing, you can probably eliminate the COBOL E35 and do it directly with DFSORT instead. This may or may not reduce the CPU time. If you can explain what exactly the COBOL E35 is doing (i.e. What is the position, length and format of the two amount fields? What exactly is meant by "checks for non-numeric and non-zero value"?) then I can probably show you how to do it directly with DFSORT. That might be a good first step.
| Quote: |
| I have a sort job which is using maximum CPU time |
What exactly do you mean by this? What is the "maximum CPU time"?
| Quote: |
| We are looking for tuning options |
That would require an analysis of how the job is currently running. Are you using DFSORT (ICExxxs messages)? If so, can you add:
//SORTDIAG DD DUMMY
to the job and rerun it? You could send me the JES and //SYSOUT messages offline (yaeger@us.ibm.com) and I could take a look. Put "DFSORT" somewhere in your Subject line to catch my attention.
Note that if you're not using DFSORT, I can't help you. |
|
| Back to top |
|
|
|
|
|
