System journal files are used primarily for:

• system recovery (recovery journals and synchronization point journals)
• system tuning (statistical journals)
• providing information about UAPs (user journals)

The recovery and synchronization point journals store system-history information necessary either for a complete recovery when the online system stops, or for a partial recovery when a UAP transaction terminates because of an error. A complete recovery requires both of the following:

• checkpoint dump of the latest generation (described in 4.2.3 System files: checkpoint dump files)
• recovery journals that were obtained after collecting the checkpoint dump of the latest generation

Partial recovery of a UAP transaction requires only the recovery journals and does not require the checkpoint dump.

In addition to the journals used for recovery, the system collects various system statistics (the statistical journals), which can be used for checking and tuning the online system; and user journals, which consist of information concerning a specific UAP.

As with the status files, the information in a system journal can be duplicated within a system journal. A system journal file is thus a logical filegroup, consisting of a pair of physical files: physical file A and physical file B. In such a case, OpenTP1 obtains the same journal information for physical file A and physical file B. This increases reliability because when a journal must be read because of some abnormality, even if one of the physical files is corrupted, the journal can be read from the other physical file.

To avoid the possibility that both physical files in a system journal file could be corrupted at the same time, place physical file A and physical file B on different disks if possible. It is preferable, but not necessary, for physical file A and physical file B to be the same size. It is preferable because a larger physical file cannot store a journal that exceeds the size of the smaller file.

In the system journal service definition, you must specify at least two logical filegroups (Figure 4-6). When defining a logical filegroup, you also define which physical files make up the logical filegroup. You can assign any name to a logical filegroup. Specifying a name for the logical filegroup enables you to manipulate both physical files in the logical file as a group: for example, both physical file A and physical file B can be opened or closed at the same time.

Usually, if a failure occurs in one physical file of a system journal file during online operation and no standby logical filegroup is found, OpenTP1 terminates abnormally. In the system journal service definition, however, you can specify whether to permit OpenTP1 to continue operation using the one normal physical file (either physical file A or B) only. When operating with only one physical file in a system journal file is permitted, a logical filegroup can be used as long as at least one of the two physical files that make up the filegroup is active. When operating with only one physical file is prohibited, a logical filegroup can be used only when both physical files are active.

For example, suppose there are two filegroups fg1 and fg2, consisting of the physical files fg1a, fg1b, fg2a, and fg2b. An error in a physical file is often caused by a failure in the disk device itself, and often all the physical files on the disk are damaged as a result. When operation with only one physical file is prohibited, if both physical files fg1a and fg2a in system A are damaged, there is no available filegroup and OpenTP1 terminates abnormally. After the problem is remedied, a complete system recovery will be required. When operation with only one physical file is permitted, as long as physical files fg1b and fg2b in system B are still operable, the filegroup will be available and OpenTP1 can continue operation.

As this example illustrates, when operation with only one physical file is permitted, if one system fails, operation can continue on the other system until the problem is remedied. Note, however, that the temporary loss of redundancy between system journal files impacts on the system's reliability. Specify in the system journal service definition whether to permit or prohibit operation with only one physical file. Whether operation with only one physical file is permitted is specified in the system journal service definition.

The following figure shows the difference between the two options.

Figure 4-6 Permitting and prohibiting operation with only one physical file

A system journal file can be configured as a filegroup containing two or more element files. This facility is known as the parallel access facility for system journal files. The following figure illustrates two filegroups configured redundantly using the parallel access facility.

Figure 4-7 Filegroup configuration using the parallel access facility (jnl_max_file_dispersion=3)

The following figure provides an overview of the parallel access facility.

Figure 4-8 Overview of the parallel access facility (jnl_max_file_dispersion=3)

With constant input and output to a system journal file, the disk load increases and I/O performance can deteriorate. In this situation, configuring a number of element files in a filegroup allows the system journal file to be accessed in parallel, raising the journal I/O performance.

The physical files that make up a filegroup can use the same SCSI interface and hard disk. However, this means that the files cannot be accessed in parallel, and the parallel access facility cannot be used to best effect. Therefore, a different SCSI interface and hard disk should be used for each physical file. The files do not need to be the same size, but if they are different, OpenTP1 regards the size of the smallest physical file as the size of all the element files. To use resources effectively, we recommend that you use physical files of the same size if at all possible.

