[Top] [Previous] [Next] [End of Book]

Chapter 2 . Understanding How BEA Connect TCP for IMS Works

Overview of Operations

This chapter contains the following information to help you understand how BEA Connect TCP for IMS works:

Inbound Processing

BEA Connect TCP for IMS runs as an ordinary transaction-oriented BMP and serves as the interface between IMS (via the IMS Message Queue) and remote BEA Connect gateways (via TCP/IP).

The BMP "listens" for incoming TCP/IP connection requests from remote gateways. When a request is received, an inbound session is established over which the remote gateway may present requests for service.

When a request is received from a remote system, it is relayed to IMS (via the IMS Message Queue) and IMS schedules the appropriate Server Transaction to process the request. If a response is required, the Server Transaction places the response in the IMS Message Queue for the BMP. The BMP retrieves the response from the Message Queue and returns it to the remote system over the TCP/IP connection.

Figure 2-1 IMS Inbound Processing

Outbound Processing

BEA Connect TCP for IMS can also initiate TCP/IP connections with remote systems. These outbound sessions are used to send IMS Client requests to remote systems for processing.

An IMS Client Transaction initiates a request by placing a properly formatted message into the IMS Message Queue for the BMP. The BMP retrieves the request and forwards it to the appropriate remote system for processing. When the response (if required) is received from the remote system, it is placed into the IMS Message Queue for delivery to a transaction that will process the response.

Figure 2-2 IMS Outbound Processing

How BEA Connect TCP for IMS Is Initialized

BEA Connect TCP for IMS is an ordinary IMS BMP that is started by submitting the appropriate JCL (or as a started task) for a batch job. The following activities then occur.

  1. The BMP (load module name, BEATCPI) opens a Message Log (normally allocated to a disk dataset) into which all messages issued during the course of execution are written.

  2. If the Message Log cannot be opened, the BMP immediately terminates; any messages are written to a sysout dataset by default.

  3. The BMP obtains configuration information from a sequential dataset containing text statements. These statements define the operating environment for BEA Connect TCP for IMS, including the definitions of local and remote gateways. If any errors are detected during configuration, the BMP immediately terminates.

Processing IMS Server Requests

What Is an IMS Server Request?

An IMS server request, also referred to as an inbound request (relative to IMS), is a request issued by a remote client for a service provided by an IMS server transaction.

How BEA Connect TCP for IMS Processes an IMS Server Request

  1. When BEA Connect TCP for IMS receives a request from a remote system, a request message is formatted and inserted into the IMS Message Queue, destined for the specified IMS server transaction (the service name for the request corresponds to the transaction code of the IMS server transaction that handles the request).

  2. IMS schedules the specified server transaction to process the request message.

  3. The server transaction retrieves the request message from the IMS Message Queue and performs the indicated processing.

  4. If a response is required, the server transaction formats a response message and inserts it into the IMS Message Queue, destined for the BEA Connect TCP for IMS BMP.

  5. The BEA Connect TCP for IMS BMP retrieves the response message from the IMS Message Queue and returns it to the requesting remote system via the TCP/IP connection.

Processing IMS Client Requests

What Is an IMS Client Request?

An IMS client request, also referred to as an outbound request (relative to IMS), is a request issued by an IMS application transaction (MPP) for a service provided by a remote system.

Two Phases of an IMS Client Request

Because of the design philosophy of IMS, processing of an IMS client request occurs in two distinct "phases":

Transactions T1 and T2 may in fact be the same transaction (with appropriate logic to perform the required request or response processing, based on execution context). The point is that T1 and T2 must be two distinct transaction executions. This is necessary because T1 can only initiate a request; it cannot "wait" on the response to that request because the architecture and design philosophy of IMS do not permit this.

How BEA Connect TCP for IMS Processes an IMS Client Request

  1. An IMS transaction issues a client request by inserting a properly-formatted message into the IMS Message Queue specifying the BEA Connect TCP for IMS BMP as the destination.

  2. Once the request has been inserted into the BMP's Message Queue, the requester is effectively "de-coupled" from the request; that is, processing of the request by BEA Connect TCP for IMS proceeds asynchronously with respect to execution of the requesting transaction. The request includes the name (transaction code) of a response transaction that will be scheduled by BEA Connect TCP for IMS to process the response to the request.

  3. The BEA Connect TCP for IMS BMP retrieves the request from the IMS Message Queue and validates it for proper format. If any errors are detected, the specified response transaction is immediately scheduled with appropriate return codes.

  4. The requested service name is located in the directory of services offered by remote systems to which BEA Connect TCP for IMS has access. If the requested service cannot be found, or the required remote gateway is currently inaccessible, an error is recognized and the response transaction is immediately scheduled with appropriate return codes.

  5. If a remote service provider is successfully identified for the request, an outbound session is established with the remote system (if one does not already exist) and the request is sent to the remote system for processing.

  6. If no response is required, the response transaction is scheduled as soon as the request has been sent to the remote system for processing. If a response is required, BEA Connect TCP for IMS schedules the response transaction (with any response data) when the response is received.

  7. Eventually, if no response is received from the remote system, the request times out, an error is recognized, and the response transaction is scheduled with appropriate return codes.

How BEA Connect TCP for IMS Shuts Down

Once started, BEA Connect TCP for IMS normally executes as a non-ending job, servicing inbound requests from remote systems and outbound requests originated by IMS client transactions.

Normal termination is initiated when a system operator issues the SHUTDOWN command. In response to a SHUTDOWN command, BEA Connect TCP for IMS:


[Top] [Previous] [Next] [End of Book]