Ü Lock
states for objects
A lock state identifies the use of the object and whether it is
shared.
Ø Exclusive
(*EXCL). The object is reserved for the exclusive use of the requesting job;
no other jobs can use the object. However, if the object is already allocated
to another job, your job cannot get exclusive use of the object. This lock
state is appropriate when a user does not want any other user to have access to
the object until the function being performed is complete.
Ø Exclusive
allow read (*EXCLRD). The object is allocated to the job that requested it, but other jobs
can read the object. This lock is appropriate when a user wants to prevent
other users from performing any operation other than a read.
Ø Shared
for update (*SHRUPD). The object can be shared either for update or read with another job.
That is, another user can request either a shared-for-read lock state or a
shared-for-update lock state for the same object. This lock state is
appropriate when a user intends to change an object but wants to allow other
users to read or change the same object.
Ø Shared
no update (*SHRNUP). The object can be shared with another job if the job requests either
a shared-no-update lock state, or a shared-for-read lock state. This lock state
is appropriate when a user does not intend to change an object but wants to
ensure that no other user changes the object.
Ø Shared
for read (*SHRRD). The object can be shared with another job if the user does not
request exclusive use of the object. That is, another user can request an
exclusive-allow-read, shared-for-update, shared-for-read, or shared-no-update
lock state.
Table 31. Valid lock state combinations
If one job obtains this lock state: | Another job can obtain this lock state:
*EXCL None
*EXCLRD *SHRRD
*SHRUPD *SHRUPD or *SHRRD
*SHRNUP *SHRNUP or *SHRRD
*SHRRD *EXCLRD, *SHRUPD, *SHRNUP, or *SHRRD