z/OS DFSMStvs Planning and Operating Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Using read integrity options in your application program

z/OS DFSMStvs Planning and Operating Guide
SC23-6877-00

DFSMStvs supports three options to control read integrity. You can specify these options in the JCL, in the ACB, or at the RPL level. Which one you choose depends on the application programming language in which your application is coded. If you specify different read integrity options, the RPL specification overrides the ACB, which overrides the JCL. If you do not specify an option, no read integrity (NRI), the default option, is in effect. The read integrity options are as follows:
NRI (no read integrity)
There is no read integrity and shared locks are not used for read requests. This is the default.
CR (consistent read)
A request to read a record is queued if the record is being updated by another task. The read completes only when the update is complete, and the updating unit of recovery relinquishes exclusive control by issuing a sync point. Specifying CR ensures that your applications do not see uncommitted data. However, it is possible that another application could modify the record after it has been read, but before your application has finished its operations on the record.
CRE (consistent read explicit)
Processing of the read request is the same as for consistent read requests. However, in this case, the reader holds on to its shared lock until the next sync point. This ensures that a record read in a unit of recovery cannot be modified while the unit of recovery makes further read requests. It is particularly useful when issuing a series of related read requests to ensure that none of the records are modified before the last record is read. This option is also known as a repeatable read.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014