Selecting an IMS lock manager

To protect database integrity, an IMS system serializes requests for database resources to ensure that no two application programs are allowed to update a database segment concurrently. Lock management is the process of controlling concurrent requests.

For lock management, you can use either or both of the following methods:

The program isolation lock manager controls only lock requests for a single IMS system (local locking); the IRLM controls requests for multiple IMS systems (global locking), as well as for a single system.

You can monitor program isolation activity using the IMS Monitor, which is invoked by the /TRACE command. A separate program isolation trace can also be used to analyze performance. The advantage of using program isolation to manage locks is that you do not need any special operating and recovery procedures, as is necessary for the IRLM.

The IRLM component is used as a part of data sharing. With program isolation, all activity (modifying the database and creating messages) of an application program that is active in the DB/DC environment is isolated from any other application programs that are active in the system. The isolation persists until that application program confirms, by reaching a synchronization point, that the data it has modified or created is valid.

Note: The PI lock manager supports a maximum of 63 waiting application programs in an IMS system. If an application program that must wait for a lock exceeds the maximum that the PI lock manager supports, the application program terminates with an abend 2478, is backed out by IMS, and its locks are released. If the requestor is a message-driven program (MPP, JMP, IFP, or BMP) the message is returned to the queue and is reprocessed.

To indicate that an IRLM is to manage locking, specify the IRLM's z/OS® subsystem name on the IRLMNM parameter of the IMSCTRL macro. The IRLM is required if the IMS online system is to take part in block-level data sharing. Because the IRLM executes in a separate region, you can plan for a known amount of common storage area (ECSA) to be allocated for use by the IRLM component, or you can retain most of its control blocks in local storage rather than in the common storage area.

Your choice of lock manager is not necessarily permanent. On the IMS procedure, specify IRLM=Y, and give the IRLM z/OS subsystem name on the IRLMNM parameter, to indicate this change. This allows the IMS online system to take part in block-level data sharing.