CICS® supplies a number of mirror transactions, some of which correspond to "architected processes" (see Architected processes). Details of the supplied mirror transactions are given in Defining local resources. In the rest of this book, they are referred to generally as the mirror transaction, and given the transaction identifier 'CSM*'.
The following description of the mirror transaction and the transformer program is generally applicable to both ISC and MRO function shipping. There are, however, some differences in the way that the mirror transaction works under MRO, and a different transformer program is used. These differences are described in MRO function shipping.
The mirror transaction executes as a normal CICS transaction and uses the CICS terminal control program facilities to communicate with the requesting system.
In the requesting system (CICA in Figure 5), the command-level EXEC interface program (for all except DL/I requests) determines that the requested resource is on another system (CICB in the example). It therefore calls the function-shipping transformer program to transform the request into a form suitable for transmission (in the example, line 2 indicates this). The EXEC interface program then calls on the intercommunication component to send the transformed request to the appropriate connected system (line 3). For DL/I requests, part of this function is handled by CICS DL/I interface modules. For guidance about DL/I request processing, see the CICS IMS™ Database Control Guide.
The intercommunication component uses CICS terminal control program facilities to send the request to the mirror transaction. The first request to a particular remote system on behalf of a transaction causes the communication component in the local system to precede the formatted request with the appropriate mirror transaction identifier, in order to attach this transaction in the remote system. Thereafter it keeps track of whether the mirror transaction terminates, and reinvokes it as required.
The mirror transaction uses the function-shipping transformer program, DFHXFP, to decode the formatted request (line 4 in Figure 5). The mirror then executes the corresponding command. On completion of the command, the mirror transaction uses the transformer program to construct a formatted reply (line 5). The mirror transaction returns this formatted reply to the requesting system, CICA (line 6). On CICA the reply is decoded, again using the transformer program (line 7), and used to complete the original request made by the application program (line 8).
If the mirror transaction is not required to update any protected resources, and no previous request updated a protected resource in its system, the mirror transaction terminates after sending its reply. However, if the request causes the mirror transaction to change or update a protected resource, or if the request is for any DL/I program specification block (PSB), it does not terminate until the requesting application program issues a synchronization point (syncpoint) request or terminates successfully. If a browse is in progress, the mirror transaction does not terminate until the browse is complete.
When the application program issues a syncpoint request, or terminates successfully, the intercommunication component sends a message to the mirror transaction that causes it also to issue a syncpoint request and terminate. The successful syncpoint by the mirror transaction is indicated in a response sent back to the requesting system, which then completes its syncpoint processing, so committing changes to any protected resources. If DL/I requests have been received from another system, CICS issues a DL/I TERM request as a part of the processing resulting from a syncpoint request made by the application program and executed by the mirror transaction.
The application program may access protected or unprotected resources in any order, and is not affected by the location of protected resources (they could all be in remote systems, for example). When the application program accesses resources in more than one remote system, the intercommunication component invokes a mirror transaction in each system to execute requests for the application program. Each mirror transaction follows the above rules for termination, and when the application program reaches a syncpoint, the intercommunication component exchanges syncpoint messages with any mirror transactions that have not yet terminated. This is called the multiple-mirror situation.
The mirror transaction uses the CICS command-level interface to execute CICS requests, and the DL/I CALL or the EXEC DLI interface to execute DL/I requests. The request is thus processed as for any other transaction and the requested resource is located in the appropriate resource table. If its entry defines the resource as being remote, the mirror transaction’s request is formatted for transmission and sent to yet another mirror transaction in the specified system. This is called a chained-mirror situation. To guard against possible threats to data integrity caused by session failures, it is strongly recommended that the system designer avoids defining a connected system in which chained mirror requests occur, except when the requests involved do not access protected resources, or are inquiry-only requests.
For MRO function shipping, the operation of the mirror transaction is slightly different from that described in the previous section.
Normally, MRO mirror tasks are terminated as soon as possible, in the same way as described for ISC mirrors (see ISC function shipping). This is 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 syncpoint, even though this is not required for data integrity. For example, a transaction that issues many READ FILE requests to a remote system may 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 syncpoint, even though they logically do not need to do so, are called long-running mirrors. They are applicable to MRO links only, and are specified, on the system on which the mirror runs, by coding MROLRM=YES in the system initialization parameters. A long-running mirror is terminated by the next syncpoint (or RETURN) on the sending side.
For some applications, the performance benefits of using long-running mirrors can be significant.
Figures Figure 7 and Figure 8 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 syncpoint to the end of the task. To achieve maximum benefit, MROFSE=YES should be used in conjunction with MROLRM=YES on the back-end region. However, MROFSE=YES applies even if the back-end region has MROLRM=NO, if requests are of the type which cause the mirror transaction to keep its inbound session.
Conceptually, MROLRM is specified 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 syncpoints and function shipping requests are issued between each syncpoint.
CICS uses a special transformer program (DFHXFX) for function shipping over MRO links. This short-path transformer is designed to optimize the path length involved in the construction of the terminal input/output areas (TIOA) that are sent on an MRO session for function shipping. It does this by using a private CICS format for the transformed request, rather than the architected format defined by SNA.
CICS uses the short-path transformer program (DFHXFX) for shipping file control, transient data, temporary storage, and interval control (asynchronous processing) requests. It is not used for DL/I requests. The shipped request always specifies the CICS mirror transaction CSMI; architected process names are not used.
The remote mirror (server) task, and the task executing the program that issued the request (client task), will share a common transaction scope unless the request was one of the following requests.
If the server task performed recoverable work as part of such a common transaction scope then, even though an error or abend was encountered, that work will be committed or backed out under the control of the syncpoint processing of the client task. The default action is for the error or abend to cause abnormal termination of the client task and back out of all recoverable updates made by both the client and server programs
However, in common with purely local execution (ie when not using function-shipping or distributed program link), the application program that issued the request that was function-shipped might attempt to handle the error or abend. The handle logic will subsequently issue an EXEC CICS SYNCPOINT , SYNCPOINT ROLLBACK, RETURN or ABEND command. Attempting a SYNCPOINT or RETURN, (rather than a SYNCPOINT ROLLBACK or ABEND), despite being informed of the error or abend, will attempt to commit the client program's local resource updates and those performed by the server transaction before the error or abend was encountered.
If the error or abend encountered by the mirror transaction can not be handled by the mirror program and this causes the termination and backout of the mirror transaction without sending a response to the client application, then CICS will force the client program's transaction to back out. Any explicit syncpoint attempt will fail and the local updates will be backed out. This is also true if a problem is encountered with the communications link between the client and server tasks.
If the client and server tasks do not share a common transaction scope, as described previously, then errors or abends that result in the termination of the server task, and problems with the communications link, do not force the client's transaction to back out.