Getting started with cloud enablement for platforms and applications
If you want to move toward cloud enablement for your CICS® applications, you can use the phased approach described here to set up a platform, deploy the application to the platform, manage and monitor the application by using a policy and application context data, and remove the application at the end of its lifecycle.
The workflow described in this process is an adoption roadmap to progressively implement platforms, applications, and policies to move existing applications towards cloud enablement. If you are developing new applications to deploy on platforms, follow the workflow described in Workflow for application deployment in the CICS Explorer product documentation . That procedure describes how to use the CICS Cloud perspective to set up a platform and create suitable applications and policies.
If you want to try out the complete process first by using one of the sample applications supplied with CICS , you can follow through Scenario: Deploying an application to a platform .
Stage 1: Create a platform
You use a platform to deploy and manage CICS applications over multiple CICS regions. The platform provides services to the applications. In this stage of cloud enablement, you can create a platform. Your platform can adopt existing CICS regions where your existing CICS applications are installed. You can also create new region types in your platform to contain new CICS regions where your CICS applications will be installed. To create a platform, you must be using CICSPlex® SM to manage your CICS regions.

In CICS Explorer® or the IBM® CICS SDK for Java™ , use the Project Explorer view in the CICS Cloud perspective to create a CICS Platform project and export it to the z/OS® UNIX file system. The CICS Platform project defines a platform bundle, which is a management bundle that describes the platform and its region types, and references the CICS bundles that are deployed at the level of the platform. A platform can include a mix of created region types, where you define a region type and set up new CICS region definitions, and adopted region types, where you adopt an existing CICS system group (CSYSGRP) as a region type with its existing CICS regions. Use the platform descriptor editor in CICS Explorer to work with your platform bundle and confirm the region types before you export the project.
After you have exported the CICS Platform project, use CICS Explorer to create and install a platform definition, which is a PLATDEF resource definition. When you install the platform definition, CICS creates the platform in the CICSplex. You can add or remove individual CICS regions in the region types in an installed, active platform.
Setting up a platform explains how to design and create a platform. For instructions to create a CICS Platform project and a platform definition, see Working with platforms in the CICS Explorer product documentation.
Stage 2: Create an application and application entry points
When you package a CICS application in an application bundle, you can deploy, manage, and monitor the application as a single entity across multiple CICS regions in a platform. Application entry points identify the resources that are access points to an application, and control users' access to different versions of an application that is deployed on a platform. In this stage of cloud enablement, you can package your existing CICS application for deployment on a platform, and define an application entry point for each of the ways in which your application can be started.

Use CICS Explorer to create one or more CICS bundles to contain the resources for each component of the application. The CICS bundles also declare any dependencies on other resources outside the bundles, known as imports, which must be available in the CICS regions for the application to run. At this stage, you can specify all the installed resources for your existing CICS application as imports. At a later stage, you can modify the bundles so that the resources are created when the bundles are installed.
In your CICS bundles, add application entry points for the PROGRAM or TRANSACTION resources that are used to access the application, or the URIMAP resources that provide URIs for requesters to access the application. Resources that are declared as an application entry point must have a unique name in the resource type in your environment. For PROGRAM resources, the resource for an application entry point does not have to be in the same CICS bundle as the statement of the application entry point.
For URIMAP or TRANSACTION resources, if you want the application entry point to control access to the service provided by the URIMAP or TRANSACTION resource, the URIMAP or TRANSACTION resource must be defined in the same CICS bundle as the application entry point. For now, declare the URIMAP or TRANSACTION resource as a dependency in the same CICS bundle as the application entry point, as a reminder to define the URIMAP or TRANSACTION resource in that CICS bundle in the next stage of cloud enablement.
For instructions about creating CICS bundles for the components of the application and for defining application entry points, see Working with bundles in the CICS Explorer product documentation. CICS bundle projects must have an ID and a version number to be included in an application project. If you want to use any CICS bundle projects from releases before CICS Transaction Server Version 5 Release 1, that do not have an ID and a version number, update the bundle manifest files for these projects to add that information.
When you have created suitable CICS bundles and declared application entry points, use the Project Explorer view in the CICS Cloud perspective in CICS Explorer or the IBM CICS SDK for Java to create a CICS Application project. The CICS Application project defines an application bundle that references all the CICS bundles for the application.
Map the CICS bundles for the application to region types in the target platform by creating an application binding, in a CICS Application Binding project. Depending on the architecture of your application, you can deploy additional CICS bundles by using the application binding, to customize the behavior of the application for the target platform. As another alternative, CICS bundles can be added to your installed platform.
Export the application bundle and the application binding to the platform home directory in zFS for the platform where you want to run the application, then create an application definition. The APPLDEF resource definition points to the application bundle and the application binding in the platform home directory for the target platform. When you install the application definition, CICS installs the CICS bundles into the CICS regions in the platform. Enable the application to verify the installation, and then make it available for use in the CICS regions. Making the application available makes the application entry points, and therefore the resources that they control for the application, available to callers.
When the application is accessed through its application entry points, the CICS regions generate application context data for the tasks relating to your application. The application context data identifies the platform, the application, the application version, and the operation. You can use the information to measure resource consumption by applications (or by particular routes into applications), to use policy-based management for applications, and to relate tasks to specific applications to help with problem diagnosis. For more information on application context, see Application context.
Packaging applications for deployment explains how to package an application in an application bundle. For instructions to create an application bundle, application binding, and application definition, see Working with applications in the CICS Explorer product documentation.
Stage 3: Add a policy
A policy is an XML definition that contains policy rules to describe controls or actions that can be applied to one or more application tasks. The policy rules define threshold conditions to manage the behavior of user tasks. For example, you can create a rule to define a threshold for the amount of storage allocated by a user task, and make CICS issue a message if the threshold is exceeded. In this stage of cloud enablement, you can create and deploy a policy to manage the tasks relating to your application.

