Resources
Note: Specifying LSR forces CA Hyper-Buf to assign an LSR buffer pool, unless SEQUENTIAL processing is the only type of processing indicated in the ACB, or if a higher precedence LEVEL SELECTOR specifies NSR. Since LSR buffering does not perform initial positioning for sequential access, do not specify LSR for mixed mode applications that do not perform their own positioning. It is safer to specify LSR on a PROGRAM or DDNAME constraint than on a CLUSTER constraint, since many different applications can access a cluster, and some of the applications may perform some sequential processing.
CA Hyper-Buf automatically promotes random-only OPENs (for example, ACBs which specify only random processing in the ACB MACRF) to use LSR buffering, unless a matching level selector specifies NSR explicitly. You should force LSR only if a predominantly random application specifies mixed-mode processing (for example, both random and sequential in the ACB MACRF) in the ACB, and performs its own positioning for all requests.
Restriction: LSR buffering does not support chained RPLs, and does not perform any positioning for sequential applications. These conditions are not detectable at OPEN time.
Do not specify LSR buffering for any applications that do not establish a position in the file before processing records sequentially. If applications that worked before CA Hyper-Buf was activated fail with positioning errors after CA Hyper-Buf is activated, make sure that LSR processing was not requested for this application, or override the LSR constraint by specifying NSR at the PROGRAM/DDNAME level.
Do not specify LSR for applications that use chained RPLs. If the file is processed randomly, and CA Hyper-Buf automatically promotes the OPEN to use LSR buffering, override CA Hyper-Buf by requesting NSR for any programs that use chained RPLs.
Default: LSR for strictly random (ACB specified) processing, else NSR.
The LSR constraint requests that CA Hyper-Buf promote NSR OPEN requests to LSR requests. This option is designed for files which are processed randomly.
There are no operands associated with the LSR control.
Prior to DFP 2, VSAM supports only one LSR buffer pool per address space. DFP 2 added LSR pools per address space.
The LSR control is not pool specific. In environments that support multiple LSR pools, the LSR constraint requests that CA Hyper-Buf select an appropriate LSR pool for this file. If you want to assign a specific LSR pool, use the SHRPOOL control instead of the LSR control. An explanation of SHRPOOL is in the section SHRPOOL: Requesting a Specific Shared Resource Pool. If you specify both SHRPOOL and LSRPOOL, the option that is specified last in the constraint list is used.
CA Hyper-Buf does not assign LSR pools to files that cannot use LSR buffering because of VSAM restrictions. Such files include files that are being loaded ('initial load' mode or 'create' mode), files that are opened with REUSE, and so forth. In these cases, the LSR constraint is ignored by CA Hyper-Buf.
|
Copyright © 2011 CA.
All rights reserved.
|
|