The terms asynchronously maintained and synchronously maintained both describe a remote journal function delivery mode for journal entry replication.
If a journal is asynchronously maintained, control is returned to the application generating the journal entry on the source system without waiting for the journal entry to be replicated to the remote journal. An asynchronously maintained remote journal might lag several journal entries behind the total number of journal entries in the journal on the source system. If a journal is synchronously maintained, control is not returned to the application generating the journal entry on the local system until the journal entry is replicated to the remote journal.
Synchronous delivery means that the journal entry is replicated to the target system concurrently with the entry being written to the local receiver on the source system. The entry is known on the target system, in main storage, prior to returning control to the user application that deposited the journal entry on the source system. Therefore, the target system knows of all journal entries as they are being made in real-time on the source system. Using this mode allows for recovery without losing journal entries on the target system if the source system fails. Providing journal entries synchronously to a target system will have some affect to the journaling throughput on the local system.
Synchronous delivery mode is only supported when a remote journal is associated with a local journal.
There are certain circumstances, when using synchronous mode, when some journal entries are not immediately sent to the target system. These entries are either not necessary for recovery or the user did not specify that they be forced to disk. Journal entries are sent to the remote journal at the same time that they are forced to disk for the source journal. Since these entries are not forced to disk at deposit time, they are not sent to the remote system.
When journal caching is being used (JRNCACHE(*YES) on the CHGJRN command), entries that exist only in the cache are not available on the target system. With journal caching, entries are not sent to the target system until they are written from the cache to disk on the source system.
Replicating a journal entry asynchronously means that the journal entry is replicated to the target system after control is returned to the application depositing the journal entry on the source system. Using this mode allows for recovery that might lose some journal entries if the source system fails. However, this mode has less affect to the journal throughput on the local system in comparison with the synchronous mode.
Journal entry latency might occur when remote journals are asynchronously maintained. Journal entry latency is the difference between the journal entries that exist in the remote journal on the target system from those residing in the journal on the source system. From a recovery standpoint, the source system might be some number of journal entries ahead of what journal entries are known on the target system.