Author: Robert Sample
Posted: Wed Oct 05, 2016 2:13 am (GMT 5.5)
YOUR definition of "a large amount of data (50 million 40-byte records) is MUCH different from my definition of a large amount of data. You've got about 2 GB and that is not even getting close to the 4 GB limit of VSAM; to me a large amount of data gets well past the 4 GB limit (requiring extended data).
Once loaded, the data will be accessed completely randomly -- no sequential reads at all? If so and this data set is allocated to CICS, put it in an LSR pool. If the data set is being used in batch, use BLSR. LSR works well for random access of data in a KSDS.
As far as your definition goes, get rid of BUFFERSPACE. Do not specify space on the index -- VSAM is efficient and good at allocating index space. Change the allocation for the DATA to CYLINDERS instead of TRACKS and if your space management policy allows you, allocate the entire 2725 cylinders for the 50 million records as the primary and use a token secondary (100 cylinders maybe). Make the CISIZE on the DATA 4096 and you can probably use 2048 for the INDEX CISIZE.
Why do you think there is a problem with the read access time? If you think there is one, you need to work with your site support group on this -- not ask a forum. Read access time can be affected by a larger variety of factors and hence only someone working at your site -- such as the site support group -- could possibly address the issue.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Posted: Wed Oct 05, 2016 2:13 am (GMT 5.5)
YOUR definition of "a large amount of data (50 million 40-byte records) is MUCH different from my definition of a large amount of data. You've got about 2 GB and that is not even getting close to the 4 GB limit of VSAM; to me a large amount of data gets well past the 4 GB limit (requiring extended data).
Once loaded, the data will be accessed completely randomly -- no sequential reads at all? If so and this data set is allocated to CICS, put it in an LSR pool. If the data set is being used in batch, use BLSR. LSR works well for random access of data in a KSDS.
As far as your definition goes, get rid of BUFFERSPACE. Do not specify space on the index -- VSAM is efficient and good at allocating index space. Change the allocation for the DATA to CYLINDERS instead of TRACKS and if your space management policy allows you, allocate the entire 2725 cylinders for the 50 million records as the primary and use a token secondary (100 cylinders maybe). Make the CISIZE on the DATA 4096 and you can probably use 2048 for the INDEX CISIZE.
| Quote: |
| Are there any options that will speed up the read access? |
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth