HostBridge Technology

A HostBridge White Paper

Content > White Papers

Socket II: Optimizing CICS® Socket Processes for a Financial Industry IT Provider

HostBridge Socket Support

From time to time, we at HostBridge write Letters from the Trenches describing one-on-one engagements with real customers. We love these opportunities because we get to roll up our sleeves and work closely with very bright people to understand and address tough technology and business challenges. When we think the story of our efforts might benefit other people and organizations, we publish it as a Letter from the Trenches. We hope you will find this one interesting and valuable.

A European IT services and solutions company – owned jointly by three commercial banks, two savings banks, a national savings bank association, and three payment card processors – provides central clearing and settlement systems, multi-tenant banking solutions, and e-invoicing and e-payment systems to financial institutions, government agencies, and other organizations. In late 2012, the company invited us on site to test whether HostBridge Socket Support could address a recurring performance issue.

On the first day of each month, the company processes 15 million CICS socket transactions. Fifty percent of these are processed during a peak four-hour period. The company’s main driver in calling on HostBridge was to see if they could reduce this peak CPU burn and open up “headroom” to run other valuable processes on System z.

We visited the company’s headquarters to test HostBridge Socket Support as a high-performance alternative to IBM’s CICS Socket Support. Using the company’s standard test facilities, we assessed the GP CPU time reduction that might be achieved with HostBridge Socket Support.

This Letter from the Trenches documents our testing procedures and findings. We hope they will be of value to anyone with CICS-based socket applications.

HostBridge Socket Support Background

HostBridge Socket Support is a suite of high-performance technologies developed specifically to address performance issues associated with CICS socket-based applications. When replacing IBM’s CICS Socket Support, these technologies enable users to:

CICS Socket Support Background

CICS Socket Support is provided by IBM as part of z/OS® Communications Server. (It is important to note that it is not a feature of CICS Transaction Server, which uses the CICS Socket Domain.) IBM’s CICS Socket Support includes Socket APIs, Listeners, and definition and management components. Introduced circa 1992, it is a well-documented workhorse still used by many organizations worldwide.

CICS Socket Support is best understood as a fully functional socket application infrastructure on top of the socket support natively provided by z/OS and USS. It is accurate to view CICS Socket Support as a “socket proxy.” Historically, this approach allowed IBM to (a) overcome the limitations of the CICS QR TCB architecture, and (b) decouple CICS Socket Support from the underlying transport when necessary. Though these attributes were important in times past, they can produce unnecessary overhead in modern CICS application environments.

A key point is this. When an application performs socket operations via one of the supported CICS Socket Support APIs, the application is not interacting directly with the socket. This has an important ramification – once a socket is “owned” by CICS Socket Support, it cannot be shared (i.e., passed) across socket APIs. For example, once a socket connection is accepted via EZASOKET, it cannot be passed to an application using the USS Socket API – or vice versa.

To restate: if the CICS Socket Listener is used to accept the socket connection, from that point forward all socket operations must be performed via the CICS Socket Support API. Thus, replacing the CICS Socket Listener is the starting point for improving performance.

Initial Configuration: Before HostBridge

The diagram below depicts the existing configuration used by the IT provider:

Figure 1

The diagram illustrates that CICS Socket Support acts as an intermediary between the CICS transactions and the actual USS Socket Services.

Initial Benchmarks

To lay the foundation for comparative analysis and assess potential GP CPU savings, the company and HostBridge jointly decided to exploit Echo mode, a feature of Handler transactions. When an Echo request is received, the Handler transaction simply sends back the inbound message with a 5 byte prefix. This Echo test was deemed to be fair and desirable because it isolates the resource consumption of the socket infrastructure and does not include the actual application processing.

CICS Socket Support Benchmark Configuration

The load test was driven by a test client running on a PC. The following diagram depicts the components involved in benchmarking the existing configuration using the Handler transaction Echo mode:

Figure 2

HostBridge Socket Support Benchmark Configuration

The following diagram depicts the components involved in benchmarking HostBridge Socket Support and assessing the potential savings:

Figure 2

Initial Results

A standard test cycle of 5,000 Echo requests was used as a comparison benchmark. Five test cycles were run using each configuration. The GP CPU consumption for each configuration was as follows:

Figure 2

This initial benchmark was very encouraging since it indicated a potential GP CPU reduction of roughly 76%. Per test parameters, this reduction in GP CPU time is attributable solely to the alternative approach to handling the socket interface and operations.

Proposed Solution

Given these results, HostBridge proposed an initial solution that exploited the following features of HostBridge Socket Support:

The diagram below depicts this initial proposed solution. This solution appeared to have the lowest risk and highest reward, at least initially.1

Figure 2

By eliminating the CICS Socket Support layer, significant efficiency is achieved. The only requirement of this approach is that customer programs must:

Anticipating that the interjection of an EZASOKET API emulation would add a small bit of overhead, we performed another round of Echo tests to compare GP CPU consumption:

Figure 2

The HostBridge Socket Support EZASOKET API added a small bit of overhead as expected. But the GP CPU reduction was still a substantial 74%. Our test data indicated that the average GP CPU savings per 5,000 Handler transaction requests would be .926 seconds. We used this figure to estimate the value proposition outlined next.

Value Proposition

It was clear that HostBridge Socket Support could save this customer significant GP CPU cycles for socket applications and open up capacity for other GP-based workloads. In addition, by drastically simplifying socket-related activity under the covers of CICS and z/OS, the overhead associated with task switching and dispatching was reduced. But the question remained: What was the monetary value of the savings?

As noted at the outset, a primary motivator for the company was to reduce their peak MSU utilization, which drove up their mainframe costs. On the first day of each month, the company processes approximately 15 million Handler transactions, half of which are processed during a peak period of four hours.

With this information and our benchmark results, it was possible to calculate estimated savings:

Our final step was to determine how this reduction in CPU minutes during the peak four-hour period would relate to MSUs.

IT Provider’s Machine Information

The company has the following IBM System z machines – both z114s:

Cheryl Watson’s System z CPU data is considered authoritative (I have included the Z02 in the following table as a point of reference; it is the highest rated model in the group):

For our analysis, we will considered the Y02. In the table below, the bold cells show HostBridge extrapolations and calculations:

We measured region-level CPU burn for various configurations. We also differentiated between CPU burn associated with socket applications and with socket infrastructure because we were trying to change only the socket infrastructure in and out of CICS, not the socket applications.

Based on this analysis, it follows that on a 2818-Y02 the estimated savings would be:

347.25 GP CPU seconds = 15.05 MSU

Further Testing

The conclusion of our testing and analysis was clear. This customer was indeed able to achieve substantial reductions in GP CPU cycles during the peak four-hour period it experienced each month. Doing so, they were also able to run additional high-value System z processes at the same time.

We also recognized, however, that our analysis was only one way to estimate the MSU savings due to HostBridge Socket Support and that it was based on a particular test scenario. With that in mind, we launched a second round of testing, this time focused on shifting socket processes to the zIIP specialty engine. We look forward to sharing these results in another Letter from the Trenches coming soon.


[1]HostBridge Socket Support can run on the zIIP as well as the GP; our second proposed solution to this customer focused on further improvements that could be achieved on the zIIP. We look forward to sharing results of zIIP testing in an upcoming Letter from the Trenches.

Copyright Notice

Copyright © 2011-2015 by HostBridge Technology. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, optical, chemical, manual, or otherwise, without prior written permission. You have limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry this copyright notice. No other rights under copyright are granted without prior written permission. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose.

Revision date: 6/12/2014


HostBridge and the HostBridge logo are trademarked by HostBridge Technology. All other trademarks mentioned are property of their respective owners.