Distributed transaction programming is needed because of the possible costs of other intercommunication functions (see Limitations of function shipping) and because of its own advantages (see Advantages of distributed transaction programming).
Function shipping gives you access to remote resources, and transaction routing lets a terminal communicate with remote transactions. From a functional point of view, these two facilities are probably sufficient for most intercommunication needs. However, design criteria go beyond pure function. Machine loading, response time, continuity of service, line traffic, and economic use of all resources are factors that affect transaction design.
The following two examples describe cases where function shipping is an obvious but not ideal solution.
You are browsing a remote file to select a record that satisfies some criteria.
Use function shipping. CICS® ships each GETNEXT request across the link, and the mirror reads the record and ships it back to the requester.
There are two network data flows per record; the data flow can be quite significant. For a browse on a large file, the overhead can be unacceptably high.
Use distributed program link. CICS links to a program that is running in the system that owns the file.
Use a DTP conversation. The local transaction sends the selection criteria. The remote transaction returns the keys and relevant fields from the selected records. This drastically reduces both the number of flows and the amount of data sent over the link.
A supermarket chain has many branches, which are served by several distribution centers, each stocking a different range of goods. Local stock records at the branches are updated online from point-of-sale terminals. Sales information has to be sorted for the separate distribution centers, and transmitted to them to enable reordering and distribution.
Use function shipping to write each reorder record to a remote file as it arises. This method is simple, but has several drawbacks:
Each sales transaction writes its reorder records to a transient data queue, and continues its conversation with the terminal.
Restocking requests are not urgent, so sorting and sending the data is delayed until an off-peak period. Alternatively, the transient data queue can 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.
The sender transaction can use function shipping to transmit the reorder records. After the sort process, each record is written to a remote file in the relevant remote system.
This method is not ideal either. The sender transaction must wait after writing each record to make sure that it gets the right response. Apart from using the link inefficiently, waiting between records makes the whole process very slow.
Using distributed transaction programming, a transaction in the branch:
Each distribution center then processes the reorder records like any other local file. This solution is a much more efficient use of the link.
In a multisystem environment, data transfers between systems are necessary because end users need access to remote resources. In managing these resources, network resources are used. But performance suffers if the network is used excessively. There is, therefore, a performance gain if application design places the processing associated with a resource in the resource-owning region.
DTP (like asynchronous processing and distributed program link) lets you process data at the point where it arises, instead of overworking network resources by assembling it at a central processing point. However, DTP is much more flexible than either asynchronous processing or DPL. For example, it: