IMS Database Locking

The type of database locking used for Enterprise Server applications that access IMS databases is based on their access mode, which can be either exclusive or shared.

Exclusive Access Mode Locking

Exclusive access mode is used for administration tools, utilities and batch application programs. Exclusive access locks an IMS database at the database level. The database is in non-sharing mode and available to a single process only. This access requires that the database is in a stopped state in Enterprise Server. Examples of exclusive access processes are:

IMS Database Editor tool

The tool is available only from the Visual Studio IDE and is exclusively owned by the IDE process.

IMS Database Utility (IMSDBU)

Accessible from the Visual StudioIDE, JCL, and the command line. The IMS database data is opened exclusively by IMSDBU and owned by the process where IMSDBU was invoked.

Batch application program

A DLI or DBB batch application program running in a JES initiator uses the IMS Database Control process to open the database data exclusively on behalf of the application program running in a JCL initiator. In addition, you can use one of the following:

IMSLOCK DD statement

Enables you to direct batch program execution to process all IMS DB calls entirely in the JES initiator, providing significant performance improvement. To use this feature, add the following to your JCL:

//IMSLOCK DD *  
(EXCLUSIVE | SHAREDGO)  
/*

EXCLUSIVE

Highest performance batch
Requires exclusive access to the database
Does not allow GO sharing
Equivalent to setting the ES_IMS_ LOCALDLI environment variable

SHAREDGO

Shared get only (dirty read). Default.

ES_IMS_LOCALDLI environment variable

Deprecated. Directs batch program execution to process all IMS DB calls entirely in the JES initiator. All IMS DB control processes accessed from the batch program must be stopped before execution because they become exclusively owned by JES until the program completes.

Shared Access Mode Locking

Shared access mode is used for online programs such as IMS and CICS transactions and IMS BMPs.

Requirements

Shared access requirements are:

The application accessing the IMS database is running in an enterprise server instance
The database is not in a stopped state

The following are some examples of shared access:

IMS Transactions (MPP)
Batch message processing programs (BMP)
CICS transactions and batch programs from CRUN
ODBA applications from JES initiator using AERTDLI or DDBA interface

Locking

In shared access mode, IMS database locking occurs at the database record level. The DB record includes the root segment and all dependent segments. Secondary Index DBs lock the DB record of the target segment in the primary database. Logical relationships lock both the DB record where the logical child segment is defined and the DB record of the destination parent.

If a locked record is encountered while processing a DLI call, DB Control goes into lock retry. This retry continues until either the record lock is released or a wait time is exceeded. The wait time is controlled by environment variable:

 ES_IMS_LOCK_TIMEOUT=n

Where n is expressed seconds in the range of 0-65535. The default value is 30 seconds. A value of 0 indicates to wait forever.

The lock retry algorithm can also be tuned for performance. This delay interval controls the retry frequency and can be externally controlled by environment variable:

 ES_IMS_LOCK_RETRY_DELAY=n

Where n is expressed in milliseconds in the range of 0-65535. The default retry delay is 5 milliseconds.

When a lock wait period expires, a BD status code is returned to the DLI call and an error message written to the server console. It is not normal to have lock wait times expire; these should be researched. Possible causes for wait expirations are when an application holding locks is waiting on resources from another resource manager or suspended for some other reason. These can also happen when a system has become CPU starved due to other machine activity resulting in pausing of the application. This can be rectified by increasing the lock timeout value.

To help diagnose lock timeout issues, the following environment variable triggers a system dump when a timeout is detected:

 ES_IMS_DUMP_ON_TIMEOUT=1

Shared access databases can use one of two locking modes: traditional or IRLM. The locking mode is defined to IMS DB Control at Enterprise Server startup.