How it works: multi-versioning applications

You can install and manage multiple versions of an application at the same time on the same platform instance. With multi-versioning, new versions of an application can be deployed to the platform without the need to disable or remove the previous version and made available to users without service interruption. Multi-versioning enables different users to start different versions of the application, and it makes it simple to switch back to a stable version of an application if a new version turns out to have errors. At runtime, programs can invoke any available version of the application or, for programs that are not aware of multi-versioning, they automatically link to the highest version of the application that you made available on the platform.

You can host two versions of the same application concurrently for use by different groups of user, or you can replace one version of an application with another version for use by all users. For an overview, see Example: hosting two versions of an application concurrently and Example: replacing one version of an application with another. Resources can be made private to each version of the application.

Image showing the CICS system programmer, application developer, system administrator, and user. The system programmer configures the platform, and creates a TRANSACTION resource and z/OS data sets. The application developer creates the original version of the application, and creates a CICS bundle, application bundle, and application binding, to deploy on the platform configured by the system programmer. The application developer exports the original version of the application to the platform home directory, creating v1.0.0 of the application. To implement the bug fix, the application developer creates, packages and exports the new version of the application, creating v1.0.1 of the application. The system administrator deploys, enables, and makes available the original version of the application, v1.0.0, on the platform. To implement the bug fix, the system administrator deploys and enables the new version of the application, v1.0.1, on the platform. When the update has been verified, the system administrator makes the older version of the application unavailable. The user initially enters a CICS transaction and gets the original version of the application. After the system administrator has made the new version of the application available, the user enters the CICS transaction and gets the new version of the application. — Figure 1. Using multiple versions of an application in a cloud solution

Resources can be treated as private to each version of the application

In applications, you package key resources into the application for lifecycle management. These key resources include the programs that are identified as application entry points and application version-specific load libraries. By bringing CICS® TS resource definitions into a CICS TS application, you provide better management for the application throughout its lifecycle. During application development, it is beneficial to describe the resources in a single development environment, and editable by the application developers. When the application is in source code management, it can encompass and track all related artifacts through application deployment. The application can be provisioned and deprovisioned through a single control point, while the states of all of the related CICS TS resources are managed by the system.

Traditionally, applications rely on key CICS TS resources to be provided outside the application, for example, by the CICS system definition data set (CSD). But application entry points for different versions of an application cannot share resource names if the resource is provided by the CSD or CICSPlex® SM Business Application Services (BAS). Multi-versioning enables multiple versions of an application to declare certain CICS TS resources with the same name. Each resource is treated as unique and private to the version of the application.

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, either as part of the application bundle, or as part of the application binding. When you create a CICS resource in this way, the resource is not available to any other application or version that is installed on the platform, and it is not available to other applications in the CICS region. It can be used only by the version of the application where the resource is defined. These resources are known as private resources. For more information, see Private resources for application versions.

The following resources are supported as part of multi-versioned applications:

PROGRAM resources that are defined in CICS bundles that are part of the application.
LIBRARY resources that are defined in CICS bundles that are part of the application.
PACKAGESET resources that are defined in CICS bundles that are part of the application.
POLICY resources
Statements of application entry points
Any resource that is defined as a dependency, or bundle import, for the application.

Other resources can be involved with multi-versioned applications if you manage the resources to avoid resource name clashes between different versions of the application. For example, a URIMAP resource that is part of an application can be renamed when you package and install a new version of the application. Or an application can be designed so that a resource that is not supported for multi-versioning is managed outside the application, but declared as a dependency, or bundle import, for the application. For resources that are, or could be, used by different applications, such as JVMSERVER resources, deploy and manage the resource at the level of the platform, where it can be used by any version of any application that is deployed on the platform.

As you do with a single version of an application, you control users' access to the resources in a multi-versioned application by declaring application entry points.

You can invoke a specific version of a multi-versioned application by using the EXEC CICS INVOKE APPLICATION command. For more information about invoking a specific version of an application, see Invoking a multi-versioned application.

Example: replacing one version of an application with another

Imagine a scenario where a company has a CICS application that users access by using a CICS transaction. A system administrator needs to deploy a new version of the application to fix a bug in the application and expects all users to move at the same time to using the new version.

The system administrator, or the application developer, uses CICS Explorer® to package and export the new version of the application. The system administrator deploys the new version of the application to the platform, then enables the installed application. When the application goes into enabled status, the system administrator knows that the installation was successful. At this point, the older version of the application is still provided to users when they enter the CICS transaction. When the system administrator makes the new version of the application available, CICS immediately provides the users with that version in place of the older version. The users enter the same CICS transaction as before, and there is no need for the users to take any action.

If there is a problem with the new version of the application, users can roll back quickly to the older version of the application. By default, CICS provides callers (such as CICS transactions or other linking applications) with the highest version of the application that you make available on the platform. If the system administrator makes, or keeps, the older version available, and then makes the new version unavailable, users are automatically provided with the older version again. User access to applications is controlled by the application entry points that are declared for the resources in your applications, which can set the resources to be available or unavailable. The system administrator does not need to disable or discard alternative versions of the application to prevent users from accessing them.

In this scenario, because the older version of the application is defective, it is appropriate to disable or discard it after the new version is verified. However, multiple versions of applications that are deployed on platforms can remain available concurrently to users. Programs that are coded to be aware of multi-versioning can access specific major and minor versions of an application by using the EXEC CICS INVOKE APPLICATION command.

Figure 2 shows that projects in CICS Explorer are used to define a platform and package the application. The example application includes a CICS bundle with definitions for a LIBRARY resource and two PROGRAM resources, called PROGA and PROGB. The TRANSACTION resource for the application is defined in a CICS bundle, but it is not deployed with the application. The Platform project, Application project, Application Binding project, and CICS Bundle projects are exported to subdirectories in the zFS platform home directory. A platform definition (PLATDEF) and application definition (APPLDEF) are created for the platform and application, and stored in the CICSPlex SM data repository. The platform definition is installed in the CICSplex to create a platform with a region type that contains the target CICS region. The application definition is installed on the platform to create the CICS bundle for version 1.0.0 of the application in the CICS region. With the information from the CICS bundle, the LIBRARY and PROGRAM resources for the application are dynamically generated in the CICS region. The LIBRARY resource points to the data set on z/OS® with the programs for version 1.0.0 of the application. The CICS bundle that contains the definition for the TRANSACTION resource is also added to the platform, and the TRANSACTION resource is dynamically generated in the CICS region.

Initial IT configuration, described in the figure description and the text following the figure. — Figure 2. Example topology for Version 1.0.0 of the application

Figure 3 shows that, for Version 1.0.1 of the application, the LIBRARY resource definition in the CICS bundle is updated to point to the data set with the new versions of the programs for the application. The other resource definitions for the application are not changed. The CICS bundle project that contains the resource for the CICS transaction also does not need to be updated because it is deployed separately.

CICS Explorer is used to package the new version of the application. The new application version includes version 1.0.1 of the CICS Bundle project that defines the resources for the application. New subdirectories are created for the new versions of the application and application binding, but the CICS bundle is stored in the same bundles subdirectory. An application definition (APPLDEF) is created for version 1.0.1 of the application, and stored in the CICSPlex SM data repository. The name of the APPLDEF resource is the same name that was used for the older version's APPLDEF resource, but the version number is changed to match the new version of the application. The new application definition is installed on the platform to create the CICS bundle and resources for version 1.0.1 of the application in the CICS region. The CICS bundles and resources for version 1.0.0 of the application are still installed in the CICS region, but the TRANSACTION resource, which has not been updated, now points automatically to Version 1.0.1 of the application.

The CICS region now hosts the new version of the application. Private LIBRARY and PROGRAM resources for the new version of the application are dynamically created in the CICS regions when the CICS bundle that contains the resources for the new version of the application is installed. The new versions of the programs for the application are stored in a different Partitioned Data Set (PDS) or Partitioned Data Set Extended (PDSE) on z/OS. The updated LIBRARY resource for the new version of the application references the new data set. The CICS transaction that runs the application is not involved with the update process, and it is unchanged. When users run the transaction, CICS automatically provides users with the highest available version of the application, so the program for version 1.0.1 of the application now runs.

Example: hosting two versions of an application concurrently

Imagine a scenario where a company has a CICS application that is presented to users through a browser interface as a web application, with the presentation logic hosted in a Liberty JVM server. The company plans to introduce a new version of the application. The change to the application is significant and, to avoid disruption to the business, the company doesn't want all of the users to move to the new version at the same time.

The system administrator deploys and makes available both versions of the application in the same CICS regions that are part of a platform. The users are directed to either the new version or the older version of the application by using different URLs.

Figure 4 shows that, for Version 1.0.0 of the application, projects in CICS Explorer are used to define a platform and package the application. The application includes a CICS Bundle project that packages the web application as an OSGi Application Project contained in an enterprise bundle archive (EBA). The URIMAP resource for the application, called INDEX, is created in a CICS bundle and deployed with the application binding. A Liberty JVM server is also defined using a CICS Bundle project. The projects are exported to subdirectories in the zFS platform home directory. A platform definition (PLATDEF) and application definition (APPLDEF) are created for the platform and application, and stored in the CICSPlex SM data repository. The platform definition is installed in the CICSplex to create a platform with a region type that contains the target CICS region. The application definition is installed on the platform to create the CICS bundles for version 1.0.0 of the application in the CICS region. With the information from the CICS bundles, the URIMAP resource for version 1.0.0 of the application, named INDEX, is dynamically generated in the CICS region, and the resources for the web application are deployed in the Liberty JVM server.

Figure 5 shows that, for Version 1.1.0 of the application, CICS Explorer is used to package the application. The new application version includes version 1.1.0 of the CICS Bundle project that packages the web application, and the OSGi Application Project is also re-versioned to Version 1.1.0. A new URIMAP resource for the new version of the application is created in a CICS bundle and deployed with the new version of the application binding. The projects are exported to subdirectories in the zFS platform home directory. New subdirectories are created for the new versions of the application and application binding, but the CICS bundles are stored in the same bundles subdirectory. An application definition (APPLDEF) is created for version 1.1.0 of the application, and stored in the CICSPlex SM data repository. The name of the APPLDEF resource is the same name that was used for the older version's APPLDEF resource, but the version number is changed to match the new version of the application. The new application definition is installed on the platform to create the CICS bundles and resources for version 1.1.0 of the application in the CICS region, alongside the CICS bundles and resources for version 1.0.0 of the application.

The CICS region handles the workload for the new version of the application as well as the workload for the older version of the application. The URIMAP resource for Version 1.1.0 of the application, called INDEX11, is dynamically generated in the CICS region and the resources for Version 1.1.0 of the web application are deployed in the Liberty JVM server. The CICS bundles for the original version of the application are still installed in the CICS region and the URIMAP resource called INDEX and the resources for Version 1.0.0 of the web application are still available. Therefore, both versions of the application are present and available in the CICS region, and are accessed by the different URLs that are specified on the different URIMAP resources.