Advanced Details about Save-While-Active Locks on Objects

Resolving The Problem

Generally, a shared, no update (*SHRNUP) lock is kept on the objects through the checkpoint processing. After the checkpoints have been established, most of the objects are unlocked. Other objects remain allocated with a shared for read (*SHRRD) lock.

Object Type	SAVACT(*NO)	Checkpoint	After Checkpoint
Most object	*SHRNUP	*SHRNUP	None
Configuration	None	1	1
Data area	*SHRNUP	*SHRRD	None
Database mbr	*SHRNUP	*SHRRD	None
Document	*SHRNUP	*SHRRD	None
Folder	*SHRRD	*SHRRD	None
Job queue	*SHRRD	*SHRRD	None
Journal	*SHRRD	*SHRRD	None
Journal rcvr	*SHRRD	*SHRRD	*SHRRD
Library or object in LIB	*SHRUPD	*SHRUPD	*SHRRD
Library or object in LIB	*SHRUPD	*SHRUPD	*SHRRD
Output queue	*SHRRD	*SHRRD	None
Spooled File *(V5R4 and above)	*EXCL	*EXCL	5
Product load	*SHRNUP	*SHRNUP	*SHRRD
SRM	*SHRNUP	1	1
User profiles, authorization lists, and authority holders	*SHRRD	1	1
Object, if STG(*FREE)	*EXCL 2	1	1
Objects in directories	Share with readers	Share with readers 3, 4	Share with readers and writers 3

Legend:

1.	The save-while-active function is not available when saving these objects.
2.	This applies to documents, files, journal receivers, modules, programs, IBM® SQL/400® packages, and service programs. Other types remain as listed previously.
3.	Objects in QLANSrv and QNetWare 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 the 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.

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). These lock types can be acquired by user applications and some object-level system commands. User applications that acquire these object-level locks or use system commands that require these object-level locks generally conflict with a save-while-active operation until the checkpoint processing is complete for the objects. Lock conflicts can prevent the object from being saved, or they can prevent applications from using the object. To eliminate lock conflicts during checkpoint processing, end your applications until checkpoint processing is complete. In general, during checkpoint processing, the system prevents the following list of operations from occurring for objects being saved:

o	Changing an object
o	Deleting an object
o	Renaming an object
o	Moving an object to a different library or folder
o	Changing the ownership of an object
o	Compressing or decompressing an object

The save-while-active will obtain locks down to the database member level (shared - read). Even though a record has an exclusive lock, most members allow for locks on multiple records. This means that the member will have only a shared lock and can be saved with the save-while-active function. However, there are some situations where applications will exclusively lock all of the records or the database member does not allow multiple records to be in use. This puts an exclusive lock on the member, which keeps it from being saved even during a save-while-active. This usually occurs during an allocation of an object.

Note: There is no way to estimate how long it will take to reach checkpoint. It is proportional to the number of objects and members; however, if any lock conflicts occur, it can greatly increase the time.