Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

VSAM read performance

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 183
Location: Toronto, ON, Canada

PostPosted: Mon Nov 09, 2015 9:13 pm    Post subject: VSAM read performance
Reply with quote

I am planning to create a large KSDS vsam file with max record length 37. The key is the first 8 bytes (packed decimal). I plan to load it just once with 50M records. After that it be read only. What DEFINE parameters will give me the best read performance when doing a key read?

Below is what I currently have
Code:
DEFINE CLUSTER
 (NAME(prefix.VSAM)
    INDEXED NONSPANNED
    RECORDSIZE(37 37) KEYS(8 0)
    NOREPLICATE NOREUSE NOIMBED
    NOERASE SPEED NWCK
    OWNER(??????)
    BUFFERSPACE(66048) SHR(1 3))               
  INDEX(NAME(prefix.VSAM.INDEX)
    TRACKS(15 15) CISZ(4096) )
  DATA(NAME(prefix.VSAM.DATA)
    TRACKS(15 15) CISZ(4096)
 )


Would it give better performance if I convert the key to a 15 bytes zoned decimal key?
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Mon Nov 09, 2015 9:34 pm    Post subject:
Reply with quote

The VSAM Demystified Redbook has an entire chapter on performance and an appendix on miscellaneous performance items. If you have not yet read them, you should start there.

Are the key reads randomly scattered across the entire file or concentrated in some way (for example, after reading one record the next several reads, even though using the key, will be retrieving data near the first read record)? Randomly scattered reads usually perform better when the CI size is smaller since less data is being processed per read. I have not heard anything indicating performance is better with a zoned decimal key instead of packed decimal, and in fact performance will probably be slightly better with packed decimal keys since there will be more keys per index CI. For online, LSR will help with randomly scattered reads. For batch, BLSR will help with randomly scattered reads.

Why are you coding buffer space? VSAM usually does a MUCH better job of determining how much buffer space is needed than people do. You also should specify CYLINDERS not TRACKS for performance improvement. Also, make sure the INDEX CI size is appropriate for the DATA CI size -- you don't want any unusable DATA CI in your data set.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Mon Nov 09, 2015 9:40 pm    Post subject:
Reply with quote

Possibly the best thing you could do is ensure that the entire index is in memory. This means you need at least the same number of index buffers as there are index records. The fewer the levels of index the better, so large index CIs can be useful. Use LISTCAT to explore.

BTW, you can check the effect before re-defining by using BUFNI= in JCL to increase the number of index buffers.

For random keyed access, additional data buffers are unlikely to be of benefit.

I don't think that converting the key to zoned decimal will do anything other than increase the amount of space used.


Garry.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Mon Nov 09, 2015 11:14 pm    Post subject: Reply to: VSAM read performance
Reply with quote

No problem with a packed-decimal key.

How the data is used will be the best indication of how to define the file. Ensure there is no dumb default freespace. Some of the options you show are only accepted syntactically, so don't worry about those. NOREUSE won't hurt. Probably change the space....

For performance and keyed access, attempt to get the entire index in memory is the best, minimum is number of levels plus one for useful index bufferspace. For dispersed "random" access, only one data buffer (otherwise it'll fill any others which isn't needed).
Back to top
View user's profile Send private message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 183
Location: Toronto, ON, Canada

PostPosted: Wed Nov 25, 2015 12:51 am    Post subject:
Reply with quote

Thanks for the tips. I will read the Redbook and try the tips provided. It will be a good opportunity to learn more about VSAM.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Thu Dec 10, 2015 6:52 pm    Post subject:
Reply with quote

What will be reading the dataset, will it be more than one application on different LPARs concurrently? Will it be batch and CICS?

Depending on the answers you may consider the following, although it's such a small dataset most of it will be in memory anyway I expect.

- sufficient LSR/GSR buffers available to CICS for the CISIZE

- for Batch BUFND and BUFNI parameters in the JCL. A good default for BUFND is two times the number of CI's that fit in a track, plus 1. And BUFNI should be at least the number of index levels.

- STRNO increase might help if multiple users accessing it concurrently

- SHROPTS should be appropriate to allow multiple concurrent reads intra or inter LPAR.

- Data CISIZE should reflect the most common access, large for more sequential, not so large for random, but also a good size fit for the RECORDSIZE. Let VSAM decide the INDEX cisize as these days it selects one that is not going to end up with dead CI's.

- allocate in CYLS for the data component and large enough so it doesn't need to extend. CYL allocation makes the CASIZE a CYL which is more efficient.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Dec 10, 2015 8:37 pm    Post subject: Reply to: VSAM read performance
Reply with quote

If this VSAM file is "Read Only" in CICS (Including Browsing), then it could be a candidate to be defined as a CICS Data-Table.

Check with your CICS System Programmer whether he/she advocates these and whether this file is eligible.

HTH....
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts BWO option in VSAM blayek CICS 3 Sat Nov 05, 2016 10:47 am
No new posts What are the way we can improve CPU p... Gunapala CN DB2 10 Mon Oct 24, 2016 2:16 pm
No new posts VSAM define for large file jerryte JCL & VSAM 9 Wed Oct 05, 2016 1:51 am
No new posts CICS VSAM RLS READ akodakka CICS 3 Tue Oct 04, 2016 3:09 pm
No new posts Multi row fetch - "for read only... Nileshkul DB2 3 Sun Aug 14, 2016 12:52 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us