Platform design

Before you create a platform, review your environment and identify how you might map regions to a platform. Alternatively, identify what new CICS® regions you might create specifically to use in a platform.

Consider the following items in the design for your platform:

Applications that you want to deploy on your platform.
Policies that you want to deploy on your platform.
Individual resources that you want to deploy as CICS bundles on your platform.
Existing CICS regions and system group definitions (CSYSGRPs) that you want to adopt as part of the platform.
New CICS regions and region types that you want to create in the platform.

If your capacity requirements increase or decrease after you have designed and installed your platform, you can use the CICS Explorer® to add further CICS regions to your active platform or remove CICS regions from it.

Designing region types

A region type is a logical grouping that collects together a number of CICS regions that share common characteristics, and enables them to be managed as a unit in a platform. Look for common characteristics of CICS regions that you want to manage as a group, and use these characteristics to divide the CICS regions in the platform into suitable region types. You could group your CICS regions by using region types to meet functional, geographical, or legal requirements, as in these examples:

Terminal owning region (TOR), File owning region (FOR), Application owning region (AOR): CICS function type
Production, Test, Development: business function type
Payroll, Personnel, Accounts: business processing function type
United Kingdom, Asia, Europe: geographical areas by continent, country, state, county

For some examples of platform architecture, see Platform examples.

You can design and create new region types to use in the platform. Alternatively, you can choose to adopt existing system group definitions (CSYSGRPs) as region types in the platform. A single platform can include both created region types and adopted region types. When you use created region types, the CICSPlex® SM topology for those CICS regions is created by the platform and is associated with the lifecycle of the platform. When you use adopted region types, you set up and maintain the CICSPlex SM topology for those CICS regions independently of the lifecycle of the platform.

If a CICS region has more than one purpose in the platform, you can include it in more than one region type, as a shared region. You can also share CICS regions with region types in other platforms. If your platform design involves sharing CICS regions between region types, be aware that a created region type can only contain created regions, and an adopted region type can only contain adopted regions. For more information about region sharing, see Sharing regions between region types in a platform.

A CICS TS Version 5.1 region connected as a MAS to a CICS TS Version 5.1, 5.2 or 5.3 CMAS can be part of a platform together with CICS TS Version 5.2 and CICS TS Version 5.3 regions connected as a MAS to a CICS TS Version 5.2 or CICS TS Version 5.3. It is possible to install applications created with CICS TS Version 5.2 or Version 5.3 on platforms that include CICS TS Version 5.1 regions. However, installation of CICS TS Version 5.2 or Version 5.3 applications into CICS TS Version 5.1 regions in a platform has the following limitations:

Private resources for applications, such as private PROGRAM or LIBRARY resources, are not supported in CICS TS Version 5.1 regions, and are not created in those regions. If multiple versions of the application are installed on the platform, resource name clashes can therefore occur in the CICS TS Version 5.1 regions. In this situation, the duplicate resource fails to install in the CICS TS Version 5.1 regions with message DFHAM4950 or DFHAM4834 being issued, and the CICS bundle for the new application version cannot be enabled in those regions.
CICS bundles with the same ID and version are not supported in CICS TS Version 5.1 regions. If multiple versions of the application are installed on the platform that include CICS bundles with the same ID and version, the CICS bundles fail to install in the CICS TS Version 5.1 regions, and the regions will issue message DFHAM4952. In this situation, the application is in INCOMPLETE status, and it cannot be enabled in the CICS TS Version 5.1 regions.

Because of these limitations, although you can install multiple versions of an application created with CICS TS Version 5.2 or Version 5.3 on a platform that includes CICS TS Version 5.1 regions, it is likely that the later versions of the application will fail to install in the CICS TS Version 5.1 regions. To avoid installation errors, only include CICS TS Version 5.2 or Version 5.3 regions in the region types where you are installing multi-versioned applications.

Designing new CICS regions for a platform

