Save-while-active object locking rules

 

The object locking rules that the system uses for save-while-active requests are less restrictive than the rules it uses for other save operations.

These object locking rules allow users to perform update operations and use most object-level commands after the system performs checkpoint processing. Generally, the system keeps a shared, no update (*SHRNUP) lock on the objects through the checkpoint processing. After the establishes checkpoints, the system unlocks most of the objects. Other objects remain allocated with a shared for read (*SHRRD) lock.

The following table shows the locks a normal save operation holds, by a save-while-active operation during checkpoint processing, and by a save-while-active operation after checkpoint processing is complete.

---

Table 1. Lock Type Needed for Save Operation

		Save-While-Active
Object Type	SAVACT(*NO)	Establish Checkpoint	After Checkpoint
Most object types	*SHRNUP	*SHRNUP	None
Configuration object	None	1	1
Data area	*SHRNUP	*SHRRD	None
Database members	*SHRNUP	*SHRRD	None
Document	*SHRNUP	*SHRRD	None
Folder	*SHRRD	*SHRRD	None
Job queue	*SHRRD	*SHRRD	None
Journal	*SHRRD	*SHRRD	None
Journal receiver	*SHRRD	*SHRRD	*SHRRD
Library, when the library or an object in it is being saved	*SHRUPD	*SHRUPD	*SHRRD
Output queue	*SHRRD	*SHRRD	None
Product load	*SHRNUP	*SHRNUP	*SHRRD
Spooled file	*EXCL	*EXCL	5
System resource management object	*SHRNUP	1	1
User profiles, authorization lists, and authority holders	*SHRRD	1	1
Object, if STG(*FREE) is specified	*EXCL2	1	1
Objects in directories	Share with readers	Share with readers3, 4	Share with readers and writers3
1 The save-while-active function is not available when saving these objects. 2 Applies to document, file, journal receiver, module, program, SQL package, and service program. Other types remain as listed previously. 3 Objects in QNTC are not synchronized with SAVACT(*SYNC). Furthermore, all locks for these file systems will be released before the checkpoint message is sent. 4 Objects that are saved with SAVACTOPT(*ALWCKPWRT) and have the QP0L_ATTR_ALWCKPWRT system attribute set, have an implied share with readers and writers lock. 5 A lock is held that prevents another save action against the spooled file. All other spooled file actions, such as displaying, copying, deleting, and printing, are allowed.

---

These locking rules pertain to object-level locks and not database record-level locks. The locking rules allow the opening and closing of database file members and any record-level I/O operations to database file members during any phase of the save-while-active operation.

• 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).

• Object locking: After save-while-active checkpoint processing
  After completing checkpoint processing, an attempt to perform one of the operations that are listed in this topic will result in a message stating that the library is in use.

 

Parent topic:

Considerations and restrictions for the save-while-active function

Related concepts
Save-while-active restrictions