Topology definitions enable you to establish logical associations of CICS® systems within your enterprise.
This means that you can combine one or more related CICS systems to form a CICSplex and, within each CICSplex, combine one or more subsets of the CICS systems to form CICS system groups.
A CICSplex is identified to CICSPlex® SM via the CICSplex definition view (CPLEXDEF in the end user interface). To access
this from the WUI main menu, click Administration views-->CMAS
configuration administration views-->CICSplex definition. Once a CICSplex exists,
you can assign an unlimited number CICS systems and CICS system groups to it.
The names of the CICS systems and CICS system groups associated with each CICSplex must be unique and must not exceed eight characters in length. The names can match any name that is not assigned by CICSPlex SM, such as VTAM® APPLIDs.
The JCL used to start the CICS systems within a CICSplex must include the EYUPARM parameters as described in the CICS Transaction Server for z/OS® Installation Guide manual.
Although you can define a CICS system to only one CICSplex, you can assign a CICS system to multiple CICS system groups within the CICSplex. You can also assign the CICS system group to any number of other CICS system groups.
If you do not plan on using 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 need to be aware that each CICS region may act as one or more of the following:
For dynamic transaction routing, the requesting region and the routing region are typically TORs, and the target region is typically an AOR.
For inbound DPL client requests, the requesting region and the routing region are typically TORs, and the target region is typically an AOR.
For EXEC CICS START commands associated with a terminal, the requesting region is typically an AOR, the routing region is typically a TOR, and the target region is typically an AOR.
For peer-to-peer DPL requests, the requesting region, routing region, and target region are typically AORs.
For enterprise bean invocations, the requesting region is the client code that invokes the enterprise bean, the routing region is typically a CICS listener region, and the target region is typically an AOR.
When you define a CICS system to a CICSplex, you need to provide the following types of information:
Identifying a CICS system includes such information as whether security checking is to occur and the time zone in which CICS system is located, as described in topic 1.
For workload management to occur, you must ensure that:
For real-time analysis to occur, you must ensure that:
The CICS system or its CICS system group can
also, or instead, be associated with an analysis point specification, also
described in the discussion of the Analysis specifications view in CICSPlex System Manager Managing Resource Usage.
For resource monitoring to occur, you must ensure that:
Identifying a CICS system to business application services includes such information as whether resource definitions should be automatically installed when the MAS connects to the CMAS, and what action should be taken if automatic installation errors occur, as described in topic 5.