If there is a create entry or delete entry in the range of journal entries to which you are applying journaled changes, changes to a directory can cause the creation or deletion of an object.
If you are journaling a directory using the Journal new files and folders (INHERIT(*YES)) option and an object is created into that directory, the system automatically starts journaling that new object and deposits associated create and start journal object journal entries. The apply of these create and start journal entries during the apply operation on the directory then creates the objects and starts journaling for them during the apply operation. For any subsequent journaled entries for that object, the apply operation applies any entries that it encounters for that object as well. Similarly, if an entry is encountered which deletes (unlinks) an integrated file system object, that object is actually deleted as part of the apply operation.
Additionally, the apply operation will start journaling for any integrated file system journal entry that adds a link to the journaled directory, such as moving a nonjournaled object into the journaled directory, or adding a new hard link to a nonjournaled object into this journaled directory. However, no entries will be applied to these objects since the state of those objects is not fully know during the apply.
As objects are created, they are included in the maximum number of objects which can be applied as part of one Apply Journaled Changes (APYJRNCHG) request.
When you apply journaled changes, you can use the Object Error Option (OBJERROPT) of the APYJRNCHG command to specify how the system responds to errors. If you specify *CONTINUE, the system stops applying changes to the object that encounters an error, but continues the apply operation for the remaining objects.
For integrated file system objects, the system processes errors for directory-level operations separately from object-level operations. For example, you perform an apply journaled changes operation for a directory and a stream file in that directory. During the apply operation, an error occurs for the stream file and the apply process ends for that stream file. You might expect some operations that are associated with that stream file, such as remove link, to end also. But since remove link is a directory level operation, the remove link operation still occurs, even though the apply operation ended for that stream file.
Therefore even though object-level operations for an object might end, directory-level operations that are associated with that object still occur.
Many journaled integrated file system operations use system initiated commitment control for the duration of the operation. These operations are not considered completed successfully unless the commitment control cycle is committed. Commitment control, here, refers to commitment control that the system initiates. Integrated file system operations cannot be included in a user initiated commitment control cycle.
For integrated file system journal entries that are part of a commitment control cycle, do not apply individual entries from within the cycle without applying the entire commit cycle. Using the Commit Boundary (CMTBDY(*YES)) parameter on the APYJRNCHG command can help enforce this. If you do not use this option and choose a specific starting point, start from the Start of commit cycle (C SC) entry for that cycle. Likewise, if you choose to end applying a journaled change at a specific point, end on the Commit (C CM) or Rollback (C RB) entry for that cycle.
See Actions of applying or removing journaled changes by journal code for what operations are applied for integrated file system related journal entries.