Overview of MRO

CICS® multiregion operation (MRO) enables CICS systems that are running in the same
MVS™ image, or in the same MVS sysplex, to communicate with each other. MRO does
not support communication between a CICS system and a non-CICS system such as
IMS™.

Note:
The external CICS interface (EXCI) uses a specialized form of MRO link to support:

• Communication between MVS batch programs and CICS

• DCE remote procedure calls to CICS programs.

ACF/VTAM and SNA networking facilities are not required for MRO. The support
within CICS that enables region-to-region communication is called interregion
communication (IRC). IRC can be implemented in three ways:

• Through support in CICS terminal control management modules and by use of a

CICS-supplied interregion program (DFHIRP) loaded in the link pack area (LPA)
of MVS. DFHIRP is invoked by a type 3 supervisor call (SVC).

• By MVS cross-memory services, which you can select as an alternative to the

CICS type 3 SVC mechanism. Here, DFHIRP is used only to open and close the
interregion links.

• By the cross-system coupling facility (XCF) of IBM® MVS/ESA™. XCF is

required for MRO links between CICS regions in different MVS images of an
MVS sysplex. It is selected dynamically by CICS for such links, if available. For
details of the benefits of cross-system MRO.

CICS regions linked by MRO can be at different release levels, If an MVS image
contains different releases of CICS, all using MRO to communicate with each other (or
XCF/MRO to communicate with regions in other images in the sysplex), the DFHIRP
module in the MVS LPA should be that from the most current CICS release in the image,
or higher. For full details of software and hardware requirements for XCF/MRO

Introduction to CICS intercommunication

Facilities available through MRO
Cross-system multiregion operation (XCF/MRO)
Applications of multiregion operation
Conversion from single-region system
Intersystem communication
Steps to install MRO

Cross-system multiregion operation (XCF/MRO)

XCF2 is part of the MVS/ESA base control program, providing high performance
communication links between MVS images that are linked in a sysplex (systems
complex) by channel-to-channel links, ESCON® channels, or coupling facility links3.
The IRC provides an XCF access method that makes it unnecessary to use VTAM® to
communicate between MVS images within the same MVS sysplex. Using XCF services,
CICS regions join a single XCF group called DFHIR000. Members of the CICS XCF
group that are in different MVS images select the XCF access method dynamically when
they wish to talk to each other, overriding the access method specified on the connection
resource definition. The use of the MVS cross-system coupling facility enables MRO to
function between MVS images in a sysplex environment, supporting all the usual MRO
operations, 4 such as:

• Function shipping

• Asynchronous processing

• Transaction routing

• Distributed program link

• Distributed transaction processing.

CICS regions linked by XCF/MRO can be at different release levels Depending on the
versions of CICS installed in the MVS images participating in XCF/MRO, the versions of
DFHIRP installed in the link pack areas of the MVS images can be different. If a single
MVS image contains different releases of CICS, all using XCF/MRO to communicate
with regions in other images in the sysplex, the DFHIRP module in the MVS LPA should
be that from the most current CICS release in the image, or higher.

Figure 2. A sysplex (SYSPLEX1) comprising two MVS images (MVS1 and MVS2). In
this illustration, the members of the CICS group, DFHIR000, are capable of
communicating via XCF/MRO links across the MVS images.

In MVS1, the DFHIRP module in the LPA should be at the level of the highest CICS TS
z/OS release in the image.

Because it contains only CICS TS OS/390, Version 1 Release 3 regions, the DFHIRP
module in the LPA can be at the CICS TS OS/390, Version 1 Release 3 level, or later.
In the MRO links between CICS1 and CICS2, and between CICS3 and CICS4, use either
the IRC or XM access methods, as defined for the link. The MRO links between CICS
regions on MVS1 and the CICS regions on MVS2 use the XCF method, which is selected
by CICS dynamically.

Benefits of XCF/MRO

Some of the benefits of cross-system MRO using XCF links are:

• A low communication overhead between MVS images, providing much better

performance than using ISC links to communicate between MVS systems.
XCF/MRO thus improves the efficiency of transaction routing, function shipping,
asynchronous processing, and distributed program link across a sysplex. (You can
also use XCF/MRO for distributed transaction processing, provided that the
LUTYPE6.1 protocol is adequate for your purpose.)

• Easier connection resource definition than for ISC links, with no VTAM tables to
update.

• Good availability, by having alternative processors and systems ready to continue

the workload of a failed MVS or a failed CICS.

