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:

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.

Related concepts
Overview of MRO
Facilities available through MRO
Cross-system multiregion operation (XCF/MRO)
Conversion from single-region system
Intersystem communication
Related tasks
Steps to install MRO
Further steps
Defining links for multiregion operation
Related reference
Requirements for XCF/MRO
[[ Contents Previous Page | Next Page Index ]]