CTG, the CICS Transaction Gateway, is an IBM product that has been around for a long time and is largely deployed in mainframe shops.
CTG is usually used from a Java client to make outbound, synchronous, calls to a CICS program. In this case, the API offered to Java clients is known as ECI (External Call Interface ). Because ECI is how most users access the CTG some of them refer to the CTG itself as ECI.
CTG is a separate product from CICS itself. Some people confuse both (probably because the names are so close: CICS Transaction Server and CICS Transaction Gateway).
CTG runs in a Java VM that could sit on z/OS (in the Unix System Services environment) but most frequently runs off a distributed server. It is also frequently used in conjunction with WebSphere and as such, can be thought of as middleware between WebSphere and CICS.
CTG’s major strength is transaction support and J2EE integration. It supports the JCA connector architecture and provides 2-phase commit and XA support.
Although CTG might sound like the definitive solution for CICS/java integration, a number of users are considering moving away from it.
I can see 3 reasons why this is happening:
- The emergence of integration standards such as Web Services (and the slow erosion of older standards such as J2EE/JCA)
- Loose coupling as a preferred architecture pattern over tight coupling
- The Open Source revolution which drives more and more enterprises to consider Open Source software as a valid alternative to closed products
An uncomfortable position within IBM
Today, CTG is competing internally with other IBM integration features particularly when it comes to SOA. You can of course create Web Services on top of JCA but there are more efficient alternatives within IBM.
CICS itself has built-in support for SOAP Web Services. This feature, known as CICS Web Services, offers programmers a standard way to call CICS programs without the need for CTG.
WebSphere, when it is installed on z/OS, also now offers CICS integration directly (an option known as OLA for Optimized Local Adapters).
WebSphere MQ can also be used to support Web Services.
CTG seems to have less and less room within the IBM offering.
Not a serious contender for loose coupling
CTG has support for asynchronous calls but it is hard to justify the heavyweight 2-phase commit support in such a setting.
Asynchronous calls can’t support 2-phase commit and therefore could run with a much more lightweight infrastructure.
Furthermore, IBM has WebSphere MQ as its preferred asynchronous programming interface so it is hard to see how CTG could be justified to support a loosely coupled architecture.
Not Open Source
CTG is not Open Source and is a complex black box that users struggle to operate.
It is hard to tell how much this costs companies but I have met with very frustrated customers.
CTG is not free of charge but it is often bundled with WebSphere, CICS and other products and it is difficult to isolate its cost from the rest.
The true cost becomes apparent though for customers migrating off WebSphere because the bundle offer does not apply anymore.
Poor and confusing tooling
So far we have discussed the runtime aspects of CTG but how about the development time tooling? How do you map the target COBOL data structures to java beans?
Here there is some confusion. This mainly stems from IBM changing names and branding several times over the last few years.
The COBOL mapping tools are usually an option buried deep into a much larger developer product:
- Enterprise Application Builder (EAB) within VisualAge for Java (No longer supported)
- J2C within RAD (Rational Application Developer for WebSphere Software which used to be named WSAD for WebSphere Application Developer)
- J2C(?) within RDz (Rational Developer for z/OS which seems to have been recently renamed Rational Developer for zEnterprise)
I am not sure about J2C being part of RDz. RDz seems to cover CICS Web Services with tooling that looks quite different from J2C. I know CICS had a “Web Service Assistant” a sort of command line utility to map COBOL to XML. RDz might have some GUI on top of that.
Although these tools are Eclipse based, they are not open source. There is usually a per seat license to be purchased.
There are several issues with J2C:
Users complain that the java beans mapping COBOL structures that J2C produces are awkward, the morphology does not always match the original COBOL structure (flattening), property names derived from COBOL data items are unfriendly (use of double underscores), arrays are turned to java arrays instead of more flexible java.util.List, no support for REDEFINES, …
J2C also produces java classes that intermingle java to COBOL transformation with remote execution of CICS programs. This tight coupling of language translation features with RPC mechanism was customary 10 years ago but has proven quite limited since then. This is because integration today is a lot more than calling CICS programs. Mainframe data can originate from files, messages, non IBM transaction monitors, etc… Also data might have to be processed asynchronously, as part of a flow (BPEL) or even in batch which was completely missed by the JCA specs.
If LegStar was architected on the same principles, it would be impossible to support ESB’s or ETL’s for instance.
LegStar might help
To summarize the CTG situation today, it has relatively limited tooling, is tightly related to JCA and has a weak position within the IBM offering.
For users considering Open Source and loosely coupled alternatives to CTG, LegStar could come handy.
At LegSem, with help from some of our pioneer users, we are building a service offering to help customers move away from RAD/CTG.
Our first step is to develop migration tools that can exploit meta data produced by tools such as RAD.
We are also working on an ECI transport for users who want to adopt LegStar COBOL Transformers (to replace the J2C beans) but would rather stick to CTG to get to their mainframe.
If you are interested, drop us a message at admin (at) legsem (dot) com or use this form.
