Long-running mirror tasks for MRO

Normally, MRO mirror tasks are stopped as soon as possible, in the same way as described for ISC mirrors, to keep the number of active tasks to a minimum, and to avoid holding on to the session for long periods.

However, for some applications, it is more efficient to retain both the mirror task and the session until the next sync point, though this retention is not required for data integrity. For example, a transaction that issues many READ FILE requests to a remote system might be better served by a single mirror task, rather than by a separate mirror task for each request. In this way, you can reduce the overheads of allocating sessions on the sending side and attaching mirror tasks on the receiving side.

Mirror tasks that wait for the next sync point, even though they logically do not need to do so, are called long-running mirrors. They are applicable to MRO and IPIC links only. For MRO links, long-running mirror tasks are specified, on the system on which the mirror runs, by coding MROLRM=YES in the system initialization parameters. A long-running mirror is stopped by the next sync point (or RETURN) on the sending side.

For some applications, the performance benefits of using long-running mirrors can be significant.

Figure 2 and Figure 3 in Function shipping examples show how the mirror acts for MROLRM=NO and MROLRM=YES, respectively.

An additional system initialization parameter, MROFSE=YES, specified on the front-end region, extends the retention of the mirror task and the session from the next sync point to the end of the task. To achieve maximum benefit, use MROFSE=YES with MROLRM=YES on the back-end region. However, MROFSE=YES still applies if the back-end region has MROLRM=NO, if requests are of the type that cause the mirror transaction to keep its inbound session.

Conceptually, you specify MROLRM on the back-end region and MROFSE is specified on the front-end region. However, if the distinction between back end and front end is not clear, it is safe to code both parameters on each region if necessary.

MROFSE=YES gives a performance improvement only if most applications initiated from the front-end region have multiple sync points, and function shipping requests are issued between each sync point.

Do not specify MROFSE=YES in the front-end region when long-running tasks might be used to function-ship requests, because a SEND session is unavailable for allocation to other tasks when unused. If you specify MROFSE=YES, you might prevent the connection from being released, when contact has been lost with the back-end region, until the task ends or issues a function-shipped request.

Long-running mirror tasks are also available over IPIC links. The lifetime of the mirror is specified using the MIRRORLIFE attribute on the IPCONN resource definition. See Long-running mirror tasks for IPIC.