In my previous article “What is CICS Application Multi-versioning?” I described how the new multi-versioning capability in the CICS TS V5.2 open beta could be used to eliminate name clashes when hosting independently developed applications on the same CICS platform. This allows you to take advantage of the increased operational efficiency and reduce the number of regions required. In this article I will explain how use to the multi-versioning capability to increase service agility.
Service agility allows you to deploy a new application or in this case a new version of an application with the confidence that users will not be impacted. This means not only ensuring continuity of service i.e. zero down time for the application but also the ability to quickly back-out a change if a problem occurs.
In the CICS TS V5.2 open beta we have introduced a new application available state in addition to the existing enabled state. This allows you to install and ENABLE a new version of an application while user requests are still routed to the old one. Only when you make the new version AVAILABLE are new requests routed it. This allows you to ensure it is properly ENABLED i.e. all dependencies satisfied, resources enabled and entry points declared across all the regions on the platform before it’s “open for business”. It also allows you to easily switch back to the old version if there’s a problem.
In this example Application A version 1.0.0 is already installed and AVAILABLE. The entry point E1 can be called from program S using a traditional EXEC CICS LINK. In fact the owner of program S doesn’t need to know that program E1 is actually an application entry point. But there’s a bug in program P that you want to fix.
First you package and install a modified program P’ in version 1.0.1 of Application A. Then you ENABLE the application to make sure everything is OK. While you are doing this, program S will still be calling version 1.0.0.
When you are ready make, version 1.0.1 AVAILABLE and program S will now use the new version. Any previous requests will complete normally using program P. Version 1.0.0 is still AVAILABLE but CICS always routes requests to the highest available version of an application.
If the update doesn’t fix the bug or made it worse you can easily revert to version 1.0.0 of Application A by making version 1.0.1 UNAVAILBLE. This is because you still have the old installed and ENABLED program P. All new requests will immediately go to the old version of the application so there should be no interruption to service.
This approach has a number of advantages over just loading a new copy of program P as you might have done if it wasn’t part of an application:
- You can update multiple resources at the same time: what if you need to change program Q as well? By packaging the required updates in a new version of the application you can guarantee to get either the old versions or the new versions of both P & Q
- You have total control of the update: all new requests go to version 1.0.1 while those tasks still using version 1.0.0 complete normally. If you make version 1.0.1 UNAVAILABLE all new requests revert to version 1.0.0
- You have better diagnostic information: each task is associated with either Application A version 1.0.0 or version 1.0.1. All messages, Monitoring, etc will identify the specific application version so you can tell whether program P’ fixed the problem
- You have an audit trail: changes in the application and CICS bundles can be recorded in your source control management system. You can see who did what and when
- You can easily undo the update: it is simply a matter of making the new version UNAVAILABLE to back out the update. The process can even be automated if you are prepared to write a utility that looks for any problems e.g. messages or abends and the calls the right API
One thing that might concern you at this point is footprint. Haven’t you just doubled the storage needed for the application code during the time period when you phase in the new version? The answer is no because you can share the programs that are the same i.e. E1 and Q so you only need extra storage for P’.
In this article you have seen how to use multi-versioning to simply and reliably phase in a new application version to fix a bug and easily revert to the previous version if a problem occurs. But what if you actually want to host two different versions simultaneously on the same platform, perhaps to allow a subset of users to beta test a new feature. In the next post I will show you how you can do this using a Liberty JVM server.
For more information please see “Making unavailable, disabling, and discarding applications” in the CICS Transaction Server 5.2.0 open beta Knowledge Center.