| Previous sections in this chapter described different aspects of a single application program accessing and updating a single IMS database. This section describes how IMS manages multiple applications that need to access and update a single database concurrently. IMS uses locks to isolate the database changes made by concurrently executing programs to maintain database integrity. Locking prevents situations in the following example from occurring: Application A reads a record. While application A is processing the record (waiting for a user to respond at a terminal), application B reads the same record. While application B is processing the record, application A reaches a commit point and updates the record. The user of application B now responds, and application B reaches a commit point and updates the record, thus overwriting the update to the record made by application A.
The mechanism to preserve data integrity is to lock or enqueue[2] the database segments or records until the application finishes processing them successfully and reaches the end of a unit of work. This section discusses how IMS ensures that application data is updated consistently; however, IMS also uses locking to keep internal information in the databases (such as pointers) consistent. [2] The term enqueue means that when an application program is granted update access to the data, IMS records and maintains the update events in enqueue/dequeue tables defined in the control program storage. These tables consist of 24-byte entries in a z/OS system. As application programs reach synchronization points, the table entries are freed, the storage can be reused, and other applications can now update the data.
One problem that can occur from this enqueueing of database segments is a deadlock between two application programs. For example: Application A reads database record 1. While application A is processing other data, application B reads database record 2, then tries to read database record 1, and is suspended waiting for it because record 1 is enqueued by application A. Application A now attempts to read database record 2, and is suspended because record 2 is enqueued by application B. Both applications are now suspended, waiting for a record that is enqueued by the other: a deadlock.
IMS detects the deadlock, abnormally terminates (abends) the application that has done the least work, and backs out that application's updates to the last commit point. The mechanism IMS uses to detect the deadlock depends on the method of data sharing being used (see "Methods of Sharing Data" on page 116). IMS either directly detects the deadlock from the details enqueued or detects the deadlock by a predefined timeout value; that is, IMS can terminate a task after a parameter-specified period of waiting for a database record. DB2 and Deadlocks If an application is accessing DB2 UDB for z/OS tables, DB2 UDB for z/OS also detects deadlocks by timeouts and instructs IMS to abend the program. The abend code that IMS issues for the application is the same code that IMS would issue for an IMS database deadlock. IMS cannot detect a deadlock between two applications where the two different resources that the applications are trying to get are managed by two separate resource managers. This situation is most common with CICS applications that access IMS databases. For example: CICS task A reads and enqueues a database record. CICS task B then issues a CICS READ UPDATE call for a CICS resource (for example, to access a transient data queue). CICS task B then attempts to read the database record held by task A, and is suspended waiting for it. CICS task A then attempts to read the resource held by task B and is suspended.
A deadlock now exists between tasks A and B, but neither IMS nor CICS is aware of the problem because both can see only the half of the deadlock they are managing. Unless IMS is using one of the data sharing techniques that times out applications that wait for the database, or CICS is set up to abend tasks after a very short time suspended, this deadlock must be resolved manually. The person who designs an application that uses IMS databases must be aware of the potential problems with database deadlocks, and design the application to avoid them. If the application also locks resources managed by another product, the application designer also must be aware of the potential for a deadlock developing between the IMS database records and the resources managed by the other product. Unfortunately, deadlocks often occur only when the application processes very large volumes because these types of applications often require very precise timing. These large-volume deadlocks might not be detected during testing because, typically, the testing is done with small volumes. Methods of Sharing Data IMS supports three methods of sharing data between a number of application tasks: Program Isolation (PI) Program Isolation can be used when all applications access the IMS databases via a single IMS control region. IMS maintains tables of all database records enqueued by the tasks in buffers in the control region address space. PI provides the lowest level of granularity for the locking and the minimum chance of a deadlock occurring. Deadlocks are resolved by IMS checking the tables of database records that are enqueued to ensure that no deadlock exists, and abending one of the tasks if one does exist. Block-level data sharing Block-level data sharing allows any IMS control region or batch address space running on a z/OS system to share access to the same databases. Block-level data sharing uses a separate feature, the internal resource lock manager (IRLM), which is delivered with IMS, but needs to be separately installed. The IRLM runs in its own address space in the z/OS system and maintains tables of the locks in this address space. With block-level data sharing, IMS locks the databases for the application at the block level. This locking is at a higher level than with Program Isolation (that is, all database records in a block are locked). Because of this coarser level of locking, there is an increased risk of deadlocks and contention between tasks for database records. Deadlocks are resolved by a timeout limit specified to the IRLM. If the disk storage that the databases are on is shared between two z/OS systems, the databases can be shared between IMS applications running on the two z/OS images, by running an IRLM address space on each of the two z/OS images. The IRLMs communicate using VTAM but maintain lock tables in each IRLM address space. The IRLM is also used as the lock manager for DB2 UDB for z/OS. Because of the different tuning requirements, you should use separate IRLM address spaces for DB2 UDB for z/OS and IMS. Sysplex data sharing When a number of z/OS systems are connected together in a sysplex, with databases on DASD that is shared by the sysplex, IMS control regions and batch jobs can run on any of these z/OS images and share access to the databases. To enable sysplex data sharing, an IRLM address space (running IRLM Version 2 or later) must run on each z/OS image that the IMS address spaces are running on. The IRLMs perform the locking at block level, as with block-level data sharing. However, instead of holding details of the locks in the IRLM address space, the lock tables are stored in shared structures in the sysplex coupling facility. Related Reading: For more information about data sharing, see: Chapter 9, "Data Sharing," on page 119. Chapter 27, "Introduction to Parallel Sysplex," on page 467. The chapter "Administering a Data Sharing Environment" in IMS Version 9: Administration Guide: System.
| 