Sep 15 ’14

Reach for the Clouds: CICS TS for z/OS V5.2 Adapts to New Technologies

by Nick Garrod in Enterprise Tech Journal

CICS TS for z/OS V5.2, and a set of tools that complement the capabilities of the run-time, address IBM customers’ greatest concerns, which include the ability to control costs, deliver new business value faster and adapt to new technologies—particularly mobile and cloud.

In CICS TS V5.1, more than 100 customer requirements were implemented and delivered under the messages of operational efficiency and service agility with cloud enablement; in this latest release, an additional 100-plus requirements have been satisfied.

In 2013, IBM introduced several feature packs and solution packs to bring new capabilities and value to CICS. Now in 2014, the capabilities of those two feature packs, plus some improvements, have been rolled into the new release of CICS. But this new release doesn’t just build on the foundations laid in V5.1. Here we outline the enhancements to support IBM’s high-level themes of service agility and operational efficiency with cloud enablement to make this the strongest release yet of CICS.

Service Agility: Hybrid Applications and a Single Run-Time
In CICS TS V5.1, customers showed great interest in the support for the WebSphere Application Server (WAS) Liberty profile and the features required to port or reuse application code:

Converging capability levels. CICS continues to provide an ever-increasing level of support for Liberty profile-based features. In CICS TS V5.2, the focus is on enabling, porting and reusing components and allowing third-party applications to run in Liberty. There are three main areas of enhancement:

Java Transaction Architecture, which allows Java components to run inside CICS and integrate with the underlying unit of work
A Java application program interface (API) that uses Java transactions (rather than a CICS-specific API) for processes such as two-phase commit. This feature is fundamental because other feature function library components use that API to integrate with the transaction manager.
JAX-WS and JAXB support, which allows Java Web service support in Liberty. (JAX-RS and JavaScript Object Notation [JSON] support were already available in a feature pack released in 2013 but now SOAP and XML payloads are supported in the Liberty server, providing a solution to port from a bespoke AXIS2 implementation to a more standard one.)
Fidelity of code. CICS V5.2 also introduces support for the DataSource Java class as a way for Java applications running inside enterprise servers to establish connection with a database. Most Java components want to use a DataSource implementation, and this support removes the current requirement to change code and use a driver manager (a proprietary DB2 API) to access the CICS/DB2 connection. DataSource implementations can be configured in XML configuration files and customized to where they’re pointing, which database to connect to and the type of data source, which provides more application portability. A second advantage is that AXIS2 promotes more type 4 JDBC connectivity to a remote DB2 database for a CICS region that runs Liberty. Traditionally, you could only connect directly to a DB2 database on the same LPAR as CICS. This is still true for existing COBOL or Java applications, but a Liberty application running inside CICS can use the type 4 JDBC connectivity that Liberty provides to connect with a remote DB2 database. If you use this function, you can also use the JTA support to integrate the transaction management of the remote DB2 update with the underlying work being performed by the Liberty application.

Security support—target for third-party Liberty apps. Additional security support is provided in CICS TS V5.2 to allow forward integration between the Liberty security model and the CICS security model. This lets you use the vast security features in Liberty, such as HTTP basic authentication, single sign-on using LTPA cookies, form login, trust association Interceptors and SSl client certificate mapping. these are the types of mechanisms used by apps that you might want to port into CICS.

Service agility—mobile integration. CICS now provides support for the creation of RESTful services for JSON payloads that work in the same way as our Web services support—using all the same infrastructure. So, it will be very familiar to anyone who has already worked with Web services in CICS. This capability was introduced as a feature pack for V5.1, and is now integrated into the base of V5.2 so that installation and configuration are streamlined. It includes key enhancements to the JSON mapping technology in the feature pack around Liberty and COBOL mapping (see Figure 1).


Operational efficiency—more policies, more control. The policy-based management capability introduced in CICS TS V5.1 received a lot of positive reaction and in V5.2, we’ve doubled the number of threshold types that can be monitored. This capability provides very low cost, heavily integrated monitoring of key task behaviors and flexible actions to take if these thresholds are broken or transgressed. The actions are unchanged from V5.1; you can abend a rogue task, issue a message or emit an event that can trigger additional processing. We’ve added the new thresholds that customers requested most; for example, elapsed time on a user task (in V5.1, CPU time is available), the number of start or syncpoint requests a user task makes, and temporary storage queue and transient data queue requests (see Figure 2).


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