• Easy transfer of CICS systems between MVS images. The simpler connection
resource definition of MRO, and having no VTAM tables to update, makes it
much easier to move CICS regions from one MVS to another. You no longer need
to change the connection definitions from CICS MRO to CICS ISC (which, in any
event, can be done only if CICS startup on the new MVS is a warm or cold start).

• Improved price and performance, by coupling low-cost, rack-mounted, air-cooled

processors (in an HPCS environment).

• Growth in small increments.

Requirements for XCF/MRO

2.
XCF. The MVS/ESA™ cross-system coupling facility that provides MVS™ coupling
services. XCF services allow authorized programs in a multisystem environment to
communicate (send and receive data) with programs in the same, or another, MVS image.
Multisystem applications can use the services of XCF, including MVS components and
application subsystems (such as CICS®), to communicate across a sysplex. See the
MVS/ESA Setting Up a Sysplex manual, GC28-1449, for more information about the use
of XCF in a sysplex.
3.
Coupling facility links. High-bandwidth fiber optic links that provide the high-speed
connectivity required for data sharing between a coupling facility and the central
processor complexes attached to it.
4.
XCF/MRO does not support shared data tables. Shared access to a data table, across two
or more CICS regions, requires the regions to be in the same MVS image. To access a
data table in a different MVS image, you can use function shipping.

Applications of multiregion operation

This section describes some typical applications of multiregion operation.

Program development

The testing of newly-written programs can be isolated from production work by running
a separate CICS® region for testing. This permits the reliability and availability of the
production system to be maintained during the development of new applications, because
the production system continues even if the test system terminates abnormally.

By using function shipping, the test transactions can access resources of the production
system, such as files or transient data queues. By using transaction routing, terminals
connected to the production system can be used to run test transactions.

The test system can be started and ended as required, without interrupting production
work. During the cutover of the new programs into production, terminal operators can
run transactions in the test system from their regular production terminals, and the new
programs can access the full resources of the production system.

Time-sharing

If one CICS system is used for compute-bound work, such as APL or ICCF, as well as
regular DB/DC work, the response time for the DB/DC user can be unduly long. It can be
improved by running the compute-bound applications in a lower-priority address space
and the DB/DC applications in another. Transaction routing allows any terminal to access
either CICS system without the operator being aware that there are two different systems.

Reliable database access

You can use the storage protection and transaction isolation facilities of CICS
Transaction Server for z/OS®, Version 3 Release 1 to guard against unreliable
applications that might otherwise bring down the system or disable other applications.
However, you could use MRO to extend the level of protection.
For example, you could define two CICS regions, one of which owns applications that
you have identified as unreliable, and the other the reliable applications and the database.
The fewer the applications that run in the database-owning region, the more reliable this
region will be. However, the cross-region traffic will be greater, so performance can be
degraded. You must balance performance against reliability.

You can take this application of MRO to its limit by having no user applications at all in
the database-owning region. The online performance degradation may be a worthwhile
trade-off against the elapsed time necessary to restart a CICS region that owns a very
large database.

Departmental separation

MRO enables you to create a CICSplex in which the various departments of an

organization have their own CICS systems. Each can start and end its own system as it
requires. At the same time, each can have access to other departments' data, with access
controlled by the system programmer. A department can run a transaction on another
department's system, again subject to the control of the system programmer. Terminals
need not be allocated to departments, because, with transaction routing, any terminal
could run a transaction on any system.

Multiprocessor performance

Using MRO, you can take advantage of a multiprocessor by linking several CICS
systems into a CICSplex, and allowing any terminal to access the transactions and data
resources of any of the systems. The system programmer can assign transactions and data
resources to any of the connected systems to get optimum performance. Transaction
routing presents the terminal user with a single system image; the user need not be aware
that there is more than one CICS system.

Transaction routing is described in CICS transaction routing.

Workload balancing in a sysplex

In an OS/390® sysplex, you can use MRO and XCF/MRO links to create a CICSplex
consisting of sets of functionally-equivalent terminal-owning regions (TORs) and
application-owning regions (AORs). You can then perform workload balancing using:

• The VTAM® generic resource function

• Dynamic transaction routing

• Dynamic routing of DPL requests

• The CICSPlex® System Manager (CICSPlex SM)

• The MVS™ workload manager.

A VTAM application program such as CICS can be known to VTAM by a generic
resource name, as well as by the specific network name defined on its VTAM APPL
definition statement. A number of CICS regions can use the same generic resource name.

