JOURNAL and NOJOURNAL: Specifying whether to write updated control data set records in the journal data set

Explanation: JOURNAL and NOJOURNAL are mutually exclusive, optional parameters specifying whether MCDS data set records, BCDS data set records, and OCDS data set records are written in the journal data set when DFSMShsm updates the control data sets. If the MCDS, BCDS, or OCDS is lost or damaged, you can use the journal data set with a backup copy of the control data set to recreate the affected control data set.

JOURNAL specifies that DFSMShsm write the BCDS, MCDS, and OCDS data set records in the journal data set when DFSMShsm updates them.

Subparameter	Explanation
SPEED	JOURNAL(SPEED) specifies that the module making the change should wait only until the journaling request has been added to the journaling queue. When you use SPEED, DFSMShsm does not wait long, because of the following reasons: The journal task has the highest dispatching priority among all DFSMShsm tasks. The journal entries are not blocked. In each DFSMShsm host, the journal entries are written in the order they are created. The task probably does not lose more than one entry if the system fails, unless you allocate the journal data set on a volume that is used often.
RECOVERY	JOURNAL(RECOVERY) specifies that the module making the change should wait until the journal entry has been written in the journal data set. DFSMShsm writes each record as it receives the record. Therefore, not more than one entry can be lost if DFSMShsm abnormally ends. After DFSMShsm has updated the affected control data set and has written each journal data set entry, DFSMShsm continues processing.

Subparameter

Explanation

SPEED

JOURNAL(SPEED) specifies that the module making the change should wait only until the journaling request has been added to the journaling queue. When you use SPEED, DFSMShsm does not wait long, because of the following reasons:

The journal task has the highest dispatching priority among all DFSMShsm tasks.
The journal entries are not blocked.
In each DFSMShsm host, the journal entries are written in the order they are created.

The task probably does not lose more than one entry if the system fails, unless you allocate the journal data set on a volume that is used often.

RECOVERY

JOURNAL(RECOVERY) specifies that the module making the change should wait until the journal entry has been written in the journal data set. DFSMShsm writes each record as it receives the record. Therefore, not more than one entry can be lost if DFSMShsm abnormally ends. After DFSMShsm has updated the affected control data set and has written each journal data set entry, DFSMShsm continues processing.

NOJOURNAL specifies that DFSMShsm is not to write the updated BCDS, MCDS, and OCDS records in the journal data set.

SMS relationship: Parameter has the same meaning when applied to SMS-managed or non-SMS-managed DASD volumes or data sets.

SETSYS default: If you specify JOURNAL without a subparameter, the SETSYS default is SPEED.

DFSMShsm default: If you do not specify this parameter on any SETSYS command, the DFSMShsm default is JOURNAL(SPEED).

Note:

The SPEED option queues the journal updates to be written as soon as possible, but the requesting task does not wait for the journal entry to be written. This can cause ABEND878, ABEND80A, or ABEND106-C during heavy journaling activity, if the logging task cannot keep up with the journaling load. This can happen if the ARCILOG task gets tied up during I/O to the DASD data set. If DFSMShsm should be abnormally terminated while running this option, all journal updates not yet written will be lost.
If JOURNAL(RECOVERY) is specified and DFSMShsm senses it is waiting too long for the journal entry to be written, DFSMShsm stops its wait and leaves the request on the journaling queue. This temporary return to SPEED mode helps prevent lockouts caused by resource contention.
DFSMShsm does not write updated entries from the BCDS, MCDS, and OCDS unless you include a JCL DD statement for the journal data set in the DFSMShsm startup procedure.
DFSMShsm nulls the journal data set every time DFSMShsm successfully backs up the control data sets.
When defined as a large format data set, the DFSMShsm journal can exceed 65,535 tracks per volume. For information about defining the DFSMShsm journal, see z/OS DFSMShsm Implementation and Customization Guide.