Using transaction pipes with OTMA
An IMS transaction represents a request for IMS to do some work. Many transactions also require a response after IMS has completed the work. So, each transaction has a source (the requester) and often a destination (for the response).
IMS uses the concept of a logical terminal (LTERM) to ensure that responses are associated with the correct requesters. An LTERM uses a queue where the transaction output is kept before it is returned to the requester.
Definition: A transaction pipe (tpipe) is a logical connection between a client and the server. It is analogous to an IMS logical terminal (LTERM). For each LTERM, IMS maintains a connection between the queue and the physical node that receives the output. OTMA does not use an LTERM but still must maintain a connection between the client and IMS. This connection is the transaction pipe, or tpipe.
Transaction pipes enable a client to associate its transactions with a transaction-pipe name. IMS uses the transaction-pipe name to associate all input and output with a particular client. The association between the transaction output and its ultimate destination (for example, a user at a terminal or a printer) is not made within IMS (as is the case with LTERMs), but is the responsibility of the client.
By using a transaction pipe, IMS does not know anything about the actual user of the transaction, often a user of the client application. Because IMS does not know anything about the actual user, the client has complete control over the output of transactions.
- Flexibility
Many transaction outputs can flow through the same transaction pipe.
- Performance
Transaction pipes give the client the ability to specify and distinguish transactions based on their message-flow control and synchronization.
- Resynchronization between a client and IMS
Transaction pipes can be either synchronized or non-synchronized. For a synchronized transaction pipe, all output messages are serialized through a single process, and sequence numbers can be assigned to messages. By logging these serialized messages, IMS and the client can resynchronize in the event of an outage.
No resynchronization is required for a non-synchronized transaction pipe.
- Object orientation
A transaction can be thought of as an object because OTMA keeps the transaction message information (such as user data and transaction-pipe name) within the message.
- Commit-then-send messages are queued on the tpipe or the tpipe hold queue.
- The tpipe is stopped.
- A trace is set on the tpipe.
- The tpipe is a synchronized tpipe, such as a tpipe used by MQSeries® for commit-then-send input transactions.
- The tpipe is in a WAIT state for a resume tpipe request that specified either the AUTO or the SINGLE-WAIT options.
The tpipe is in an MCP state, which indicates that
the tpipe is running in a shared queues environment and might have output messages on the global
queue. Tip: If no messages are queued to the TPIPE but the MCP status is displayed for the TPIPE so that the tpipe cannot be removed, issue the/DISPLAY TMEMBER tmembername TPIPE tpipename QCNTcommand or the/DISPLAY TMEMBER tmembername QCNTcommand to reset the MCP status.
- The tpipe is being scanned by IMS.
You can use the /DISPLAY
TMEMBER TPIPE command to see whether a tpipe cannot be removed by IMS because one of the circumstances in the preceding list is
true for the tpipe.
The following figure illustrates how transaction pipes fit in an OTMA client/server environment. As shown in the figure, transaction-pipe structures reside in the OTMA layer only for the server. z/OS® cross-system coupling facility, which resides in the transport layer, can be thought of as an interprocess communication layer, because it provides communication between the client process and the server process.