A terminal user, wishing to start a session with a CICSplex that has several terminal-
owning regions, uses the generic resource name in the logon request. Using the generic
resource name, VTAM is able to select one of the CICS TORs to be the target for that
session. For this mechanism to operate, the TORs must all register to VTAM under the
same generic resource name. VTAM is able to perform workload balancing of the
terminal sessions across the available terminal-owning regions.

The terminal-owning regions can in turn perform workload balancing using dynamic
transaction routing. Application-owning regions can route DPL requests dynamically.
The CICSPlex SM product can help you manage dynamic routing across a CICSplex.

For further information about VTAM generic resources, see the VTAM Version 4 Release
2 Release Guide. Dynamic routing of DPL requests is described in topic Dynamically
routing DPL requests of this book. Dynamic transaction routing is described in Dynamic
transaction routing. For an overview of CICSPlex SM, see the CICSPlex SM Concepts
and Planning manual. For information about the MVS workload manager, see the CICS
Performance Guide.

Virtual storage constraint relief

In some large CICS systems, the amount of virtual storage available can become a
limiting factor. In such cases, it is often possible to relieve the virtual storage problem by
splitting the system into two or more separate systems with shared resources. All the
facilities of MRO can be used to help maintain a single-system image for end users.

Note:
If you are using DL/I databases, and want to split your system to avoid virtual storage
constraints, consider using DBCTL, rather than CICS function shipping, to share the
databases between your CICS address spaces.

Conversion from single-region system

Existing single-region CICS® systems can generally be converted to multiregion CICS
systems with little or no reprogramming.

CICS function shipping allows operators of terminals owned by an existing command-

level application to continue accessing existing data resources after either the application
or the resource has been transferred to another CICS region. Applications that use
function shipping must follow the rules given in Application programming for CICS
function shipping. To conform to these rules, it may sometimes be necessary to modify
programs written for single-region CICS systems.
CICS transaction routing allows operators of terminals owned by one CICS region to run
transactions in a connected CICS region. One use of this facility is to allow applications
to continue to use function that has been discontinued in the current release of CICS.
Such coexistence considerations are described in the CICS Transaction Server for z/OS®
Migration from CICS TS Version 2.3. In addition, the restrictions that apply are given in
Application programming for CICS transaction routing.

It is always necessary to define an MRO link between the two regions and to provide
local and remote definitions of the shared resources. These operations are described in
Defining intercommunication resources.

Installing MRO support

CICS® multiregion operation (MRO) enables CICS regions that are running in the same
z/OS® image, or in the same z/OS sysplex, to communicate with each other. MRO does
not support communication between a CICS system and a non-CICS system such as
IMS™.

The external CICS interface (EXCI) uses a specialized form of MRO link to support DCE
remote procedure calls to CICS programs, and communication between z/OS batch
programs and CICS .

MRO does not require ACF/VTAM or SNA networking facilities. The support within
CICS that enables region-to-region communication is called interregion communication
(IRC). IRC is implemented in three ways:

1. Through support in CICS terminal control management modules and by use of a

CICS-supplied interregion program, DFHIRP, loaded in the z/OS link pack area.
DFHIRP is invoked by a type 3 supervisory call (SVC).

2. By z/OS cross-memory services, which you can select as an alternative to the

CICS type 3 SVC mechanism. Here, DFHIRP only opens and closes the
interregion links.

3. By the cross-system coupling facility (XCF) of z/OS. XCF/MRO is required for

links between CICS regions in different z/OS images of an z/OS sysplex. CICS
selects XCF/MRO dynamically for such links, if available.

For information about the design and implementation of interregion communication, and
about the benefits of cross-system MRO, the Intercommunication concepts and facilities
topic in the CICS Intercommunication Guide.
To install support for MRO, complete the following steps (outlined in more detail in this
section):

1. Define CICS as an z/OS subsystem.

2. Install the current versions of the DFHIRP and DFHCSVC modules in the LPA.

3. If you give the SVC a new number, and you have CICS Version 1 or Version 2
regions that use MRO, regenerate the CICS modules DFHCRC and DFHDRPA
for those CICS versions, specifying the SVC number.

4. Specify appropriate system initialization parameters to enable MRO for each

CICS region startup.

If you intend using cross-system MRO (XCF/MRO) you must also:

5. Install the required sysplex hardware and software.

6. Define the z/OS images as systems in an XCF sysplex.

To use the MRO support, you must also:

7. Define and install the MRO connections appropriate to your CICS environment.

