IBM helped celebrate the 80's by introducing CICS multi-region operation (MRO). There were probably a lot of reasons why IBM chose to include this feature. First, shops that needed serious Virtual Storage Constraint Relief (VSCR) in the days of 16M address spaces could exploit MRO to grow CICS horizontally. MRO also got around CICS' one TCB structure which prevented it from taking advantage of multiple processors. Clunky and slow at first, MRO would grow into becoming the basis for CICS' wonderful flexibility and distributive properties.
In the 80's a typical MRO configuration consisted of a terminal owning region (TOR) connected to one or more application owning regions (AOR's). By virtue of transaction routing someone logged onto the TOR could use various applications blissfully unaware of where they went or executed. Command level programs could take advantage of function shipping whereby they could access remote resources on other regions as if they were local. Later transaction routing grew to support LU6.2 connections eliminating the need to tie servers or other regions directly to AOR's.
Of course MRO didn't spring perfect and entire from IBM's brow. Cross-region communication added appreciable overhead to the slower processors of the day. IBM hadn't quite worked all the kinks out of inter-address space communication. In addition, more CICS regions used more real storage back when 16M was a hardware limit too.
The 90's saw a couple of wonderful developments. The first was the expansion of CICS' protocol suite and communication with CICS clients beyond the mainframe. IBM added support for the new-fangled (to us, at least) TCP/IP and gave us the CICS Transaction Gateway (CTG).
This lead to a broadening of the "routing" concept with a Listening Region (LR) replacing the TOR of the previous configuration. Although an LR served the same purpose as a TOR it did it in a slightly different way. As the name implies, an LR listens for incoming traffic on a socket and jiggles the input message around until it can start a transaction. Once the transaction started, routing takes over and sends it to an AOR for processing. Another difference was the return trip may not come back through the LR because the application could choose to send the message directly from the AOR to the client. The interface with CTG relied instead on distributed program link (DPL) to get work from the LR to an AOR.
The second great development was dynamic transaction routing (DTR). Now enterprises could put some intelligence into the routing decisions made at the TOR or LR either through custom code or CICSPlex System Manager (CPSM). In my opinion, DTR fulfilled the promise of MRO as it bloomed into facility supporting intelligent workload distribution, high availability and fully distributed systems.
I think it's time to generalize again and conceptually lump all the TOR's and LR's together into routing regions (RR's). After all, dynamic routing can already control transaction starts and attaches, along with DPL's. It's not too far to take a leap into such things as:
An MQ listening region: In this case, MQ would wake up the trigger transaction CKTI. CKTI, in turn, reads the initial message and starts the application transaction passing the name of the input queue. There's no reason an enterprise couldn't use transaction routing to send the application task to an AOR so long as the input queue is available there. The chief advantage here is the AOR's can bounce all day and still support the MQ application.
Dynamic function shipping: Even with record level sharing (RLS) File Owning Regions (FOR's) can still be useful for some operational reasons. But if that single instance of an FOR goes down the application is still toast. Why not start multiple FOR's and let routing code in the AOR decide which one to go to?
MRO and DTR offer an amazing amount of flexibility and functionality. There is overhead to be sure. However, in these days of the web most shops are choosing flexibility and availability over performance. It's also important to remember that redundancy is cheaper and more effective than bullet-proofing. Therefore, if you have cycles to spare you may want to take advantage of these facilities to ensure an application is up even during system maintenance.
About the author:
Robert Crawford has been a CICS systems programmer for 24 years.
References:
Follow the Yelavich Road, 2003. Yelavich Consulting, Sparks, NV September 25, 2006
