Configuration views allow you to establish and maintain definitions that:
When you define a CICSplex to a CMAS, as described in topic Managing CICSplex definitions using the end-user interface, the definition is stored in the data repository for that CMAS. There is no limit to the number of CICSplexes that you can associate with a CMAS as long as the name of each CICSplex is unique within your CICSPlex® SM environment.
Figure 21 illustrates a CMAS named EYUCMS1A and its data repository. In this example, the data repository contains a single CICSplex definition. The definition identifies the CICSplex as EYUPLX01 and associates it with the CMAS named EYUCMS1A.
When multiple CMASs are involved in the management of a CICSplex, the CMAS identified as the current context when the CICSplex was defined becomes the maintenance point CMAS for the CICSplex. As described in topic Adding a CMAS to a CICSplex, the names of the other CMASs are then added to the CICSplex definition. In Figure 22, for example, the data repository for the CMAS named EYUCMS1A shows that the CICSplex named EYUPLX01 is to be managed by three CMASs. In this example, EYUCMS1A is the maintenance point CMAS.
Note that because no communication links exist between the CMASs shown in Figure 22, the data repositories for the CMASs named EYUCMS1B and EYUCMS1A do not contain any CICSplex definitions. Once communication is established, the maintenance point CMAS informs the other CMASs that they are involved in managing the CICSplex. The maintenance point CMAS also informs the other CMASs, via repository resynchronization, when any administration definitions relating to the CICSplex are added, updated, or removed. This ensures that the data repository for each CMAS contains the same information.
For additional information about working with multiple CMASs, see Working with maintenance point CMASs.
When multiple CMASs are involved in an action, such as managing a CICSplex, they can communicate with each other either directly or indirectly, where:
Figure 23 illustrates direct communication links that
exist between EYUCMS1A and EYUCMS1B and between EYUCMS1B and EYUCMS1D. In
this example, there is no direct link between EYUCMS1A and EYUCMS1D. This
means that for EYUCMS1A to communicate with EYUCMS1D, it must pass information
to EYUCMS1B, the adjacent CMAS to which it does have a direct link. (Indirect
links, such as the connection between EYUCMS1A and EYUCMS1D, can be seen in
the access type column of the CICSPLex SM operation view EYUSTARTCMASLIST (the CMAS view in the end-user
interface). Because EYUCMS1B has a direct link to EYUCMS1D, the information
is passed on to that CMAS.
The only requirement on your use of direct and indirect communication
links between CMASs is that there must be at least one path from each CMAS to
every other CMAS.
A MAS is a CICS® system that is defined to CICSPlex SM and contains MAS agent
code. As illustrated in Figure 24, a MAS is local to the CMAS to
which it is associated.
A local MAS resides in the same MVS™ image as the CMAS and uses CICSPlex SM facilities provided by Environment Services System Services (ESSS) to communicate with the CMAS. (The ESSS is the component that owns all of the data spaces used by CICSPlex SM in an MVS image.)
[[ Contents Previous Page | Next Page Index ]]