CICS feature toggles and continuous delivery

In order to meet growing needs for more rapid delivery of key capabilities, CICS® TS continuous delivery makes new functional enhancements available on a much shorter cadence so that you can use them without waiting for the next release. Some of these new capabilities require changes to the CICS configuration - the kind of changes that you would previously expect only with a new release of CICS. To make it easier for you to make the necessary configuration changes between releases to enable the new capabilities, feature toggles are introduced, giving you great flexibility and control in enablement and disablement of such capabilities during run time.

For a list of available toggle-enabled features by release, see Toggle-enabled features, support by release, and follow the links in the feature list table to locate the information that describes the feature toggle and configuration options for enabling a specific toggle-enabled feature.

Production-ready or work-in-progress?

Traditionally, in software development, the feature toggle is used to release work-in-progress features. In CICS, the feature toggle doesn’t indicate a different quality of feature. All the features that you can toggle on or off are as ready to use as the rest of the CICS release.

In a generally-available release of CICS, a feature that is enabled by a feature toggle goes through the same development processes as any other feature.

In an open beta release of CICS, a feature that is enabled by a feature toggle is, like the rest of the product, under development. In beta releases, the flexibility of feature toggles allows you to test potential new function and provide feedback to the CICS team before the function reaches a production release. This kind of feature toggle might not make the product documentation but is communicated as part of the beta program.

How can you benefit from CICS feature toggles?

Using CICS feature toggling mechanism has the following benefits:

Rapid enablement and configuration of new features for trial in your test environment and for use in your production environment
Flexibility and easier control over the features that are switched on for use and the CICS regions where the enabled features are available
Lower risk of trying and using new features

The feature toggling mechanism is light-weight in size compared with SIT changes that typically come with a large chain of service per-requisites. It works like a SIT change but on a temporary basis. It is non-intrusive because if you don’t enable the feature, there is no impact on system behavior. Usually, toggle-enabled features are disabled by default.

How does feature toggling work?

In CICS, a feature toggle is a configuration option to specify whether a CICS region supports a new function. The feature toggle sets the new function on or off. Some features require additional configuration options. These options are specified in a similar way to the feature toggles themselves.

The name of the feature toggle is fully-qualified. The CICS toggles all start with com.ibm.cics.

Figure 1. Example of a feature toggle

Here’s an example of the feature toggle to enable MFA in the CMCI:

# enable the CMCI JVM server (only applicable to the WUI region)
com.ibm.cics.cmci.jvmserver=true

You define the feature toggles in feature toggle configuration files. There are two types of feature toggle configuration files: a common file and a region-level file. Both files are optional. If neither is present, default values are used.

You can use a common file to control the features that you want to enable in a group of CICS regions that share the same zFS directory specified by the USSCONFIG system initialization parameter. By use of the optional parameter finalize in the common file, you can lock specific settings that are defined in the common file, preventing region-level files from overriding these settings.

You can use a region-level file to try out a feature on a single region before it is enabled in the production environment.

For detailed instructions on how to specify feature toggles and on how to set up feature toggle configuration files, see Specifying feature toggles.

The feature toggle configuration files are read at CICS startup, immediately after system initialization reads the SIT parameters. The common file is read first, followed by the region-level file. Settings in the region-level file overrides settings in the common file except common settings that are specified with the parameter finalize.

Unlike SIT overrides, CICS ignores unknown feature toggles. The feature properties file doesn’t have dependencies on the level of service that is applied. When you are using a common feature toggle file between multiple regions, if some regions have the service applied which use the feature and some don’t, then those regions that don’t know about the feature will ignore the toggle.

You can use the following SPI and XPI to inquire on the settings of feature toggles and to browse the feature toggle configuration of CICS regions:

INQUIRE FEATUREKEY(data-value) VALUE(data-area)

How long will a feature toggle be there?

CICS feature toggles aren’t intended to replace SIT parameters as the way to configure CICS. They are temporary configurations.

Feature toggles will generally be withdrawn one or two releases of CICS after their introduction. Feature toggles that are introduced for evaluation in beta releases might never surface in a generally-available version of CICS.

For some functions, feature toggles and their configuration options will evolve into a regular SIT parameter in a future release of CICS. In other cases, they will disappear as their associated function becomes part of the CICS base function.

Is it possible to add user-defined feature toggles?

As a client or a vendor, you can use the feature toggle properties file to specify your own feature toggles and configuration options.

For example, as an alternative to using the CWA or a data table for defining constants, you can specify feature toggle properties, and then use the SPI to read the value of a feature keyword. An application can use this information for its own configuration purposes.

If you use your own feature toggles, for uniqueness, you should use a prefix in the form of com.company.application.