How it works: platforms
A platform is a CICS resource that provides a layer of abstraction to decouple applications from the underlying region topology. A platform contains one or more region types, each of which contains one or more CICS regions. Platforms can both create and reuse existing region definitions. An application can be dynamically deployed to the relevant region types within a platform, and removed again when no longer needed. Platforms can be used to deploy policies, to limit and control resources, and to provide application separation.
The region is the basic unit of server deployment in a CICS TS installation. CICS TS regions are IBM z/OS address spaces that are defined to run as jobs or started tasks. They are identified by various attributes, including their job names, their IBM VTAM applid, or their CICS TS SysID, according to context. Regions require various dedicated resources, such as data sets.
As workloads grow and the number of regions increases, the functions of a single region must be provided by groups of regions for scale and availability. These regions are clones of the original single region. It makes sense to operate on these clones as a single group. Each action that is performed against the group is performed against all regions in that group. Inside a platform, a group of cloned regions that provides the same capability is called a region type.
- Manage system characteristics, such as the status of platform services and declared dependencies, from a single point
- Host applications and platform services
- Provision policies to all applications that are installed in the platform
- Dynamically add and remove services and dependencies while a platform is installed
- Share systems between region types and platforms in a controlled way
- Scale hosted applications while the platform is already installed and without changes.
This section introduces Components of a platform and Platform examples and How do I set up a platform?
How is a platform different to a CICSplex?
Before CICS TS V5.1, you could use only a CICSplex or a CICS system group to mark the boundaries of your infrastructure. Platforms allow you to specify a more descriptive and more distinct boundary.
A CICSplex supports separation of environments, such as production and test or different business units. Within a CICSplex, you can define multiple platforms. Compared to a CICSplex, the platform follows a more descriptive route, providing a set of region types to encapsulate the regions within the scope of the platform. Also, platforms support sharing of regions between region types. You can use platforms to separate your concerns within a CICSplex. For example, in a development CICSplex, you can choose to allocate a platform per developer. In a test and production CICSplex, you can choose to have a separate application for each line of business. If you want to consolidate regions, you can take advantage of a platform’s ability to share regions with other platforms. For example, you can choose to combine your routing regions for a subset of platforms within the same CICSplex.
- If the regions must be isolated from other regions because they are for a different part of the business or, for example, for development and test regions, a CICSplex is usually a good option. Using a separate CICSplex means that changes made in one scope do not affect the other.
- If the regions don't have to be isolated, platforms might be a better choice. Platforms can also share resources and regions with other platforms, but only where requested.
Components of a platform
- The platform resource itself
- Region types
- A PLATDEF resource definition
- Optionally, CICS bundles to define resources that will be supplied to the applications that run on the platform
- Optionally, policies to control the execution of tasks that run in the context of the application in that platform.
The deployed CICS® platform artefacts are located in a directory in zFS. See Platform directory structure on zFS for details.
You use CICS Explorer® to create and manage the components of the platform. Figure 5 shows the relationship between these components. You can secure a platform and its deployed applications by setting up RACF® security profiles in a similar way to security for other CICSPlex® SM components. For information, see Security for platforms and applications.
- Platform
- A platform bundle, defined in CICS Explorer, describes the platform and its region types and references the CICS bundles that are deployed at
the platform level. When you install a platform definition, a PLATFORM resource is created to
represent the platform bundle and you can use this resource to remove a platform as a single
entity.
The platform resource reflects the current state of the platform. It determines both the overall activity of the regions within the region types, and the overall state of installed platform services. For example, a platform is ACTIVE if at least one region in each region type is active and connected to CICSPlex SM.
The platform also tracks the services that it manages, and any declared dependencies. Platform services and dependencies are installed as CICS bundles, and the platform reflects the health of these bundles with its property ENABLESTATUS. For example, when all bundles are enabled across the platform region types, the platform states that it is ENABLED.
Applications require protection from environment change, and this protection is reflected in the lifecycle of the platform. After a platform is installed, it cannot be discarded until all applications installed within it are also discarded. While the platform is installed, the region types cannot be modified or discarded but regions can be added and removed from region types. Platform services also follow the lifecycle of the platform. When platforms are installed, enabled, disabled, or discarded, all defined services take the same action.
- Region types
- A platform includes one or more region types. Region types are used to classify and contain CICS regions
according to their type. For example, all CICS regions that handle connections to Db2® could belong to the same group.
Region types define the interface to the platform that applications must be bound to before deployment. When a platform is installed and the region type is created, it creates the region definitions for all defined regions. Alternatively, a region type can ruse an existing environment by adopting an existing CICS system group (CSYSGRP) and the regions in it.
You can clone certain region attribute values for all the CICS regions in a created region type by specifying the attributes at a region type level. Only CICS regions whose definitions have the same values specified for those attributes, or have no values specified for those attributes, can be part of that region type.
Region types can share regions between each other in the same or different platforms. This ability is valuable for consolidation scenarios where you might have a group of routing regions that service several different platforms, or a file-owning region that hosts files for each platform.
- Platform (PLATDEF) resource definition
- The platform definition, which is a PLATDEF resource definition in the data repository for the CICSplex, identifies the target CICSplex for the platform. On installation of the PLATDEF, the platform is created with a region type that contains the target CICS regions.
- CICS bundles
- Platforms can install and manage resources to be supplied to the application. For example, a
platform might provide a TCP/IP service that the application can consume by using a URIMAP. Platform
services and dependencies are installed in CICS bundles. All services that are installed in this
manner can be added, enabled, disabled, and removed from the platform through the ADDBUNDLE and
REMOVEBUNDLE actions.
After an ADDBUNDLE action is issued, the bundle is installed into all regions within the region type. This bundle is then enabled if the platform was previously enabled. The REMOVEBUNDLE action reverses this process by disabling and discarding the bundle in all regions within the region type.
The relationship between the platform and each installed CICS bundle is saved in a management part. The management part is a MGMTPART record that is created automatically for each CICS bundle during the platform installation process. The management part records the CICS regions where the bundle is installed, and tracks the status of the bundle in the CICS regions.
Platform services don't have to be provided by the platform itself. Platforms can import resources into bundles. Bundle imports declare dependencies on services that are provided outside the platform. For example, if multiple platforms need to share a file, one platform could create the file definition in a bundle, while the other platforms import that file definition into their bundles.
- Policies
- A platform can also install CICS TS policies. Policies provide a contract for the execution of
tasks that run in the context of any application within that specific platform. For example, a
policy can force an abend if the task exceeds the contracted processor consumption. Like resource
definitions, policies and their associated rules are installed in CICS bundles.
For more information, see CICS policies.
Platform examples
All managed regions within a CICSplex can be defined to a single platform, or managed regions within a CICSplex can be spread across multiple, detached, or overlapping platforms (as a result of the same CICS region being present in more than one platform).
In the next example, the CICS regions that are Managed Address Spaces (MASs) in the platform are a web-owning region (WOR), an application-owning region (AOR), and a file-owning region (FOR). The CMAS is a CICSPlex SM MAS that manages not just the WOR, AOR, and FOR, but also the platform.
How do I set up a platform?
At a high-level, you'll go through the steps listed below. Figure 5 shows what you'll end up with.
- Design the platform. You consider what applications, policies, and resources that you want to deploy on the platform and whether you are creating new CICS regions and region types or adopting existing CICS regions and system group definitions. For more information, see Designing a CICS platform.
- In zFS, configure your platform home directory. For more information, see Preparing zFS for platforms.
- In CICS Explorer, create a platform project. To this project, you add regions types, specify any CICS bundles to deploy and the regions types where they will be deployed. For more information, see Setting up a platform.
- From CICS Explorer, export the platform project from to zFS. The export process packages the CICS bundles that are referenced in the CICS platform project, then exports all the files for the platform bundle and the CICS bundles to the platform home directory in zFS. For more information, see Deploying a CICS platform.
- In CICS Explorer, create a platform definition. The platform definition is a CICSPlex SM PLATDEF resource definition, which points to the platform bundle in the platform home directory in zFS, and identifies the target CICSplex for the platform. For more information, see Deploying a CICS platform.
- For each CICS region definition that you created in a region type in your platform project, set up an actual CICS region. For more information, see Deploying a CICS platform.
- In CICS Explorer, install the platform definition into the CICSplex where you want to run the platform. CICSPlex SM uses the information in the platform bundle to install the platform in the target CICSplex, along with any CICS bundles that are installed with the platform. For more information, see Deploying a CICS platform.
- Start your CICS regions.
- If you have any CICS bundles deployed with the platform, in CICS Explorer, enable them so that they are available to the platform.
