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

VSAM read performance

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

Active User

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

PostPosted: Mon Nov 09, 2015 9:13 pm
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
    RECORDSIZE(37 37) KEYS(8 0)
    BUFFERSPACE(66048) SHR(1 3))               
    TRACKS(15 15) CISZ(4096) )
    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: 8569
Location: Dubuque, Iowa, USA

PostPosted: Mon Nov 09, 2015 9:34 pm
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

Senior Member

Joined: 08 May 2006
Posts: 1100
Location: Dublin, Ireland

PostPosted: Mon Nov 09, 2015 9:40 pm
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.

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

Moderator Emeritus

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

PostPosted: Mon Nov 09, 2015 11:14 pm
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

Active User

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

PostPosted: Wed Nov 25, 2015 12:51 am
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: 490
Location: London

PostPosted: Thu Dec 10, 2015 6:52 pm
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: 2504
Location: Atlanta, Georgia, USA

PostPosted: Thu Dec 10, 2015 8:37 pm
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.

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 Which SORT utility can improve the Pe... DFSORT/ICETOOL 16
No new posts FILE STATUS - 39 ON VARIABLE LENGTH V... COBOL Programming 2
No new posts COBOL Performance Tuning COBOL Programming 6
No new posts Need to read duplicate rows from tabl... DB2 3
No new posts Read 4MB message and split into multi... COBOL Programming 9
Search our Forums:

Back to Top