CICS / WebSphere


Operational efficiency—security extensions. In 2013, the CICS TS Feature Pack for Security Token Extensions was introduced for CICS TS V4.2 and V5.1. In CICS TS V5.2, this function is integrated into the core of CICS to provide better integration of identity mechanisms common in the distributed world. Traditionally, CICS has only natively coped with usernames, passwords and certificates that could be used in service messages or SSL. Web services could use Security Assertion Markup Language (SAML) and Kerberos by using a third-party server, but we were aware that customers perceived disadvantages with leaving the trusted System z platform just to validate the credentials. Customer requests through our Request For Enhancement (RFE) process clearly showed two areas that were in demand, so in response, SAML and kerberos are provided in V5.2.

These security tokens do slightly different jobs: SAML revolves around specifications that allow security authority to be represented in an XML form and is designed to be fully extensible, so applications can have application security that flows with the identity. This contrasts with the existing model, where identity flows in and is then mapped to a set of system-level security permissions that are known only to the z/OS System Authorization Facility (SAF) database. SAML can intercept those through the identity but can also allow the application to have its own bespoke application permissions that can flow with the identity. Kerberos, by contrast, is a more distributed way of providing single sign-on and propagation of identities that’s more secure than username passwords.

The feature pack allowed you to receive SAML assertions, validate them and map them to a SAF user ID and use that SAF user ID to start a task in a pipeline ID for a Web service. This is now extended to include three more assertions. You can now create SAML assertions from inside a CICS region, which is useful if you need to send an outbound token when you send out a request without having received an inbound token. You can also modify existing assertions; that is, add new properties then cryptographically re-sign them and show they were modified within CICS. And finally, you can propagate an assertion so that when a request is received with an assertion and it has been validated, you can reuse and resend that assertion on outbound flows going out over Web services or a RESTful call, because that propagated assertion is available to the requester. typically, a program created a channel and container, which it propagated on a link or start call. Now, you can use the concept of a static channel that survives for the lifetime of the transaction, irrespective of the link level nesting that holds the SAML assertion. For kerberos, validation and mapping facilities are supported, so a token can be received and transformed into a user ID.

A Java virtual machine (JVM) implementation for both Kerberos and SAML is accessible through a linkable API. Both support zero code configuration methods through a Web services pipeline, but the Kerberos implementation uses a local SAF API, so it communicates directly with RACF for validation and doesn’t require a third party server. SAML uses a JVM because more heavyweight XML processing is required. That JVM can be local to the receiving regions, or you can use a smaller set of security-owning regions to handle those SAML JVMs. This approach provides more deployment choices, depending on the needs of the infrastructure and how many JVMs you want, and is implemented using the normal distributed program link technology. This supports a scenario that customers and auditors may require; that is, the security service needs to run in a region that’s isolated from application code (see Figure 3).


Cloud enablement. In general, we’ve continued to build on the cloud enablement that was provided in CICS TS V5.1 and more CICS resources can be defined and managed in CICS bundles. We’ve also provided new support in two areas. First, we’ve introduced a set of capabilities around cloud lifecycle that help manage the risk when making application changes and thus allow smoother crossover between different levels of applications. This is the foundation for our future road map of our multi-tenancy strategy—the ability to have private programs and load libraries for individual applications.

We’ve enhanced the use of application entry points by adding a Universal Resource Identifier (URI) entry point and also support for rapid swapping between versions. Another customer-requested enhancement is a new copy option, available through CICS explorer. You can install a new version of an application, with new load modules that contain code changes, in a region where another version of the same application is running. You can then enable that new version, check that dependencies are met while running the old version, and swap between the new application and the old one, thus providing rapid fallback.

More than one version of the application can be available in the same region at the same time. We provide an API to invoke an application so that routing code can be more intelligent and target a specific version of an application. You could use this for customer routing, where customer A goes to version 1 of an application and customer B goes to version 2 of the application. Another example of use is a routing algorithm where 90 percent of the work goes to one version and 10 percent to another version (and a third backup version is available for unforeseen events). So, the need to keep things in separate regions is reduced. Private program support provides a controlled way for multiple instances of those programs to exist in a region. Because private programs are accessed only from inside the application, rigorous visibility boundaries can be used in the application architecture; only programs that are declared as entry points can be linked to from outside the application. Therefore, this provides a robust and safe way to manage the lifecycle of items such as shared components and application infrastructure.

Cloud enablement with enhanced platforms. In response to other customer feedback, platform support has been enhanced so it’s now possible for someone with minimal CICSplex (CMAS) knowledge or skill to create a cloud instance (see Figure 4). You just need to set up a CMAS management point (a web user interface [WUI] and CMAS pair); you can use CICS deployment assistant for help with this task. Then, there are simple steps to manage everything through the platform definition in a model-based way. So, you create a platform, add a region type by name, and then list the applids of the regions that you want to be part of the region type in the definition. When you deploy, CICS creates the CICSplex SM (CPSM) artifacts and topology, and the configuration required to support that platform. You can then manage and observe that platform, again without needing deep CPSM skills. You can add a new region to a region type dynamically during run-time, remove regions from region type dynamically, or update the configuration and cold start the platform with relative ease.


CICS Version 5 provides a balanced release of new function and improved core value on traditional workloads. There are tools to help extend the reach of CICS to new devices, new markets and new opportunities, and despite being available for more than 45 years, CICS remains as vibrant and essential as any smartphone app—but with more longevity! The new RFE process has allowed CICS customers to shape the new release of CICS, so CICS TS V5.2 not only extends the value of CICS TS V5.1, but also addresses many key suggestions from customers and only 18 months after CICS TS V5.1.


“New Technologies Help Bridge Gap Between Mobile and the Mainframe” available at
“How CICS Helps Eliminate the Batch Window” available at 

2 Pages