Extending the life of mirror transactions (MROLRM and MROFSE)

The MROLRM system initialization parameter can have a significant effect on the performance of a workload in an MRO function shipping environment.

Setting MROLRM=NO causes the mirror to be attached and detached for each function-shipped request until the first request for a recoverable resource or a file control start browse is received. After such a request is received, the mirror remains attached to the session until the calling transaction reaches syncpoint.

Setting MROLRM=YES in a region receiving function shipping requests causes a mirror transaction to remain attached to the MRO session from first request until the calling transaction reaches syncpoint. This option causes system-dependent effects, as follows:

In general, setting MROLRM=YES is recommended.

Start of changeSetting MROFSE=YES in the front-end region prevents the mirror task in the back-end region from being terminated after syncpoint. The mirror task in the back-end region will only be terminated when the front-end task terminates.End of change

Start of changeUse of MROFSE=YES in the front-end region is not recommended when long-running tasks may be used to function-ship requests. This is because a SEND session will be unavailable for allocation to other tasks when unused. It might also prevent the connection from being released when contact has been lost with the back-end region, until the task terminates or issues a function-ship request.End of change

Related tasks
MRO and ISC: performance considerations
CICS intercommunication facilities and performance: overview
Managing queues for intersystems sessions
Using transaction classes DFHTCLSX and DFHTCLQ2 to control storage use
Controlling the length of the terminal input/output area (SESSIONS IOAREALEN) for MRO sessions
Batching requests (MROBTCH)
Controlling the deletion of shipped terminal definitions (DSHIPINT and DSHIPIDL)
[[ Contents Previous Page | Next Page Index ]]