When using the parallel access facility for system journal files, the number of element files that can be accessed in parallel (hereafter referred to as the number of parallel accesses) decreases if, for example, an error occurs in the system journal file. To prevent journal I/O performance from declining as a result of having too few element files, you can specify a minimum guaranteed number of parallel access files. This is known as the minimum dispersed files for parallel access. You can also specify the maximum dispersed files for parallel access, which indicates the maximum number of element files that can be accessed in parallel.

Specify the element file names when specifying a filegroup in the system journal service definition. Specify the maximum dispersed files for parallel access in the jnl_max_file_dispersion operand and the minimum dispersed files for parallel access in the jnl_min_file_dispersion operand.

(a) Contents of synchronization point journals

At a complete recovery or UAP partial recovery, the consistency of resources must be assured by performing commit or rollback operations for any undetermined transactions. For such commit or rollback operations, OpenTP1 obtains information about whether a transaction determination is completed or how far the processing at a synchronization point had proceeded. This history information is called a synchronization point journal and is used to decide whether OpenTP1 must perform recovery operations for the resource.The synchronization point journals are named BJ, DJ, HJ, PJ, and TJ. They are described in the following table.

Table 4-5 Synchronization point journals

Type	Description
PJ	A journal output when the root transaction branch or a transaction branch starts commit processing.
HJ	A journal output when a transaction branch becomes ready to start commit processing. This journal is not output for the root transaction branch.
BJ	A journal output when a transaction is rolled back. This journal is output for the root transaction branch and transaction branches.
TJ	A journal output when synchronization point processing of a transaction is terminated. This journal is output for the root transaction branch and transaction branches.
DJ	A journal output when the heuristic decision of a transaction is performed. This journal is output for the root transaction branch and transaction branches.

(b) Contents of recovery journals

In a complete recovery or partial recovery, OpenTP1 first examines the synchronization point journal to determine whether any resources must be recovered. If resources must be recovered, OpenTP1 first recovers databases and system and other tables. OpenTP1 obtains the necessary update information for the resources from the recovery journals. The recovery journals are named CJ and FJ. They are described in the following table.

Table 4-6 Recovery journals

Type	Description
FJ	Consists of update information for DAM files. DAM files are recovered using this FJ recovery journal during a complete recovery or partial recovery.
CJ	Consist of update information for recovery target tables managed by the MCF and TAM services. The CJ recovery journal is obtained, for example, at a synchronization point. The complete recovery of a table uses this CJ recovery journal.
	Consist of update information for recovery target tables managed by the transaction management service. The CJ recovery journal is obtained, for example, at a synchronization point. Entire recovery of a table during a complete recovery uses this CJ recovery journal.

(c) Contents of statistical journals

Statistical journals contain information for tuning the system. Statistical journals (AJ, GJ, IJ, OJ, MJ, and SJ) are necessary to tune the system.

Of the statistical journals, information for AJ, GJ, IJ, MJ, and OJ is obtained only when OpenTP1 uses MCF to exchange messages with another system. You can use commands to start (mcftactmj command) and end (mcftdctmj command) obtaining information for MJ. In the application attribute definition for each application of an MHP, you can define whether or not to obtain information for GJ, IJ, and OJ. In the logical terminal definition for each logical terminal, you can specify whether to obtain information for AJ.

SJ contains statistics for the entire OpenTP1 system: these statistics include system statistics and transaction statistics. The system statistics are obtained at a user-specified interval after entering the command dcstats. In the transaction service definition, you can define whether to obtain the transaction statistics. Statistical journals are listed in the following table.

Table 4-7 Statistical journals

Type	Description
MJ	Message input information before editing the input, and message output information after editing the output.
IJ	Message input information obtained immediately before a received message is stored in the input queue.
GJ	MHP receive information obtained immediately before MHP receives a message with the segment-receiving function (i.e., with the dc_mcf_receive() C function or the equivalent COBOL subprogram).
OJ	Message output information obtained immediately after a send message is placed in the output queue.
AJ	Transmission-completion information obtained immediately after a transmission-completed message is received from another system in response to a message sent earlier to that other system.
SJ	Statistics of OpenTP1 activities allowing the user to examine the OpenTP1 operation status. The SJ journal contains both system statistics and transaction statistics. The system statistics cover the system service and UAPs. The status of OpenTP1 can be obtained at set intervals. The transaction statistics cover the processing over transactions. The transaction statistics are obtained when synchronization point processing is completed for each transaction branch.

(d) Contents of user journals

OpenTP1 provides the dc_jnl_ujput() function to enable a user journal to be stored in a system journal file. The user journal (UJ) is used for system tuning or for collecting information about the user's application. The user journal can be output inside or outside a transaction.

