VSAM read performance

jerryte · Posted: Mon Nov 09, 2015 9:13 pm

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

Robert Sample · Posted: Mon Nov 09, 2015 9:34 pm

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.

Garry Carroll · Posted: Mon Nov 09, 2015 9:40 pm

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.

Bill Woodger · Posted: Mon Nov 09, 2015 11:14 pm

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).

jerryte · Posted: Wed Nov 25, 2015 12:51 am

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.

Pete Wilson · Posted: Thu Dec 10, 2015 6:52 pm

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.

Bill O'Boyle · Posted: Thu Dec 10, 2015 8:37 pm

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....