Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Replacing a tool that allows a server-based program to initiate a CICS program

We are trying to replace a tool that will not work with IBM's TCP/IP. It allows a server-based program to pass a commarea to a listener in CICS and initiate a CICS program to edit data and return responses to the server-based program. Initially, this was done by the Interlink CICS Programmer's toolkit and a purchased VB interface and was done when running CICS 2.1.2. Now we are looking for an option to replace this process and are running CICS TS 1.3. We do not have WebSphere or CTG. Looks to me like ECI is what we want. Do we need CTG to get the CICS Client to allow this? Are the TCP/IP Sockets interface a viable option? Thanks in advance for your able assistance in figuring this out.

You could use either ECI or TCP/IP CICS sockets.

If you use ECI you must use either the CICS Universal Client on a single-user workstation or the CICS Transaction Gateway on an intermediate server. In your question you refer to VB and to a "server-based program" calling CICS. I deduce that you are using VB clients on the desktop and a mid-tier server to connect to CICS.

There are, in fact, two ways you could use the CTG in this kind of configuration.

The first way is to use the CICS Transaction Gateway on the middle tier. You need to confirm that the CTG is supported on your middle tier. In addition I expect that you want to continue using a TCP/IP connection between your middle tier and CICS. If you were to use CICS TS V2.2 this is straightforward because ECI over native TCP/IP is supported in that release of CICS. For use with CICS TS V1.3 the CTG supports a protocol called TCP62. This carries SNA LU6.2 flows over TCP/IP. There are no requirements for SNA runtime support or configuration on the middle tier but on the OS/390 or z/OS host TCP62 requires the use of VTAM and SNA configuration.

The second way is to use the remote Java classes from the middle tier connecting to a CTG daemon running on OS/390 or z/OS. The Java classes (which do not require a license to run on the middle tier) connect to the CTG daemon over TCP/IP (with SSL support as an option). The daemon connects to CICS using the CICS External Call Interface which uses a high-performance cross-memory or XCF (cross-MVS image) transport. This approach has the advantage (for a CICS TS V1.3 user) that the mid-tier connection to the S/390 is native TCP/IP. It has the disadvantage that the daemon, which must run in a separate address space on OS/390, is another logical layer adding complexity to the solution. In addition the invoking application must be written (at least partially) in Java: you may consider this an advantage or a disadvantage.

The TCP/IP sockets interface is also a viable option. Its great advantage is that it does not require any special code on the client or middle tier beyond the all-pervasive socket support. Its great disadvantage is that sockets is a very low level protocol and it is up to the application to provide any additional support beyond simply passing data back and forth. Hence, for example, any security, recovery and data conversion functions are left to the application. In addition the API provided by TCPIP CICS sockets maps closely to a standard sockets API: it does not provide a COMMAREA interface. It is, however, a relatively simple programming exercise to write a program that encapsulates all the sockets calls and issues an EXEC CICS LINK to your existing CICS program.

If you were starting from scratch and were using CICS TS V2.2 I would have no hesitation in recommending using the CTG on the middle tier, even though it does cost money. If you must have native TCP/IP support and cannot upgrade to CICS TS V1.3 consider using the Gateway daemon running on OS/390. Both these solutions use native TCP/IP transport, provide security support and performance optimizations for multi-user three-tier configurations. The CTG, used either way, is a mature, robust and strategic product.

However the requirement for a daemon address space on the host and the need to change the client or middle tier application may be significant disadvantages. It should be possible to code a TCP/IP CICS sockets application that performs essentially the same function as the Interlink support without changing the client or middle tier. This may be an overriding consideration.

There are many considerations to be taken into account. I recommend you read the sections of the Redbook "Revealed! Architecting Web Access to CICS" (SG24-5466) pertaining to the CTG before making your decision.

Dig Deeper on IBM system z and mainframe systems

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.