View previous topic :: View next topic
|
Author |
Message |
karthikr44
Active User
Joined: 25 Aug 2007 Posts: 235 Location: Chennai
|
|
|
|
Hi,
I want to tune one update process of VSAM file in COBOL.
Here is the scenario.
File 1 is sequential file containing 275000 records.
Here key field (1,16).
Code: |
03 IN-KEY VALUE SPACES.
05 IN-LEVEL1 PIC XX.
05 IN-LEVEL2 PIC XXXX.
05 IN-NBR PIC 9(5).
05 IN-NBR PIC 9(5). |
File 2 is VSAM KSDS file containing 280000 records.
Code: |
SELECT VSAM-FILE ASSIGN VSAMINOT
ACCESS MODE IS RANDOM
ORGANIZATION IS INDEXED
RECORD KEY IS F16-PRIMARY-KEY
FILE STATUS IS VSAM-STATUS-CODE. |
Here key field (1,16).
Opening sequential file in input mode and vsam file in I-O mode.
I will read the first record from sequential file and move key field to F16-PRIMARY-KEY and reading VSAM file. If key found i will update single field in VSAM file which i get from sequential file. If key not found i will bypass that input record.
This process repeated until sequential file EOF.
In our system we are running this job daily and it takes about 1 hour to complete.
Is there any process improvement can be done on this logic..Is reading in Skip sequential mode possible to implement this logic...Or can we use SORT utility to achieve this..
I am also trying whether increase in buffer space will help to reduce elapsed time.
Kindly share your knowledge on this.
Thanks
R KARTHIK |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
You managed to post a lot but not a lot of useful data. Is your VSAM read direct (random) or sequential? Why not sort the sequential file and then you just have a simple two-file match process, for which a well-defined solution exists on this forum.
Elapsed time varies dramatically depending upon many, many, many factors -- and while you can control some of them, there are others that you have absolutely no control over. And only someone working at your site could possibly help you tune your job to reduce elapsed time.
Asking if increasing the buffers will reduce elapsed time is a useless question unless you know (1) how many buffers does the current process use for each file, (2) is the VSAM file using NSR or BLSR or RLS already, and (3) how much will adding buffers impact memory usage, channel utilization, and volume contention -- not to mention other questions such as what is the VSAM read distribution (100% sequential or 100% direct or some mix, and what is the mix)? |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
I would certainly make sure that the PS file is in key sequence as this may reduce the IO for the VSAM file as any one index or data CI will only ever be read once. If the file is not in key sequence the same CIs may be read multiple times.
Not sure that buffer increases will acchieve much if the PS file is processed in key sequence, and may cause even more delays if not.
Can't see how skip sequential processing would help at all as the buffers will be dropped and reloaded for every change of access method. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
If your driver file is unsorted, the time/resources taken will drop like a stone if you sort it. 275,000 in an hour, I'd guess it is unsorted, but only a guess.
If the driver is already sorted, find out the cut-off point between keyed reads and the two-file match. By this I mean, at some point the number of driver file records will cause more resources to read/update than it would take to read the vsam file serially. Once you find the ball-park size of the cut-off, then you can decide which route is best for your data.
Obviously consider the CI sizes. Small for any keyed access, big for sequential access. Is your VSAM used online? For a lot of keyed processing?
Is your VSAM file "split-to-hell-and-back"? High levels of "splits" have negative performance implications. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
Also make sure you don't open and close the file(s) for every record! |
|
Back to top |
|
|
|