Differences between the distributed and dynamic routing interfaces

The distributed routing interface differs from the dynamic routing interface in several significant respects.

If you have previously written a dynamic routing program, and are about to write a distributed routing program, bear in mind that:
  1. The dynamic routing program and the distributed routing program are invoked if the resource (the transaction or program) is defined as DYNAMIC(YES). The exception is for BTS activities that are run asynchronously, for which the distributed routing program is invoked even if the associated transaction is defined as DYNAMIC(NO). In this situation, the distributed routing program cannot route the request, but it can monitor the effect of the request on workloads, or perform other activities. What this means is that the distributed routing program is better able to monitor the effect of statically-routed requests on the relative workloads of the target regions.
  2. Because the dynamic routing program uses the hierarchical “hub” routing model—one routing program controls access to resources on several target regions—the routing program that is invoked at termination of a routed request is the same program that was invoked for route selection.

    The distributed routing program, on the other hand, uses the distributed model, which is a peer-to-peer system; the routing program itself is distributed. The routing program that is invoked at initiation, termination, or abend of a routed transaction is not the same program that was invoked for route selection—it is the routing program on the target region.

    Because the dynamic routing program is invoked only on the routing region, the order of its invocations is strictly defined:
    1. Route selection or notification
    2. Route selection error (if appropriate, and possibly repeated)
    3. Transaction termination or abend (if requested).

  3. For a single request, the user area passed to each invocation of the dynamic routing program is the same piece of storage; any modifications made to the user area on one invocation are retained and passed to the next invocation.

    The distributed routing program, on the other hand, may be invoked on the target region as well as on the routing region; because of this, the order of its invocations is less strictly defined. For example, the final invocation on the routing region (for “routing attempt complete”) may occur before or after the first invocation on the target region (for “transaction initiation”). To cope with this uncertainty, the user area passed to the distributed routing program on its first invocation on the target region is a copy of the user area on the routing region. This means that any modifications to the user area made on the target region have no effect on the user area in the routing region. For more details, see the description of the DYRUSER field in Parameters passed to the distributed routing program.

  4. The distributed routing program is invoked at more points than the dynamic routing program. When the distributed routing program is invoked explains the points at which the distributed routing program is invoked, and the region on which each invocation occurs.
  5. Unlike the dynamic routing program, the distributed routing program cannot:
    • Select a target region by supplying a netname (any value set in the DYRNETNM field of the communications area is ignored). The target must be specified by its CICS system identifier (sysid).
    • Change the remote transaction name passed to the target region. (Any value set in the DYRTRAN field of the communications area is ignored.)
    • Change the initial program associated with a routed request. (Any value set in the DYRLPROG field of the communications area is ignored).
    • Choose that the request is not to be queued if there are no MRO sessions to the target region. (The DYRQUEUE field of the communications area is always set to 'Y'.)
    • Modify the routed application's communications area. (The routing program is not passed the address of the routed application's communications area in field DYRACMAA.)
    • Pass the dispatch priority of the transaction to the target region. (The DYRRTPRI field of the communications area is always set to 'N'.)

    These restrictions are documented more fully in the descriptions of the relevant fields in the DFHDYPDS communications area.