[v7 z/OS] UR and Concurrency

Philip Sevetson

[v7 z/OS] UR and Concurrency
Has anyone got a pointer to a good presentation/discussion on how a
UR-bound plan might be held up by a non-UR process?

We're in a situation where it's clear that this is what's happening, and
I'm guessing that it has something to do with either the claim, the IX
lock, or the mass-delete lock which I'm variously informed will occur
while a UR application is reading data. (If you're confused by this, then
you're where I'm at.)

The explanation in the DB2 Application Programming Guide is, I'm sorry to
say, typical old-IBM; they tell you what locks are taken but offer no
solid information about what it means in an application. I'm looking for
something a bit more in-depth -- doesn't have to be one of Chuck Hoover's
presentations, but longer than two paragraphs would be nice...

--Phil Sevetson
Database Administration
Wakefern Food Corporation CISD
mailto:[login to unmask email]


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

[login to unmask email]

Re: [v7 z/OS] UR and Concurrency
(in response to Philip Sevetson)
Phil,

Well, there's a basic discussion in the Admin Guide (V7) on page 684:

Restrictions on concurrent access: An application using UR isolation
cannot run
concurrently with a utility that drains all claim classes. Also, the
application must
acquire the following locks:

A special mass delete lock acquired in S mode on the target table or table
space.
A ?mass delete? is a DELETE statement without a WHERE clause; that
operation
must acquire the lock in X mode and thus cannot run concurrently.

An IX lock on any table space used in the work file database. That lock
prevents
dropping the table space while the application is running.

If LOB values are read, LOB locks and a lock on the LOB table space. If
the
LOB lock is not available because it is held by another application in an
incompatible lock state, the UR reader skips the LOB and moves on to the
next
LOB that satisfies the query.


This, and other references obtained by accessing the pdf version of the
manual and doing a search on "uncommitted" and "UR".


Lock (no relation) Lyon
Compuware Corp




Has anyone got a pointer to a good presentation/discussion on how a
UR-bound plan might be held up by a non-UR process?

We're in a situation where it's clear that this is what's happening, and
I'm guessing that it has something to do with either the claim, the IX
lock, or the mass-delete lock which I'm variously informed will occur
while a UR application is reading data. (If you're confused by this, then
you're where I'm at.)

The explanation in the DB2 Application Programming Guide is, I'm sorry to
say, typical old-IBM; they tell you what locks are taken but offer no
solid information about what it means in an application. I'm looking for
something a bit more in-depth -- doesn't have to be one of Chuck Hoover's
presentations, but longer than two paragraphs would be nice...

--Phil Sevetson
Database Administration
Wakefern Food Corporation CISD
mailto:[login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm