|
View previous topic :: View next topic
|
| Author |
Message |
mankand007
New User
Joined: 08 Feb 2012
Posts: 2
Location: india
|
|
|
|
Hi all,
I'm trying to implement some performance tuning for my VSAM job, and I read that using SMB for buffering will improve performance. I used SMB and played with a lot of options like ACCBIAS, REGION, BUFNO.
I'm seeing a reduction in CPU time 2.59 minutes from 3.25 minutes, but the elapsed time and the EXCP counts are increasing manifold (from 7 minutes to minimum 18 minutes maximum 33 minutes).
Please advise me on the best approach to implement SMB technique for in VSAM.
Also please let me know if you need any additional information. Thanks! |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
You can't just assume that "tuning" a file will improve performance. If the programs using the file are doing something dumb, it is much better to fix the programs, for instance.
A LISTCAT (in the Code tags) and a general description of the main uses of the file would be good.
How long are the step(s) running which use the file? Is it batch only usage, or a mix?
Or you can just whack ahead with your method.
Even then, you have to show what you have tried to have any chance of a reasonable answer. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Do NOT expect file tuning to impact elapsed time. Elapsed time tends to be a factor of CPU (TCB) time, yes -- but also it depends upon the number of address spaces in the system, the Workload Manager policies in place, the relative priorities of the address spaces, and a myriad of other factors. There is absolutely NO correlation between CPU time and elapsed time -- a job that uses 3 minutes of CPU time could run in 5 minutes or 500 minutes, depending upon the external factors. And it could run in 5 minutes on one day, then 500 minutes on the very next day on the very same system. |
|
| Back to top |
|
|
mankand007
New User
Joined: 08 Feb 2012
Posts: 2
Location: india
|
|
|
|
It is a batch job and there are 8 vsam file accessed by a cobol program(24 bit processing). Currently, in the production, in the JCL, the buffer allocation for these vsam file is given as AMP=('BUFND=5','BUFNI=50'). All these files are accessed Dynamically by the cobol program.
From What I have learnt, I did the following changes in the test region:
Made the VSAM files as extended type by coding dataclass = EXT4GB while defining VSAM cluster. In the JCL, invoked SMB by giving AMP=('ACCBIAS=SO', RMODE31=NONE) for all the 8 VSAM files.
As a resut there was a reduction in CPU but the elapsed time and EXCP count increased compared to production.
I tested with different cases giving ACCBIAS=SO/DO/DW/SW. Also tried giving RMODE31 = BUFF/NONE/ALL
I also tried increasing the REGION size.
All the time there was a reduction in CPU but the elapsed time and EXCP count increased compared to production.
The same VSAM files containing program has been called in certain other programs in other jobs also and those jobs have been successfully tuning using SMB for those files. Regarding my job, when unmodified production job in the test environment runs consistently for around 7mins and the same job modified for SMB runs consistently anywhere between 18 to 35 mins based on the ACCBIAS value. Please share your thoughts on what factor might be causing this increase in elapsed time.
Please find various test run results for the same job tuned for SMB:
ACCBIAS VALUE| RMODE31 Value| REGION VALUE| CPU| ELAPSED TIME
SO | BUFF | 0 | 2.53 | 22.31
SO | NONE | 0 | 2.57 | 23.65
SO | ALL | 0 | 2.65 | 17.84
SO | ALL | 64M | 2.73 | 22.82
SO | ALL | 40M | 2.62 | 18.47
SO | NONE | 28M | 2.59 | 17.36
SO | ALL | 16M | 0 | 0
SO | ALL | 28M | 2.69 | 18.68
SO | BUFF | 64M | 2.75 | 30.48
SO | ALL | 64M | 2.73 | 46.02
SO | NONE | 36M | 2.69 | 27.27
SO | BUFF | 0M | 2.75 | 28.61
Result of unmodified production job in test
REGION VALUE | CPU | ELAPSED TIME
0 | 3.27 | 7.14
Thanks a lot for all your valuable inputs!! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Your values don't make sense. If the files are accessed dynamically, why on earth are you specifying SO (sequential optimized) instead of DW or SW? And BUFND=5 is woefully inadequate for sequential access -- I typically allocate enough buffers for a cylinder (which is the recommendation IBM followed in APAR OW49494 when changing the IDCAMS REPRO buffers). So what's the data CI size(s)?
Is the dynamic access primarily sequential or random or do you not know? Is the index CI size big enough for the data CI size? What's the weighting of the test LPAR in the sysplex, compared to the production LPAR (that, alone, could explain the elapsed time difference if the weightings are skewed enough)?
As I said in my previous post, there are many, many, MANY possible reasons for the difference in elapsed time -- and few of them have anything to do with file buffering or region size. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
If the step normally runs for about seven minutes, what do you hope to get out of "tuning" the VSAM datasets?
You have eight VSAM files accessed dynamically in the Cobol program. Which means serial or keyed read. So which? One serial and seven keyed? START and READ NEXT on seven files? What?
From what you have said so far, I'd guess all the access is random except the main file. I expect that not all the files are being accessed randomly in key order. I suspect you are loading a lot of data into the buffers, then going off and loading another lot from another location on one, or more, or all, of the files. File IO goes up. IO tends to introduce waits. Elapsed time, in equal conditions, goes up.
If you really need to reduce from seven minutes. look at the program. I'd not be surprised if you could get rid of up to 90% of the CPU and IO usage, if needed. But for seven minutes?
I'd suggest, leave the "tuning" out of it, define the datasets for the best mix of how they are used... jeez, that'd be enough for a seven minute step. You got no real work to do? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
|
|