When you design a platform, you can include new CICS regions in created region types to meet the exact requirements of the applications that you want to deploy on your platform. You can use created regions to provide extra functions that supplement existing CICS regions that you plan to adopt as part of the platform. Or you can design a platform that consists entirely of created regions.

In your platform design, consider the characteristics that are required for the CICS regions in each created region type. Created region types can specify the properties of the CICS regions that they contain. You can clone certain region attribute values for all the CICS regions in a region type by specifying the attributes at a region type level. Only CICS regions that can accept the required settings can be part of that region type. The setting in the CICS region can be the same as the setting for the region type, or the setting can be absent in the CICS region, in which case it is supplied from the setting for the region type. However, the setting in the CICS region cannot conflict with the setting for the region type. Shared regions must be able to accept settings from all the region types in which they are included.

You can specify the following region attribute values at a region type level:

Eligible as Routing Region (WLMSTATUS attribute): Whether or not this CICS region is to participate in its associated workload as a routing region when the CICS region is started.
Eligible as Target Region (DYNROUTE attribute): Whether or not this CICS region is to be active as a target region and accept work for the workload for which it is a target at CICS startup.
Enable BAS Install (AUTOINST attribute): Whether resources associated with the CICS region through a resource description should be automatically installed when the MAS connects to the CMAS.
BAS Install Failure Action (AINSFAIL attribute): The action to be taken in the event of a BAS install failure.

If the architecture of your platform requires that all the CICS regions in a region type have particular capabilities or restrictions in these areas, specify the appropriate values at a region type level when you are setting up the region type. If a created region type has no special requirements for an attribute, do not specify any value for that attribute, so that any setting is allowed in the CICS regions. When you specify a region attribute value at a region type level, that attribute value is locked and cannot subsequently be changed in a CICS region that is part of the region type.

Mapping existing CICS regions to a platform

When evaluating your existing systems for possible candidates to become a platform, look for any top-level groups that contain two or more system group definitions (CSYSGRPs) and multiple CICS regions. The top-level group could potentially be a good candidate to be re-implemented as a platform, and the CSYSGRPs could potentially be good candidates for region type adoption. You can more easily manage and deploy resources and applications to the CICS regions in the platform by packaging parts of your existing topology as a platform.

Each CICS system group (CSYSGRP) that you include as part of a platform must meet the following requirements:

The group has not already been adopted by a platform that is already installed. If the group is already associated with a platform, it cannot be adopted as a region type.
The group does not contain any subgroups.
The group will not require modification (for example, a group that is involved in WLM or RTA). Platforms require a lock on the groups that are used as region types.
All the CICS regions in the group have the CICSPlex SM system parameter MASPLTWAIT(YES) specified. MASPLTWAIT(YES) is also required for Business Application Services. This parameter is required to automatically install resources for an application or platform when the CICS region is initialized.

If you have CICS regions in a CSYSGRP that does not meet these requirements, and you want to use the CICS regions as part of the platform, add their system definitions (CSYSDEFs) to a new CSYSGRP that you create specifically for the platform.

CICSPlex SM data repository (EYUDREP) size

If you are planning a large-scale deployment, check that the size of your CICSPlex SM data repository is adequate. The data repository is the VSAM data set where system configuration and definition data for CICSPlex SM is stored. Each CMAS has its own data repository.

The resources for platforms and applications are managed from the data repository, not from the CICS CSD, so the data repository needs to have enough space for the definitions for your platform and the applications and bundles deployed on it. You can determine the current size of the data repository by using the LISTCAT function of the IDCAMS utility.

If you want to expand the data repository, use the REPRO function of the IDCAMS utility. An example of the JCL to do this is in the EYUJXDRP member of the CICSTS51.CPSM.SEYUSAMP library. In that JCL, on the RECORDS(xx,yy) statement, specify a primary (xx) and a secondary (yy) value that are appropriate for your environment. The initial values are 500 and 3000.