Updating applications

When you make changes to the CICS® bundles for the components of an application, update the versions of the CICS bundles, the application, and the application binding, and deploy the new versions on the platform.

Before you begin

Ensure that all the projects related to the application are present in your local workspace for CICS Explorer®, including the platform project for the target platform. CICS Explorer requires the platform project in order to validate the application project and the application binding project.

To update an application, you need to edit the application project and the application binding project. If you do not have a versioned backup system that enables you to revert to a previous version of the projects, instead of editing the existing projects directly as described in these instructions, you might prefer to copy them to another project and then edit the new copies.

Applications deployed on platforms that use the CICS resources that are supported as private resources, in combination with other resources designed for applications and with imported resources, are eligible for multi-versioning. The following resources are supported as part of multi-versioned applications:
  • PROGRAM resources defined in CICS bundles that are part of the application
  • LIBRARY resources defined in CICS bundles that are part of the application
  • Policies
  • Statements of application entry points
  • Any resource that is defined as a dependency, or import, for the application

If your application uses only these resources, you can install and make available multiple versions of the application at the same time, on the same platform. If your application uses resources that are not supported for multi-versioning, you must disable and discard the existing version of the application before you install a new version. Alternatively, consider renaming the resources that are not supported for multi-versioning, so that they do not conflict with the resources installed for previous versions of the application.

If you have to disable an application in order to install a new version, it is unavailable to users from the time when you make the previous version of the application unavailable in order to disable and discard the installed APPLCTN resource in the CICSplex, to the time when you install the new APPLDEF resource definition, enable the new version of the application, and make it available. Plan a suitable time when this can safely occur, or plan an alternative solution for users of the application during that time.

About this task

You manage different versions of applications by using version control. Each CICS bundle, application bundle, and application binding has an ID and version information to uniquely identify it. The version uses major, minor, and micro identifiers, so you can indicate the significance of a change and manage the dependencies between bundles. This concept is called semantic versioning and is taken from the OSGi Alliance. Although it focuses on Java™ packages, you can use the same principles to apply to bundles in general.

Semantic versioning provides a way to increment the major, minor, or micro parts of a version to indicate the compatibility or incompatibility with previous versions of a bundle. For example, bug fixes might increment the micro part of the version, compatible changes increment the minor part of the version, and incompatible changes increment the major part of the version. For more information about semantic versioning, see Semantic Versioning Technical Whitepaper.

You must apply a versioning policy to your CICS bundles, application bundles, and application bindings to deploy and manage updates in the CICS environment. You cannot use an existing version of an application bundle to deploy new versions of the CICS bundles for the application, and you cannot use an existing version of an application binding with a new version of an application bundle. You must update the versions of the application bundle and application binding whenever you update the CICS bundles for the application.

When you change the version of an application, according to the principles of semantic versioning, the new version should reflect the largest change in a CICS bundle that is included in the application. For example, you might change one CICS bundle for an application from Version 1.0.1 to Version 1.0.2, which is a micro version change, and change another CICS bundle for the application from Version 1.2.0 to Version 1.3.0, which is a minor version change. The application bundle that includes these two CICS bundles should therefore have a minor version change, so if the application was previously at Version 2.5.1, it should change to Version 2.6.0.

Results

The new version of the application is deployed on the platform. The CICS bundles that are included in the new version of the application are installed in the appropriate CICS regions, and the resources that are defined inside the CICS bundles are dynamically created in the CICS regions.

When you make a new version of an application available, CICS allows callers to access the application version through its application entry points, which can be PROGRAM or URIMAP resources. For applications that are supported for multi-versioning, if multiple versions are available, callers can either access the highest available application version, or use the EXEC CICS INVOKE APPLICATION command to specify any available application version.