Joined: 29 Oct 2010 Posts: 194 Location: Toronto, ON, Canada
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?
Joined: 06 Jun 2008 Posts: 8527 Location: Dubuque, Iowa, USA
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.
Joined: 08 May 2006 Posts: 1056 Location: Dublin, Ireland
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.
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).
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.