Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Autonomic DataBase Management System Locking

IP.com Disclosure Number: IPCOM000011462D
Original Publication Date: 2003-Feb-21
Included in the Prior Art Database: 2003-Feb-21
Document File: 4 page(s) / 61K

Publishing Venue



IMS and DB2 are Data Base Management Systems that provide application program access to only secure data. Data that is concurrently being changed is not available to other concurrently running programs. This isolation is provided by implementing and enforcing data locking protocols where the order of such locking guarantees the integrity of data access and change. In IMS and DB2 running on IBM's z/OS operating system, this is implemented to provide inter-processor data sharing using IRLM as the global lock manager.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 4

Autonomic DataBase Management System Locking

The problems identified here and solved autonomically deal specifically with IMS's sharing of VSAM (IBM's Virtual Storage Access Method) KSDS files (Keyed Sequential Data Sets). When inserting keyed data into a KSDS, VSAM may sometimes perform Control Interval and/or Control Area (CI and/or CA) splits which involve moving existing data from one or more CI's into one or more new CI's. The locking done by IMS to provide this data sharing is very complex because of functional limitations within VSAM. CA splits may involve what is called End-Of-Volume processing whereby a new DASD extent is added to the dataset. Such extending of the dataset must be serialized with any concurrent opening and/or closing of the dataset by sharing subsystem instances. The terminology in IMS for this serialization is called the dataset busy lock (short name ZID ).

IRLM also provides states of locks. That is, locks may be acquired compatible with other holders or exclusive from other holders. IMS acquires block locks (short name BID ) on CI's being changed by an IMS instance. That is, one IMS instance locks such that it is the only IMS instance with changes in a particular CI which is the unit of transfer between the processor and the DASD control unit or DASD device. The IMS locking strategy is such that concurrent updates by concurrent programs running or serviced by that IMS instance are allowed. That is, each such concurrently running program will obtain the BID lock compatible with other program changes in that CI within that IMS instance. Multiple concurrent units of work thus can hold a given BID lock. Again, other IMS instances can not update that CI until the as yet uncommitted units of work commit or abort their changes and write the CI back to DASD where it can be read by other sharing IMS instances.

Program and machine failures can and do occur. When a failure such as one IRLM instance abends, the IMS's connected to that IRLM directly must back out all in-flight uncommitted units of work since no new locks can be granted/acquired. The BID locks protecting those uncommitted changes must be sufficient to guarantee that restoring the data changes to their before image can be accomplished without acquiring any new locks. That is in this case that the reinsertion of deleted keyed records must not cause any CI or CA splits where serialization and new block locks would be required. To guarantee this, the locking of the BID must be such that multiple programs can each erase data in the same CI - or - multiple programs can each insert data into the same CI. A program must not be allowed to insert data into a CI using the space of an uncommited erased record thereby preventing backout of the deletion from holding to the rule above about needing new locks because backout might cause a CI split. IRLM provides 8 lock states specifiable on the lock request which allows for IMS to provide for concurrent erases or f...