The daily edition.

Scope: Rocket Enterprise Developer 12.0 for Eclipse on Linux/UNIX; Enterprise Server IMS database support.

In shared-access mode, Enterprise Server locks an IMS database record, meaning the root segment together with all its dependent segments. Logical relationships can require locks on both the logical child’s record and the destination parent’s record. This locking granularity explains why applications touching different dependent segments beneath the same root can still contend. IMS Database Locking

A simple lock conflict initially causes a retry—not immediate deadlock processing. Two settings control that behavior:

• ES_IMS_LOCK_TIMEOUT specifies how long DB Control retries before abandoning the wait. Its range is 0–65535 seconds, the default is 30 seconds, and zero means wait forever.
• ES_IMS_LOCK_RETRY_DELAY controls retry frequency. Its range is 0–65535 milliseconds, with a default of 5 milliseconds.

If the timeout expires, the DLI call receives status BD and Enterprise Server writes an error to the console. Rocket says expired waits are not normal and should be investigated; documented causes include an application retaining IMS locks while waiting on another resource manager, application suspension, or CPU starvation. ES_IMS_DUMP_ON_TIMEOUT=1 produces a system dump when such a timeout occurs. IMS Database Locking

A deadlock is different. Rocket’s documented example is the classic AB–BA sequence: program 1 locks segment A and then requests B, while program 2 locks B and then requests A. IMS DB Control selects a loser, terminates its DLI call with status FD, and initiates rollback. The recovery behavior depends on the workload: IMS BMP and CICS programs receive FD, whereas IMS transactions restart automatically. The loser selection considers application type, DLI-call count in the current unit of work, and execution duration. Importantly, DB Control does not detect deadlocks spanning multiple resource managers—for example, a cycle involving both IMS DB and SQL. Deadlocking

Traditional locking is the default. It locks reads and updates without distinguishing read, update-intent, and update locks, providing high isolation but increasing contention and deadlock risk. IRLM more closely follows mainframe IMS locking behavior, prevents multiple readers from blocking one another, and gives PROCOPT=GO applications no locking or data constraint. Enable it by setting ES_IMS_IRLM=1 before starting the Enterprise Server instance. Traditional Locking Enabling IRLM Locking

Takeaway: Treat BD as an exhausted lock wait and FD as deadlock victim selection; changing the timeout can mask contention, but it does not resolve an application-level or cross-resource deadlock.