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.
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.
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 the CICS Customization Guide.
In the server region to which the program-link request is shipped, the mirror transaction is invoked in the way described for static routing.
For a program-link request to be eligible for dynamic routing, the remote program must either:
For further information about autoinstalling programs invoked by EXEC CICS LINK commands, see When definitions of remote server programs aren’t required.
As well as "traditional" CICS-to-CICS DPL calls instigated by EXEC CICS LINK PROGRAM commands, program-link requests received from outside CICS can also be dynamically routed. For example, all of the following types of program-link request can be dynamically routed:
A program-link request received from outside CICS can be dynamically routed by:
For eligible program-link requests, 9 the dynamic routing program is invoked at the following points:
In this case, specifying the target region explicitly takes precedence over any SYSID returned by the dynamic routing program.
If you use the CICSPlex® System Manager (CICSPlex SM) product to manage your CICSplex, you may not need to write your own dynamic routing program. CICSPlex SM provides a dynamic routing program that supports both workload balancing and workload separation. All you have to do is to tell CICSPlex SM, through its user interface, which regions in the CICSplex can participate in dynamic routing.
Using CICSPlex SM, you could integrate workload balancing for program-link requests with that for terminal-initiated transactions.
For introductory information about CICSPlex SM, see the CICSPlex SM Concepts and Planning manual.
A transaction identifier is always associated with each dynamic program-link request. CICS obtains the transaction ID using the following sequence:
If you write your own dynamic routing program, perhaps based on DFHDYP, the transaction ID associated with the request may not be significant--you could, for example, code your program to route requests based simply on program name and available AORs.
However, if you use CICSPlex SM to route your program-link
requests, the transaction ID becomes much more significant, because CICSPlex SM’s routing logic is transaction-based. CICSPlex SM routes each DPL
request according to the rules for its associated transaction as specified
in the Transaction Group (TRANGRP), Workload Management Definition
(WLMDEF) and Workload Management Specification (WLMSPEC) resource
tables.