Journal output synchronization

When a journal record is created by issuing the JOURNAL command with the WAIT option, the requesting task can wait until the output has been completed. By specifying that this should happen, the application programmer ensures that the journal record is written on the external storage device that is associated with the journal before processing continues; the task is said to be synchronized with the output operation.

The application programmer can also request asynchronous journal output. This causes a journal record to be created in an operating system file system buffer and, optionally, initiates the data output operation from the buffer to the external device, but allows the requesting task to retain control and thus to continue with other processing. The task can check and wait for output completion (that is, synchronize) at some later time by issuing the WAIT JOURNAL command.

If possible, journal transactions should write asynchronously to minimize task waits. However, if journal records must be physically written before end of task to maintain integrity, you must use a synchronous write. If several journal writes occur, the transaction should use asynchronous writes for all but the last logical record, so that the logical records for the task are written with a minimum number of physical I/O operations and only one wait. Use journals for audit purposes where the CrucialFlag attribute in the Journal Definitions (JD) ensures that all writes succeed, or in conditions in which a significant proportion of writes can be asynchronous (buffered).

The basic process of building journal records in file system buffers continues until one of the following events occurs:

When any of these occurs, all journal records that are present in the buffer, including any deferred output from asynchronous requests, are written to auxiliary storage as one block.

The advantages that can be gained by deferring journal output are:

However, these advantages are achievable only at the cost of more buffer space and greater programming complexity. It is necessary to plan and program to control synchronizing with journal output. Additional decisions that depend on the data content of the journal record and how it is to be used must be made in the application program. In any case, the full benefit of deferring journal output is obtained only when the load on the journal is high.

The STARTIO option is used in EXEC CICS® JOURNAL commands to request that the journal output operation be initiated immediately. This is the default behavior for CICS, because a write operation to file system buffers is always performed immediately, regardless of the presence or absence of the STARTIO option. Control is returned to the requesting program immediately after the record is buffered, unless the WAIT option is used, in which case the return is delayed until after the journal record has become permanent. The WAIT option should not be used unnecessarily because, if every journal request uses WAIT, no improvement over synchronous output requests (in terms of reducing the number of physical I/O operations) is possible.

If not enough file system space is available to write the journal record at the time of the request, the NOJBUFSP condition occurs. If no HANDLE CONDITION request is active for this condition, the requesting task loses control and is suspended until space becomes available again and the journal record has been written to the journal.

If the requesting task is not willing to lose control (for example, if some housekeeping must be performed before other tasks get control), a HANDLE CONDITION command should be issued. If the NOJBUFSP condition occurs, no journal record is built for the request, and control is returned directly to the requesting program at the location that is provided in the HANDLE CONDITION request. The requesting program can perform any housekeeping that is needed before it reissues the journal output request.

When using journal 1, which is the system journal on other CICS systems, it is advisable to specify a journal type identifier (JTYPEID) to distinguish between user journal record types and system journal record types.

See Journal Definitions (JD) and the JOURNAL for related information.