Dynamically routing DPL requests

Dynamic routing means that the location of the server program is decided at run-time, rather than at design time. DPL requests for a particular remote program may be routed to different server regions. For example, if you have several cloned application-owning regions, you may want to use dynamic routing to balance the workload across the regions.

Dynamic routing models:

Dynamic routing of DPL requests received from outside CICS® uses the “hub” routing model described in The hub model.

Dynamic routing of CICS-to-CICS DPL requests uses the distributed routing model described in The distributed model. Note, however, that it is the dynamic routing program, not the distributed routing program, that is invoked for routing CICS-to-CICS DPL requests.

For eligible DPL requests, a user-replaceable program called the dynamic routing program is invoked. (This is the same dynamic routing program that is invoked for transactions defined as DYNAMIC—see Dynamic transaction routing.) The routing program selects the server region to which the program-link request is shipped.

The default dynamic routing program, supplied with CICS, is named DFHDYP. You can modify the supplied program, or replace it with one that you write yourself. You can also use the DTRPGM system initialization parameter to specify the name of the program that is invoked for dynamic routing, if you want to name your program something other than DFHDYP. For programming information about user-replaceable programs in general, and about the dynamic routing program in particular, see Writing a dynamic routing program.

If you are using a threadsafe program that makes DPL requests that are transmitted to another region using IPIC communication, you might benefit from improved performance by changing your dynamic routing program to be coded to threadsafe standards.

You can review the value of the CONCURRENCY attribute in the PROGRAM resource definition for your dynamic routing program. If the program is not defined as threadsafe, each use of the program causes a switch back to the QR TCB, incurring an additional cost. If the program is defined as threadsafe but uses non-threadsafe CICS commands (which is permitted), each non-threadsafe command causes a switch back to the QR TCB and incurs the additional cost. For more information about threadsafe programs, see Threadsafe programs.

In the server region to which the program-link request is shipped, the mirror transaction is invoked in the way described for static routing.