As shown in Figure 2‑1, the TMA TCP for IMS gateway serves as the interface between IMS and remote Oracle Tuxedo Mainframe Adapter gateways via TCP/IP.Figure 2‑1 IMS ProcessingThe gateway “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 can present requests for service.As shown in Figure 2‑2, when a request is received from a remote system, it is relayed to IMS which 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. If the TMA TCP gateway is running as an OTMA client, the response is queued to the transaction pipe and delivered to the client through the cross-system coupling facility (XCF). The response is returned to the remote system over the TCP/IP connection.Figure 2‑2 IMS Inbound ProcessingThe TMA TCP for IMS product can also initiate TCP/IP connections with remote systems. These outbound sessions are used to send IMS client requests to remote systems for processing.As shown in Figure 2‑3, an IMS client transaction initiates a request by placing a properly formatted message into the IMS message queue. When running the gateway, two IMS user exits must be installed to route messages to the OTMA client. (For more information about request/response processing, refer to the “Programming Oracle TMA TCP for IMS” section, and for sample user exits, refer to the “Sample JCL and User Exits” section.) The gateway 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 returned to IMS for delivery to a transaction that processes the response.Figure 2‑3 IMS Outbound Processing
1. The gateway (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 gateway immediately terminates; any messages are written to a SYSOUT dataset by default.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.
1. When TMA TCP for IMS receives a request from a remote system, a request message is formatted and is 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).
4. If a response is required, the server transaction formats a response message and inserts it into the IMS message queue, destined for the TMA TCP for IMS gateway.An IMS client request, also referred to as an outbound request (relative to IMS), is a request issued by an IMS application message processing program (MPP) for a service provided by a remote system.
1.
2. A corresponding response phase wherein the response is processed during the execution of a second transaction (T2).
2. Once the request has been inserted into the Message Queue, the requester is effectively “decoupled” from the request; that is, processing of the request by TMA 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 is scheduled by TMA TCP for IMS to process the response to the request.
6. If a response is required, TMA 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.Normal termination is initiated when a system operator issues the SHUTDOWN command. In response to a SHUTDOWN command, TMA TCP for IMS performs the following tasks.
Note: