The CICS transaction gateway

When I started in computers back in 1981, there were two things I thought would exist until the earth was engulfed by a swollen, red sun. One was the Berlin Wall. The other was SNA. Well, we know what happened

    Requires Free Membership to View

    Login

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).

 

CICS statistics: Reporting and predicting systems behavior

Using DFH$MOLS with CMF performance records

Using CICS dump tables to manage problems in online systems

Manage CICS workloads with transaction classes

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.

 

This was first published in May 2006

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top