Provided you complete the above steps, you can use MRO to communicate with all levels
of CICS from CICS/ESA® Version 4.1 onwards.

Should MRO be used to communicate between different releases of CICS, the function
provided on any connection is that of the lower-level release.

Connections between subsystems

This section presents a brief overview of the ways in which subsystems can be connected
for inter system communication. There are three basic forms to be considered:

• ISC within a single host operating system

• ISC between physically adjacent operating systems

• ISC between physically remote operating systems.

Single operating system

ISC within a single operating system (intrahost ISC) is possible through the application-
to-application facilities of ACF/VTAM. these facilities can be used to communicate
between CICSA and CICSB, between CICSC and IMSA, and between CICSD and
CICSE.

In an MVS™ system, you can use intrahost ISC for communication between two or more
CICS® systems (although MRO is a more efficient alternative) or between, for example,
a CICS system and an IMS™ system.

From the CICS point of view, intrahost ISC is the same as ISC between systems in
different VTAM® domains.

Physically adjacent operating systems

An IBM® 3725 can be configured with a multichannel adapter that permits you to
connect two VTAM domains (for example, VTAM1 and VTAM2 in Figure 3) through a
single ACF/NCP/VS. This configuration may be useful for communication between:

• A production system and a local but separate test system

• Two production systems5 with differing characteristics or requirements.

Direct channel-to-channel communication is available between systems that have

ACF/VTAM installed.

Remote operating systems

This is the most typical configuration for intersystem communication. in CICSD and
CICSE can be connected to CICSA, CICSB, and CICSC in this way. Each participating
system is appropriately configured for its particular location, using MVS or Virtual
Storage Extended (VSE) CICS or IMS, and one of the ACF access methods such as
ACF/VTAM.

For a list of the CICS and non-CICS systems that CICS Transaction Server for z/OS®
can connect to via ISC, For detailed information about using ISC to connect CICS
Transaction Server for z/OS to other CICS products, see the CICS Family:
Communicating from CICS on System/390® manual.

Intercommunication concepts and facilities

This topic of the manual describes the basic concepts of CICS® intercommunication and
the various facilities that are provided.
Introduction to CICS intercommunication defines CICS intercommunication, and
introduces the two types of intercommunication: multiregion operation and intersystem
communication. It then describes the basic intercommunication facilities that CICS
provides. These are:

• Function shipping

• Asynchronous processing

• Transaction routing

• Distributed program link (DPL)

• Distributed transaction processing (DTP).

Establishing intersystem sessions

Before traffic can flow on an intersystem session, the session must be established, or
bound. CICS® can be either the primary (BIND sender) or secondary (BIND receiver) in
an intersystem session, and can be either the contention winner or the contention loser.
The contention winner in an LU-LU session is the LU that is permitted to begin a
conversation at any time. The contention loser is the LU that must use an SNA BID
command (LUTYPE6.1) or LUSTATUS command (APPC) to request permission to
begin a conversation.

The number of contention-winning and contention-losing sessions required on a link to a

particular remote system can be specified by the system programmer.

For LUTYPE6.1 sessions, CICS always binds as a contention loser.

For APPC links, the number of contention-winning sessions is specified when the link is
defined. The contention-winning sessions are normally bound by CICS, but CICS also
accepts bind requests from the remote system for these sessions.

Normally, the contention-losing sessions are bound by the remote system. However,
CICS can also bind contention-losing sessions if the remote system is incapable of
sending bind requests.

A single session to an APPC terminal is normally defined as the contention winner, and is
bound by CICS, but CICS can accept a negotiated bind in which the contention winner is
changed to the loser.

Session initiation can be performed in one of the following ways:

 • By CICS during CICS initialization for sessions for which
AUTOCONNECT(YES) or AUTOCONNECT(ALL) has been specified.

• By a request from the CICS master terminal operator.

• By the remote system with which CICS is to communicate.

• By CICS when an application explicitly or implicitly requests the use of an

intersystem session and the request can be satisfied only by binding a previously
unbound session.

Intersystem communication over SNA

To provide the necessary protocols to support communication between CICS® regions
that are in different z/OS images, or in different z/OS sysplexes, ISC over SNA uses the
ACF/VTAM access method. (You can also use ISC over SNA in the same CPC, through
the application-to-application facilities of ACF/VTAM.)

You must include the following management programs in your CICS regions, (by
specifying the system initialization parameters that are given in parentheses):

• DFHISC – the intersystem communication program (ISC=YES).

• DFHTCP – the terminal control program (TCP=YES is the default).