|
View previous topic :: View next topic
|
| Author |
Message |
sprakash1279
New User
Joined: 18 Apr 2011
Posts: 3
Location: India
|
|
|
|
Hi,
I have a VSAM file reading the record by RANDOM read. The below are the values from the LISTCAT. After introducing this VSAM file in the processing, the Job is started runnning for 3 hours, which was completed in 5 to 10 mins earlier.
The VSAM file has only 500 records in it. I tried having AMP='BUFNI=20' but didnt reduce the run time. What would be the optimum Buffer value I could add to improve the performace of the Job ? Many thanks.
| Code: |
Total Index Records HURBA CISIZE CIs per CA
1 691200 5,120 135
BUFSPACE-----------11264 CISIZE--------------5120
EXCPEXIT----------(NULL) CI/CA----------------135
INDEXED NOWRITECHK NOIMBED NOREPLICAT
|
|
|
| Back to top |
|
 |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
In the SELECT, ensure that you're specifying ACCESS IS RANDOM rather than ACCESS IS DYNAMIC.
This may help....
Bill |
|
| Back to top |
|
|
sprakash1279
New User
Joined: 18 Apr 2011
Posts: 3
Location: India
|
|
|
|
Hi Bill,
Yes. The file control is mentioned correctly.
| Code: |
SELECT TNBSCOS ASSIGN TO TNBSCI1
ORGANIZATION IS INDEXED
ACCESS IS RANDOM
RECORD KEY IS COST-KEY OF TNBSC01
FILE STATUS IS WS-FILE-STATUS.
|
File processing Status :
| Code: |
Command ===>
System: S0E5 Jobname: JSBDKV17 Stepname: JS010010
Duration: 00:01:11
DD Name: TNBSCI1 DS Name: JSSBSA.LIVE.TNBSCOS
Data Source: JOB CTL BLOCKS
Status Type Format Access Opts LSR Misc
CLSD-IN KSDS NSR DIR KEY
DATA:------------------------------------------------------------------------
CIFR CAFR CISP CASP CISZ CI-CA Keyln Keyps Maxlr
10 0 0 0 5,120 135 6 0 43
EXTNT EXCPs Reccount Retrved Updated Deleted Insrted
1 20,776 303 0 0 0 0
INDEX:-----------------------------------------------------------------------
CIFR CAFR CISP CASP CISZ CA LVL EXT Reccnt EXCP
0 0 0 0 1,024 33 1 1 1 20,775
|
|
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| How many times is the file accessed in each run? It may be more efficient to load it to a COBOL table. Another way to improve efficiency is to check to see if the key being used to access the file is the same as for the previous access in which case you do not need to access it again as the data would be current in your program. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Your EXCP counts for data and index are surprisingly close. In addition to Nic, is your input file in key order? If not, buffers will be filled, only to be thrown away, as a lower key arrives. More buffer space, more wasted io.
For the size of your file, Nic's Cobol table sounds a good idea. Load it up, occurs depending on, search all, with Nic's check-for-previous-search as well.
Or process in key order, even if you have to re-sequence later.
Or if it has to be like you have it, try making only one buffer. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| What would be the optimum Buffer value I could add to improve the performace of the Job ? |
Your last post indicates there is 1 index level -- so providing anything more than 2 index buffers will not result in performance improvements, and could degrade performance (the system does have to manage however many buffers you tell it to use). You should add more data buffers, however, since the minimum is usually not enough.
I think the basic problem is you have started with an invalid assumption and are leaping to invalid conclusions thereby. You are assuming -- on no evidence that I can see -- that VSAM buffering is your problem. It is much more likely that you have a program logic problem that is causing the additional elapsed time for your job. For example, if you open the file, read a record, close the file and repeat this over and over -- that alone could add a LOT of time to your run. Of course, there are many other potential problems -- but you should be looking at your code around the VSAM file access, not changing system parameters, to fix the problem. |
|
| Back to top |
|
|
|
|
