When I started in computers back in 1981, there were two things I thought would exist until the earth was engulfed...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
by a swollen, red sun. One was the Berlin Wall. The other was SNA. Well, we know what happened to the former, and the latter doesn't look so good either. Many shops are actively replacing SNA interfaces, of all LU types, with TCP/IP and other Internet protocols. Fortunately IBM offers many ways for old mainframe workhorses to interface with this new fangled stuff. For CICS one of your choices is the CICS Transaction Gateway (CTG).
CTG comes in client and server pieces. The client piece consists of a set of classes enabling Java and C++ clients to talk to the server. The server runs on the host either as a standalone started task or integrated into Websphere. The two parts communicate through TCP/IP. The CTG server talks to CICS through the external call interface (EXCI). EXCI is a protocol CICS uses to communicate between regions but is also a published programming interface any mainframe non-CICS program may use. Note that EXCI uses cross-memory services if the target CICS is on the LPAR and cross-coupling facility (XCF) if it is not.
CTG's client API is relatively flexible and easy to use. One of its chief advantages is it shields the client programmer from a lot of network and protocol details. Although I've never used them, I understand other frameworks such as CCF or JCA can encapsulate the CTG API's.
In its simplest form a CTG client program first creates a gateway object, specifying the URL (or IP address) and port of the server it wants to talk to. After it opens the gateway the program must build an external call interface (ECI) object. At the very least the client must specify the program to be invoked on CICS and a communications area (COMMAREA) to be passed to it. There is no automatic ASCII/EBCDIC translation, so handling of the COMMAREA must be coordinated between the client and server, but, this doesn't preclude binary data. There is also a 32K byte limit on the COMMAREA at this time. For performance reasons it's best to specify the true size of the COMMAREA instead of some default maximum.
Communication in this mode means one trip to and from CICS all as one logical unit of work. Therefore, the client program must understand when data on CICS gets committed. Also, since each transaction is independent, the application server must use some of the same CICS programming techniques that have been in use for years for pseudo-conversational applications to persist information across the physical transactions.
There are many other options in creating an ECI request if you need them, including:
- The target CICS
- A transaction name to be used instead of the default mirror transaction CSMI
- Flags allowing the client to interact with a server program several times over a logical unit of work.
- A host user ID and password if required by the CTG server.
In my next column I'll talk about setting up and operating the CTG server on the mainframe in standalone mode.