It is important to select the correct isolation level while browsing DB2 table data in order to ensure that other users of the same data are not disrupted unless there is a valid reason to hold the data. Upon connection to a DB2 database, the isolation level used determines the scope of data integrity and concurrency. A stronger isolation level leads to increased data integrity, while a weaker isolation level leads to more concurrency and better performance. A weaker isolation level also reduces row locking, so the incidence of deadlock situations is minimised.

Background:

The R20 release of CA RC/Query for db2 for z/os provides a new ability to specify the isolation level used by users that are browsing DB2 tables.Cursor stability (CS) and uncommitted read (UR) are supported at the global and user level. Being able to specify the isolation level prevents queries from locking the table rows when the table rows are being read and changed simultaneously by multiple users.The isolation level is appended to the SELECT statement used while browsing using the WITH clause. For example, WITH CS or WITH UR.

Environment:

DB2 for Z/OS

Instructions:

All users at a site are provided with a new parameter named ISOLATN that has been added to the RCEDIT parmlib member in the hlq.CDBAPARM data set. CS - CURSOR STABILITY is the default.

Individual users can set a new Isolation Level parameter for RC Browse in the RC/Edit Parameters panel. If left blank (the default), the global level setting from the hlq.CDBAPARM(RCEDIT) member is used. The individual user settings in the RC/Edit Parameters panel are saved on the users own ISPF profile dataset for the users next session.