Advantages over function shipping and transaction routing

Distributed transaction processing has advantages over function shipping and transaction routing.

Function shipping gives access to remote resources, and transaction routing lets a terminal communicate with remote transactions. These two facilities might appear sufficient for all your intercommunication needs, especially from a functional perspective. However, you must consider other design criteria, for example, machine loading, response time, continuity of service, and economic use of resources.

Consider the example of a supermarket chain. It has many branches that each stock a different range of goods, which are served by several distribution centers. Local stock records at the branches are updated online from point-of-sale terminals. Sales information must be sorted for the separate distribution centers, and transmitted to them to enable reordering and distribution.

An analyst might consider using function shipping to write each reorder record to a remote file as it arises. This method has simplicity, but must be rejected for several reasons:
  • Data is transmitted to the remote systems irregularly in small packets. This means inefficient use of the links.
  • The transactions associated with the point-of-sale devices are competing for sessions with the remote systems. This could mean unacceptable delays at point-of-sale.
  • Failure of a link results in a catastrophic suspension of operations at a branch.
  • Intensive intercommunication activity (for example, at peak periods) causes reduction in performance at the terminals.

Now consider the solution where each sales transaction writes its reorder records to a transient data queue. The data is quickly disposed of, leaving the transaction to carry on its conversation with the terminal.

Restocking requests are seldom urgent, so it might be possible to delay the sorting and sending of the data until an off-peak period. Alternatively, the transient data queue could be set to trigger the sender transaction when a predefined data level is reached. Either way, the sender transaction has the same job to do.

Again, it is tempting to use function shipping to transmit the reorder records. After the sort process, each record could be written to a remote file in the relevant remote system. However, this method is still not ideal. The sender transaction would have to wait after writing each record to make sure that it got the correct response. Apart from using the link inefficiently, waiting between records would make the whole process impossibly slow. You can use distributed transaction processing to solve this problem, and others.

The flexibility of DTP can, in some circumstances, be used to achieve improved performance over function shipping. Consider browsing a remote file to select a record that satisfies some criteria. If you use function shipping, CICS® ships the GETNEXT request across the link, and lets the mirror perform the operation and ship the record back to the requester. This is a lot of activity (two flows on the network) and the data flow can be significant. If the browse is on a large file, the overhead can be unacceptably high.

One alternative is to write a DTP conversation that ships the selection criteria, and returns only the keys and relevant fields from the selected records. This reduces both the number of flows and the amount of data sent over the link, thus reducing the overhead incurred in the function-shipping case.