Previous Topic: FIX: Page Fixing LSR Buffers and IOBsNext Topic: LSR: Converting Non-Shared Requests to Local Shared


HIPERSPACE: Backing LSR Buffers in HIPERSPACE

Restriction: Only buffers that are a multiple of 4K are eligible for backing in expanded storage. If the LSR pool contains some buffers that are a multiple of 4K and some that are not, only the buffers that are a multiple of 4K are backed in expanded storage. If none of the buffers are a multiple of 4K, no buffers are backed in expanded storage.

IPERSPACE is only effective if specified for a file that is using LSR buffering. Files that are strictly RANDOM use LSR processing, as will files that specify the LSR or SHRPOOL constraints. Since GVBDBFON cannot determine how a file is used, it cannot validate the use of HIPERSPACE. Therefore, you can specify HIPERSPACE anywhere (for example, no error message generated). However, the specification is effective only if LSR is in effect.

Default: HIPERSPACE=1

Option: HIPERSPACE=0 (turns off feature)

The HIPERSPACE control specifies that the LSR pool associated with this OPEN is to be backed in expanded storage. Access to expanded storage is slower than access to main memory, but much faster than access to DASD. By backing LSR buffers in HIPERSPACE, large quantities of data can be accessed without I/O.

The HIPERSPACE control specifies a multiplier that is used to determine the number of buffers that are allocated in expanded storage. CA Hyper-Buf attempts to allocate (multiplier x LSR buffers) HIPERSPACE buffers for this OPEN. The multiplier ranges from 1 to 32,767.

. . . 

CLUSTER=A.Z, SHRPOOL=5, *  Could  also be  LSR, or  merged  at a  lower  level HIPERSPACE=10 . . .

These constraints associate cluster A.Z with LSR pool 5. The LSR buffers are backed in expanded storage (HIPERSPACE). The number of buffers that are allocated in expanded storage are ten times the number of buffers that are allocated in the LSR pool.

This calculation is performed for each size buffer that is allocated to the LSR pool. For example, if the LSR pool 5 contains twelve 4K buffers, five 8K buffers, and two 16K buffers, and HIPERSPACE=10 is specified, then there are 10*12=120 4K buffers, 10*5=50 8K buffers, and 10*2=20 16K buffers allocated in expanded storage for this LSR pool.

HIPERSPACE backing of buffers in expanded storage creates a cache of data that can be accessed without an I/O to DASD. This can significantly reduce the number of I/Os required to process a cluster. If the requested data is resident in a HIPERSPACE buffer, it is moved synchronously to the requester's address space instead of being read asynchronously from DASD.

The data that is cached in HIPERSPACE buffers is not paged out. If the address space is swapped out, the data in the HIPERSPACE buffers must be rebuilt when the address space is swapped back in. The cache is lost each time the address space is swapped out. Therefore, swap-outs defeat the intended purpose of the cache, which is to reduce I/O. You should allow address spaces using HIPERSPACE buffers to be non-swappable for maximum performance.

CA Hyper-Buf automatically makes any address space using HIPERSPACE non-swappable, and automatically page fixes the LSR buffer pool. This is recommended for the above performance reasons. If for any reason you want to use HIPERSPACE and wish the address space to remain swappable, specify the SWAP constraint in addition to the HIPERSPACE constraint. This is not recommended for performance reasons, so be careful when you use this option in conjunction with the HIPERSPACE option.

A further explanation of the SWAP constraint can be found in the section SWAP: Do Not Mark Address Space Non-Swappable. If you force the address space swappable, VSAM is forced to rebuild the expanded storage cache of CIs each time the address space is swapped back into storage. The HIPERSPACE data is not swapped out and back in with the application. If you do not want the LSR buffers page fixed, specify UNFIX.

Additionally, there may be insufficient expanded storage available to allocate as many buffers as requested. In this situation, you can obtain less HIPERSPACE buffers than requested, and you might not obtain any. Processing continues without (or with reduced) HIPERSPACE buffer backing.