IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

VSAM Performance tuning..


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
karthikr44

Active User


Joined: 25 Aug 2007
Posts: 235
Location: Chennai

PostPosted: Thu Feb 16, 2012 8:14 pm
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Feb 16, 2012 8:42 pm
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Thu Feb 16, 2012 8:44 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Feb 16, 2012 9:12 pm
Reply with quote

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
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Mon Mar 19, 2012 9:21 pm
Reply with quote

Also make sure you don't open and close the file(s) for every record!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts Access to non cataloged VSAM file JCL & VSAM 18
No new posts Merge two VSAM KSDS files into third ... JCL & VSAM 6
No new posts exploiting Z16 performance PL/I & Assembler 2
No new posts CVDA value for RRDS VSAM dataset. CICS 2
No new posts VSAM return code 23 - for a Random read COBOL Programming 4
Search our Forums:

Back to Top