The CICSplex is the largest unit that you can manipulate in your CICSPlex® SM configuration. A CICSplex is made up of an association of CICS® systems and CICS system groups. This section gives guidance on deciding how to group your CICS systems into system groups, and then to identify CICSplexes.
The very first thing you must do when planning to install CICSPlex SM is to identify the CICS systems or regions in your enterprise. You may already have a clear picture of the systems you have, and of where they are installed. However, in the larger enterprises, where CICS systems are numbered in the hundreds, it’s possible that no one individual has this complete view. Whatever the case, the aim of this exercise is to document the current arrangement of your CICS systems in a graphical form. The "map" you produce should be a logical representation of your CICS systems rather than a physical one, so don’t worry unduly about recording where particular processors are located, for example. Whether you simply sketch the map on paper or use an on-line graphics tool, be sure to leave plenty of space so that you can update the map with CICSPlex SM components as you work through this chapter.
Figure 4 shows an example of the type of map you should be aiming to produce.
Your initial map of the enterprise CICS systems should include every operating environment in which CICS is installed. It should also show:
(If you can’t get all of this detail on your map, record it separately from the graphical representation of the CICS systems.)
Next, refine the map by identifying those CICS systems or systems that can and cannot be managed by CICSPlex SM. A list of CICS systems that CICSPlex SM can manage is given in CICS system connectivity. Any CICS systems that are not directly-connectable to CICS Transaction Server for z/OS®, Version 3 Release 1 and later will need special consideration when you are locating CMASs (see Locating CMASs).
In the example map shown in Figure 4, only the CICS systems running under OS/400® cannot be managed by CICSPlex SM. On your own map, choose a convention, such as shading or use of color, for marking CICS systems that cannot be managed by CICSPlex SM. However, don’t remove them from the map altogether. If you decide to move those systems to a CICS platform or release that CICSPlex SM can manage, they can be reinstated easily in the enterprise map.
All the other CICS systems become your MASs.
When you have identified those CICS systems or regions in your enterprise that can be managed by CICSPlex SM, your next task is to decide how many CICSplexes you want to define to CICSPlex SM, and which of your CICS systems is to belong to each. You can have any number of CICSplexes. For example, you could define:
If you do not plan to use workload management facilities, there are no restrictions on how you combine CICS systems and CICS system groups to form a CICSplex. For example, you might associate CICS systems by:
If you do plan to use workload management facilities, you must ensure that:
If you plan to use the logical scoping, resource management, or installation functions of BAS, you should keep a business application within one CICSplex.
If you plan to use CICS BTS, you should keep a BTS-set with one CICSplex.
The question is, how do you decide what to do? There are no hard-and-fast rules governing the number of CICSplexes you define, but there are some guidelines that will help you select the most suitable configuration for your enterprise. These guidelines are presented in the form of a three-step process:
Each of these steps is discussed below.
You will remember that the CICSplex is the largest single entity that CICSPlex SM can manipulate, and that none of the CICSPlex SM definitions or specifications can cross a CICSplex boundary. Furthermore, CICSplexes are mutually exclusive, so no CICS system can belong to more than one CICSplex. Therefore, having a single CICSplex for the enterprise brings several advantages. For example:
In summary, having one CICSplex means that there are no system management barriers between one group of the enterprise CICS systems and another.
Firstly, you must ask whether the organization of your enterprise lends itself to a single CICSplex. For example, if you have processors in different geographical locations, are there connections between those processors, or are they managed as separate entities, each with its own workload? If you have these separate units in your enterprise, it’s likely that you will need to define multiple CICSplexes, and so manage the enterprise CICS systems as if they belonged to more than one enterprise.
Similarly, is your enterprise organized and run as multiple, separate business units? For example, if you are running a bureau that provides computing services to a variety of customers, the absolute separation of one set of regions from another, even within a single processor, might simplify other processes, such as security management, customer billing, or workload management. If you have similar reasons for wanting to keep the management of some regions entirely separate from the management of others, you should define multiple CICSplexes rather than one.
If you have decided that you need to define more than one CICSplex, for reasons such as those outlined above, it’s probably obvious to you already which CICS system or CICS systems should belong to each. If it isn’t, you should revisit your decision to have multiple CICSplexes because it suggests that you are trying to erect artificial barriers. And, as a final check, you should ensure that the way you separate the regions is not disruptive to your other system management goals. For example, if you want to use CICSPlex SM’s WLM functions, both routing regions and the target regions to which they route transactions must belong to the same CICSplex, unless you are planning to customize the supplied dynamic routing program.
Finally, try to remember that you can alter your decision. Ideally, you would discover the best possible configuration at your first attempt. However, if you decide after a while that a different CICSplex configuration would be better, you can make the necessary changes.
Figure 5 shows the number of CICSplexes required in the example enterprise.
This section gives some suggested CICS system groups for the example configuration:
Notice that Group 7 in CICSplex 1 and Group 6 in CICSplex 2 comprise of other groups. Defining groups within groups is very efficient, both for you (because it means less effort) and for CICSPlex SM.
Group 8 in CICSplex 1 and Group 7 in CICSplex 2 include the same set of CICS systems as the CICSplex to which it belongs. These are often useful groups to define because the scope value (as specified for a monitor specification, for example) can be a CICS system or a CICS system group name only: it cannot be the name of a CICSplex.
This is merely an initial list of system groups. It is likely to be added to (or altered) when BAS, WLM, RTA, and monitoring requirements are identified.
You can identify one or more subsets of the CICS systems within a CICSplex as a CICS system group, which can be manipulated as a single entity and independently of the rest of CICSplex. For example, if you define a CICSplex made up of TOR, AOR, and FOR CICS systems, you might want to define the AORs as a CICS system group, so that you can use a single CICSPlex SM command to make changes to, or request data from, all CICS systems in that category.
Alternatively, you could define a single group for any of the following:
CICS system groups, unlike CICSplexes, do not have to be mutually exclusive: a CICS system can belong to any number of groups within a CICSplex. However, because the CICS system group is a subset of the CICSplex, a system group cannot cross CICSplex boundaries.
You can create CICS system groups from other groups. For example, if you want a single group to contain all AORs and all TORs in CICSplex, you can define its members as:
Any duplication of CICS system names that occurs in this way (for example, if a particular CICS system belongs to more than one constituent group) is accommodated by CICSPlex SM. When a CICS system group is the target of a CICSPlex SM command, CICS systems appearing in the group more than once are acted on once only.
[[ Contents Previous Page | Next Page Index ]]