For details about how to obtain a user journal, see the OpenTP1 Programming Guide.

The filegroup of system journal files is either available or unavailable for journal output:

• Available
  The number of opened physical files in a filegroup is greater than the required number. The required number of physical files is determined according to the value specified in the system journal service definition. Available filegroups are current or standby.
  
• Unavailable
  The number of opened physical files in a filegroup is less than the required number. Unavailable filegroups are also called reserved.
  

Filegroups are managed as having current or standby status if available for journal output, or in reserved status if unavailable for journal output. The required number of element files is determined by the value specified in the system journal service definition.

• Current
  An available filegroup which is the current destination of journals to be output. There is always only one current filegroup.
  
• Standby
  An available filegroup which is not currently the destination of journals to be output but is waiting to be switched to become current. The two standby statuses are:
  
  • Ready to be the next swap destination:
    A standby filegroup that can be overwritten (there is no journal that is required for system recovery) and is already unloaded.
    
  • Not ready to be the next swap destination:
    A standby filegroup that cannot be overwritten or is waiting to be unloaded.
    
• Reserved
  An unavailable filegroup.
  

A system journal file requires at least two filegroups other than the reserved filegroups.

When OpenTP1 starts normally, all the filegroups specified as ONL, among the filegroups specified in the system journal file service definition, are opened. Among the opened filegroups, the first filegroup that is specified becomes the current filegroup; other filegroups become the standby filegroups. A filegroup that has fewer physical files than the required number or a filegroup that is not specified as ONL becomes a reserved filegroup.

In a system journal file, journals are always output to the current filegroup. If the current filegroup becomes full, one of the standby filegroups becomes the current filegroup. The previous current filegroup becomes one of the standby filegroups. If all the available filegroups become full, journals are again output to the first filegroup.

The journals in a standby system journal file must be copied to another file. This copying is called unloading. To unload a system journal file, use the jnlunlfg command. Alternatively, specify Y in the jnl_auto_unload operand of the system journal service definition to enable automatic unloading. The file to which a standby system journal file is unloaded is called an unloaded-journals file (or, in some manual versions, an unload journal file).

In an unload check, OpenTP1 checks whether or not the journals in a logical filegroup have been unloaded. If the journals have not been unloaded yet, OpenTP1 does not swap the filegroup with the current filegroup. If there is no swappable standby system file, OpenTP1 terminates abnormally. For the processing in this case, see 5.3 Failure and error recovery.

(a) Restraining an unload check

The standby filegroup, which is usually in the unload wait status, can be specified to be used as is. This is called an unload check restraint. When restraining an unload check, specify N in the jnl_unload_check operand in the system journal service definition.

If the unload check is restrained, do not unload the journal files using a command during the operation of OpenTP1. If an unload is performed by specifying an unload check restraint, unload the file after the concerned files are once closed by the jnlclsfg command.

When the unload check is restrained, neither journal edit command jnlcolc command nor jnlstts command can be executed as input of an unload journal file, because the unload journal file cannot be created.

If an unload check is restrained, the unload wait status may be output when confirming the filegroup status using the jnlls command. Even if the unload wait status is output, the current filegroups are actually used.

In a system journal swap the current logical filegroup becomes a standby logical filegroup, and a standby logical filegroup becomes the current logical filegroup. Not all standby logical filegroups are eligible to be swapped in as the current filegroup. A standby filegroup whose journals have not been unloaded yet or a standby filegroup that contains a journal necessary for recovery cannot be swapped with the current filegroup. See 4.2.3(4) Multigeneration Guarantee facility for details about checking whether a system journal filegroup contains a journal necessary for recovery.

If there are no swappable files, OpenTP1 terminates abnormally. For the processing in this case, see 5.3 Failure and error recovery.

Figure 4-9 shows the conditions on swapping system journal filegroups.

Figure 4-9 Swapping system journal filegroups

When performing a complete recovery after an error occurs during online processing, OpenTP1 outputs journals that are used for transaction determinations. In such a case, if the opened system journal filegroups cannot store more journal information, OpenTP1 terminates abnormally again.

If there are too few journal filegroups opened at complete recovery, reserved filegroups can be opened to store the journals. In the system journal service definition you can define whether or not reserved filegroups are to be opened. If there is a swappable system journal filegroup that can be overwritten after its contents are unloaded, reserved filegroups are not opened. Unload the journal by the command jnlunlfg.