Calculating the size of the lock structure
The size of a coupling facility lock structure is dependent on a variety of factors that are unique to your installation, such as transaction rates, update rates, contention rates, commit frequency, and so forth. Consequently, there is no way to calculate the optimum size of a lock structure that does not involve some estimation, monitoring, and adjustment.
The simplest method is to start with a likely size that is a power of 2, such as 256 MB or 512 MB. Then monitor your update and contention rates. Tune the lock structure size to lower contention to an acceptable level and to ensure that enough room is available for modify (update) locks. Lock structures that are too big can also adversely affect performance.
You can also use the z/OS® Coupling Facility Structure Sizer Tool (CFSizer). CFSizer is a web-based application that calculates the structure size based on the input data you provide. If you use CFSizer, you still need to monitor your update and contention rates and adjust the lock structure size as necessary. To use the CFSizer tool, go to http://www.ibm.com/systems/support/z/cfsizer/.
After setting the initial value, monitor the use of the lock structure using IRLM messages, some of which suggest that you increase the size of the structure. You will begin to receive IRLM messages when 50% of the current lock structure is used.
The coupling facility lock structure contains two parts. The first part is a lock entry table used to determine if there is inter-IMS read/write interest on a particular hash class (resources that hash to a particular place in the lock table). The second part is a list of the update locks that are currently held (sometimes called a modify lock list or record list table). The division of the lock structure storage between these two components can be controlled by the user through the IRLM DXRJPROC procedure or by an IRLM MODIFY command. If the user does not specify how the structure is to be split, then IRLM will attempt to divide it with a 1:1 ratio between lock table entries and record list storage. The total size of the lock structure must be large enough to prevent performance problems by limiting hash contention and to prevent failures resulting from lack of record list storage to write a MODIFY entry (RLE). Proper specification for the number of lock table entries can help avoid hash contention.
IRLM reserves 10% of the record table entries for “must complete” functions (such as rollback or commit processing) so that a shortage of storage does not cause an IMS system failure. However, if storage runs short in the record table, there can be an impact on availability (transactions are terminated), response time, and throughput.
Considerations for the lock entry size
The lock entry size is the number of bytes required for lock contention control information (that is, individual entries in the lock table). The lock entry size is determined by the maximum number of IRLM members in the data-sharing group, as defined by the value specified on the MAXUSRS= parameter in the IRLM startup procedure. The more users in the group, the more bytes are needed to manage each lock table entry. The lock entry size can be a value that is an exact power of 2 in the range 2 - 32, and the default lock entry size is 2 bytes.
The lock entry size and the number of lock table entries of the first IRLM to join the group causing structure allocation determine the storage size needed for the lock table and the lock table entry width for the whole group. By adjusting the value of the MAXUSRS= parameter to the actual number of IRLMs that are connected to the data sharing group, you maximize the amount of LTE space available from the defined structure size. This can help avoid false contention.
Storage estimate for the lock structure
For installation planning purposes, the initial size of the lock structure is based on how much updating you do.
When specifying a value for the LTE= parameter in the IRLM DXRJPROC procedure, or when issuing the IRLM MODIFY SET,LTE= command, you should monitor XES contention rates to determine the optimum value for your normal environment. If the contention rates appear too high, then increase the LTE= value to the next power of 2, keeping in mind that any increase in the size of the lock table will cause a corresponding decrease in the record table, unless the structure size is also increased. If you have little contention and want more storage available for record table entries, then decrease the LTE= value by a power of two. Anytime the number of lock table entries are decreased, it is good to monitor contention rates for a period of time.
Since the structure allocation is performed at CONNECT time, any change made to the LTE= value does not take affect unless the group is terminated, structure forced and the group restarted or a REBUILD is done. Also, the LTE= value of the first IRLM to CONNECT dictates the coupling facility attributes used by the group.
Automatic altering of the size of the lock structure
z/OS can automatically expand or contract the size of a lock structure in the coupling facility if it needs storage space. The ALLOWAUTOALT parameter in the CRFM policy specifies whether system-initiated alters (automatic alters) are allowed for the lock structure. If no competing resource is using the coupling facility, ALLOWAUTOALT(YES) might be desirable to allow the lock structure to change as the workload grows. However, with the parameter set to YES, another resource can force the lock structure to decrease, possibly causing an IRLM out-of-storage condition in the lock table during coupling facility use. In this case, the application terminates abnormally with a U3307 abend. In addition, the IMS control region might terminate with a U0113 or U1027 abend.
If you need the lock structure to be stable, use ALLOWAUTOALT(NO).