Multiple CICS Regions (MRO)

What is MRO ?
MRO (or Multiple Region Option) is the term used to describe a set of inter-linked CICS regions. Each region may perform a different function, such as an FOR (File Owning Region). An FOR would contain all the definitions for the files that will be used by CICS. When an action such as READ or WRITE is requested, the request can be routed to the FOR. The CICS regions communicate with each other using Inter System Communication (ISC). The CICS regions must be in the same MVS image or in the same MVS sysplex to use MRO.
 
Why use MRO ?
In the early days of CICS, before MRO, all definitions for files, terminals, programs etc would be stored in one CICS region. These definitions all take up CICS storage, as the numbers of terminals, files etc increase so the amount of storage available for running programs is reduced. This could often lead to problems with CICS because of a lack of available storage. The CICS system might eventually grind to a halt and have to be re started. The term for this kind of problem is Virtual Storage Constraint (VSC). Using MRO can help to relieve the problems of VSC. Resource definitions could be stored in different CICS regions that were linked together in order to reduce the amount of storage required in the main CICS region. Different resource types are generally grouped together in a particular region which gives rise to the term “owning Region”. So a CICS region that has all the terminal definitions is called a Terminal Owning Region or TOR, the region that contains the applications programs is called the Apication Owing Region or AOR. Another reason for using MRO might be that you have seperate development teams that require access to the same files or database, but are developing different applications. You could specify different Application Regions, which are both connected to the same File Owning Region. Team 1 could develop their applications in AOR 1, and Team2 could develop their applications in AOR 2. If there are any problems with the applications in AOR 1, then Team 2 could continue working in AOR 2.

Transaction Routing.
Transaction routing lets you run a transaction in any connected CICS system. When you enter the transaction id the transaction might run in any one of the connected CICS regions.
 
Function Shipping.
Function Shipping lets your program access resources by 'shipping' requests to another CICS region. For example if your program requests access to a file, the file control request might be shipped to the File Owning Region. You can also ship requests for access to TSQs, TDQs and databases owned by another CICS region. When you write an application you do not need to know where the resource is located. The CICS resource definitions will specify where the required resources are.
 
Connecting to other Regions in MRO.
When you logon to CICS you will (in most cases) be logging in to the Application Owning Region. If you want to look at (say) a definition of a file in the FOR you might find that you cannot see the details of the file because it is in another region, or you may want to change the definition of the file and are unable to, because it is in the FOR. So how do you get into the FOR? Many sites use some form of session manager (NC-ACCESS, MULTSESS, Tubes, etc) which will only let you login to the AORs. To overcome this problem you should login to the CICS region as you would normally do. Then you can use the CRTE transaction to login to another region.
eg CRTE SYSID=xxxx , where xxxx is the name of the region you want to go to (You can find out names of the connected regions using CEMT INQUIRE CONNECTION).
You then login using the CESN transaction. Once you have done all the work you want to, you return to the original CICS region by entering 'cancel'.