Understanding How BEA eLink TCP for CICS Works

To understand how the BEA eLink for Mainframe TCP for CICS (hereafter referenced as eLink TCP for CICS) product works, you should know how the product performs the following functions:

• Starting the Listener Program

• Running BEA eLink TCP for CICS

• How eLink TCP for TUXEDO Translates Data

Each of these operations is described in the following subsections. Additionally, this document describes some programming considerations that may be useful when you develop or change programs that interoperate with BEA eLink TCP for CICS.

Starting the Listener Program

The Listener program is supplied by IBM and is part of the Sockets for CICS software product which must be purchased from IBM.

Note: Before you can use BEA eLink TCP for CICS, you must install and configure both IBM TCP/IP and the Sockets for CICS product as outlined in the documentation that accompanies those products.

The Listener's job is to wait for connection requests at a particular network address and port of your choosing. When the Listener receives a connection request it invokes the appropriate CICS program automatically, based on the name supplied as part of the Listener's connection protocol buffer. For example, if the Listener receives a connection request from eLink TCP for TUXEDO running on a remote BEA TUXEDO node, it processes the connection and invokes the BEA eLink TCP Handler.

Running BEA eLink TCP for CICS

The eLink TCP Handler is invoked automatically by the Listener process. Once invoked, the Handler takes control of the socket connection and retains control until either the Handler is shut down or until there is a network problem that affects the socket connection. The Handler processes service requests up to the configured multiplex count. To process more service requests than the configured multiplex count, start more than one Handler. Due to the limitations of the IBM Sockets for CICS Listener, the maximum number of concurrent socket connections is 50, which means that up to 50 Handlers can be processing service requests at any one time.

Initializing the Handler

The very first service request that is sent from the eLink TCP for TUXEDO gateway running on a remote BEA TUXEDO node causes the following to occur:

1. CICS Sockets Listener starts the eLink Handler

2. Listener issues a givesocket() function call

3. Handler issues a takesocket() function call

4. Listener resumes listening for new connection requests

5. Handler communicates directly with the remote eLink TCP for TUXEDO gateway using TCP/IP

1. The eLink TCP Handler receives the request from the remote eLink TCP for TUXEDO gateway (in the BEA TUXEDO region) over TCP/IP. If necessary, the data will have already been translated and/or converted into the proper data format or layout.

2. If the multiplex count is 1 and security is disabled, or if the service request came from a version of eLink TCP for TUXEDO prior to Version 3.0, then the following tasks occur.

   1. The Handler issues a CICS LINK command to execute the program specified in the eLink TCP protocol header. With the LINK command it also passes along any request data provided by the client application that made the original BEA TUXEDO service request.

   2. The Handler waits for the CICS program to finish and receives any returned data from the CICS program.

   3. The Handler transmits the response to the remote eLink TCP for TUXEDO gateway.

   4. The Handler stays connected to the remote gateway awaiting another service request.

3. If the multiplex count is greater than 1 or security is enabled, then the following tasks occur.

   1. The Handler issues a CICS START TRANS call with the transaction specified in the Inbound Service File for the service specified in the eLink TCP protocol header. The transaction should be the same as the Application Handler program.

   2. For any completed service requests, the Handler retrieves the response data from the Application Handler.

   3. The Handler transmits the response to the remote eLink TCP for TUXEDO gateway.

   4. The connection between the Handler and the gateway remains and the Handler waits for another service request.

      Note: If security is enabled, the CICS START TRANS call uses the USERID=userid specified in the eLink TCP protocol header.

For tpacall/TPNOREPLY requests, the remote program is invoked by a CICS START TRAN command and no data is returned to the original caller. In this case, a unique transaction must be defined for the service. Use the Inbound Service Information screen to enter this unique transaction name rather than using the transaction name that starts the Application Handler.

Shutting Down the Handler

When the network connection is lost, the Handler process automatically shuts down. The next service request sent causes the Listener to automatically start a new Handler, if necessary.

Shutting down BEA TUXEDO on the remote gateway to which the Handler is attached will issue a CICS administration command to cancel the BEACIC00 program.

Use the eLink TCP for CICS Maintenance System described in "Configuring and Administering BEA eLink TCP for CICS" to disable the Handler. This will cause the Handler to clean up its tables and shut down gracefully. The next service request sent causes the Listener to automatically start a new Handler.

Use the supplied shutdown transaction BDWN. This will cause ALL Handlers to shut down gracefully. The name of the BDWN transaction may have been changed at your site during installation. Check with the person who installed BEA eLink TCP for CICS at your site.

Starting the Requester Program

The Requester is started automatically when the first service request for it is made by a CICS client program. At that point, the Requester establishes a connection with its remote endpoint and updates its control tables with run-time information for use by subsequent requests. If the connection with the remote endpoint is lost for any reason, the Requester attempts to re-establish the connection automatically. After a configured number of unsuccessful connection attempts, the Requester will mark itself disabled.

If the gateway receives additional service requests, they are accommodated as long as the maximum multiplex count for the existing connection is not exceeded. Also, additional connections are opened, as necessary, until the configured maximum connection count is reached or all requests are accommodated.

Processing eLink TCP for CICS Originated Service Requests

1. The CICS client program (your program) issues an EXEC CICS LINK command to the BEA eLink TCP for CICS Pre-requester.

2. The Pre-requester verifies that the request is valid, and then determines whether a Requester has been started for the specific endpoint for which this request is destined. If a Requester is not already running, the Pre-requester starts one.

3. The request is then handed over to the Requester.

4. The Requester transmits the request information to the remote BEA TUXEDO region.

5. If the request is a type that needs a response, the Requester receives that response back from BEA TUXEDO, and hands the data over to the Pre-requester.

6. The Pre-requester issues an EXEC CICS RETURN command to the client program (your program). The client receives its response in the commarea.

There are two ways to shut down the Requester:

• Use the administrative tool (described in "Configuring and Administering BEA eLink TCP for CICS") to disable the Requester. This will cause the Requester to clean up its tables and shut down gracefully. It will also prohibit any service requests to invoke it. When you are ready, use the administrative tool to enable the Requester.

• Use the supplied shutdown transaction BDWN. This will cause ALL Requesters to shut down gracefully. The name of the BDWN transaction may have been changed at your site during installation. Check with the person who installed BEA eLink TCP for CICS at your site.

How eLink TCP for TUXEDO Translates Data

Due to the way eLink TCP for TUXEDO on the remote BEA TUXEDO system translates and converts data, the CICS programmer does not need to do anything to prepare data that is destined for the remote BEA TUXEDO system.

The key to this high degree of transparency is the eLink TCP for TUXEDO configuration. It is through this mechanism that environmental differences, such as naming conventions and data formats, are concealed from programmers and programs.

Although all data is converted and translated automatically by the remote eLink TCP for TUXEDO gateway, the rules implemented are outlined in the following subsections to assist the CICS programmer in understanding how the data is manipulated. It is important for the CICS programmer to remember that this information is written from the point of view of the BEA TUXEDO environment.

When a client program on the remote BEA TUXEDO system sends data to (or receives data from) a service routine on a different model of computer, eLink TCP for TUXEDO automatically translates data as required. Translation involves changing the representation of intrinsic data types by changing attributes such as word length and byte order.

The following subsections describe the basic rules that eLink TCP for TUXEDO follows when it translates data and provide detailed information about how eLink TCP for TUXEDO handles string and numeric data.

BEA TUXEDO Terminology

The following are some commonly used BEA TUXEDO terms for buffer types:

STRING

A buffer of character data that is terminated by the first null character in the buffer. Typically, character string buffers undergo translation when sent to a system that is different from the sending system.

CARRAY

A CARRAY is a buffer of raw data that contains no terminating character and that undergoes no conversion or translation; the data is sent from one system to another without modification.A CARRAY is an exemplary buffer type for a graphics file.

VIEW

A VIEW buffer is a collection of field definitions that can be treated as a single entity. It is comparable to a record layout in COBOL or a structure in C.

FML

FML (Fielded Manipulation Language) buffers are variable length, dynamic, self-describing buffers. Each field in the buffer has its own descriptive header. In BEA TUXEDO, FML buffers can be tied closely to VIEW buffers so that conversion from one

The following table lists the data translation rules that BEA eLink TCP for TUXEDO follows:

Note: BEA TUXEDO provides a field type named dec_t that supports decimal values within VIEWs. BEA eLink TCP for TUXEDO translates these fields into machine independent representations of packed decimals. For example, dec_t(m,n) becomes S9(2*m-(n+1))V9(n) COMP-3. Therefore, a decimal field with a size of 8,5 corresponds to S9(10)V9(5) COMP-3.

The following table summarizes the translation rules between C and IBM/310 data types.

Strings and Numeric Data: A Closer Look

This subsection provides suggestions that will help you develop VIEW definitions for input and output buffers and records. It also explains how string data and numeric data are treated in the eLink TCP for TUXEDO environment.

Including NULL Characters in String Length Calculations

When you create VIEW definitions for input and output records that are used by CICS applications, do not specify an extra position for the terminating NULL characters that are used in string fields.

For example, when a CICS application program expects 10 characters in an input record, specify 10 for that field, not 10 plus 1.

Note: Although eLink TCP for TUXEDO does not require strings to be NULL-terminated, it respects NULL termination. Therefore, when BEA eLink TCP for TUXEDO detects a NULL (zero) character within a string, it does not process any subsequent characters. To pass full 8-bit data that contains embedded NULL values, use a CARRAY type field or buffer.

The character set translations performed by eLink TCP for TUXEDO can be fully localized, in accordance with the X/Open XPG Portability Guides. ASCII and EBCDIC translations are loadable from message files. BEA eLink TCP for TUXEDO contains default behaviors which should meet the requirements of most English-language applications. However, you may find it necessary to customize tables. See the BEA eLink TCP for TUXEDO User Guide for complete instructions.

Converting Numeric Data

You can convert numeric data into different data types easily, provided that you have enough range in the intermediate and destination types to handle the maximum value you need to represent.

For example, you can convert an FML field of double into a packed decimal field on the remote target system by specifying an appropriate dec_t type VIEW element.

In addition, you can convert numeric values into strings (and the reverse). For example, while FML buffers do not directly support the dec_t type, you can place decimal values in string fields and map these to dec_t fields within VIEW definitions.