Shared IMS Database Access

Each of the IBM IMS products provides some capability for sharing IMS resources. Two general categories of sharing exist:

The concepts of Read integrity and Update integrity are important in a description of resource sharing. Read integrity means that two programs cannot access a record simultaneously if one has update intent. Read integrity guarantees that the data is current when reading a record. Update integrity means that two programs cannot access a record simultaneously if both have update intent. Update integrity guarantees that data accessed for update is current, but it does not guarantee that data accessed for reading is current.

Resource sharing within one subsystem is the most common form of resource sharing and is available with an online IMS subsystem. In the online IMS subsystem, the online IMS control region allocates the database data sets and controls concurrent access to the databases by multiple programs. Read integrity is guaranteed when sharing within an online subsystem unless the processing option GO has been specified in the PCB. For more information about the GO option, see Chapter 2, "Program Specification Block (PSB) Generation," in the IMS/ESA Utilities Reference Manual, or DL/I Resource Definition and Utilities. Update integrity is always guaranteed in an online subsystem.

In the second form of sharing, sharing resources between multiple IMS subsystems, there are two subcategories:

When sharing resources, IMS preserves both Read and Update integrity.

When resources are shared, whether within a subsystem or between subsystems, many users can access a given database at the same time. Consequently, one invocation of the SAS/ACCESS interface to IMS can have an impact on the performance of several users' programs.

When Read integrity is guaranteed, the SAS/ACCESS interface has Read-Only access and owns (has exclusive access to) the last database record that it accessed. Even under these circumstances, the SAS/ACCESS interface with Read-Only access does not normally affect the performance of other programs. However, if the SAS/ACCESS interface is positioned on one database record for a long time, it affects other programs by preventing them from accessing that record. If Read integrity is not guaranteed, the SAS/ACCESS interface does not own records and therefore does not affect other programs.

The SAS/ACCESS interface is more likely to affect the performance of other programs if it updates database records. When the SAS/ACCESS interface updates records, it owns any record that has been updated since the interface's last synchronization point. A synchronization point occurs when the SAS/ACCESS interface issues a CHKP (checkpoint) call. This synchronization point saves the changes the SAS/ACCESS interface has made since the last CHKP call it issued to the database. By default, the SAS/ACCESS interface issues CHKP calls at the beginning and end of processing. With SAS/FSP software, use the AUTOSAVE option to increase the frequency of issuing CHKP calls.

Synchronization points are important because they cause IMS to release some resources allocated to the SAS/ACCESS interface. These resources include the database records owned by the interface, the IMS enqueue table entries that mark this ownership, and the dynamic log records required to back out (cancel) updates since the prior synchronization point. When IMS releases the SAS/ACCESS interface's ownership of updated database records, other programs can access the record with the updated information.

In database-level shared access, multiple IMS subsystems (batch or online or both) allocate the database data sets concurrently. Concurrent allocation is possible in a single operating system with shared disposition allocation. It might be possible between multiple operating systems, regardless of the allocation disposition, if the database data sets reside on shared Direct Access Storage Device (DASD).

In database-level sharing, one subsystem can have Update access to a database while other subsystems have Read access to the same database. In this case, Update integrity is guaranteed, but Read integrity is not guaranteed. Alternatively, all subsystems can be restricted to Read access. In that case, Read integrity is guaranteed because there is no danger of a record being updated. The remainder of this section on database-level sharing discusses sharing when one subsystem has Update access and other systems have Read access.

When one subsystem has Update access and the others have Read access, it is possible for a Read-access invocation of the SAS/ACCESS interface to obtain uncommitted update data from a program that later backs out the updates.

If the subsystem with Update access is a batch subsystem, only one program or invocation of the SAS/ACCESS interface has Update access to the database (since only one program executes in a batch subsystem). No other program or invocation of the interface with update intent (indicated in the PCB) can execute until the first subsystem completes, so there is no contention for the database records. (Remember that Read integrity is not guaranteed in this situation and programs with Read access do not own records.) Since other executing programs are not waiting for records, you do not have to be concerned about releasing records for other programs to use.

If the subsystem with uUpdate access is an online subsystem, other subsystems (whether batch or online) are still restricted to Read access. However, unlike a batch subsystem, multiple programs in the Update-access online subsystem can update the database. In other words, two forms of sharing occur at once:

Database-level sharing is specified by completing the following tasks:

Under z/OS, if DBRC is not used, database integrity is compromised. DBRC is active in SAS executions of application regions as long as the value of the SAS system option IMSDLDBR= is not N.

In block-level shared access, multiple IMS subsystems allocate the database data sets concurrently. This shared allocation is possible in a single operating system with shared disposition allocation. Block-level shared access is possible between multiple operating systems regardless of the allocation disposition if the database data sets reside on shared DASD.

If the IMS requirements for block-level sharing are not followed completely, the IMS database integrity might be compromised by this multiple allocation. Make sure that you implement block-level sharing for a database before you allocate a database data set with shared disposition.

Block-level shared access differs from database-level shared access in that it guarantees both Read and Update integrity for the shared database. It is not possible for the SAS/ACCESS interface to IMS to obtain uncommitted update data that is later backed out.

A disadvantage of block-level sharing is that different subsystems must contend for database records. Therefore, synchronization-point processing becomes essential when updating a database that is shared at the block level with other IMS subsystems.

An advantage of block-level sharing over database-level sharing is that the SAS/ACCESS interface that updates does not have to wait to obtain exclusive update control of the database.

Block-level sharing is specified by completing the following tasks:

If DBRC is not active, database integrity is compromised. If DBRC was included in IMS/ESA during operating system generation, DBRC is active in SAS executions of application regions as long as the SAS system option IMSDLDBR= does not have a value of N.

Similarly, if communication with the IRLM is not established, database integrity is compromised. The IMS region establishes communication with the IRLM specified by the SAS system option IMSDLIRN= as long as the IRLM is active and the SAS system option IMSDLIRL= does not have a value of N.