Problem solve Get help with specific problems with your technologies, process and projects.

Under the hood of IBM's CICS Transaction Gateway V9.0

CICS Transaction Gateway V9.0 lets admins run multiple threads through a gateway connector, capture message identification info and more.

Announced last October, the latest version of IBM's Customer Information Control System Transaction Gateway connector will be generally available in December. Version 9 of the connector features numerous tweaks and some interesting updates, including the ability to perform intelligent routing with Cross Component Trace and a push toward vertical integration to fit more work into fewer address spaces.

External Call Interface version 2 updates

Version 9 of the CICS Transaction Gateway (CTG) connector includes many enhancements to version 2 of the External Call Interface (ECI) application programming interface (API). ECI version 2 applications can now run multiple threads through one gateway connection for greater throughput. Of course, with great power comes great responsibility, so multithreaded clients must ensure that various threads don't simultaneously update the communications area that's used to talk with CTG.

In addition, CTG V9.0 extends asynchronous request support to ECI version 2 clients. Asynchronous requests allow a client to send multiple messages to CTG and retrieve the replies at a later time. To get the replies, the client may ask after a specific response or receive the answer for any number of outstanding requests. Another parameter tells the adapter if the client will wait for a reply.

Breadcrumb trails with XCT

CTG version 9 takes part in Cross Component Trace (XCT), which allows participating members to inject or capture message identification information as it processes.

A request can have up to three "contexts," or identification information, at a time. The first, called the root context, belongs to the request originator. The second context -- the parent context -- orginates from the calling process, while the current context originates in the component actively working on the message.

XCT requires WebSphere Application Server (WAS) V8.5 or higher with High Performance Extensible Logging enabled. CTG V9.0 can pass the context information into CICS through IP interconnectivity (IPIC) connections. CICS will stow contexts in the task association data field of CICS monitoring facility records.

Including this identifying information accomplishes several things. First, installations trace messages through an internal network, which may enable them to debug problems more quickly. Second, an enterprise could use the identifying information to perform intelligent routing or application versioning. Lastly, if a data center manager wants, he could use the information to tie WAS and mainframe performance data together for chargeback.

Vertical integration: Going up?

With the advent of the last couple of processor families, IBM seems to be encouraging users to vertically integrate system software to take advantage of features such as cache, HiperDispatch and out-of-order instruction execution. CTG V9.0 is no exception with several new abilities that can do more work in fewer address spaces.

CTG version 9 works with version 7 of the Java Development Kit and can use 64-bit storage. More storage means bigger heaps and more room for worker threads, as well as larger application payloads. IBM does recommend watching CTG's heap size as it may need to be adjusted to avoid excessive garbage collection. Fortunately, CTG provides statistics for understanding its heap usage. For example, IBM recommends computing SE_CHEAPGCMIN, the Java virtual machine heap size after last garbage collection, as a percentage of SE_SHEAPMAX, the maximum JVM heap size. If the ratio is above 70%, you can increase the heap size. If it is below 40%, you can afford to decrease the heap size.

IBM also mentions that using the reference compression -Xcompressedrefs directive can lead to some performance gains. Reference compression hashes 64-bit object references down to 32 bits. There may be a CPU penalty for compressing references; the amount of memory below the 4 GB bar may limit the ability to use this feature.

Version 9 documentation lists the advantages of a 64-bit JVM, along with scenarios and recommended heap sizes.

CTG V9.0 enables further system software integration with some additional support for global extended architecture (XA) transactions. As implemented, CTG's XA support must route messages from the distributed unit of work to the same CICS server. But with the introduction of Dynamic Server Selection (DSS) in version 8, the request exit didn't have enough information to ensure the required consistency. Instead, shops had to create CTG-CICS pairs that would ensure that XA transactions always went to the correct region.

Now, with version 9, the request exit has enough information to route the message to the CICS participating in the global transaction. This will allow IT shops to collapse previously created specialized CTG instances and achieve more vertical integration.

Other notable CICS Transaction Gateway improvements

Version 9 includes other small improvements that have less impact but are still useful, including the following:

  • Users can specify a global timeout value for requests over IPIC connections. Previously, individual applications had to specify timeout values.
  • The client's IP address is available to all exits.
  • A new exit point, RequestDetails, will be called after DSS, but before the request goes to CICS. This serves as another point to collect detailed information about an incoming request and where it is going.
  • Password phrases can be used through External Connection Interface connections.
  • Bidirectional data support automates, to an extent, language conversions that read left to right, as well as those that go right to left.

About the author:
Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support, he has also worked with Virtual Storage Access Method, IBM DB2, IBM IMS and other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career is as an operations architect responsible for establishing mainframe strategy and direction for a large insurance company. He works in south Texas, where he lives with his family.

Dig Deeper on IBM system z and mainframe systems