CICSplexed and Confused? Part 1: Understanding your CICSplex
ChrisHodgins 060000AX8A Visits (1368)
Every now and then over the last few years, I've repeatedly been asked about recommended approaches for growing a CICSPlex SM environment or for those moving from a pure CICS environment to a new CICSPlex SM one. I've been promising myself that I was going to write this all down in a series of blog posts some day and that day seems to be now. So if you are CICSplexed and confused, read on!
Let's start our journey by looking at what address spaces are required to run the CICS Explorer across your CICS environment. In this post, we will start simple with a set of 3 CICS regions in a single LPAR.
The first job is to setup a managment address space for CICSPlex SM. This region is called a CMAS and will be the manager of one or more CICSplex. A CICSplex is simply a logical container for one or more CICS regions that are under the control of CICSPlex SM. The CMAS manages the CICSplex but does not participate in it as a CICS region. Although the CMAS is a CICS region, you should not run any CICS workload in it. For the eagle-eyed reader who spotted the lower and upper-case "p" in CICSplex, we use the upper-case CICSPlex when talking about the product CICSPlex SM but the lower-case CICSplex when talking about the CICSplex itself.
Now although the CMAS is up and running in our example, it can't yet communicate with the CICS regions. For that to happen, the CICS regions must be added to the CICSplex and converted into MAS regions. A MAS is a normal CICS region with a little CICSPlex SM magic on top to allow fast communication and resource collection on behalf of the CMAS. To add the CICS regions to the CICSplex, we need to first connect the CICS Explorer and for that we need a WUI region.
A WUI region is responsible for hosting Web based interfaces for CICSPlex SM. The interface we want to use here is the CMCI (CICS Management Client Interface). This is the interface the CICS Explorer uses to provide it's full management capability on top of CICS. Again note that you should not run CICS workload on a WUI region.
As well as being a host for external connectivity for CICSPlex SM, the WUI itself is a MAS region. Above though I said that before a MAS could be connected it must be added to the CICSplex. Well this is true and the WUI is no exception. However, when you define your CICSPlex SM Data Repository (the CICSPlex SM equivelant to the CSD), you specify an initial CICSplex name and WUI region details. As the WUI starts it also creates and installs the resources required to make the CMCI available. Now start and connect your CICS Explorer and specify what those other CICS regions are called.
Although the CICS Explorer is now running and connected to our environment it can't retrieve information from the other systems as they are not connected to the CICSplex. So the final step is to convert the CICS regions into MAS regions. This is simply a matter of making sure the CICSPlex SM datasets SEYUAUTH and SEYULOAD are in the STEPLIB and DFHRPL respectively, the CPSMCONN=LMAS SIT parameter is set and the EYUPARM dataset is defined in the JCL with the name of the CICSplex specified. Start your regions and they will connect to the CICSplex and appear in the CICS Explorer.
From this point you can continue to expand the CICS regions (MAS) in your LPAR and CICS Explorer will get instant access to their resources as well.
The IBM Knowledge Center for CICS Transaction Server V5.1 has more detailed information on this topic:
In the next post, we'll extend this topology further for additional LPARs, then in the third post we will take another look at the topology, discuss the limitations around upgrades and make an improvement, then in part four we will look at CMAS to CMAS connectivity and discuss the topology again from a high availability stand-point.