In a CICS bundle, define a policy with suitable policy rules for your existing CICS application. You can add the CICS bundle containing the policy to your application bundle, or to target the policy to a specific environment such as your production CICS regions, add the policy to your application binding instead. If you want to apply the policy to all applications in the platform, add it directly to the platform.
If you deployed the policy with your application bundle or application binding, update and apply a new version number to the application and the application binding, and install the new version of the application in the platform. The policy now applies to the user tasks that have application context for your application, that is, the tasks for which you created application entry points.
For instructions to create a policy, see Working with policies in the CICS Explorer product documentation.
Stage 4: Add resources for the application
When you completed the previous stage of cloud enablement, the CICS regions where your existing CICS application was installed were defined as part of a platform, and your existing CICS application was defined as an application in the platform, with its tasks managed by a policy. However, the resources for the application were defined and managed in the CICS regions in the same way as before. In this stage, you can transfer the responsibility for creating, installing, and managing the resources to the platform.
You can use CICS bundles to package suitable resources for artifacts such as a CICS program or transaction, a CICS library, an Atom feed, an XML-based service, a Java application that has been packaged as an OSGi bundle, or an application or system event. You can only add user-defined resources to a CICS bundle; you cannot add CICS-supplied resources (beginning with DFH). Defining CICS bundles has information about the types of resources that you can define in a CICS bundle, and how they are managed when you have defined them.
Defining resources in a CICS bundle is an important step, because the management and lifecycle of those resources is delegated to the CICS bundles and management bundles that installed the resources. You no longer modify the resources or change their state individually, because they are automatically added, updated, or removed when you operate on the CICS bundles and the application. Application architects must therefore carefully consider which resources for an application should have their lifecycle tied to the lifecycle of a CICS bundle.
Review the information in Characteristics of bundled resources to help you choose which resources to define in CICS bundles and how to arrange them. If your application uses resources that cannot be defined in a CICS bundle, or that you do not want to define in a CICS bundle, you can continue to specify these as imports.
For supported resource types, a CICS resource is private if the resource is defined in a CICS bundle that is packaged and installed as part of an application. Because these resources are not available to any other application or version installed on the platform, or to other applications in the CICS region, the resource name does not have to be unique in your installation. Review the information in Private resources for application versions to understand the changes to behavior and management for private resources. If you do not want a resource of the supported resource types to be private, continue to specify it as an import.
Applications that use the CICS resources that are supported as private resources, together with other resources such as policies and application entry points, are eligible for multi-versioning. You can install multiple versions of the application, at the same time, on the same platform instance, and make new versions available to users without service interruption. Other resources may be involved with multi-versioned applications if you manage the resources appropriately to avoid resource name clashes between different versions of the application. Review the information in Multi-versioning for applications deployed on platforms to see the advantages of structuring your application so that it is eligible for multi-versioning.

Update the CICS bundles for your application to add suitable resources to be dynamically created in the CICS regions when you install the application in the platform. For URIMAP resources, if you want the application entry point to control access to the service provided by the URIMAP resource, remember to define the URIMAP resource in the same CICS bundle as the relevant application entry point.
Update the application with the new versions of your CICS bundles, apply a new version number to the application and the application binding, and install the new version of the application in the platform. When you install the application, the resources that you defined in the CICS bundles are dynamically created in the CICS regions. These resources must now be managed through the CICS bundles. CICS automatically manages the deployment of applications when you start or restart CICS regions that are in the platform. You can view the installed applications and their private resources using the CICS Explorer.
For instructions to add resources to a bundle, see Working with bundles in the CICS Explorer product documentation.
Stage 5: Remove the application from the platform
If you no longer require your existing CICS application, you can complete its lifecycle by removing it from the platform. You can also remove individual versions of the application that are not likely to be required again. When you make unavailable, disable, and discard a version of an application, the CICS bundles that are deployed as part of the application version are also made unavailable, disabled, and discarded in the CICS region types to which they are bound.
For each application version that you want to remove, use the Cloud Explorer view in the CICS Cloud perspective in CICS Explorer or the IBM CICS SDK for Java to make the application version unavailable. Next, use the Cloud Explorer view to disable, then discard the application version . Alternatively, double-click the application name in the Cloud Explorer view to open it, then select the Disable and discard option to discard the application version.
If you do not require the application version again, you can remove its application definition from the data repository. You can also use the z/OS perspective in CICS Explorer to remove the versioned directory containing the application bundle from the platform home directory in zFS.
Administering platforms, applications, and policies has instructions to make unavailable, disable, discard, and remove an application from a platform.