Object locking: During save-while-active checkpoint processing

During checkpoint processing, these locking rules can conflict with object-level lock types of exclusive allow read (*EXCLRD); exclusive, no read (*EXCL); and share update (*SHRUPD).

Some object-level system commands and user applications can acquire these lock types. User applications that acquire these object-level locks generally conflict with save-while-active operations until the checkpoint processing is complete for the objects. User applications that use system commands that require these object-level locks also conflict with save-while-active operations until the checkpoint processing is complete for the objects. Lock conflicts can prevent the save operation from saving the object. Lock conflicts can also can prevent applications from using the object. To eliminate lock conflicts during checkpoint processing, you should end your applications until checkpoint processing is complete.

If you are saving spooled files with SPLFDTA(*ALL) specified, quiesce your spooling writers until checkpoint processing is complete. To quiesce the spooling writers, hold the output queues of each spooling writer or end the spooling writer.

In general, checkpoint processing operations prevent the following list of operations from occurring for objects you are saving.

Parent topic: Save-while-active object locking rules