What is meant by object lock requests,held locks and locks waiting to be applied (wrkobjlck)

An object lock is a type of status and usage indicator that is associated with an object. It tells when processes are using the object and can tell something about how the object is being and how other processes may use the object.

An established lock is used by new processes that want to use the object. The new process can test the lock to see if the object can be read or changed. When a process establishes a lock, it says that other processes may read or may change the object at the same time or that no other process may access the object at all.

The type of lock is what determines if other processes can use the object (during the time the lock exists) or if other processes can change the object. For example, if a process establishes an *EXCL (exclusive) lock on an object, then no other process is allowed to access the object until the *EXCL lock is released.

Locks can be explicitly or implicitly set or released. The most common way to set a lock explicitly is with the ALCOBJ (Allocate Object) command. The lock may then be explicitly released with the DLCOBJ (Deallocate Object) command. A lock will be implicitly set whenever you access an object; e.g., changing an object’s authorities or ownership will implicitly set an exclusive lock while the change is being made. Opening a file to read it will implicitly set a “read” lock which will prevent another process from setting an exclusive lock but will allow other processes to also read the same file. When the file is closed, the “read” lock is implicitly released. When any job ends, all locks held by that job are implicitly released.

There are combinations of locks and accesses that are allowed. The Locked objects subtopic in Work Management gives a general description of how a type of object lock can match up with types of allowed accesses.

Ideally, a lock should be set just before the object is needed and should be released as soon as the object is no longer in use. This gives the maximum amount of time for other processes also to use the same object. Locks are usually requested with a time limit for setting the lock. If the lock can’t be set before the time runs out, an exception is signaled to the requesting process. The exception tells the process that some other process is using the object. This lets you write programs that can adapt to changing circumstances.

A requested lock might not be granted immediately. Another process might already have a conflicting lock. In that case, the request will remain until it can be granted or until the time limit expires. Many different processes might be requesting locks, and each one would be processed in its turn.

You might be creating a CL program that will be backing up a series of objects with the SAVOBJ command. There are two general approaches you can take with regard to locks. You can execute the SAVOBJ command and see if it succeeds, or you can execute ALCOBJ first to find out if the object is available before running SAVOBJ.

Why should we apply for locks.

Locks will be established no matter what. The question should be whether or not you should explicitly apply for (request) a lock and what kind of lock should be requested.

You would request a lock when you want to know ahead of time whether or not an object will be available for what you want to do. If you can’t get the lock before your time limit runs out, your program might choose to go to sleep for a while and try again later; or it might send amessage to ask an operator what it should do.

By knowing ahead of time, you can write code that takes alternative actions.

There are a lot of details that can be discussed. Ask about details in the discussion area below if you need more.

Tom