Message flow using transaction pipes

The flow control of transactions is handled by the client.

The client dynamically binds flow-control parameters to the transaction by querying the transaction attributes in the server. Transaction pipes are not usually associated with flow control (except for synchronized transaction pipes using half-duplex processing).

The following figure shows the basic message flow between a client and a server, using the z/OS® cross-system coupling facility (XCF). The order of processing is:

  1. The client sends a transaction as input to the server (IMS).
  2. The server returns transaction output messages to the client.
Figure 1. Basic transaction-pipe message flow
Workstation client is at left. Transaction labeled 1 is sent through XCF to server. Response labeled 2 is sent back through XCF to client.

Within the server, the input transaction and the output messages are organized and synchronized using IMS queues, as shown in the following figure. The figure illustrates a commit-then-send transaction flow for a non-Fast Path environment.

The order of processing is:

  1. The client sends a transaction to the server, and the server enqueues the transaction on a message queue.
  2. The transaction is submitted to an application program for processing.
  3. The application program prepares any output for the transaction and commits the output during sync-point processing.
  4. The output is returned to the client.
Figure 2. Use of queues in the transaction-pipe message flow
There is no additional descriptive information for this figure. The flow is described in the list that precedes the figure.

In a full-duplex environment, transactions and output messages are being sent and processed in parallel, as shown in the following figure. This parallelism can be maximized by creating a process for every transaction and output message. The order of processing is:

  1. The client sends a transaction (Tran 1) to the server, and the server's transaction pipe enqueues the transaction.
  2. The transaction (Tran 1) is submitted to an application program for processing.
  3. The application program enqueues any output (Message 1) for the transaction (Tran 1).
  4. The client sends a second transaction (Tran 2) to the server and the server's transaction pipe enqueues the transaction.
  5. The second transaction (Tran 2) is submitted to an application program for processing.
  6. The output (Message 1) for Tran 1 is returned to the client.
  7. The application program enqueues the output (Message 2) for the second transaction (Tran 2).
  8. The output (Message 2) for Tran 2 is returned to the client.
Figure 3. Transaction-pipe flow in full-duplex environment
There is no additional descriptive information for this figure. The flow is described in the list that precedes the figure.

Q:  Does specifying a transaction pipe as synchronized make the communication flow half-duplex?

A:  No. Transaction pipes are always full-duplex.

Whether the communication flow is actually half-duplex depends on the client. For a synchronized transaction pipe, IMS processes all output messages in the order received. No new messages are sent for the transaction until IMS has received an ACK message for the previous message. A NAK message causes IMS to halt all output processing for that transaction.

While this output processing is taking place, the client could be sending new input transaction messages to IMS on that synchronized transaction pipe. If the client coordinates the sending of transactions with the receipt of IMS output, the client can effect half-duplex processing.