This original configuration, as previously explained, allowed transactions to be defined in the TOR, which contained an identifier to route the task to the appropriate AOR. This was called static routing since the target AOR was pre-defined. An availability issue arose because, if that specific AOR wasn’t available, the task couldn’t be routed, and therefore was abnormally terminated. What if this task could run in any AOR? If the installation defined AORs that all contained similar resources, there was no reason the task couldn’t run in another AOR. It significantly increased availability and flexibility since the installation and the respective workload weren’t dependent on any particular AOR.
This was the birth of dynamic routing. It removed the requirement of specific identifiers in the transaction definition and created a target group of AORs that could be acceptable for the routing. The prerequisite, however, was that every AOR must contain the resources required for any of these transactions to run. The term cloning was adopted to describe all the AORs that would need to be built to support this process. This is now a popular configuration since it significantly increases availability and removes the dependency on a single AOR for any task to execute. The typical process that produces AOR cloning includes:
• All AORs contain the exact same DFHRPL concatenation so all programs are available in the same sequence.
• All AORs contain the exact same DFHCSD grouplist so all resource definitions are available.
• All AORs contain the same DFHSIT so all system parameters, including storage sizes, and system definitions are the same.
• All AORs contain the same DB2 connection definition since most CICS tasks now use DB2 resources, not VSAM files.
Once the configuration that allows dynamic routing has been built, there needs to be some mechanism to allow routing from the TOR without a static identifier. There are several ways to do this. One way is to use a sample program that IBM ships with the product. The module name is DFHDYP; the source can be found in the DFHSAMP library. Customers can use this or modify it to route the transactions from the TOR to the cloned AORs. Another alternative is to install and implement CICSPlex SM (CPSM). This product, which is shipped with every new release of CICS, has a complex, sophisticated process of defining transactions and the target AORs that would be available for dynamic routing. CPSM is covered in the next section.
An additional consideration in dynamic routing is that the application must be able to execute in any of the AORs in the configuration in multiple executions. In the past, many applications had affinities that dictated they always execute in the same AOR. Typically, these applications would leave data or other information behind in the AOR they initially executed in and expect that data to be available in the next cycle.
These affinities would preclude them from being dispatched again into a different AOR. IBM recognized this limit to dynamic routing and initially introduced The CICS Affinity Utility, which could be run against CICS programs to identify the Application Program Interface (API) commands that produced affinities. This utility has evolved into the CICS Interdependency Analyzer for z/OS. The CICS Publications Library offers more information about affinities and this product.
Once a multi-region configuration is built, it can be used to take advantage of new hardware configurations as the mainframe evolves. While earlier mainframes may have had a small number of Central Processors (CPs), the new machines have dozens of CPs that can be used to process workload. All these processors are available for executing work, which allows processing to be spread out across the Plex. Since CICS can dispatch multiple Task Control Blocks (TCBs) on these CPs, a multi-region configuration lets the installation use the hardware available and distribute workload. This balances processing and increases throughput, even creating a higher volume of transactions during any interval. Some large installations can sustain thousands of transactions per second during their peak interval.
Installations that require a great deal of flexibility and complexity for their dynamic routing requirements usually install and implement CICSPlex SM, which is shipped with every new CICS release. This product has complex algorithms to route workload through specifications set up for each transaction group. CICS doesn’t control it; it’s managed via a Web User Interface (WUI) external to CICS. As their configurations grow, many customers find that a tool such as CPSM is required to handle the complex routing algorithms of multiple business processes. CPSM is powerful but also requires a great deal of administration. Some customers find that support of the complex environment requires a full-time resource.
Each installation must consider its own needs in evaluating CPSM. To learn more about CPSM, see the IBM CICS library of publications at http://www-01.ibm.com/software/htp/cics/library/.
MRO has been a great asset to installations that have a large, complex CICS configuration. Even though virtual storage constraint isn’t as much a factor now as it was in the past, MRO continues to be a high-availability advantage for most installations that require non-stop processing. IBM continues to deliver enhancements to CICS with every release. MRO may now be taken for granted, but it was a major plus back in 1980 and is used extensively today.
The third article in this series, "CICS 101: Debugging Problems," is available here.