How can I phase in the new version of a CICS Application?
MatthewWebster 060000AMGC Comments (3) Visits (5336)
In my previous article “Wha
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:
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 “Mak