Chapter 2 . Understanding How BEA Connect TCP for CICS Works

To understand how Connect TCP for CICS works, you should know how the product performs the following functions:

• Initializes during the start-up procedure

• Communicates with the Connect TPS Gateway

• Handles service shut downs

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

How the Connect TCP for CICS Handler Is Initialized

The very first service request that is sent from the Connect TPS Gateway running on a remote BEA TUXEDO node causes the following to occur:

1. CICS Sockets Listener starts the Connect 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 Connect TPS Gateway using TCP/IP

1. The Connect TCP Handler receives the request from the remote Connect TPS 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. The Handler issues a CICS LINK command to execute the transaction code specified in the Connect 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.

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

4. The Handler transmits the response to the remote Connect TPS Gateway.

5. The Handler stays connected to the remote Gateway awaiting another service request.

For tpacall/TPNOREPLY requests the same scenario applies. However, the remote program is invoked by a CICS START TRAN command and no data is returned to the original caller.

How the Connect TCP for CICS Handler Shuts Down

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.

How Connect TCP for CICS Processes CICS Originated Service Requests

1. The CICS client program (your program) issues an EXEC CICS LINK command to the BEA Connect 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 Chapter 5, "Administering BEA Connect 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 Connect TCP for CICS at your site.